adek Posted March 8, 2011 Share Posted March 8, 2011 Firma Exocortex zamieściła na swojej stronie, krótki film przedstawiający możliwości Momentum 2.0 - nowej wersji szybkiego silnika fizyki dla Softimage. Pełna treść wiadomości znajduje się na stronie głównej serwisu pod adresem: http://www.max3d.pl/news.php?id=1665 Link to comment Share on other sites More sharing options...
polka dot Posted March 8, 2011 Share Posted March 8, 2011 bardzo fajne demko. Link to comment Share on other sites More sharing options...
Nezumi Posted March 8, 2011 Share Posted March 8, 2011 Spoko demko - w koncu jakas inna muzyka od tego elektronicznego smucenia ;) A sam silnik? Nie znam sie - widzialem juz tony rozwalanych scian, kulek, klockow i ragdoli. Trudno mi powiedziec co tu jest takiego wartego uwagi. Link to comment Share on other sites More sharing options...
Artur Paprocki Posted March 8, 2011 Share Posted March 8, 2011 Chyba poza ceną nic nowaterskiego w tym nie ma.Może jeszcze poza faktem że to RGDB,SoftBody,Cloth,DeformedRGBD w 1 Link to comment Share on other sites More sharing options...
SYmek Posted March 8, 2011 Share Posted March 8, 2011 Na świecie co roku powstaje kilka nowych rendererów, a każdy robi to samo, co poprzedni. Stosując waszą logikę, wszystkie owe silniki są warte tyle samo... To jest Bullet, ale jakość jego implementacji ma zasadnicze znaczenie, bo od niej przede wszystkim zależy to, co da się z nim zrobić w danym programie. Ten plugin wygląda bardzo solidnie. To raz. Dwa, że demko jest banalne dla kogoś, kto nie zajmuje się fizyką. W istocie jest tam kilka trudnych efektów, które o ile działają stabilnie i szybko, są poważnym atutem. To tyle. Natomiast przyznaję, że sam Bullet nie rozgrzewa mojej wyobraźni... pozdro, skk. Link to comment Share on other sites More sharing options...
Nezumi Posted March 8, 2011 Share Posted March 8, 2011 Ale jaka logika, SYmek? Powiedz jak ocenic jakosc implementacji bulleta, predkosc dzialania i komfort pracy w pluginie po wyrenderowanym filmiku walacych sie klockow..? Link to comment Share on other sites More sharing options...
Kris_R Posted March 8, 2011 Share Posted March 8, 2011 Jest tam na dole ekraniku taki mały przypis: "All simulations shown in this video run at interactive framerates". Można wierzyć, można nie wierzyć, ale daje do myślenia. Albo wystarczy pogadać z kimś, kto tego używał w jakiejś produkcji zamiast gdybać. Link to comment Share on other sites More sharing options...
MaxymilianMax Posted March 9, 2011 Share Posted March 9, 2011 a jak sie nazywał ten plugin do Softimage jakies pół oku temu w newsach prezentowany jako super symulator cieczy i dymu i softbody? Zrobił wtedy duuze tu wrażenie :) Link to comment Share on other sites More sharing options...
Monio Posted March 9, 2011 Share Posted March 9, 2011 lagoa multiphysics? http://www.max3d.pl/news.php?id=1292 Link to comment Share on other sites More sharing options...
Nezumi Posted March 9, 2011 Share Posted March 9, 2011 MaxymilianMax - wiecej kuleczek to i wrazenie bylo wieksze ;) Link to comment Share on other sites More sharing options...
Skoti Posted March 9, 2011 Share Posted March 9, 2011 Firma Exocortex zamieściła na swojej stronie, krótki film przedstawiający możliwości Momentum 2.0 - nowej wersji szybkiego silnika fizyki dla Softimage. To nie jest nowa wersja silnika - to jest ten sam silnik który jest w Cinema 4D, LightWave 3D czy Blender standardowo, a w produkcjach Hollywoodzkich wykorzystywany przez m.in. Sony (np. 2012, Hancock), Disney (Bolt), Dreamworks (Megamind, Shrek 4), jak i filmach produkowanych przez innych (Sherlock Holmes). Disney jest autorem darmowych pluginów do Maya czy 3ds http://code.google.com/p/dynamica/ To jest Bullet, ale jakość jego implementacji ma zasadnicze znaczenie, bo od niej przede wszystkim zależy to, co da się z nim zrobić w danym programie. Ten plugin wygląda bardzo solidnie. Implementacja fizyki wszędzie jest ta sama - różni się integracja, która daje do czegoś dostęp lub nie - jeśli daje to praktycznie takie same efekty uzyskasz wszędzie (mogą być minimalne różnicę polegające na innych ustawieniach domyślnych materiałów czy marginesu, ale przeważnie da się to ustawić ręcznie). Przeważnie różnicę wynikają raczej z różnicy wiedzy i umiejętności osób robiących demka. Jest tam na dole ekraniku taki mały przypis: "All simulations shown in this video run at interactive framerates". Można wierzyć, można nie wierzyć, ale daje do myślenia. Albo wystarczy pogadać z kimś, kto tego używał w jakiejś produkcji zamiast gdybać. Nic dziwnego, że działa w RT bo tu nie ma za wiele do liczenia (siatki liczone do softbody są liczone dla rzadkich siatek, a później jest ona zagęszczana już po fizyce co widać na tych filmikach). Naprawdę szybka i wydajna fizyka dla ciał miękkich, ciuchów, deformowanych obiektów, fracturingu, fluidów będzie dopiero przy liczeniu na GPU z nadchodzącą wersją 3.0 silnika Bullet i liczenia w OpenCL (może liczyć na CPU ale i GPU niezależnie czy to GPU jest nvidii, amd czy intela). Teraz twórca Bullet pracuje dla AMD i AMD już zapowiedziało plugin do Maya wykorzystujący wersję OpenCL http://www.amd.com/us/press-releases/Pages/amd-plug-in-maya-gd-conf-2011mar02.aspx 1 Link to comment Share on other sites More sharing options...
SYmek Posted March 9, 2011 Share Posted March 9, 2011 Implementacja fizyki wszędzie jest ta sama - różni się integracja, która daje do czegoś dostęp lub nie - jeśli daje to praktycznie takie same efekty uzyskasz wszędzie (mogą być minimalne różnicę polegające na innych ustawieniach domyślnych materiałów czy marginesu, ale przeważnie da się to ustawić ręcznie). Przeważnie różnicę wynikają raczej z różnicy wiedzy i umiejętności osób robiących demka. Bzdura. Integracja, którą bagatelizujesz ma zasadnicze znaczenie dla efektów końcowych. Łatwo to zrozumieć per analogia, porównując na przykład pełny Syflex z Mai, z tym obecnym w XSI. Albo ODE w Houdinim i ODE w XSI. Warto też zauważyć, że studia, które wspominasz używają Bulleta jako framework, udoskonalając go o dziesiątki rzeczy - włączając w to tak zasadnicze rzeczy, jak własna detekcja kolizji (jak miało to miejsce w 2012 i DD), więc powoływanie się na nie w kontekście C4D czy powyższego pluginu nie ma wielkiego sensu. Nic dziwnego, że działa w RT bo tu nie ma za wiele do liczenia (siatki liczone do softbody są liczone dla rzadkich siatek, a później jest ona zagęszczana już po fizyce co widać na tych filmikach). Naprawdę szybka i wydajna fizyka dla ciał miękkich, ciuchów, deformowanych obiektów, fracturingu, fluidów będzie dopiero przy liczeniu na GPU z nadchodzącą wersją 3.0 silnika Bullet i liczenia w OpenCL Nie ma wiele do liczenia, bo przyjęty w Bullecie model fizyczny jest prosty (gierkowy), a nie dlatego, że siatki są rzadkie. Gdyby Bullet miał bardziej kompletny fizycznie model ciał miękkich i te rzadkie siatki liczyłyby się długo. Inna sprawa, że ten uproszczony model jest najwyraźniej bardzo stabilny, co wiele mówi o jakości metod Bulleta, a czego nie zauważają ludzie kolejny raz oglądający kulki, gridy i boxy... Link to comment Share on other sites More sharing options...
Skoti Posted March 9, 2011 Share Posted March 9, 2011 Bzdura. Integracja, którą bagatelizujesz ma zasadnicze znaczenie dla efektów końcowych. Łatwo to zrozumieć per analogia, porównując na przykład pełny Syflex z Mai, z tym obecnym w XSI. Albo ODE w Houdinim i ODE w XSI. Nie wiem jak wygląda do z Syflex, ale w wypadku ODE to mylisz silnik fizyki, a wykorzystanie części do budowania własnego - ODE to tylko silnik brył sztywnych, a w Houdinim nawet tego nie wykorzystali (jedyne co użyli z tego co pamiętam to detekcji kolizji, a całą fizyką zajmuje się już ich silnik). Warto też zauważyć, że studia, które wspominasz używają Bulleta jako framework, udoskonalając go o dziesiątki rzeczy - włączając w to tak zasadnicze rzeczy, jak własna detekcja kolizji (jak miało to miejsce w 2012 i DD), więc powoływanie się na nie w kontekście C4D czy powyższego pluginu nie ma wielkiego sensu. Nie ruszali nic przy detekcji kolizji (sam bullet ma w sobie z tego co pamiętam 5 algorytmów (nawet więcej wliczając te bardziej egzotyczne jak detekcja kolizji przez CUDA) do wyboru tu i tu tylko sobie wybrali jeden), ani przy 2012 nie ruszali nic przy fizyce brył sztywnych (tam fizyka praktycznie w całości się na tym opierała), a dodali swoje własne relacje między obiektami - bo Bullet tu ma tylko najpopularniejsze zawiasy, suwaki, połączenia czy 6Dof, a tu potrzebowali czegoś więcej (czegoś co im by pewnie nie zapewnił żaden silnik out of box, a tu mieli dostęp do źródeł i łatwą możliwość dodania). Nie ma wiele do liczenia, bo przyjęty w Bullecie model fizyczny jest prosty (gierkowy), a nie dlatego, że siatki są rzadkie. Gdyby Bullet miał bardziej kompletny fizycznie model ciał miękkich i te rzadkie siatki liczyłyby się długo. Gdyby babcia miała wąsy... - mowa o tym algorytmie który był użyty. Ten algorytm nie bez powodu został przygotowany pod gry - w czasie dodawania wsparcia dla softbody twórca tego silnika pracował dla sony i DevKit konsoli Sony Playstation 3. Jasne jest, że im bardziej realistyczne algorytmy tym więcej czasu zajmuje obliczanie (gdyby chcieć zrobić fizykę SB realistyczną to najszybsze komputery swiata przez lata liczyłyby prostą scenę, ale nie o realistyczność tu chodzi, a o realizm/wydajność - a tu Bullet nie ma czego się wstydzić (przy gęstszej siatce, bo wtedy efekt wygląda lepiej niż przy tak rzadkiej, mimo, że o realizmie dalej nie można mówić)). Inna sprawa, że ten uproszczony model jest najwyraźniej bardzo stabilny, co wiele mówi o jakości metod Bulleta, a czego nie zauważają ludzie kolejny raz oglądający kulki, gridy i boxy... Bullet jak i PhysX czy Havok bywa niestabilny - np. w wypadku bardzo rzadkiej siatki dużej siatki kolidującej z małą (np. jak zrobisz podłogę o 1km2 powierzchni złożoną z 1x quad lub 2x tri i postać gdzie kolidują jej stopy w normalnych rozmiarach, to przy poruszaniu się będzie widoczna niestabilność - rozwiązanie to gęstsza siatka podłogi, lub uznanie jej jako płaszczyznę i taki kształt zamiast siatki dać do obliczeń). Link to comment Share on other sites More sharing options...
czaps Posted March 9, 2011 Share Posted March 9, 2011 Wtrące się w tą dyskusje bo ciekawa się robi. ;-) Co do bulleta to może jest gierkowy ale PhysX do pięt mu nie dorasta, nawet, pod katem szybkości , możliwości rozbudowy i proceduralnego podejścia w aplikacjach , które potrafią go wykorzystać lub własnych API. Maya 2012 będzie miała wbudowany już na stale PhysX jak w ostatnich wersjach 3ds maxa ale co z tego ;-)) Z kolei programowanie pod GPU wiąże się z przepisywaniem całej struktory np. bulleta i inne kody niż dla CPU. Powiązanie tych dwóch kodów jest zbyt skomplikowane ,żeby tak od razu to sprawnie zintegrować i przyspieszyć od tak sobie. pozdro czaps Link to comment Share on other sites More sharing options...
SYmek Posted March 9, 2011 Share Posted March 9, 2011 Nie wiem jak wygląda do z Syflex, ale w wypadku ODE to mylisz silnik fizyki, a wykorzystanie części do budowania własnego - ODE to tylko silnik brył sztywnych, a w Houdinim nawet tego nie wykorzystali (jedyne co użyli z tego co pamiętam to detekcji kolizji, a całą fizyką zajmuje się już ich silnik). Niczego nie mylę, tylko wiem o czym mówię. Skąd wiesz, jak wygląda implementacja ODE w Houdinim? Widziałeś kod? Gdybyś go widział, nie wypowiadałbyś z takim przekonaniem fałszywych sądów. Anyway, ODE jest w pełni zaimplementowane w H., podobnie jak w Xsi. Tyle, że w pierwszym można zrobić znacznie więcej za jego pomocą, niż w drugim. Tego dotyczył przykład. Nie schodźmy z tematu w jałowych przepychankach. Nie ruszali nic przy detekcji kolizji (sam bullet ma w sobie z tego co pamiętam 5 algorytmów (nawet więcej wliczając te bardziej egzotyczne jak detekcja kolizji przez CUDA) do wyboru tu i tu tylko sobie wybrali jeden), ani przy 2012 nie ruszali nic przy fizyce brył sztywnych (tam fizyka praktycznie w całości się na tym opierała), a dodali swoje własne relacje między obiektami - bo Bullet tu ma tylko najpopularniejsze zawiasy, suwaki, połączenia czy 6Dof, a tu potrzebowali czegoś więcej (czegoś co im by pewnie nie zapewnił żaden silnik out of box, a tu mieli dostęp do źródeł i łatwą możliwość dodania). Wiem coś innego, ze źródła. Jak by nie było, nie jest to ten sam silnik. Gdyby babcia miała wąsy... Pytanie, czy to są wąsy. Zwracam uwagę, że jeden algorytm jest tak samo szybki lub wolny, bez względu na to, czy liczymy go na CPU czy GPU, czy liczy gęstą siatkę czy rzadką. Zmieniają się warunki testu, a nie algorytm. Porównujmy jabłka do jabłek. Prawdę mówiąc szybki algorytm ma liniową relację zadania do czasu. I tyle. Nawet nie musi być taki szybki... Bullet jak i PhysX czy Havok bywa niestabilny - np. w wypadku bardzo rzadkiej siatki dużej siatki kolidującej z małą (np. jak zrobisz podłogę o 1km2 powierzchni złożoną z 1x quad lub 2x tri i postać gdzie kolidują jej stopy w normalnych rozmiarach, to przy poruszaniu się będzie widoczna niestabilność - rozwiązanie to gęstsza siatka podłogi, lub uznanie jej jako płaszczyznę i taki kształt zamiast siatki dać do obliczeń). Tak, oczywiście, każdy silnik bywa niestabilny. Są też takie, które rzadko kiedy bywają stabilne. I tego dotyczyła uwaga. Link to comment Share on other sites More sharing options...
Skoti Posted March 9, 2011 Share Posted March 9, 2011 Z kolei programowanie pod GPU wiąże się z przepisywaniem całej struktory np. bulleta i inne kody niż dla CPU. Powiązanie tych dwóch kodów jest zbyt skomplikowane ,żeby tak od razu to sprawnie zintegrować i przyspieszyć od tak sobie. Akurat fizyka jest już z założenia przystosowana do obliczeń na GPU (bo z założenia działa na wektorach (czyli tak jak SSE w x86 czy SPU w PS3) i danych które idealnie pasują pod obliczenia równoległe). Ofc trzeba zrobić nowe wykrywanie kolizji które będzie jeszcze lepiej działać na GPU (w tej chwili Bullet ma 2x opcje różnych struktur i algorytmów wykrywania kolizji), a kod już po przepisaniu do OpenCL będzie ten sam dla CPU jak i GPU (intel i amd mają własne implementację OpenCL wykorzystujące SSE, a IBM ma implementację wykorzystującą SPE w Cell (odpowiednik SSE), czy ARM wykorzystujące NEON) - jedna implementacja załatwi już wtedy wszystkie możliwe urządzenia i platformy (liczy się tylko czy coś może liczyć). OFC zajmie to jeszcze trochę czasu (już od końca 2008 roku zaczynali i pewnie najwcześniej wydania pod koniec roku można się spodziewać), i nawet po wydaniu mogą być problemy z tym co dla CPU najłatwiejsze czyli z bryłami sztywnymi, ale idzie to w dobrym kierunku Niczego nie mylę, tylko wiem o czym mówię. Skąd wiesz, jak wygląda implementacja ODE w Houdinim? Widziałeś kod? Gdybyś go widział, nie wypowiadałbyś z takim przekonaniem fałszywych sądów. Anyway, ODE jest w pełni zaimplementowane w H., podobnie jak w Xsi. Tyle, że w pierwszym można zrobić znacznie więcej za jego pomocą, niż w drugim. Tego dotyczył przykład. Nie schodźmy z tematu w jałowych przepychankach. W Houdinim przy tych samych ustawieniach i identycznej scenie jak w ODE wynik symulacji jest zupełnie inny (ODE jest silnikiem deterministycznym i w tych samych warunkach dokładnie zawsze taki sam efekt jest uzyskiwany) - czyli jest inna fizyka brył sztywnych niż w ODE, a z czystego ODE zostało tylko wykrywanie kolizji - tu nie trzeba widzieć kodu, bo to widać po efektach. Pytanie, czy to są wąsy. Zwracam uwagę, że jeden algorytm jest tak samo szybki lub wolny, bez względu na to, czy liczymy go na CPU czy GPU, czy liczy gęstą siatkę czy rzadką. Zmieniają się warunki testu, a nie algorytm. Porównujmy jabłka do jabłek. Prawdę mówiąc szybki algorytm ma liniową relację zadania do czasu. I tyle. Nawet nie musi być taki szybki... Wręcz przeciwnie - o ile algorytm może być bardzo szybki dla małej ilości danych, może być najwolniejszy dla dużej ilości danych (jeden wykonuje się w czasie 16*n, a drugi n^2 to dla danych od 1 do 4 algorytm drugi będzie szybszy, a dla większych danych pierwszy) - złożoność algorytmu wyznacza się dla n dążącego do nieskończoności, ale praktycznie zawsze dla małych danych wydajność wygląda inaczej. Podobnie jest z CPU/GPU - algorytm który nie można rozdzielić na wątki działa zawsze lepiej na CPU, algorytm który rozdziela się na wątki i każdy wątek robi to samo na innych danych działa lepiej na GPU, a algorytmy które są pomiędzy tym to zależy - algorytm nigdy nie jest tak samo szybki/wolny dla różnych warunków. Tak, oczywiście, każdy silnik bywa niestabilny. Są też takie, które rzadko kiedy bywają stabilne. I tego dotyczyła uwaga. Wiem, jednak opinia o stabilności danego silnika często bierze się nie z faktycznego stanu tylko z tego, czy ktoś potrafił wykorzystać silnik czy nie (bo można przedstawić, że silnik z założenia niestabilny jest stabilny jak ktoś go zna, jak i to, że Havok/PhysX/Bullet są niestabilne)... dlatego napisałem, że bywa niestabilny, bo opinii o stabilności animacji fizycznej nie powinno się kształtować w oparciu o filmiki promujące silnik (bo na nich będzie zawsze silnik stabilny, nawet jeśli w praktyce, jest to bardzo trudne do uzyskania). Link to comment Share on other sites More sharing options...
Nezumi Posted March 9, 2011 Share Posted March 9, 2011 Jakby kogos interesowalo to moze sobie zerknac na makaronowo, sznurkowo lancuchowe demko bulleta z Blendera. Od 7:15 pokazuja w real time jak to dziala (cos czego mi brakuje w demku Momentum 2.0). Szczerze powiem ze bardziej interesujace wydaje mi sie demko blenderowe (fajniejsze przyklady) ale brakuje mi w nim z kolei prezentacji wgniatania powierzchni. Wrzucam tu linka bo ciekawa dyskusja a to akurat w temacie. Poniekad ;) Link to comment Share on other sites More sharing options...
SYmek Posted March 10, 2011 Share Posted March 10, 2011 Akurat fizyka jest już z założenia przystosowana do obliczeń na GPU Wątpię, aby obliczenia na wektorach były gwarantem przydatności obliczeń na GPGPU, to jest jednak uproszczenie*. Akademicka dyskusja. W Houdinim przy tych samych ustawieniach i identycznej scenie jak w ODE wynik symulacji jest zupełnie inny (ODE jest silnikiem deterministycznym i w tych samych warunkach dokładnie zawsze taki sam efekt jest uzyskiwany) - czyli jest inna fizyka brył sztywnych niż w ODE, a z czystego ODE zostało tylko wykrywanie kolizji - tu nie trzeba widzieć kodu, bo to widać po efektach. Nie zrozumiałem, co z czym porównujesz, scenę ODE/XSI z ODE/Houdini, DOPsy z ODE w H., czy dwie identyczne sceny ODE w H? Tylko ostatnia ewentualność ma prawo zachować ten sam w wynik w tych samych warunkach. O to właśnie chodzi, że ODE w dwóch aplikacjach zachowa się inaczej, bo jest zbyt wiele elementów, które mogą się różnić, mimo tego samego silnika. BTW kod solvera ODE dla Houdiniego jest otwarty. Możesz go sobie obejrzeć. Wręcz przeciwnie - o ile algorytm może być bardzo szybki dla małej ilości danych, może być najwolniejszy dla dużej ilości danych (jeden wykonuje się w czasie 16*n, a drugi n^2 to dla danych od 1 do 4 algorytm drugi będzie szybszy, a dla większych danych pierwszy) Co ty robisz, żeby uzyskać taki efekt? Piszesz dokładnie to samo, co ja, ale zaczynasz zdanie od "wręcz przeciwnie" i dalej eksplikujesz to, z czego sam, najwyraźniej, zdaję sobie sprawę, skoro zwróciłem na to uwagę. (...) bo opinii o stabilności animacji fizycznej nie powinno się kształtować w oparciu o filmiki promujące silnik (bo na nich będzie zawsze silnik stabilny, nawet jeśli w praktyce, jest to bardzo trudne do uzyskania). True. Napisałem "wygląda na stabilny", bo widzę kilka softbodies odbijających się od sobie i od małych, wąskich RBD w czasie bliskim real time (a zatem bez jakiegoś wysokiego super samplingu). Napisałem również, że Bullet jako taki, nie podnieca mnie specjalnie, bo niestety wszystkie te cuda osiąga za pomocą poważnych uproszczeń, i to niestety widać nawet w najprostszych przykładach. Wieje plastikiem. pozdro., skk. * - Choćby taki kawałek kodu, jak rozwiązywania penetracji wielu obiektów zderzających się jednocześnie. Większość tego zadania trzeba po prostu wykonać szeregowo, albo stawać na rzęsach. Inaczej jest np. z SPH, gdzie można z powodzeniem założyć, że cząsteczki oddalone od sobie o 5 m, nie mają wpływu na siebie, itd itd. Link to comment Share on other sites More sharing options...
MaxymilianMax Posted March 10, 2011 Share Posted March 10, 2011 Monio . TAK to o to chodziło!!. Nie widziałem do dziś nic lepszego. Może na XSI wychodzi znacznie mniej pluginów niż do MAXa ale za to jak juz wychodzą to gniotą konkurencje.. Link to comment Share on other sites More sharing options...
Skoti Posted March 10, 2011 Share Posted March 10, 2011 Wątpię, aby obliczenia na wektorach były gwarantem przydatności obliczeń na GPGPU, to jest jednak uproszczenie*. Akademicka dyskusja. * - Choćby taki kawałek kodu, jak rozwiązywania penetracji wielu obiektów zderzających się jednocześnie. Większość tego zadania trzeba po prostu wykonać szeregowo, albo stawać na rzęsach. Inaczej jest np. z SPH, gdzie można z powodzeniem założyć, że cząsteczki oddalone od sobie o 5 m, nie mają wpływu na siebie, itd itd. Karty graficzne są przystosowane do obliczeń wektorów 4x elementowych i macierzy 4x4 elementowych (w praktyce tylko tym się zajmują - operacjami na wektorach pozycji, normalnej, tangent, binormal, padania światła, kamery, koloru... i macierzy 4x4 transformacji, projekcji, widoku, tekstur, kości...). OFC to nie jest to gwarantem, bo w wypadku jeśli będziemy mieli pesymistyczny kod z obliczaniem wektorów to np. z 1536 rdzeni 6970 będzie działało 96 (w wypadku obliczeń na pojedynczych liczbach w pesymistycznym wypadku będzie to jednak tylko 24) - na GeForce GTX 580 z 512 rdzeni w pesymistycznym wypadku będzie działać w obliczeniach na wektorach 4x elementowych 128 rdzeni (w wypadku danych niewektorowych pesymistyczny wypadek dla tej karty to 32 rdzenie) - lepsze wyniki niż AMD mimo mniejszej całkowitej liczby rdzeni zapewnia sobie mniejszymi SIMD i Dual Warp w nich. Co do gwiazdki to od tego są właśnie struktury danych jak QBVH (Q od quad, bo zarówno 4x jest optymalnym rozwiązaniem dla kart graficznych i SSE/SPE), które jest np. wykorzystywane przy renderingu na GPU (np. Octane) - pozwala na organizację danych, dzięki której wiesz co jest blisko, a co daleko obiektu, a nie musisz sprawdzać wielu ze sobą, więc taka cząsteczka oddalona o 5m nie będzie nawet sprawdzana, bo będzie za daleko w drzewie akceleracyjnym. Nie przyglądałem się algorytmom w branchu Bullet OpenCL, ale nazwa Hier3dGridBroadphase sugeruje, że używają właśnie BVH w jakiejś odmianie. Nie zrozumiałem, co z czym porównujesz, scenę ODE/XSI z ODE/Houdini, DOPsy z ODE w H., czy dwie identyczne sceny ODE w H? Tylko ostatnia ewentualność ma prawo zachować ten sam w wynik w tych samych warunkach. O to właśnie chodzi, że ODE w dwóch aplikacjach zachowa się inaczej, bo jest zbyt wiele elementów, które mogą się różnić, mimo tego samego silnika. BTW kod solvera ODE dla Houdiniego jest otwarty. Możesz go sobie obejrzeć. Nie porównuję ODE/XSI z ODE/Houdini - tylko ODE/Houdini z ODE ;]. Ode zachowa się tak samo w każdej aplikacji, chyba, że to nie jest czysty ODE, a zmodyfikowany kod tylko pod daną aplikację (jednak wtedy nie ma mowy o integracji z silnikiem X, a o integracji z silnikiem Y opartym o X). Co do solvera to podaj link, to jak będę miał trochę wolnego czasu to chętnie zobaczę. Co ty robisz, żeby uzyskać taki efekt? Piszesz dokładnie to samo, co ja, ale zaczynasz zdanie od "wręcz przeciwnie" i dalej eksplikujesz to, z czego sam, najwyraźniej, zdaję sobie sprawę, skoro zwróciłem na to uwagę. "tak samo szybki lub wolny, bez względu na to, czy liczymy go na CPU czy GPU, czy liczy gęstą siatkę czy rzadką" Napisałeś to, a jest odwrotnie - Algorytm nie jest tak samo szybki dla różnych danych - algorytm dla jednych danych jest najszybszy, a dla innych może być najwolniejszym algorytmem - Chyba, że pisząc to miałeś na myśli to co napisałem, ale niezbyt jasno to przekazałeś. Napisałem również, że Bullet jako taki, nie podnieca mnie specjalnie, bo niestety wszystkie te cuda osiąga za pomocą poważnych uproszczeń, i to niestety widać nawet w najprostszych przykładach. Wieje plastikiem. Co w jednych zastosowaniach jest wadą w innych jest zaletą - algorytmy dokładniejsze są zaletą w filmach gdzie nie za wiele jest SB i można się pobawić jakością symulacji - w wypadku kiedy mamy na scenie za dużo SB, aby mówić o rozsądnym czasie liczenia za pomocą dokładniejszych algorytmów, prosta symulacja w Bullet okazuje się świetnym rozwiązaniem i wystarczająco realistycznym. To tak jak z renderami MLT - wszyscy wiemy, że jakość symulacji oświetlenia świetna, ale nikt by ich nie użył do animacji ;]. Link to comment Share on other sites More sharing options...
SYmek Posted March 10, 2011 Share Posted March 10, 2011 Co do gwiazdki to od tego są właśnie struktury danych jak QBVH (Q od quad, bo zarówno 4x jest optymalnym rozwiązaniem dla kart graficznych i SSE/SPE), które jest np. wykorzystywane przy renderingu na GPU (np. Octane) Znów nie czytasz, co piszę, tylko się popisujesz.Owszem, drzewa binarne są dobre do renderingu albo SPH - co napisałem, więc nie musisz tego powtarzać - bo rdzenie mogą liczyć niezależnie od siebie. Natomiast propagacja sił w kolizji kilku obiektów nie może być tak liczona, trzeba je sprawdzać szeregowo, albo przynajmniej cholernie się napocić, żeby zsynchronizować wątki. A to jest tylko prosty przykład. Ergo, założenie, że jak maszyna jest dobra do liczenia wektorów, jest dobra do fizyki jest grubym uproszczeniem. Nie porównuję ODE/XSI z ODE/Houdini - tylko ODE/Houdini z ODE ;]. Ode zachowa się tak samo w każdej aplikacji, chyba, że to nie jest czysty ODE, a zmodyfikowany kod tylko pod daną aplikację (jednak wtedy nie ma mowy o integracji z silnikiem X, a o integracji z silnikiem Y opartym o X). Wystarczy zmienić specyfikację floata i wszystko zacznie działać inaczej. Właśnie to mam na myśli, kiedy mówię, że implementacja implementacji nie równa. Co do solvera to podaj link, to jak będę miał trochę wolnego czasu to chętnie zobaczę. proszę: $HFS/houdini/public/SIM_SolverODE Napisałeś to, a jest odwrotnie - Algorytm nie jest tak samo szybki dla różnych danych - algorytm dla jednych danych jest najszybszy, a dla innych może być najwolniejszym algorytmem - Chyba, że pisząc to miałeś na myśli to co napisałem, ale niezbyt jasno to przekazałeś. Napisałem, że liczy się liniowa wydajność, nawet jeśli prędkość nie jest początkowo zawrotna. A ty na to... tłumaczysz dlaczego x*n jest lepsze od n^2. Hm? Co w jednych zastosowaniach jest wadą w innych jest zaletą. True. pozdro, skk. Link to comment Share on other sites More sharing options...
Skoti Posted March 10, 2011 Share Posted March 10, 2011 Znów nie czytasz, co piszę, tylko się popisujesz.Owszem, drzewa binarne są dobre do renderingu albo SPH - co napisałem, więc nie musisz tego powtarzać - bo rdzenie mogą liczyć niezależnie od siebie. Natomiast propagacja sił w kolizji kilku obiektów nie może być tak liczona, trzeba je sprawdzać szeregowo, albo przynajmniej cholernie się napocić, żeby zsynchronizować wątki. A to jest tylko prosty przykład. Ergo, założenie, że jak maszyna jest dobra do liczenia wektorów, jest dobra do fizyki jest grubym uproszczeniem. Kto tu kogo nie czyta: OFC zajmie to jeszcze trochę czasu (już od końca 2008 roku zaczynali i pewnie najwcześniej wydania pod koniec roku można się spodziewać), i nawet po wydaniu mogą być problemy z tym co dla CPU najłatwiejsze czyli z bryłami sztywnymi, ale idzie to w dobrym kierunku Liczenie na GPU jest super dla SoftBody, Fluidów..., a z bryłami sztywnymi jest największy problem - jednak już kilka lat temu wydanie w Bullet wykrywania kolizji w CUDA pokazało, że zrobili to na GPU stabilniej i wydajniej niż na CPU (a od tego czasu GPU sporo przyspieszyły). PS. QBVH nie jest drzewem binarnym (na co sama nazwa wskazuje). Wystarczy zmienić specyfikację floata i wszystko zacznie działać inaczej. Właśnie to mam na myśli, kiedy mówię, że implementacja implementacji nie równa Ta tylko wtedy nie mówimy o integracji silnika fizyki (tak jak w wypadku właśnie Momentum), ale o jego modyfikacji, bo bez zmian w silniku (tak jak tu, blenderze, cinema, dynamica...) robiąc tylko integrację komunikując się z implementacją silnika za pomocą jego API symulacja jest zawsze taka sama. Napisałem, że liczy się liniowa wydajność, nawet jeśli prędkość nie jest początkowo zawrotna. Nie liczy się liniowa wydajność (chociaż nie wiem czy do końca rozumiem co chcesz przez to powiedzieć - chodzi Ci o złożoność?) - liczy się jak najmniejsza złożoność algorytmu i właśnie najlepiej aby nie była liniowa - liniowy czas (lepszy tylko od wykładniczego czasu) to słaby algorytm dużo fajniejsze są w czasie logarytmicznym lub stałym (podobno fajne SB w o złożoności O(1) jest Fast Lattice Shape Matching ale się nim nie interesowałem głębiej i nie wiem czy ten czas podawany przez nich jest faktycznym czasem czy czasem w specyficznych warunkach). Link to comment Share on other sites More sharing options...
polka dot Posted March 10, 2011 Share Posted March 10, 2011 ależ Wam się panowie algorytmy zapętliły! Link to comment Share on other sites More sharing options...
Artur Paprocki Posted March 11, 2011 Share Posted March 11, 2011 Kiedyś będę miał tyle czasu i to przeczytam bo dużo tu ciekawej treści patrząc po łebkach. Link to comment Share on other sites More sharing options...
SYmek Posted March 11, 2011 Share Posted March 11, 2011 Liczenie na GPU jest super dla SoftBody, Fluidów..., a z bryłami sztywnymi jest największy problem - jednak już kilka lat temu wydanie w Bullet wykrywania kolizji w CUDA pokazało, że zrobili to na GPU stabilniej i wydajniej niż na CPU (a od tego czasu GPU sporo przyspieszyły. Reasumując Gpu jest trudne w użyciu do niemal wszystkiego, co nie jest grafiką online, co nie powinno dziwić, skoro do tego zostało stworzone. Łatwo jest oczywiscie napisać, że swietnie się robi fluidy na Gpu, choć prawda jest taka, ze ich kod na cpu jest znacznie prostszy, ze połowa metod z agebry liniowej słabo się paralelizuje (np. faktoryzacja LU), albo wymaga stałego dostępu do ram i tak dalej. Gdyby Intel miał alternatywę, nikt nie zawracalby sobie głowy gpgpu. Fakt, ze do dzisiaj walcza o solver RBD na Gpu o czymś świadczy. PS. QBVH nie jest drzewem binarnym (na co sama nazwa wskazuje). Racja, zapędziłem się, a co wiecej w tym przypadku ma to znaczenie, bo jest świetnym przykładem na to, jak trzeba stawać na rzęsach, żeby zmusić Gpu do współpracy. Nie liczy się liniowa wydajność (chociaż nie wiem czy do końca rozumiem co chcesz przez to powiedzieć - chodzi Ci o złożoność?) Tak, chodziło mi o złozonosc (gratuluje, zdales test na człowieka). Oczywiście istnieją niższe rzędy złożoności, tyle ze zwykle uważa się, ze od liniowych w dół algorytm jest uzywalny. Upraszczajac oczywiście... (muszę to napisać, bo mam poważne obawy, ze rozmawiam z komputerem). Kończę. Pozdro, Skk. Link to comment Share on other sites More sharing options...
adek Posted March 12, 2011 Author Share Posted March 12, 2011 Symek, Skoti - zdecydowanie muszę więcej pisać o GPU i tego typu rzeczach. Faktycznie, nie da się wszysktiego śledzić, a tutaj naprawdę z postów można się wiele nauczyć. Aż przykro, że skończyliście dyskusję. Bardzo dobrze się to czyta rano z kawą w ręce :) Link to comment Share on other sites More sharing options...
Skoti Posted March 12, 2011 Share Posted March 12, 2011 Reasumując Gpu jest trudne w użyciu do niemal wszystkiego, co nie jest grafiką online, co nie powinno dziwić, skoro do tego zostało stworzone. W niektórych zadaniach jest trudniej wykorzystać GPU, w innych znacznie łatwiej (chociażby liniowe algorytmy, gdzie trzeba wykonywać wiele razy te same obliczenia (np. łamanie haseł aż nieprzyzwoicie dobrze się pisze na GPU ;p)). Łatwo jest oczywiscie napisać, że swietnie się robi fluidy na Gpu, choć prawda jest taka, ze ich kod na cpu jest znacznie prostszy, ze połowa metod z agebry liniowej słabo się paralelizuje (np. faktoryzacja LU), albo wymaga stałego dostępu do ram i tak dalej. Gdyby Intel miał alternatywę, nikt nie zawracalby sobie głowy gpgpu. OFC to jest inny sprzęt i kod jest trochę inny, ale akurat w wypadku fluidów i innych takich obliczeń kod na GPU wcale nie jest bardziej skomplikowany (jedynie trochę inaczej skonstruowany). Fakt, ze do dzisiaj walcza o solver RBD na Gpu o czymś świadczy. Tak - RBD to najtrudniejsza sprawa dla GPU z fizyki, i PhysX też akcelerował do niedawna wszystko poza Rigid Body (do niedawna bo już mają wydajny GPU Rigid Body w PhysX i był już on wykorzystany w Batman: Arkham Asylum). Racja, zapędziłem się, a co wiecej w tym przypadku ma to znaczenie, bo jest świetnym przykładem na to, jak trzeba stawać na rzęsach, żeby zmusić Gpu do współpracy. Nie wiem czy wykorzystanie algorytmu pisanego specjalnie dla CPU z SSE, AltiVec, SPE to stawanie na rzęsach i wykorzystywanego przez renderery liczące na CPU jak i programy graficzne (np. blender 2.5 poza rendererem, korzysta z tej struktury m.in przy sculpcie). To jest po prostu wybranie najlepszego algorytmu do architektury GPU (która z SIMD takimi jak SSE/SPU/AltiVec ma bardzo wiele wspólnego) i osobiście nie widzę tu stawania na rzęsach (w wypadku CPU szybszą alternatywą jest np. Kd-Tree, które nie nadaje się do dynamicznych scen bo trzeba przebudowywać drzewo co klatkę (BVH jak coś się rusza to po prostu powiększysz tylko bound volume i jest (a co ileś tam klatek można sobie pozwolić na optymalizacje drzewa - nie przebudowę tylko optymalizacje - przerzucić jeden obiekt do innej gałęzi i reszty nie ruszać)... do fizyki QBVH po prostu jest najlepszym wyborem niezależnie czy to procek czy karta graficzna)). Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now