Skoti

Nie wiem czego się naczytałeś, ale korzystanie z takich struktur danych na gpu nie przysparza nikomu problemów. Miał zwykłe drzewo usemkowe które w pewnych scenach jest idealne się sprawdza i wyprzedza inne drzewa - jednak w większości wypadków lepszym jest BVH (co nie zmienia faktu, że octree sprawuje się lepiej niż zwykłe binarne drzewko BSP)... no chyba że chcesz robić wszystko na GPU razem z tworzeniem drzewa co wiele prościej można zrobić jako preprocess na CPU i gotowe drzewo podać do GPU (na GPU da się to zrobić - tylko po co ;p). Tak złożoność w tych algorytmach jest olbrzymia i na CPU te algorytmy zdychają - dlatego na CPU lepiej użyć mniej realistycznych, ale za to szybkich metod (które na gpu liczyłyby się w mgnieniu oka). Tak jeśli mówisz o Light Propagation Volumes to jest on szybki i na szybko jak kiedyś przejrzałem jest on bardzo podobny do Point-Based Approximate Color Bleeding stosowany przez Pixara i ILM (metody oparte na tej http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter14.html). Co do tego, że jest nie możliwe, to CUDA i OpenCL mogą korzystać z RAM komputera jeśli tego programista zapragnie (straci to trochę na wydajności, bo wąskim gardłem jest przepustowość szyny, ale i tak jest to szybsze rozwiązanie niż CPU) - co do Realtime to są metody dające lepsze rezultaty tylko wtedy innych efektów nie można robić typu wolumetryczne światła (nawet najprostsze jak w cryengine 2 czyli robione przez radial blur nieba i słońca), reliefmaping już się z lepszym GI w tej chwili nie wyrobią. no niestety cechą przypowieści jest też to, że ktoś kto ją opowiada powinien wiedzieć o czym mówi. w serii 4k 4770 obsługuje fp64 - tylko w nowych obcięli. W ray tracingu jest to wystarczające - głębokość promieni, cieni, odbicia... ustalasz przed renderingiem, przed renderingkiem kompilujesz kernel i już. Do prawdziwej rekurencji musisz poczekać do fermi. O jakim natywnym wsparciu dla C++ piszesz? Fermi będzie to po prostu pierwszy GPU który potrafi taki kod wykonać (tu nie jest ważne czy C++/C/Java...) - wcześniejsze GPU nVidii czy AMD nie potrafiły wykonać rekurencji czy też nie miały zunifikowanego adresowania pamięci i nie potrafiły wykonać programu pisanego na CPU - Fermi to zmienia i można korzystać z "normalnego" języka, a nie okrojonego C jak w wypadku CUDA czy OpenCL 1.0 Zapewne zaimplementują ją w pamięci globalnej, a Ty jak chcesz nawet w pamięci hosta możesz - to, że nie ma stosu to z jednej strony wada, ale z innej zaleta (tak jak w językach scala etc. stos i call jest jest implementowany na stercie dzięki czemu przy naprawdę głębokiej rekurencji nie wywali Ci przepełnienia stosu - bo umówmy się tail-call optimization w kompilatorach C++ na stosie działają raczej kiepsko). Nie gniewam się bo tu masz rację - rekurencja jest bardzo ważna i sam z powodu jej braku w OpenCL zrezygnowałem z przepisania swojego MLT na GPU ;p - CUDA nie lubie bo one-vendor-only, a w OpenCL nie można zrobić nawet sztuczki z szablonami bo ich nie ma ;p. W Fermi i nowych wersjach Cuda i OpenCL się to zmieni i wtedy reaktywuje odprężający projekcik pisany w wolnym czasie (jednak dla firm i osób które mają dużo wolnego czasu ograniczenia tych wersji Cuda i OpenCL nie są za wielkim ograniczeniem - po prostu muszą zmienić sposób zapisu algorytmu). a czy ja mówiłem że wcześniej był super? Takiego przyspieszenia by nie uzyskali gdyby był wcześniej super. Dynamiczne pętle da się zrobić (od SM3.0 jeśli dobrze pamiętam)... ale fakt, że instrukcje kontroli przepływu są strasznie wolne (wolne są i na CPU gdzie zwykły if to kilka cykli zegara, ale na GPU jest faktycznie jeszcze gorzej) - jednak w zastosowaniach takich jak raytracing i tak mimo wad GPU miażdży CPU - taka jest prawda.

