Momentum - symulator fizyki dla Softimage

[adek]

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

 

 

[polka dot]

bardzo fajne demko.

[Nezumi]

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.

[Artur Paprocki]

Chyba poza ceną nic nowaterskiego w tym nie ma.Może jeszcze poza faktem że to RGDB,SoftBody,Cloth,DeformedRGBD w 1

[SYmek]

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.

[Nezumi]

Ale jaka logika, SYmek? Powiedz jak ocenic jakosc implementacji bulleta, predkosc dzialania i komfort pracy w pluginie po wyrenderowanym filmiku walacych sie klockow..?

[Kris_R]

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ć.

[MaxymilianMax]

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 :)

[Monio]

lagoa multiphysics?

http://www.max3d.pl/news.php?id=1292

[Nezumi]

MaxymilianMax - wiecej kuleczek to i wrazenie bylo wieksze ;)

[Skoti]

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

[SYmek]

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...

[Skoti]

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ń).

[czaps]

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

[SYmek]

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.

[Skoti]

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).

[Nezumi]

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 ;)

[SYmek]

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.

[MaxymilianMax]

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..

[Skoti]

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 ;].

[SYmek]

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.

[Skoti]

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).

[polka dot]

ależ Wam się panowie algorytmy zapętliły!

[Artur Paprocki]

Kiedyś będę miał tyle czasu i to przeczytam bo dużo tu ciekawej treści patrząc po łebkach.

[SYmek]

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.

[adek]

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 :)

[Skoti]

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)).