Skoti

Nie rozumiem czego nie rozumiesz... napisałeś: I pytam się skąd masz liczbę 4x (poza tym, że wiem, że z sufitu). Wróżenie z fusów to można uprawiać kiedy nie ma danych, a wszystkie dane mamy (trzeba tylko je rozumieć i poznać architekturę i aplikacje od środka). Nowy toolkit tu zupełnie nic nie zmieni (pomijając to, że poprawki w nim poprawią działanie w równym stopniu fermi co kepler (oraz to, że nowy toolkit już jakiś czas jest) to wydajność nie ulegnie znacznej zmianie - architektura pozostanie ta sama... nowy toolkit to mniej więcej w porównaniu do samochodu i roweru to wymiana obu kierowców na szybszych). Różnicy wydajności też nie widzisz mimo 2x wyższej ceny, a względem 580 zobaczysz nawet spadek wydajności... za który musisz sporo dopłacić. 680 jest fajną kartą, ale do gier - tu jest wątek o GPGPU, a tu nie jest najlepszą kartą od Nvidii i 580 będzie wydajniejsze w tym zastosowaniu (przy znacznie niższej cenie), więc głupotą do takiego zastosowania polecać karty które w GPGPU są słabe, ale za to w innych zastosowaniach są dobre. Jeśli ktoś chce wydać więcej kasy to i tak lepiej polecić 590 (tylko trzeba pamiętać, że ilość pamięci podawanej trzeba podzielić przez 2x i program musi obsługiwać multiGPU) i ta karta rozłoży wszystkie inne na łopatki.

Wiem tylko pytam skąd Ci się wzięło to 4x, bo na pewno nie z ilości rdzeni (3x), a z uwzględnieniem częstotliwości to nawet nie 2x. Rdzenie mają taką samą wydajność jak rdzenie stream AMD czyli 2 operacje na cykl zegara (mnożenie i dodawanie na raz) - lepsze wykorzystanie tych rdzeni za to było zasługą dużej ilości małych SIMT (w poprzednich seriach Nvidia miała SIMT wielkości 16, a AMD 80 i 64). Większa ilość SIMT zwiększa znacznie ilość tranzystorów i pobór energii, m.in. dla tego teraz karty AMD pobierają więcej energii niż poprzednie serie (pamiętając, że jest różnica w procesie technologicznym), a karty Nvidii mniej. Nie wiem jak ty ale ja wiem jak wypadnie w VRay RT (to tak jakbyś mówił, że nie wiesz czym dojedziesz szybciej rowerem czy samochodem 100km znając same ich teoretyczne możliwości (i pokazywanie testów które nie mają nic do rzeczy jak test gdzie jest w mieście w korku nic nie zmieniają, jeśli interesuje nas konkretny typ zadania)). Profity ładnie pomnożyłeś, ale wszystko to wynik jednego: jest nowa architektura (zmniejszająca stosunek SIMT do ilości rdzeni) dzięki czemu zmniejsza się ilość tranzystorów zajmujących się zarządzaniem rdzeniami i wątkami (czyli nie bezpośrednio wpływające na teoretyczną wydajność, ale mające kluczową rolę w realnych wynikach) - nowa architektura to zarówno profit (zmniejszenie poboru energii) jak i zmniejszenie wydajności w GPGPU. Jeśli patrzysz na symulacje softbody czy fluidów to jak najbardziej masz rację bo to są algorytmy dla SIMT bardzo przyjazne. Ja mówiłem jednak o fizyce brył sztywnych (rigid body), które z architekturą SIMT się nie lubi (nie bez powodu softbody i fluidy przez lata w PhysX były na GPU, podczas gdy rigid body robione były na CPU, bo było to szybsze niż na GPU - dopiero niedawno (jeśli dobrze pamiętam ~rok temu PhysX doczekał się implementacji na GPU gdzie 580 już radził sobie kilkukrotnie lepiej niż CPU)). Wszystko zależy od oprogramowania - a dokładniej to od algorytmów. Jednak renderery GPGPU to nie rasteryzatory tylko raytracery i tu nie ma opcji - z 680 nie będą się tak lubić jak z 580 - takie to oprogramowanie i w taki, a nie inny sposób musi korzystać z GPU.

Piszesz, że ilość rdzeni sugeruje 4x większą wydajność, więc pytam się po prostu skąd to wiozłeś Akurat Vray RT działa na radeonach co zresztą sugerują sami twórcy pisząc, że powinien działać na kartach AMD, ale nie jest to dobrze przetestowane i że aktualnie implementacje w sterownikach są na tyle dojrzałe, aby używać ich z pewnością jest w sterownikach Nvidii. Dlatego też nie radzę kupować radeonów, bo mimo dobrego sprzętu sterowniki ssą i do czasu ich poprawienia (zarówno OpenCL i OpenGL) nie są realną opcją. Nvidia w tej materii postawił na gry, a nie na quadro i teslę z Fermi. Słabsza od GTX560 nie jest - jest słabsza od tańszych pełnych Fermi czyli 580. Możesz napisać plusy? OFC tu nie ma co narzekać, tylko rozważyć opcje: 680 2GB (2k zł), 680 4GB (2.4k zł) 580 3GB (1.5k zł) - z tego wszystkiego najtańszy jest jednocześnie w renderingu najszybszy. 670 2GB (1.7k zł) 570 2.5GB (1.3k zł) i ten tańszy znowu jest lepszy. Jeśli uważasz, że większe znaczenie ma pamięć to dlaczego nie polecasz 7970? Są karty z 6GB pamięci, pamięci mają szerszą szynę i znacznie większą przepustowość (masz więcej i to szybszej pamięci). A dlaczego ja ich nie polecam? Bo sterowniki ssą i co z tego że jest sprzęt świetny jak sterowniki psują wszystko. Widać w GPGPU różnie wypada, bo są różne algorytmy i zadania - tworzenie hashy czy szybkiej transformacji Fouriera (test który pokazałeś, że wygląda ciekawie czyli DirectCompute & OpenCL Benchmark który robi FFT) jest tak szybkie jak maksymalna wydajność sprzętu (prosty liniowy kod jak w shaderach gier) i w takich testach 680 będzie szybszy, jednak tu nie jest wątek na forum kryptograficznym, żeby robić hashe sha/md5 na czas do łamania haseł czy też nikogo nie interesuje FFT, a raytracing, który jest dla kart graficznych dużo bardziej kłopotliwy (mniej więcej tak kłopotliwy jak silniki fizyki na GPU).