O czyli jednak się nie postarali - ale jak chcesz programowalne shadery to możesz użyć jednego z rendermanów w Cuda (chociażby nVidia Gelato + rozszerzenie robiące z niego rendermana - ale łykać plików *.mi też nie będzie). Nie wiem jakich algorytmów używa dokładnie iray ale nie wierzę że to jest zwykły path tracer (i czy to jest ogólnie zwykły pathtracer a nie np. Metropolis light transport (zmodyfikowany bi-pathtracer, który jest faktycznie bardzo wolny - Maxwell, Indigo) bez żadnych optymalizacji. Co do photon mappingu (który jest implementowany bez przeszków nawet w RT w shaderach HLSL/GLSL), irradiance cache to jak najbardziej są możliwe na gpu... tylko po prostu są za szybkie (a po co używać tych metod skoro można w nie dużym czasie robić np. MLT które daje nieporównywalnie lepsze rezultaty, jednak moc CPU nie pozwalała do tej pory na szersze stosowanie), drzewa bsp, octree jak i kd-trees można zaimplementować na GPU... tylko po co się cofać i od razu implementuje się drzewa które są dziś stosowane w renderingu, a nie x lat temu (np. bvh dzięki którym blender 2.5 dostał speed up 7x jest implementowany nawet w raczkujących pathtracerach MLT na GPU jak SmallLuxGPU). Proponuj, ale następnym razem takie które mają co kolwiek wspólnego z tematem Dlatego miałoby nie działać bo nie ma jednostek obsługujących podwójną precyzję, bo amd je obcieła w tych seriach, które podałem http://www.geeks3d.com/public/jegx/200910/amd_opencl_supported_devices.jpg Tak jednak plusem 8600 (jednym z niewielu) jest to że jest stara i kosztuje grosze - a jak już kupować coś nowego to lepiej nie produkt który może się możliwościami mierzyć z kartami pokroju 8600 (poza wydajnością) - więc jak już amd to 5800+ lub nVidia 200+ (a najlepiej poczekać do fermi ;p). W CUDA da się zrobić rekurencję trochę na około bo z użyciem szablonów, ale się da (z tego między innymi powodu renderery używają CUDA, a nie OpenCL który działa również na AMD). Rekurencja i wskaźniki na funkcję w Cuda/OpenCL wejdą dopiero za chwilę razem z fermi (który będzie potrafił wszystko co CPU, a nawet znacznie więcej i będzie potrafił wykonać kod pisany w C++).

@dokturpotfor: w max też polecanym rendererem jest OpenGL. 8600 jest bardzo słabą kartą, ale jednak potrafi więcej niż CPU. Co do plików mental ray'a to zapewne pierwszym rendererem gpu go obsługującym będzie iray korzystający z SceneX i Cuda (oba to rozwiązania nvidii) twórców mental raya (rendermany gpgpu już są na rynku od bardzo dawna). Co do kart graficznych z serii 56xx i 57xx to nie za bardzo warto, bo w obliczeniach gdy będzie potrzeba użyć liczb podwójnej precyzji nie będzie działać GPGPU, a do samego renderingu scen przy modelowaniu lepiej wybrać starsze tańsze rozwiązania.

@M@Ti: Radeony są dobre dla graczy, ale sobie słabo radzą z OpenGL (mają bardzo słabe sterowniki do OpenGL - nawet nie chodzi o to, że działają dużo wolniej, a o to że czasami nie działa wcale (na szczęście ostatnio się to nie za często zdaża, ale w sterownikach z serii 8.x było to bardzo częste) - na wszystkich systemach operacyjnych w przeciwieństwie do NVidii)... jak pewnie dobrze wiesz praktycznie 100% programów graficznych działa na OpenGL... dodatkowo nawet stara karta graficzna typu 8600 potrafi przyspieszyć znacznie rendering w stosunku do CPU na rendererach korzystających z Cuda... do grania radeony są alternatywą, ale do grafiki jest to słaby wybór.

A faktycznie można - zapomniałem o sprawdzeniu w ipo ;p

Tylko jeśli dobrze pamiętam fluidy nie słuchają się pól siłowych, tylko swojej grawitacji wpisanej w ustawieniach domain (której nie da się ustawić klucza... a w 2.50 jest to możliwe, bo tu do wszystko możesz animować). W 2.49 animację grawitacji można uzyskać tylko przez animację reszty w przeciwną stronę ;p.

Jeśli trzeba by, robić animację płynu przy przesuwaniu (co w takim projekcie jak ten jest raczej zbędne) to można by też zasymilować to w małym domain - trzeba jednak więcej zachodu, bo trzeba by zrobić dłuższą symulacje płynu z obrotami fiolki w przeciwną stronę do wektora przyspieszenia (i później w trakcie poruszania poziomego fiolki robić rotację domain, o taki sam kąt tylko przemnożony przez -1) - będzie się ciecz zachowywała jakby oddziaływało na nią przyspieszenie, bez gigabajtów pamięci i olbrzymich rozdzielczości (co łączy się z czasem liczenia)

Tak wreszcie zrozumiałeś - nie musisz robić symulacji wszystkich fiolek, tylko jednej (i to tylko w jednym miejscu (przy nalewaniu - przed nalaniem nie ma fluidu więc tam nie musi być tam domain, po nalaniu animacja fluidu nie jest rzeczą niezbędną, więc może być po prostu przesuniętym domain (ostatnia klatka animacji fluidu to koniec wlewania się z inflow, a dalej przesuwasz normalnie szklankę już razem z domain) - więc nie musisz mieć wielkiego domain tylko na wielkość szklanki, przez co nie jest Ci potrzebna wielka rozdzielczość)).

Przeczytaj swój poprzedni post to się dowiesz co na studiach mi powiedzieli - dowiesz się o co pytałeś (matma) -, 160 MB powiedział mi profiler (ilość ramu zajmowanego przez blendera przed symulacją odjęta). Co do trolowania to oboje zdajemy sobie sprawę kto tu troluje - po prostu nie ośmieszaj się na przyszłość i nie zabieraj głosu w sprawach o których nie masz pojęcia.

Z zajęć i wykładów algebry liniowej, oraz programowania grafiki 3d - przy symuacji fluidów są stosowane macierze ale 3x3 (obroty) lub 4x4 (przesunięcie, skalowanie i obroty) i wektory oraz kwaterniony (macierze jednowymiarowe) 3 i 4 elementowe. Dane przechowywane z rozdzielczością N x N x N to zwykłe trójwymiarowe tablice danych i z macierzami nie mają nic wspólnego (i nie da się na nich, żadnych działań na macierzy robić). 160MB zajmuje w pamięci operacyjnej podczas liczenia - na dysku zajmuje dużo więcej, bo w przeciwieństwie do pamięci ram gdzie trzymane jest tylko klatka-1 i aktualnie liczona klatka muszą być zapisane wszystkie klatki obliczone wcześniej. Skoro nie pamiętasz kiedy pisałeś, że w tym wypadku potrzeba 20gb to zobacz swój pierwszy post w odpowiedzi za pytanie o konkretny przypadek. W każdym kubeczku pewnie ma być woda, ale po co mają być na raz przechowywane? Animacja jest ta sama więc wystarczy fluid w jednej szklance (to, że nie potrafisz rozwiązywać problemów nie oznacza, że nie da się ich rozwiązać i trzeba zwalać na za słaby sprzęt).

Przy 200 res 1.28gb pamięci na 64bit arch, blender 64bit Co tu ma macieRZ do rzeczy? Nawet jeśli pominąć 3 wymiary w opisie macierzy (które są dwu wymiarowe) nie ma to nic do rzeczy. Jeśli mówisz o rozdzielczości domain ustawionej na 100 to zajmuje ~160MB (64bit system i blender). Co do animacji jaką chce uzyskać autor wątku spokojnie wystarczy res 75 (z dobrze dobranym małym domain (jeśli chciałbyć użyć domain wielkości pokoju to faktycznie rozdzielczość 1000 będzie mało, ale domain wielkości szklanki to nawet 75 starczy z nadwyżką) i ustawieniami w zakładce advanced). Nie gadaj głupot, że trzeba 20GB ramu na taką pierdołę bo jesteś wtedy śmieszny... tym bardziej mówiąc o mainframe o których nie masz pojęcia, gdzie przeważnie na procesor przypada ~8gb ram (i każdy ma swoją kopię danych na których ma pracować)

@Matuzalem: Wynik nie jest zależny od karty graficznej, tylko od algorytmu/implementacji, a że w programach dostępnych w tej chwili używa się 2ch osobnych implementacji (w wersji CUDA i AMD Stream) i są pomiędzy nimi różnice (np. konwertowanie materiału Video), co jednak nie oznacza, że karty podają błędne dane - dają dane dobre... zmieni to dopiero OpenCL, ale tu jeszcze sterowniki nie są dopracowane zarówno u nVidii i Amd więc programy czekają z przesiadką (np. Octane Render planuje przesiadkę).

@Nezumi: nie martw się nie zablokują, tym bardziej, że nVidia chce pogrążyć intela i inwestuje w GPGPU dużo kasy, a nVidia raczej nie cofnie się i jak można obliczać na kartach z 2006 to i na nowych będzie można (tym bardziej, że nowe są specjalnie do tego tworzone). @hamek1990: przepisanie istniejącego silnika to żaden problem, a kolejna karta nVidii posiada 512 jednostek potrafiących liczyć wszystko to co CPU (tzn dużo więcej, ale teraz pokrywa w pełni CPU) i będzie dostarczony kompilator C++ tworzący kod dla GPU (więc programy nie będą musiały być przepisywane, a tylko przekompilowane, co oznacza tyle, że każdy program praktycznie od ręki będzie mógł być wydany na GPU). @Traitor: w tej chwili procesor jest potrzebny jedynie do komunikacji z bibliotekami napisanymi w C/C++ (np. okienka) i przesyłania danych z plików/pamięci do GPU - całe obliczenia mogą być robione na GPU. Moc CPU w renderingu jest marna i jak renderery przejdą na GPU procek będzie mógł być zwykłą budżetówką, bez utraty wydajności (i o to chodzi nVidii która wyśmiewa procki intela i chce go zdetronizować na rynku obliczeniowym).

@MF,Marcin: sprawdźcie w filtrze antyspamowym, bo z doświadczenia wiem, że niektóre filtry odsiewają maile od nVidia, Intel, AMD, IBM, Sun ;p

Wielkość ścianki wydłuża rendering ;p... z tym, że nie wielkość w 3d, a po przemnożeniu przez macierz projekcji kamery (jak w 2d zajmuje więcej to dłużej się renderuje) - ale to już nie jest zależne od samej wielkości tri, a stosunku wielkości tri do odległości kamery ;p.

Tak w 2012 niektóre efekty są w Bullet (czyli po prostu większość rigid body, bo tu nie trzeba nie wiadomo jakiego silnika i Bullet w zupełności wystarczy - jednak nie wszędzie wystarcza jednak dlatego, nie cała fizyka w 2012 była robiona w nim). Heh przeważnie w dyskusjach na temat bullet piszę o tym jak on wiele ma, bo się szybko rozwija i wiele programistów nie nadąża za rozwojem (np. już rozpoczynają się wczesne fazy pisania fizyki fluidów... z tym, że inne silniki mają to od lat). Mogli użyć chociażby Angel Script, Ruby, Lua czy nawet skoro używają Qt QtScript (chociaż ten jest trochę za młody). To dobrze - a co do pythona to nie jest on standardem... ot jest chwilowo modny (jak przed nim kilka podobnych języków jak perl).

A kto mówi, że zrobili na złość? Po prostu nie zrobili sobie na złość i wybrali język który im nie doda pracy (łatwo się osadza - gdyby mieli coś w nim pisać już dodałby dużo więcej pracy przy debugowaniu niż zaoszczędził przy osadzaniu ;p), a wygoda użytkownika w tym wypadku wystarczy, że była im obojętna, żeby wybrać pythona. PS. Tak samo nie myślisz chyba, że wybrali bullet dlatego, bo lepiej oddaje fizykę, czy pozwala na więcej... po prostu, za licencję na Havok/PhysX (do takiego projektu nie można wybrać darmowego physx tylko trzeba mieć możliwość poprawiania bugów - a kod źródłowy jest dostępny po kupieniu licencji) trzeba wyłożyć dodatkową kasę, a bullet ma dobre perspektywy rozwoju (i już pisze się w nim obsługa OpenCL). W programach/grach nie wybiera się narzędzi najlepszych, ale najlepsze w stosunku do strat (czyli najlepsze dla producenta, a nie dla klienta, czy obiektywnie najlepszych)... a tu po prostu po przekalkulowaniu wygrały bullet (którego sam wykorzystuje), i python (którego niestety miałem nieprzyjemność wykorzystywać przy jednym projekcie).

To nie spisek - łatwo się go osadza, a twórcy programu w nim nie będą pisać to przyjemny być nie musi - czyli banalnie łatwo dodali funkcjonalność i nie musieli myśleć nad tym jak będzie się programować, czy jak to wpłynie na spowolnienie rozwoju programu, bo w nim nic nie jest napisane przez twórców - po prostu jest możliwość pisania przez użytkowników, a to czy będzie łatwo debugować, czy język swoimi założeniami nie będzie sam generował masy problemów ich nie musi obchodzić. @mamoulian: dziwi mnie twój avatar w kontekście wpisu o sobie, gdzie piszesz, że programujesz gry (ale jakoś Cię nie kojarzę z tego nicku) - python jest językiem, który zupełnie nie pasuje do produkcji gier (zarówno do tooli, jak i silnika).

Python - słabo (istnieją dużo przyjemniejsze języki... a raczej jest mało tak nieprzyjemnych), Bullet - dobrze (mimo, że są dwie biblioteki, które więcej potrafią), Collada - super ;p

@SYmek: blender nie korzysta z QT tylko własnego rozwiązania, pisanego od podstaw dla blendera (zarówno stary jak i nowy blender mają specjalnie pisane pod blendera rozwiązanie). Bullet to silnik i łatwo się pod niego podpina siatkę, więc tu też nic nie musieli brać ;]. Oba są darmowe i można za darmo wykorzystywać komercyjnie bo są na licencji LGPL/zlib (QT od niedawna czyli od wersji 4.5 - wcześniej była na dwóch licencjach GPL dla otwartych programów i komercyjnej dla aplikacji komercyjnych). Do tego mieli swój stary kod całkiem dobrego programu i zapewne nawet im przez myśl nie przeszedł Blender. @n-pigeon: Bullet nie powstał jako silnik fizyczny do gier Sony - powstał z potrzeby rozwoju silnika dla mas na licencji zbliżonej do LGPL (zlib) i został zainicjowany przez programistów sławy w dziedzinie programowania fizyki na czele z Erwin Coumans (pracował wcześniej nad Havok), a pierwszą większą firmą która wykorzystywała bullet to nVidia (jeszcze do niedawna w NVSG, ale nVidia przeszła na "swój produkt" (była zmuszona - Intel kupił Havok, i był wyścig pomiędzy nV i AMD kto pierwszy kupi PhysX (Bullet przez dostępny kod należący do wielu programistów na świecie, nie był atrakcyjnym zakupem))). Sony dopiero długo później rozpoczęło wykorzystywać Bullet jak zatrudniło Erwin'a (żeby napisał wersję na procesory Cell - w końcu to główny silnik fizyki na PS3). Teraz się używa Bullet praktycznie wszędzie i w naprawdę wielkich projektach przez wielkie firmy, jak Sony, Disney (które jest autorem pluginu do Maya), Rockstar (np. GTA4 na PS3/XBox360/PC wykorzystuje Bullet) i inne. Co do Autodesk to masz przecież wieloplatformowe Maya, Softimage, a teraz robią Mudboxa - jeśli masz na myśli 3ds max to na to nie licz, bo jest to nieopłacalne... gdyby chcieli go od nowa pisać i rozpisali sobie co trzeba poprawić, to z 3ds nie wiele by zostało, a tak póki jeszcze się nie rozsypał to zarabiają. Adobe wykorzystuje Qt np. w Adobe Photoshop Elements, i zamierza stosować Qt we wszystkich nowo powstałych programach. Czyli przytyk kto kolejny raczej nietrafiony... wszyscy chcą, tylko po prostu czasami się to nie opłaca, bo kod programów jest słaby i skostniały (dlatego, mimo, że Qt dałby dużo np. interfejsowi 3ds max elastyczności to go nie użyją - 3ds swoje przeszedł przez lata kiedy był co chwile sprzedawany, oraz zdążył się już trochę zestarzeć).

@mokramyszka666: czego nie rozumiesz w "do danych dziedzin"? Mimo że jakaś firma mówi, że film powstał w programie XYZ, przeważnie jest tylko częścią prawdy - część jest modelowana w innych programach, animacje postaci robi się w programach bardziej dostosowanych do tego zadania (jak np. motionbuilder), w innych się robi symulacje/efekty specjalne (czasami te programy są skompilowane do plugina)... i np. w jeszcze innym programie składa się to do kupy i renderuje. Praktycznie wszystko można robić w pojedynczym programie jak lightwave, maya, softimage, blender, 3ds, c4d... tylko nikt tak nie robi, bo w jednym programie lepiej się modeluje, w innym lepiej rzeźbi, jeszcze w innym animuje, a kolejny jest po prostu popularny, więc ma dobre integrację do rendererów... najlepiej brać narzędzia najlepsze do danej dziedziny - jeśli modelujesz w 3ds to stracisz dużo czasu... jeśli chcesz zrobić animację tłumu w blenderze to stracisz jeszcze więcej ;p (niby są skrypty, ale nie są tak dobre, jak pluginy do 3ds).

@mokramyszka666: nie pisałem o całej produkcji i renderingu, tylko o modelowaniu w innych aplikacjach (akurat w wypadku kinematografa).