Tak - Nvidia jest lepsza zarówno w OpenGL jak i OpenCL (nowa seria AMD ma kuszącą arch, ale sterowniki ssą i poza DirectX w grach ciężko myśleć o tych kartach poważnie) i mają znacznie bardziej dopracowane sterowniki (ogólnie bardziej dbają o standardy Khronos Group, któremu przewodniczą i zarówno grupom rozwojowym OpenCL i OpenGL przewodniczy wiceprezes Nvidii, a Nvidia daje sterowniki w dniu wydania nowego standardu). OpenCL to nie syf tylko bardzo dobre API, problem w sterownikach AMD, które wywalają się przy bardziej skomplikowanym kodzie (nie potrafią go skompilować nawet jeśli jest 100% zgodny z OpenCL) - co nie oznacza, że OpenCL jest zły, bo kompilator Intela czy Nvidii nie ma takich problemów. Jednak jeśli chce się renderować na GPU (a ten wątek sugeruje, że tak jest) to lepiej wybrać kartę 580, która jest tańsza, niewiele mniej wydajna w viewporcie, a wydajniejsza w renderingu na GPGPU. Kepler będzie lepszy od 580, ale ten pełny (GK100 to pełny Kepler (ma wyjść w tym roku jeszcze), GK104 w 680 to odpowiednik GF104 stosowanego w 460/560, a nie GF100 z 480/580).