1. Dobra "ziomkom" napisałeś. 2. Tak, bo koleś odpowiedzialny za integracje z blenderem na poziomie kodu: a) może nie znać pythona, b) może na tyle nie lubić pythona, że oleje pisanie (dość powszechne wśród programistów c/c++), c) będzie dużo więcej błędów i nieprzewidzianego działania skryptu (python to wręcz wymusza (przypadkiem usuniesz/dodasz tab/spację, a program działa zupełnie inaczej + dynamiczne typowanie, i już są błędy ciężkie do odnalezienia w kodzie)), d) zapewne jest zajęty innym ważniejszym dla siebie projektem, niż pisanie wszystkiego na nowo.

Napisałeś autorów, a tworzyła to jedna osoba więc poprawiłem - niczego nie chciałem udowadniać, ani do czegoś prowadzić - po prostu stwierdziłem fakt. Własne buildy to właśnie integracja C++ (którą trzeba kompilować (czy jak wolisz budować (od tego build))), a że w 2.5+ całe UI jest pisane w skryptach na specjalne buildy nie licz - wszystkie integracje to będą skrypty. ... możesz podać źródło cytatu, bo twórca mówił/pisał zupełnie coś innego jak przechodził na komercyjną drogę rozwoju.

Nic takiego nie powiedziałem, - wykonał bardzo użyteczną pracę, ale nie on pisał wolumetrykę - rozpoczął współpracę, jak wolumetryka była już napisana. Za integrację w C++ odpowiedzialna jest jedna osoba... za skrypt (w 2.5 możliwy jest tylko skrypt), odpowiedzialne są 4ry osoby. Kerkythea jest nierozwijana i już nie będzie (i prawie pewne, że nowych skryptów do blendera nie zobaczysz), a wcale taki dopracowany nie jest i ma wiele bugów (nawet kamery nie potrafi ustawić tak jak masz w programie z którego eksportujesz). Lux jest bardzo dobry i rendering unbiased to tylko część jego funkcji (LuxRender korzysta z algorytmu MLT tak samo jak Maxwell i Kerkythea (tak nie przesłyszałeś się Kerkythea też może renderować "unbiased"), ale możesz mu też ustawić normalny pathtracer, czy nawet directlighting). Nie zostałeś wyśmiany - po prostu Kerkythea był dobrym wyborem kilka lat temu - teraz dobrym możliwe że będzie Thea, ale Kerkythea to już przeszłość. A jeśli mpta korzysta z mentala to już prędzej doczeka się integracji Mentala z B2.5, niż Kerkythea (do starego blendera integracja jest np. http://graphicall.org/builds/builds/showbuild.php?action=show&id=384)