Nie przekręcaj nicku ;p. Teoria i praktyka to jedno i to samo, co najwyżej ktoś w teoretycznych obliczeniach może nie brać wszystkich danych (i mówić, że jest 2x wydajniejsze 680 ze względu na teoretyczną maksymalną wydajność osiąganą przez kartę). Ja GPU i ich dobre i złe strony znam dosyć dobrze programując je od kilkunastu lat (więc zarówno od strony teoretycznej i praktycznej). Tu się mylisz bardzo - to zupełnie inny sposób wyświetlania grafiki! W grach stosuje się rasteryzacje co bardzo pasuje arch SIMD, bo jest to zazwyczaj prosty liniowy kod przekształcający wierzchołki do przestrzeni ekranu (punkty mnożone po kolei przez macierze kości, macierz obiektu, macierz widoku i macierz projekcji), co jest wykonywane z maksymalną możliwą wydajnością karty (ewentualnie jest mały spadek mocy w wypadku jak programista gdzieś da jakąś instrukcję warunkową co jest bardzo rzadkie i dziwne ;p), później karta rasteryzuje to co wyszło z shadera wierzchołków i leci shader fragmentów - też zazwyczaj prosty liniowy kod bez instrukcji warunkowych, pętli etc (jeśli jest tu coś do sterowania to odbyło się zapewne na etapie kompilowania shadera przez dyrektywy preprocesora) dla każdego pixela - karty graficzne są idealnie skrojone pod rasteryzacje i nawet największe upakowanie SIMD nie jest dla nich przeszkodą, ale rasteryzacja ma wady, jak problematyczne i ciężkie obliczeniowo cienie, odbicia, kaustyki... i w zastosowaniu graficznym praktycznie odpada. Renderery GPGPU działają na zupełnie innej zasadzie, a dokładniej na podstawie raytracingu (jeszcze dokładniej na pochodnych pathtracingu, bipathtracingu z losowaniem próbek monte carlo, MLT czy jeszcze inne algorytmy). Tu nie można tak prosto i liniowo liczyć tu rzuca się promień i trzeba sprawdzać CZY przecina coś w drzewie obiektów (przykładowo QBVH), JEŚLI tak to sprawdza czy przecina się z daną siatką, JEŚLI tak to liczy materiał i JEŚLI odbija to odbić promień i śledzić dalej, JEŚLI załamuje to załamaś i śledzić dalej... To tylko mały wycinek z tego co musi sprawdzić i wszystko jest zależne od danych. Procesory w kartach grafiki mają arch SIMT czyli cała grupa procesorów dostaje JEDNĄ instrukcję na wiele wątków. Jeśli przynajmniej jeden procesor w grupie ma jakąś instrukcje do wykonania to reszta w tym czasie nic nie robi tylko czeka. Przykładowo mamy kod if( object.material.reflection ){ //20 instrukcji } else if( object.material.refraction ){ //30 instrukcji } i karta dostaje dane takie, że w grupie wątków (promieni) jeden trafił na obiekt odbijający, jeden na obiekt załamujący, a reszta w materiały bez odbić i załamań lub nie trafiło w żaden obiekt to karta to wykona tak: wszystkie procesory dostają 20 instrukcji dla obiektu odbijającego światło i je wykonują (tylko jeden zapisuje swoją pracę), później wszystkie dostają 30 instrukcji dla obiektu załamującego światło i czas wykonania pracy takiej grupy wątków to czas wykonania 50 instrukcji i zajęty w tym czasie czas grupy (16 w Fermi, 32 lub 64 (zależy gdzie trafi - średnio 48) w Kepler) podczas gdy przykładowo 62 procki się cały ten czas marnowały, jeden zrobił 20 instrukcji, drugi 30. Im większe są grupy SIMT tym więcej procesorów musi czekać, na inne zamiast pracować. Dla wydajności w rendererach GPGPU ważne jest jak najwięcej SIMT, jak najmniej procków w tych SIMT, podczas gdy w rasteryzacji dla gier jest wręcz przeciwnie, bo tu praktycznie nie stosuje się dynamicznej kontroli przepływu w kodzie i jest to praktycznie liniowy kod, który nie zablokuje żadnego procesora, bo wszystkie mają dokładnie to samo do policzenia, niezależnie od danych wejściowych i tu marnowanie tranzystorów i miejsca na więcej SIMT jest głupotą, podczas gdy najważniejsza jest ilość procesorów ;p. Podsumowując bardzo się mylisz mówiąc "Przeciez ten sam sposob wyswietlania grafiki", bo te sposoby nawet ze sobą nie mają nic wspólnego.

Nie muszę testować, żeby wiedzieć jak będzie się zachowywać karta w danych zadaniach, bo do tego wystarczą dokumenty dotyczące architektury kart i żadne fixy oprogramowania tu nie pomogą, bo to problem sprzętowy i gorszej dla GPGPU architektury sprzętu (lepszej do gier, ale nie do obliczeń). Ilość rdzeni CUDA to jest bardzo mała składowa wydajności całego układu. Swoją drogą zastanawia mnie skąd to 4x skoro jest 3x więcej rdzeni CUDA i do tego z niższą częstotliwością. 680 jest w najbardziej optymalnym przypadku 2x wydajniejsze od 580 (3.1 TFLOPS vs 1.6 TFLOPS), jednak tak to nie działa (no poza prostymi rzeczami jak generowanie hashy czy innych liniowych zadań, ale nie w fizyce czy rendererach) i znacznie ważniejsze od ilości rdzeni jest to jak są one ułożone i zarządzane i tu zaczynają się niekorzystne dla Keplera dane, które nie są tak marketingowo sprzedawane jak ilość rdzeni. Przykładowo strumieniowe multiprocesory (w których mieszczą się rdzenie CUDA) to 8 takich procków jest w 680... podczas gdy w 580 było ich 16, w Fermi te multiprocesory wykonywały zadania na 32 prockach w niezależnych grupach po 16 procków (jest to arch SIMT więc wydajność w pesymistycznym wypadku jest 1/16 wydajności gdy dane pozwalają tylko jednemu prockowi działać), w Keplerze multiprocesory działają na 192 prockach w grupach po 48 procków (przyjmijmy tak dla uproszczenia obliczeń bo tu podobnie jest do fermi z serii 460/560 i niżej czyli jeden wrap scheduler robi po 16, a drugi po 32, tylko w keplerze masz 32 i 64 czyli w najgorszym wypadku osiąga 1/48 wydajności). Rendering jest niestety bliski pesymistycznych danych dla SIMT i 680 ze względu na swoją architekturę w obliczeniach tego typu powinien być gorszy niż 580. Jeśli jednak nie uważasz, że architektura jest ważna, a liczy się liczba rdzeni to dlaczego nie poradziłeś kupić Radeon 5870? Ma więcej rdzeni niż 680 (1600 rdzeni), Teoretyczną wydajność ma trochę niższą ze względu na częstotliwości, ale i tak wyższą niż GTX670 (2.72 TFLOPS vs 2.46 TFLOPS) i jest dużo tańszy. A kogo tam obchodzi, że ma upakowane w SIMD 80 procków i wydajność w pesymistycznym wypadku spada 80cio krotnie i w renderingu średnia klasa Fermi bije je na głowe. OFC jakbyś polecił 7970 to nie miałbym się do czego przyczepić bo tu AMD zrobiło przeciwny krok i SIMD ma po 16 rdzeni czyli tak jak w Fermi (przez co ta seria dostała kopa w obliczeniach), a rdzeni masz 2048 przy teoretycznej mocy 3.8 TFLOPS - tu jednak problemem dalej są sterowniki. Kepler do gier się nadaje wyśmienicie, do mobilków będzie świetny, dla grafików czy do obliczeń to już nie najlepsza architektura (z tego powodu też nie widzisz opartych na Keplerze Tesla czy Quadro, bo to krok wstecz tu - nowe karty tu zobaczysz pod koniec roku jak wyjdzie pełny Kepler (780) i wydajność będzie trochę lepsza bo w pesymistycznym wypadku będzie to 1/32, ale za to podstawowa wydajność będzie już znacznie wyższa niż 580 i będzie już w obliczeniach od 580 w praktyce wydajniejsze (dopiero te karty oparte na pełnym keplerze GK100, a nie na GK104 jak 680 czy 670)).

@kokos6: Nadaje się o ile zmieszczą Ci się sceny w pamięci (1.2GB to nie wiele, i wielu osobom na tym forum nawet w 4GB się sceny by nie zmieściły, ale jeśli stosujesz niskie rozdzielczości tekstur i siatki nie masz w gigantycznych ilościach to może wystarczyć). Bardzo zła rada - Kepler to krok wstecz w GPGPU. Co z tego, że masz ponad 1.5k rdzeni CUDA, skoro są one: - 2x niżej taktowane, - jest więcej rdzeni na SIMD i ostatecznie w renderingu te 1500 rdzeni cuda z GF680 jest wolniejsze niż 512 z GF580. W serii 6xx Nvidii liczy się pobór energii (nic dziwnego, bo kepler to kolejny krok integracji kilku gałęzi - i teraz jeden projekt jest w obliczeniach (Tesla), zadaniach profesjonalnych (Quadro), dla graczy (GeForce) i na rynki mobilne (Tegra od planowanej na styczeń wersji 4, którego GPU ma zastąpić jeden SIMD Keplera)). Lepiej kupić 580, 570, 470 niż Keplera. W przeciwną drogę poszło AMD i zmniejszyło ilość rdzeni na SIMD i wydajność GPGPU w ich najnowszej serii poszła ostro do góry, ale tu odstraszają sterowniki OpenCL, które nie są najwyższej jakości, a wręcz spowalniają powstawanie aplikacji (przykładowo Cycles dla OpenCL ma od dawna możliwości wersji dla CUDA (na kartach Nvidii obie pełne implementacje działają), ale kompilator AMD ma problemy i co aktualizację sterowników AMD do Cycles dostaje nowe możliwości (zostaje odkomentowany kod od dawna już gotowy, tylko sterowniki AMD sobie z nim nie radziły)).

@mrys: są 2 podejścia do rozwoju oprogramowania: - robienie wszystkiego od podstaw w dobrze przemyślany sposób, - robienie wszystkiego na raz, nie myśląc o dobrym zaprojektowaniu. pierwszy sposób to mozolny początek, bez szybkich efektów, ale tępo nabiera rozpędu i rośnie wykładniczo (są solidne podstawy i dobrze zaprojektowany kod i zarządzanie nim to przyjemność), a drugi sposób daje duże efekty na początku, ale czym później tym wolniej i gorzej się rozwija lub wręcz rozwój jest niemożliwy (bo nikt nie wie gdzie co i jak, a wszędzie widać tylko zgliszcza). Z tego powodu ostatnio znacznie bardziej boję się o tępo rozwoju blendera niż gimpa. W rozwoju blendera coraz bardziej widać jednak, że widzą co się stało z kodem i zaczyna się przepisywanie (Brecht przyznał, że Blender Internal już nie da się rozwijać, bo kod jest tak napisany, że aby coś z rendererem zrobić trzeba napisać wszystko od nowa (Cycles), system zarządzania siatką też ssał i wreszcie po wielu latach wszedł bmesh... ale problemem jest to, że jeśli spojrzy się prawdzie w oczy to cały program jest do przepisania i do przeprojektowania (od viewportu po symulacje fizyki) i wszystkie nowe rzeczy z X ostatnich lat powinny iść do kosza i zamiast czekać na nowe możliwości użytkownicy będą czekać, aż będzie przepisane i odzyska dawne możliwości). GIMP wcześniej niż Blender wpadł na to, że trzeba całe jądro aplikacji przepisać i cofnąć się wstecz aby iść do przodu... jednak jeśli chodzi o tępo to blender wcale nie ma takiego tempa - przepisywanie blendera już trwa około 3 lata i do tej pory tak podstawowych narzędzi nie było jak bevel (który dalej nie działa jak powinien), dodatkowo mimo 3ch lat prac nad "nowym blenderem" w większości kod jest taki jaki był... nie wiem czy to tempo jest faktycznie takie szybkie (tempo wydań tak bo raz na 2 miesiące to szybko, ale nie rozwoju). PS. różnica pomiędzy będzie a jest... jest spora, tylko to już jest napisane, a zapewne będzie dotyczy udostępnienia (wsparcie dla GPU wyszło zaraz po zamknięciu listy nowinek w Gimpie i przyjmowane były tylko bugfixy do tego co się znajdzie z tego co pamiętam, dlatego wsparcie dla GPU opuściło to wydanie).

To dotyczące ostatnich wersji PS i przykład jest świetny, z tego względu, że GEGL przynosi naprawdę w Gimpie dużo usprawnień i cały kod jest odpowiedzialny za canvas i operacje na nim (łącznie z przekształceniami, filtrami, pędzlami) jest przenoszony do GEGL i jest wykorzystywane API GEGL przy pisaniu nowych narzędzi i filtrów. Dzięki takiemu wszystkie nowe narzędzia, zależą od implementacji GEGL... który już częściowo jest w wersji OpenCL (gsoc2011 w którym pomagało AMD) i można wykorzystać moc GPU (nie w najnowszej wersji, bo uznano, że jeszcze nie jest rozwiązanie na etapie wydania, ale w 2.8 RC1 można było testować ustawiając zmienną środowiskową GEGL_USE_OPENCL=yes) - OpenCL będzie zapewne oficjalnie w 2.10 lub 3.0. W przyszłości również dodanie CUDA czy innych nowych API to nie będzie przepisywanie wszystkiego, a napisanie backendu dla API, a wszystkie narzędzia będą bez zmian w kodzie (bo API się nie zmienia). GEGL wygląda na solidną dobrze zaprojektowaną robotę, która może dać gimpowi kopa takiego, że każde przyszłe zmiany będą wymagały przykładowo tygodni zamiast roku pracy (podobnie jak u Adobe, które ma przemyślaną i dobrze zaprojektowaną podstawę PS i jest na tyle elastyczna, że pozwala dalej się szybko rozwijać).

To nie jest olewanie windowsa co często jego brak i nieznajomość jego oraz jego narzędzi - i wbrew temu co mówisz blender ma podobne problemy. Problem polega na tym, że programiści OS zazwyczaj sami korzystają z systemu i narzędzi OS (Linux, Eclipse, GCC, Valgrind...), i Windows jest im bardziej obcy niż tobie Linux (przykładem mogę być ja, ostatnio dłużej niż kilka godzin na rok używający Windowsa na przełomie 1999/2000). Pod Windowsem, którego nie znają, muszą przebudować w Microsoft Visual Studio masę bibliotek, które się z nim gryzą, i całą aplikacje, oraz zrobić pakiet instalacyjny. To wszystko trwa - podobnie byłoby gdyby używali Windowsa i musieli robić na Linuksa. Blender jakiś czas temu miał podobny problem i szukali osoby, która będzie robić buildy na Windowsa, bo nikt się tego nie chciał podejmować. Obecnie jest osoba odpowiedzialna za buildy na Windowsa, ale nawet mimo to te buildy wychodzą 1-2 dni po linuksowych (jedyna różnica to to, że Blender nie ogłasza na stronie zanim nie będą gotowe wszystkie pakiety - czytaj użytkownicy Linuksa muszą czekać mimo gotowej wersji na wersję Blendera dla Windows). Problemem jest czas - kiedy pod linuksem wszystkie biblioteki ma bo używa ich, dodatkowo w każdej dystrybucji dostaje je w gotowej formie, to pod Windowsem musi je sam budować, często pod kompilatorem pod którym nie zadziałają (przykładowo kod jest kompatybilny z GCC i Mingw32 (GCC pod windowsa), ale kompilator Microsoftu już nie jest w stanie go skompilować (bo żaden kompilator nie wspiera dobrze standardów C/C++ i każdy w inny sposób, więc dobry kod w jednym nie działa w innym), a inna biblioteka znowu pod Windowsem zadziała tylko i wyłącznie z kompilatorem Microsoftu (kod wykrywa, że to _WIN32 i daje kod specyficzny dla kompilatora Microsoftu i nie zadziała z Mingw32)). Rozwiązywanie takich problemów i konfliktów bibliotek z różnymi kompilatorami w kodzie którego nie znasz i w narzędziach, których nie używasz, może potrwać (chociaż nie więcej niż właśnie kilka dni). Gry są wydawane na konsole pierwsze, bo to jest priorytet. Konsole przynoszą więcej zysku z gier i to jest fakt. Wymaganie, aby gry wychodziły równocześnie na Windowa i Konsole, lub nawet wcześniej na Windowsa, to mniej więcej tego typu wymaganie jak od firmy produkującej gry i zarabiającej na nich wymagać, aby równocześnie z Windowsem wychodziły wersje na MacOS i Linux, albo na nie wcześniej. Dodatkowo nie prawdą jest to co pisałeś o piractwie, bo konsole mimo wszystko mają mocniejsze zabezpieczenia, a ich łamanie nie jest takie łatwe i powszechne. Wydanie równocześnie jest niekorzystne bo: - Spowalnia wydanie na konsole... o czas w której robiona jest wersja na Windowsa, - Wydanie na Windowsa, który nie ma praktycznie żadnych zabezpieczeń antypirackich, zmniejsza zyski nawet z konsoli (bo gracze mają dylemat: kupić grę na konsolę, czy ściągnąć pirata na Windowsa).

Jednookienkowość jest zdecydowanie wygodniejsza... pod Windowsem ;p. Pod innymi systemami masz znacznie większe pole manewru z okienkami i możesz każde okno pinować, ustawiać zawsze na wierchu (aby się nie chowały), dowolnie przesuwać, grupować z dowolnymi innymi oknami i masz te okna jako karty w jednym oknie itp. Dzięki temu możesz ustawić sobie interface tak jak chcesz, ale jeśli nie ma dobrego zarządzania oknami w systemie, to wygodniejsze jest jedno okienko.

Split to według twórców gimpa najmniej ważna sprawa była i się z nią nie spieszyli, bo nie czuli się odpowiedzialni za to, że Windows nie potrafi dobrze zarządzać oknami. Photoshop też tylko w wersji dla Windowsa, jest jedookienkowy, a dla MacOS X jest wielookienkowy tak jak GIMP.

Jak się sprawdza wiemy z bmesha i regresji, których narobił, oraz z tego, że wszystko jest pisane wielokrotnie i narzędzia ze sobą nie współdziałają (przykładowo jedna symulacja fizyczna z drugą się nie dogada, bo jest robione to bez planu i oddzielnie - jeśli kiedyś ktoś będzie chciał zrobić, aby to działało dobrze będzie musiał wszystko co zostało napisane wyrzucić do kosza i pisać wszystko od zera). Tak i to nigdy nie są najważniejsze problemy, bo cele które są stawiane to specyficzne zastosowania potrzebne promilowi użytkowników i nad tymi usprawnieniami się pracuje, bo inne problemy które są prawdziwym bólem tyłka dla 100% użytkowników, graficy pracujący nad filmami w ramach BF nauczyli się omijać i potrafią zrobić wszystko bez nich (niewygodnie, powoli, irytująco, ale da się to wykonać, więc się nad tym nie pracuje). Ty widzisz szlifowanie projektów, a ja widzę brnięcie dalej w błędach projektowych do momentu, aż wszystko pierdolnie i trzeba będzie pisać wszystko od nowa, zamiast na początku dobrze przemyśleć koncepcje i elastyczność. Granty jeszcze tu nic nie zrobiły - były przeznaczone na projekty, które już istniały i dobrze się rozwijały bez nich, a nie widzę też przyspieszenia prac ze względu na grant (ale jak najbardziej to, że się wspiera różne inicjatywy jest ok). Problemem jest dla mnie brak dobrej bazy dla takich inicjatyw i przygotowanych podstaw. Przykładowo programiści core team powinni napisać system zarządzania przykładowo OpenCL i udostępnienie api wyższego poziomu i na podstawie tego budować inne projekty jak cycles, symulacje fizyczne, kompozycje, ale w blenderze jest zupełnie inaczej i nie ma takich podstaw wspólnych i każdy projekt sam robi to samo i później jeśli trzeba zrobić poprawki właśnie w tej podstawie to nikt rozsądny się za to nie chce brać, bo zamiast spójnego kodu są zgliszcza rozrzucona w wielu miejscach. Jason podął się zadania heroicznego i mam tylko nadzieję (czemu niektóre jego wypowiedzi przeczą), że wie co robi. Kod renderujący w OpenGL to właśnie zgliszcza braku zarządzania projektami i dbaniem o spójne podstawy, i wszystko jest rysowane w inny sposób i łatane przez innych ludzi różnymi dziwnymi sposobami i jedyne co da się dziś zrobić z tym to cały kod renderujący viewportów wywalić, zaprojektować jeden spójny renderer od nowa taki aby można było go rozwijać niezależnie od innych rzeczy i podpiąć wszystko do niego. Tego się właśnie podejmuje i dlatego pisze, że w przyszłości będzie można łatwiej rozwijać (nie będzie kod rozproszony, niespójny i niechlujny tylko wszystko trzeba napisać od nowa i uniezależnić od reszty kodu (co powinno być zrobione przy powstawaniu blendera, jeśli ktoś zajmowałby się projektowaniem, zamiast pisać na hura, bez planu i zarysowanej koncepcji)). To samo co dziś dotyczy kodu OpenGL w przyszłości czeka fizykę, akcelerację OpenCL, paint/sculpt i inne projekty, które mimo, że robią to samo to każdy robi to osobno i bez współpracy z resztą aplikacji.

5 lat wychodzi kiedy zamiast skupić się na podstawach większą grupą i zrobić szybko dobrą implementację, robi jedna osoba po godzinach jako jeden z wielu projektów i jak nawet jest gotowe to nie może wejść, bo wymaga przepisania większości narzędzi które powstawały równolegle i się ciągnie później latami to (bo jak już przepisane są tamte, to są nowe rzeczy które postały podczas przepisywania, bo rozwój nie skupia się na danym problemie tylko jest chaotyczny i nie zsynchronizowany). To prowadzi do tego, że po 5 latach dostajesz produkt, który powinien postać w kilka miesięcy i gratis jest frustracja użytkowników, którzy stracili narzędzia które powinny od razu powstać ze wsparciem dla nowych elementów "rdzeniowych". Ja pamiętam jeszcze co najmniej kilka jego projektów i żaden z tych które pamiętam nie wszedł do trunka. Widziałem, że nazywał rzeczy dostępne w kartach i sterownikach OpenGL od 2004/2005 dostępnymi z kontekstu OpenGL 1.x/2.x nowoczesnymi możliwościami OpenGL... może faktycznie dla blendera są one nowoczesne, bo VBO z OpenGL 1.5 dalej jest tylko standardowo nieaktywną opcją, a standardowe rysowanie wierzchołków w Viewporcie blendera to dalej VA (OpenGL 1.1) z 1997, aby starsze karty mogły działać. Jednak wątpię w obsługę kontekstu 3.x i 4.x OpenGL, a tym bardziej obsługę nowoczesnych możliwości OpenGL, bo wymagałoby to dużo zachodu i pisania różnych wersji rendererów dla różnych kart (już bardziej wierzę, że oleją stare karty ;p), a w specyficzne narzędzia, które są aktywne tylko dla niektórych kart (sculptowanie za pomocą tekstur i teselacji dla kart Dx11/OpenGL 4.0 - ewentualnie dla kart starszych (od Shader Model 3) dostępna wersja gdzie jest stosowany multiress, ale manipulacja na siatce odbywa się w vertex shaderach w oparciu o teksturę, a nie na CPU) to w wypadku blendera można na lata między bajki włożyć. Bywam na IRCu, ale rzadko, na forum nie bywam, na ML blendera rzadko piszę, bo trzeba mieć czas, a tego mi brakuje na czytanie wszystkiego co jest na ML blendera, tym bardziej, że nie jest to główne moje narzędzie pracy i jeszcze na kilku innych ML siedzę. Najczęściej piszę maila bezpośrednio do danej osoby, a nie na ML, bo to znacznie zmniejsza ilość czasu, który trzeba poświęcić (pisząc na ML na pewne tematy trzeba się liczyć z dyskusją trwającą pół miesiąca i setkami wiadomości).

A czy na marudzenie musi być monopol? To, że marudzę tu nie znaczy, że nie rozmawiam z programistami blendera na wiele innych sposobów. Jeśli by tak było to dziś zapewne nie miałbyś w blenderze wsparcia dla formatu Collada, którego usunięcie popierali Ton, Cambell, Brecht czy Erwin. Game Projekt to najgorsze co mogło by się przytrafić blenderowi. Żadnych nowych narzędzi wspomagających pracę, wiele kutni i niepotrzebnego nikomu kodu, a graficy wszelkiego rodzaju dostaliby przez to po tyłku bo blender stał by zupełnie w miejscu przez ten czas. Mnie ani Sculpt Masking, ani Skin Modifier jakoś nie interesują zupełnie. Udoskonalenia Paint Toolsów pierwsze, a dopiero później PTex (i przepisywanie Paint Toolsów później od nowa)? Ciekawa koncepcja przyznam i podobna właśnie do problemów z BMeshem - czyli prace trwały od końca do początku przez co wiele rzeczy trzeba było robić kilka razy, zamiast raz a dobrze. Ja rozumiem, że PTex nie są efektowne i wcale nie uatrakcyjniają features jak inne projekty, bo jest to tylko inny sposób mapowania tekstury dodająca możliwość w każdej chwili zmiany wielkości rozdzielczości danego face/fragmentu siatki i dowolne manipulowanie jej rozdzielczością na każdym face osobno (nie jest to efektowne, ani grafikowi super niezbędne i może się bez tego obejść - to coś ala BMesh tylko dla tekstur, a nie siatki), jednak obsługa PTex daje większe możliwości nowym narzędziom do malowania tekstur, jak i nawet sculptowi (nie do rzeźbienia od zera, a do rzeźbienia na base mesh jako mapka do wypalenia normalnych)... jeśli potraktować sculpt jako paint tool do mapowania mapy wysokości/mapy normalnych gdzie możesz dowolnie sterować szczegółowością (PTex) fragmentów, a efekt widzisz z bardzo dobrą wydajnością, bo można wykorzystać sprzętową akcelerację czyli Tessellacje na GPU z przesunięciami wierzchołków w oparciu o mapę którą rysujesz (jedynym minusem jest tu to, że oznacza to obsługi OpenGL 3.x przez blendera i 4.x przez kartę, co przekładając na rozwój blendera w tym aspekcie nastąpi za 10-20 lat kiedy już to rozwiązanie będzie bezsensowne, bo zbyt kurczowo trzymają się kompatybilności z kilkunastu letnimi komputerami (blender obecnie wspiera wszystko nawet jeśli Twój komputer nie ma karty graficznej obsługującej 3d i emuluje na CPU zadania GPU)... śmieszy to tym bardziej, że za pół roku będą wychodzić telefony i tablety, z obsługą OpenGL 4.x i DirectX 11.x, a karty z obsługą tych API można kupić obecnie za mniej niż 100zł).

@n-pigeon: Ja tam nie widzę, żadnych poważnych planów z PTex, a to co się obecnie z nim robi przypomina mi "plany" dotyczące bmesha, który już w 2007 roku był na ukończeniu jako projekt z gałęzi 2.4x. Marudzenie, nic nie da, podobnie jak nic innego też nie zmieni kierunku prac przez najbliższy rok, który upłynie pod znakiem Mango, co jednak nie znaczy, że ponarzekać na tak obrany projekt nie można.

To, że dobrze unwrapp działa naczy, że w tak ważnej kwestii można zasypiać gruszki w popiele i olać narzędzia do lepszej edycji UV, czy olać wsparcie dla nowinek jak Per-Face Texture Mapping (PTex), które weszły już do wielu aplikacji konkurentów, a blender nawet nie ma wsparcia w planach.

Dobre narzędzia modelarskie, dobrze narzędzia do teksturowania, porządna wypalarka tekstur i GI, dobre wsparcie dla najpopularniejszych formatów import/eksport, lepsze narzędzia do zarządzania wagami i cała masa innych rzeczy, ale ogólnie można nazwać to PODSTAWY, bo od tego trzeba zacząć, a teraz to trochę wygląda na sztukowanie podstaw, a rozpoczynają zabawy z VFX, Motion Tracingiem i tego typu projekty, przez co coraz bardziej blender staje się olbrzymem na glinianych nogach (coraz więcej wyczesanych features, coraz bardziej chwiejne podstawy).

Ile razy można stwierdzać ten sam fakt? ;p Czy ja wiem? Ngony mnie nie interesują, nowinki w tej wersji w większości były w 2.4x i je po prostu odzyskaliśmy (i tak nie całkiem), ważne dla mnie aspekty stoją w miejscu, lub wręcz się cofają, a kierunek rozwoju to VFX (co mnie zupełnie nie interesuje) i nad tym aspektem skupią się prace, a nie nad innymi IMHO ważniejszymi. Jak widać wiele zależy od miejsca siedzenia ;p.

W podanym linku pokazane są specyficzne możliwości Catmull-Clark względem innego algorytmu Subdivision (nie podanego z nazwy). Jedyne za co tu nie dałbym sobie ręki uciąć to to czy Edge Creases były w oryginalnych papierkach Catmull-Clark czy były dodane później (nie implementowałem sam, a tylko lata temu przeglądałem papierki i odrzuciłem Catmull-Clark jako opcję to moich zastosowań ;p).

Modo pokazuje jak pisałem, że korzysta z Catmull-Clark (pod oknem 3d) i to jest ważne, że mówi jednoznacznie jakie to narzędzie. Catmull i Clark to pracownicy Pixara i w ramach pracy w Pixar stworzyli Catmull-Clark. PSUBS to tylko nazwa od firmy, a nie od nazwisk (w tym, że mniej precyzyjna, bo Pixar ma już kilka algorytmów podobnych)

@Monio: A tam SSS - powiedz mi jak ustawić parametry dobrze dla takiego nieba w modelu Preetham'a (atmospheric scattering) ;p. @ikkiz: Turbosmooth to nie jest dokładnie catmull-clark tylko coś co daje podobny efekt, ale nie ma mowy o identycznym działaniu jak w innych aplikacjach. Co do wikipedii to mnie nie dziwi to, że jest wymieniony (bo samo miejsce to alfabetyczna kolejność), bo wikipedia często ma problem z rzetelnością, a dodatkowo nie do końca jest to nierzetelne, bo catmull-clark jest w mental ray, który jest dołączony do 3ds max.

Maxowy Mesh smooth nie ma na czole wypisane catmull-clark tylko z jednego powodu... nie obsługuje go, ale za to ma wypisane na czole przykładowo NURBS jako domyślna metoda interpolacji (a użytkownicy maxa głosują na wprowadzenie catmull-clark do Maxa na http://3dsmaxfeedback.autodesk.com/forums/80695-publicgeneralfeaturerequests/filters/top i jest to jedna z najpopularniejszych pozycji na Maxowej Wishlist). Jeśli by używał to zapewne podobnie jak blender, maya, softimage, lightwave, cinema 4d i modo (tu subtelniej nazywa się PSUBS (Pixar Subdivisions), bo pokazuje na pasku statusu "type: catmull-clark", podczas zabawy z modelem). Odwracasz trochę kota ogonem. Jeśli już chcesz takie rzeczy przytaczać to możesz woleć blender ręczny od blendera kielichowego, bo to są ich nazwy. Przykładowo w medycynie też narzędzia, choroby itd są nazywane od nazw twórców i połowa narzędzi chirurga w nazwach ma nazwisko twórcy aby jednoznacznie powiedzieć jaki typ dokładnie narzędzia jest potrzebne (a nie "ten ciekawy nóż" czy "a z jakiej firmy dziś mamy narzędzia, bo mogli inaczej nazwać"). Jednoznaczność opisu narzędzia i stosowanie do tego celu nazwiska jest normalne wszędzie (praktycznie w każdej dziedzinie - nawet opatentowane profile gwoździ, które inaczej się wbija, mają inne zastosowanie, wytrzymałość itp. mają nazwy od nazwiska i jest ta nazwa potocznie używana w danym środowisku). Jednoznaczność nazw jest ważna przy wszelkiego rodzaju narzędziach.

Dokładniej rzecz ujmując to interpoluje położenie nowych wierzchołków na podstawie punktów kontrolnych (base mesh) w celu aproksymacji ich nieznanego położenia. Podobną sytuację masz w Photoshopie skalując obraz wybierasz interpolacje (najbliższy sąsiad, dwuliniowa, bikubiczna... akurat w Photoshopie nie ma, ale tu może być też przykładowo Catmull-Rom użyte) wyższej rozdzielczości w oparciu o punkty kontrolne z mniejszej aproksymując kolor pikselów w punktach pomiędzy pikselami znanymi.

Kiedy sterowniki OpenCL od AMD będą na tyle dojrzałe, żeby specjalnie dla nich twórcy nie musieli wyłączać gotowego kodu renderera, bo kompilator w sterownikach sobie nie radzi z poprawnym kodem OpenCL. Zaskakujesz mnie takimi tekstami, bo ja tam nie widzę tłumaczenia co to algorytm, a opis jest tylko jeden zawierający się w "Catmull-clark to nazwa sposobu interpolacji" co żadnym opisem algorytmu nie jest, a najłatwiejszym opisem co robi - różnica jest spora i taka jak "telewizor wyświetla obraz", z opisem budowy telewizora. Masz jakieś oficjalne info na temat tego, że Sub D korzysta z Catmull-Clark? Nie mówię o nadinterpretacji użytkowników forum DAZa na temat algorytmu i podobnych rezultatów jak w Catmull-Clark (nie tożsamych więc nie jest to czysty Catmull-Clark, a jeśli ma coś z nim wspólnego to albo jest błąd implementacji, albo świadoma modyfikacja). Co więcej właśnie ta niewiedza co do algorytmu płoszy i irytuje grafików, a innym wcale nie pomaga nielogiczne nazewnictwo, bo co ma wspólnego Sub D, co jest samo w sobie dziwnym skrótem od Subdivision (podział) z automatycznym wygładzaniem nieznanym algorytmem interpolacji? Jeśli twórcy DAZ nie chcieli by płoszyć nazwami jak Sub D to używaliby Smooth lub Smooth Subdivision co byłoby czytelne, ale tu tego nie ma - po prostu jest nielogiczne nazewnictwo, które tylko drażni i przeszkadza grafikowi zamiast pomagać.