Houdini 12

[SYmek]

Dla tych co czekali dobrze, choć moim zdaniem zdecydowanie za wcześnie:

sidefx.com/H12

 

Edytowane 1 Marzec 2012 przez SYmek
ktoś mi to miesza z postami ;)

[safian]

Dobry news, bym przeoczył, bo wczoraj ściągałem jeszcze 11. :D

[legomir]

Ogólnie, jedyne co mi się na usta ciśnie to pogrom ;)

[peters]

Ogólnie, jedyne co mi się na usta ciśnie to pogrom ;)

 

Dobrze to ujales legomir! :D

[SYmek]

Ja jestem trochę zaskoczony. Miesiąc za wcześnie at least. Nowy viewport leży i kwiczy, sporo rzeczy wciąż działa wolniej, niż w H11... kurcze, powinna być publiczna beta, a nie gold.

[legomir]

Ja oceniam po filmikach Mądra kózko jeszcze nie dorwałem tego w swoje łapki... A co do viemportów to tak jest z reguły

[safian]

Strasznie słabiutki transfer póki co, strasznie niecierpliwie się :D.

[ApaczoS]

Dziwny overview...

SYmek, możesz coś powiedzieć więcej o cloth?

[SYmek]

Dziwny overview...

SYmek, możesz coś powiedzieć więcej o cloth?

 

Miarodajnie musiałby się wypowiedzieć jakiś character TD, Kroopson na ten przykład. Z moich testów wynika, że jest niesamowicie stabilny, bez porównania z dawnym solverem, ale z drugiej strony wszystkie fajne ficzery dawnego solvera (rozrywanie, deformacje, atrybuty per point) pozostały.

 

Jak znam życie będzie pewnie brakować jakieś pierdoły, o której może wiedzieć tylko ktoś robiący cloth od 20 lat w Mai ;).

[ApaczoS]

Z moich testów wynika, że jest niesamowicie stabilny, bez porównania z dawnym solverem, ale z drugiej strony wszystkie fajne ficzery dawnego solvera (rozrywanie, deformacje, atrybuty per point) pozostały.

 

No właśnie się tak zastanawiałem co tam poprawili/dodali, bo wiem, że istnieje od kilku ładnych lat. W 2006r Silenta robili właśnie w Hudym(peeling effect) więc chyba ze stabilnością aż takich problemów nie było, żeby nie można było zastosować tego w produkcji(głośno myślę, bo nie bawiłem się clothem w Hudym). Ciekaw też jestem, jak to się ma do maxowego clotha lub Physx glue(Pflow Box 2).

[Creator]

Panowie, powiedzcie mi jak wygląda learning curve tego programu? Czy dla kogoś kto zna dobrze Mayke, Blendera i kilka mniejszych programów, do tego programuje w c++ co nieco i pisze skrypty w melu, będzie trudno się zanurzyć w Houdinim?

Kusi mnie ten soft od dłuższego czasu.

 

ps

Widać ze z kartki czytają, zwłaszcza Pan od 2:48 ;D

[SYmek]

No właśnie się tak zastanawiałem co tam poprawili/dodali, bo wiem, że istnieje od kilku ładnych lat. W 2006r Silenta robili właśnie w Hudym(peeling effect) więc chyba ze stabilnością aż takich problemów nie było, żeby nie można było zastosować tego w produkcji(głośno myślę, bo nie bawiłem się clothem w Hudym). Ciekaw też jestem, jak to się ma do maxowego clotha lub Physx glue(Pflow Box 2).

Sądząc po efektach, nie tyle coś dodali, ale napisali całkiem nowy solver. To naprawdę działa dobrze. Szukałbym bardziej porównania z nClothem i syflexem, niż z physx'em.

 

Co do starego clotha w ogole nie nadawał się do ubrań... (sic!) ludzie gieli nim blachę... był wolny i bardzo niestabilny.

[SYmek]

Panowie, powiedzcie mi jak wygląda learning curve tego programu? Czy dla kogoś kto zna dobrze Mayke, Blendera i kilka mniejszych programów, do tego programuje w c++ co nieco i pisze skrypty w melu, będzie trudno się zanurzyć w Houdinim?

Kusi mnie ten soft od dłuższego czasu.

 

Dla kogoś takiego nauczenie się obsługi jakiegokolwiek programu nie powinno stanowić problemu...

 

Pozdr.,

Skk.

 

Ps większość zaawansowanych użytkowników H. to byli użytkownicy Mai (odwrotnych przypadków nie znam :))

[ApaczoS]

Sądząc po efektach, nie tyle coś dodali, ale napisali całkiem nowy solver. To naprawdę działa dobrze. Szukałbym bardziej porównania z nClothem i syflexem, niż z physx'em.

 

Hmm...w sumie racja, Hudy to taka trochę Maya, aczkolwiek interfejs Hudego bardziej mi leży. A powiedz, bo na pewno coś tam dziergałeś w Pyro, jak z jego szybkością ?(chodzi mi o bardziej zaawansowane twory niżeli dym z cigareta). Pewnie teraz będzie lepiej ale jak to wyglądało do tej pory według Ciebie?

[Creator]

Ps większość zaawansowanych użytkowników H. to byli użytkownicy Mai (odwrotnych przypadków nie znam :))

O taką odpowiedź mi chodziło :D To teraz powiedzcie mi od których tutków najlepiej zacząć? Polecacie jakieś? Te z ich strony są ok?

[tmdag]

Hudy to taka trochę Maya

 

Wszsytkie programy sa w pewnym sensie takie same.. dzialaja na tych samych zasadach wykorzystujac podobne rozwiazania.

 

 

To teraz powiedzcie mi od których tutków najlepiej zacząć?

 

polecam zaczac od przeczytania helpa, naprawde.

[Adam_Guzowski]

A ja mam troszke laickie pytanie.Spotkalismy sie z Hudym jakos tak przy wersji 10 i wszystko bylo "cacy" puki nie trzeba bylo czegos przemodelowac.Toz to tragedia byla.Ja rozumiem ze to soft skierowany dla TD,ale jak wyglada sprawa modelowania w v12? :)

 

[Creator]

Wszsytkie programy sa w pewnym sensie takie same.. dzialaja na tych samych zasadach wykorzystujac podobne rozwiazania.

Jasne, ale jak pierwszy raz odpaliłem Mayke - intuicyjność UI: 3/10 ;)

 

A ja mam troszke laickie pytanie.Spotkalismy sie z Hudym jakos tak przy wersji 10 i wszystko bylo "cacy" puki nie trzeba bylo czegos przemodelowac.Toz to tragedia byla.Ja rozumiem ze to soft skierowany dla TD,ale jak wyglada sprawa modelowania w v12? :)

Pamiętam jak pierwszy raz byłem w pracy i mówiłem, że czasem wolę w Wingsie coś wymodelować i wtedy kolega z działu FX powiedział:

- Możesz sobie modelować w czym chcesz byle to nie był Houdini!

Także musi coś w tym być ;)

[Marshall]

Ja do Hudego przymierzam się od dłuższej ilości czasu (parę miesięcy temu posiedziałem chwilę na 11, obejrzałem GoProcedural i w sumie na tym stanąłem).

Jestem użytkownikiem Mayki - i myślę że radzę sobie w niej całkiem nieźle od modelowania przez animacje aż po (głównie) dynamikę.

Ogółem zastanawiam się czy warto jest tak na prawdę siadać do Hudego (Pyro itd ogółem rzeczy do dynamiki) skoro większość studiów swój pipeline opiera (póki co jeszcze) na Mayce.

 

I teraz moje pytanko - czy dla kogoś kto dopiero przymierza się do nauki skyptowania (python) Hudy jest dobrym "krokiem do przodu" ?

Czy może lepiej łyknąć trochę skryptu i dopiero zasiąść do Hudego?

 

P.S

Jeżeli ktoś zna jakieś dobre tutki/ref do nauki pythona to byłbym wdzięczny :).

 

 

Pozdrówka

[SYmek]

A powiedz, bo na pewno coś tam dziergałeś w Pyro, jak z jego szybkością? (chodzi mi o bardziej zaawansowane twory niżeli dym z cigareta). Pewnie teraz będzie lepiej ale jak to wyglądało do tej pory według Ciebie?

 

Dymy są po prostu szybkie, bardzo. Sprawdź, zrób testy porównawcze, nie ma co bić piany. Szkopuł tkwi w tym, co z czym się porównuje. Fluidy Mayowe zawsze były szybkie, ale niedokładne, bo miały uproszczony model fizyczny. To samo jest z clothem, może physix jest szybki, ale czy jest wystarczająco dokładny i stabilny, aby symulować fotorealistycznie 4 warstwy ubrań?

 

Fluidy w Houdinim zawsze były bardzo dokładne, ale wolne. Wolne głównie przez problemy z architekturą kontenerów danych. Wiele z przyspieszań w H12 bierze się po prostu z tego, że zapis do pamięci może być wielowątkowy, a do tej pory, nawet jeśli symulacja używała wiele wątków, zapis robił tylko jeden. To wciąż jest poważny problem Houdiniego na wielu polach. Na przykład nigdy nie należy robić dużych symulacji w viewporcie. Po ustawieniu sceny, należy odpalić hscripta i włączyć symulacje z linii komend. To zajmuje chwilę, a przyspiesza symulacje np. o 40%. Należy także pamiętać, że fluidy w H. od wersji 11 można posyłać na farmę na kilka komputerów, to nie tylko przyspiesza, ale umożliwia symulacje, które nie mieszczą się w jednym Ramie, jak na przykład ten grzyb (obrazek pochodzi z forum bety h12, symulacja zajmowała około 250GB ramu):

 

[ATTACH=CONFIG]84947[/ATTACH]

 

Ten grzybek ma 1600x2048x1600=5.5miliarda voxeli. Sam density field zajmuje jakieś ~5GB na dysku dla jednej klatki (i dla 32 bitowych danych, choć można dane zapisać także jako half float).

 

 

A ja mam troszke laickie pytanie.Spotkalismy sie z Hudym jakos tak przy wersji 10 i wszystko bylo "cacy" puki nie trzeba bylo czegos przemodelowac.Toz to tragedia byla.Ja rozumiem ze to soft skierowany dla TD,ale jak wyglada sprawa modelowania w v12? :)

 

Poza udogodnieniami w viewporcie (preselection highlights) nie ma wiele zmian w modelowaniu. To po prostu nie jest narzędzie do tego (poza przypadkami modeli proceduralnych).

 

 

Ogółem zastanawiam się czy warto jest tak na prawdę siadać do Hudego (Pyro itd ogółem rzeczy do dynamiki) skoro większość studiów swój pipeline opiera (póki co jeszcze) na Mayce.

 

http://forums.cgsociety.org/showthread.php?f=86&t=1034527

 

Używaj, co lubisz :)

Edytowane 2 Marzec 2012 przez SYmek

[ca mel]

A jak jest z wielowątkowością cząsteczek w Hudym? Zakładając pojedynczy emiter, dziesięć tysięcy cząsteczek i goal

dla cząstek na podstawie uv - zadziała to na jednym wątku czy użyje całego procesora ?

Ostatnio zjadłem na czymś takim zęby w mai, genialni panowie z autodesku zrobili nucleus który używa 10% cpu

i wszelkie poważniejsze symulacje idą jak krew z nosa.

Jak jest w Houdinim, ma wielowątkowe cząsteczki ?

[SYmek]

A jak jest z wielowątkowością cząsteczek w Hudym? Zakładając pojedynczy emiter, dziesięć tysięcy cząsteczek i goal

dla cząstek na podstawie uv - zadziała to na jednym wątku czy użyje całego procesora ?

Ostatnio zjadłem na czymś takim zęby w mai, genialni panowie z autodesku zrobili nucleus który używa 10% cpu

i wszelkie poważniejsze symulacje idą jak krew z nosa.

Jak jest w Houdinim, ma wielowątkowe cząsteczki ?

 

Selektywnie. Emiter zadziała w jednym wątku, goal po uv w VOPPOPie w wielu...POPy są w tej chwili najstarszym elementem Houdiniego, nawet tuż przed premierą 12 usunęli dodatkowy POP emiter z FLIPA, bo spowalniał całość.

 

But here is a hint: W Sopach istnieje teraz SOPSolver, wchodzisz do środka, odtwarzasz wszystkie POPy za pomocą Vexa, co już od dawna robi większość 'prosów' w Popach), i masz w pełni wielowątkowe cząsteczki. Fizyka cząsteczek jest na tyle prosta, że odtworzenie większości POPów samemu nie jest żadnym problemem (zarówno wewnątrz POPów jak i SOPów).

 

W takim przypadku prosta symulacja (adwekcja noisem), daje na przykład 0.2 sekundy dla 1 miliona cząsteczek (dwa rdzenie mojego laptopa na 100%), oraz 2 sekundy dla 10 milionów cząsteczek (oba przypadki 5 substepów). Jednak wystarczy, że dodasz DragPOP, i wydajność spada o 4 sekundy dla 10 milionów cząsteczek. Czyli unikać zwykłych nodów w POPach i robić wszystko VOPami, a będziesz miał w pełni wielowątkowe środowisko.

 

Inna sprawa, że do symulacji cząsteczek możesz dodawać siły z SPH czy Flipa, czyli jak Ci się zachce możesz nagle dodać ciśnienie powierzchniowe, albo gęstość, chociaż cała symulacja wciąż będzie "ręczna".

[ca mel]

But here is a hint: W Sopach istnieje teraz SOPSolver, wchodzisz do środka, odtwarzasz wszystkie POPy za pomocą Vexa

 

W takim przypadku prosta symulacja (adwekcja noisem), daje na przykład 0.2 sekundy dla 1 miliona cząsteczek (dwa rdzenie mojego laptopa na 100%), oraz 2 sekundy dla 10 milionów cząsteczek (oba przypadki 5 substepów). Jednak wystarczy, że dodasz DragPOP, i wydajność spada o 4 sekundy dla 10 milionów cząsteczek. Czyli unikać zwykłych nodów w POPach i robić wszystko VOPami, a będziesz miał w pełni wielowątkowe środowisko.

 

Właściwie wielowątkowy emiter nie wyobrażam sobie do czego miałby być potrzebny ;) Chodzi mi właśnie o wielowątkowe sterowanie particlami skryptem. Te czasy, które opisujesz przy milionach cząstek są dla mnie totalnym szokiem, chociaż zauważyłem że nawet na jednym wątku maya póki chcesz od niej prostej symulacji działa w miarę sprawnie.

Z niezrozumiałych dla mnie jednak powodów, w chwili gdy przy kreacji cząstki dostaje współrzędne u i v miejsca gdzie docelowo ma polecieć, symulację szlag trafia i dzieje się wszystko dziesiątki razy wolniej niż na zdrowy rozum powinno.

Oczywiście póki goal nie ma uv, a wybierany jest losowo, na podstawie numerów wierzchołków obiektu wszystko działa w miarę sprawnie,

jednak jak chcemy czegoś konkretnego to zaczynają się schody.

 

Jeśli cząstki w Hudym działają tak sprawnie, nawet z delikatnym spadkiem wydajności po przyłączeniu pól siłowych,

to i tak jest dziesiątki razy lepiej niż w mai. Prosta dość symulacja, ok 10k cząstek z dołączoną turbulencją i goal wg uv to godzina

obliczeń dla 50ciu klatek, przy jednym wątku topowego procesora, wszystko przy wyłączonych zależnościach między cząstkami.

Albo kochany nucleus jest jakimś delikatnie mówiąc nieporozumieniem, albo cały program jednak należy napisać od nowa.

 

W Hudym zaś wszystko wydaje mi się jakieś skomplikowane, choćby samo budowanie assetów to czarna magia;]

Z cząsteczkami (w H.) zacząłem zabawy jakiś czas temu, ale rzuciłem to w cholerę po tym jak odkryłem, że gdy ginie jakaś cząstka (bo ma np przypadkowy czas życia) to zmieniają się ID wszystkich pozostałych... Pewnie dla kogoś z doświadczeniem taki problem jest śmieszny,

ale zauważyłem że ten program ma w sobie tyle zaskakujących rzeczy że łatwo się zaciąć na czymś delikatnie mówiąc nietypowym. A szkoda, bo komplikuje to strasznie próby przestawienia się na na pewno świetne narzędzie.

[SYmek]

Z niezrozumiałych dla mnie jednak powodów, w chwili gdy przy kreacji cząstki dostaje współrzędne u i v miejsca gdzie docelowo ma polecieć, symulację szlag trafia i dzieje się wszystko dziesiątki razy wolniej niż na zdrowy rozum powinno

 

Na chłopski rozum cząsteczki próbkują geometrię klatka po klatce, aby dostać pozycje w świecie z uv. Jeśli sampler jest wolny i jednowątkowy będzie to działać wolno, także w Houdinim, jeśli spróbujesz to zrobić ekspresją, ale na szczęście jest VEX :)

 

ale rzuciłem to w cholerę po tym jak odkryłem, że gdy ginie jakaś cząstka (bo ma np przypadkowy czas życia) to zmieniają się ID wszystkich pozostałych... Pewnie dla kogoś z doświadczeniem taki problem jest śmieszny,

ale zauważyłem że ten program ma w sobie tyle zaskakujących rzeczy że łatwo się zaciąć na czymś delikatnie mówiąc nietypowym. A szkoda, bo komplikuje to strasznie próby przestawienia się na na pewno świetne narzędzie.

 

He, he, zmieniają się numery punktów, ale ID cząsteczek (dodatkowy atrybut właśnie na tę okoliczność) zostaje niezmienne i nigdy się nie powtarza... po prostu w cząsteczkach używamy $ID, a nie $PT. Tak to bywa z tymi programami :)

 

 

W Hudym zaś wszystko wydaje mi się jakieś skomplikowane, choćby samo budowanie assetów to czarna magia;]

 

Ważne są podstawy, czym się różni atrybut od zmiennej, jak zbudowana jest geometria i jak działają ekspresje i VEX. Reszta jest logiczną konsekwencją powyższych. Możesz nie wiedzieć, jak nazywa się node robiący to a to, ale sam program więcej cię nie zaskoczy. Jest przerażająco logiczny (z urokliwymi wyjątkami ;) ).

Edytowane 2 Marzec 2012 przez SYmek

[ca mel]

Na chłopski rozum cząsteczki próbkują geometrię klatka po klatce, aby dostać pozycje w świecie z uv. Jeśli sampler jest wolny i jednowątkowy będzie to działać wolno, także w Houdinim, jeśli spróbujesz to zrobić ekspresją, ale na szczęście jest VEX :)

 

Też doszedłem do podobnych wniosków, że nie tylko nowy nucleus jest totalnym niewypałem, ale problem tkwi głębiej w trzewiach programu. Smutne to, że program o niemałych możliwościach, do dziś nie potrafi sobie radzić w rozsądny sposób z dość trywialną sprawą.

 

 

He, he, zmieniają się numery punktów, ale ID cząsteczek (dodatkowy atrybut właśnie na tę okoliczność) zostaje niezmienne i nigdy się nie powtarza... po prostu w cząsteczkach używamy $ID, a nie $PT. Tak to bywa z tymi programami :)

 

No proszę, wystarczyło zapytać mądrych ludzi a nie obrażać się na program.

Żyłem w przekonaniu, że $PT to skrót od ParTicle i że to to samo co ParticleId w mai ;]

 

 

Ważne są podstawy, czym się różni atrybut od zmiennej, jak zbudowana jest geometria i jak działają ekspresje i VEX. Reszta jest logiczną konsekwencją powyższych. Możesz nie wiedzieć, jak nazywa się node robiący to a to, ale sam program więcej cię nie zaskoczy. Jest przerażająco logiczny (z urokliwymi wyjątkami ;) ).

 

Tu też, wydawało mi się, że VEX i ekspresje są tym samym, ale chociaż w mai z melem jestem za pan brat, to nie próbowałem skryptów w H.

Maya też wydaje mi się bardzo logiczna i niestety uczy różnych myślowych przyzwyczajeń, choćby expressions piszę się w melu, a do numeru cząsteczki dobrać się można tylko dzięki ID a nie bezpośrednio po numerze punktu geometrii z której wyparowała. No ale tak to jest gdy zamiast czytać helpa ogląda się tutoriale omijające całe tony podstaw ;]

Kusi w każdym razie bardzo ten Houdini, głównie szybkością. Gdyby maya była wielowątkowa nie myślałbym chyba o zmianach, bo uważam, że to dobry kawał softu. Ale staje się przeraźliwie powolna w dzisiejszych wymagających czasach, a nie zapowiada się żeby autodesk coś z tym zaczął robić.

 

Anyways, dzięki za naświetlenie kilku fajnych spraw, chęć do odkopania H wraca ;]

[ApaczoS]

nigdy nie należy robić dużych symulacji w viewporcie. Po ustawieniu sceny, należy odpalić hscripta i włączyć symulacje z linii komend. To zajmuje chwilę, a przyspiesza symulacje np. o 40%.

 

Nie zdawałem sobie z tego sprawy, dzięki, przyda się:)

 

 

Należy także pamiętać, że fluidy w H. od wersji 11 można posyłać na farmę na kilka komputerów, to nie tylko przyspiesza, ale umożliwia symulacje, które nie mieszczą się w jednym Ramie, jak na przykład ten grzyb (obrazek pochodzi z forum bety h12, symulacja zajmowała około 250GB ramu):

 

Ten grzybek ma 1600x2048x1600=5.5miliarda voxeli. Sam density field zajmuje jakieś ~5GB na dysku dla jednej klatki (i dla 32 bitowych danych, choć można dane zapisać także jako half float).

 

Holy crap! Fajny detal, ciekawe ile to szło. Lubię takie testy wytrzymałościowe.

W zeszłym roku Bobo z Thinkbox Software testował Krakatoa na expercie:) Udało się wypuścić 7mld particli przy 256gb ramu, dla mnie to sci-fi ale ciekawie sprawa wygląda:

http://www.thinkboxsoftware.com/news/2011/8/30/7bpf.html

 

Ciągnie do tego Hudego cholernie, trzeba sobie chyba lepiej organizować czas:)

Dzięki SYmuś za obszerną odpowiedź;)

[czaps]

Symek a jak jest ze wsparciem Fluidów na GPU i Fermi ?

 

Reklamowali swego czasu, że ma być to wsparcie. Pytanie czy to tylko na Tesli jako silnik i Quadro jako display czy da radę na jednej lub dwóch kartach typu Geforce / Fermi ?

 

Sam render cząstek kilku "ładnych milionów" w mantrze , z resztą z Twoją pomocą na starcie wykrzywił mi gębę pozytywnie...

 

Nie ma co tu porównywać nawet tego z Mayą ...

 

pozdro

 

czaps

[SYmek]

Nie zdawałem sobie z tego sprawy, dzięki, przyda się:)

Holy crap! Fajny detal, ciekawe ile to szło. Lubię takie testy wytrzymałościowe.

 

28 minut na klatkę, ale na jakiejś monster maszynie.

 

W zeszłym roku Bobo z Thinkbox Software testował Krakatoa na expercie:) Udało się wypuścić 7mld particli przy 256gb ramu, dla mnie to sci-fi ale ciekawie sprawa wygląda:

http://www.thinkboxsoftware.com/news/2011/8/30/7bpf.html

 

No jak lubisz, to tutaj ponad miliard cząsteczek we Flipie i ich render:

[ATTACH=CONFIG]84953[/ATTACH]

 

Symek a jak jest ze wsparciem Fluidów na GPU i Fermi ?

Reklamowali swego czasu, że ma być to wsparcie. Pytanie czy to tylko na Tesli jako silnik i Quadro jako display czy da radę na jednej lub dwóch kartach typu Geforce / Fermi ? (...)

 

Jest akceleracja fluidów gridowych (dymki) na GPU. Kilka mikro-solverów ma toggle włączający wsparcie dla OpenCL. Działa bardzo przyjemnie o ile wystarczy Ci vramu. Idzie na każdej karcie z Cuda, nawet nasze stare Quadro 3500/3600 fx działają (choć wolniej niż 8 rdzeni CPU...). Ludzie robią testy na Gforcach.

 

Na przykład porównanie GeForce GTX 470 z i7 930 @ 2.80ghz 4 Cores/8 threads:

 

Grid: 256^3

OpenCL: 853.19 ms. na klatkę

CPU : 8.35 sek. na klatkę

[czaps]

Na przykład porównanie GeForce GTX 470 z i7 930 @ 2.80ghz 4 Cores/8 threads:

 

Grid: 256^3

OpenCL: 853.19 ms. na klatkę

CPU : 8.35 sek. na klatkę

 

Hmm no to tak jak się spodziewałem ,,,, trzeba powoli robic FLIP ;))

 

Zobaczymy czy Nowa Maya też będzie miała to samo wsparcie. Jeśli tylko dla TESLI / Quadro tak jak na to wszystko wskazuje to hmmm ... Flip , FLIP ;)

 

dzeki

 

czaps

[SYmek]

Algorytm czy nowy ficzer nie powinien być powodem zmiany narzędzia. Nie daj się zwariować :) Mam ci napisać, do czego Houdini się nie nadaje? :)

[czaps]

Algorytm czy nowy ficzer nie powinien być powodem zmiany narzędzia. Nie daj się zwariować :) Mam ci napisać, do czego Houdini się nie nadaje? :)

 

Nie , nie musisz tego wypisywać ;) THX

 

pozdro

 

czaps

[legomir]

a ba Geforce 250 moge robić symulacje w hudym?

[przems]

Należy także pamiętać, że fluidy w H. od wersji 11 można posyłać na farmę na kilka komputerów, to nie tylko przyspiesza, ale umożliwia symulacje, które nie mieszczą się w jednym Ramie, jak na przykład ten grzyb (obrazek pochodzi z forum bety h12, symulacja zajmowała około 250GB ramu):

 

[ATTACH=CONFIG]84947[/ATTACH]

 

Ten grzybek ma 1600x2048x1600=5.5miliarda voxeli. Sam density field zajmuje jakieś ~5GB na dysku dla jednej klatki (i dla 32 bitowych danych, choć można dane zapisać także jako half float).

 

a tam, trochę cierpliwości i stara szkapa Maya też potrafi, dzisiaj wypuściłem takiego nuke-grzybka-

1500x1500x1500 box ;) jako przykład że da się na 1-nym Ramie, możliwe że i więcej by się dało wydusić...

ja poczekam aż zrobią w Houdym postęp z meshowaniem fluids jak w Rf i efektami jak krakatoa, wtedy zacznę myśleć o mozolnej nauce.

[tmdag]

ja poczekam aż zrobią w Houdym postęp z meshowaniem fluids jak w Rf i efektami jak krakatoa, wtedy zacznę myśleć o mozolnej nauce.

 

a co jest nie tak z aktualnym meshowaniem?

I o jakich 'efektach krakatoa' mowisz?

[przems]

a co jest nie tak z aktualnym meshowaniem?

I o jakich 'efektach krakatoa' mowisz?

 

zrobili coś w stylu hybrido? ;) w mayce na upartego można też robić fluidy, albo oparte na particles albo ten fluid container do którego niby jest przeznaczony tyle że nie efektywne trochę to jest...

z krakatoa takie coś jak to-

[ApaczoS]

zrobili coś w stylu hybrido? ;)

 

Nie liczyłbym, że jakikolwiek soft(Maya, Hudy, Max, Softimage) dostanie takie wsparcie. Nie bez powodu Real Flow jest oddzielną aplikacją.

Krakatoa to volumetric particle renderer, czyli taki Vray do particli. Nie ma tam spektakularnych efektów, robisz je sam w systemie particli.

[tmdag]

zrobili coś w stylu hybrido? ;)

 

Prostymi slowami - Flip solver to hybrydowe polaczenie systemu symulacji czasteczek z voxelowym.

'hybrido' jest wlasnie takim FLIP solverem.

Sam FLIP solver zostal wprowadzony do houdiniego w wersji 11 a w wersji 12 dostal bardzo duzego przyspieszenia.

Niestety nie mialem za duzo czasu na testowanie houdiniego 12 bo to za wczesnie na wprowadzanie go do pipeline ale kolega barejko robiac szybkie testy przekazal mi :

"Houdini 2mln partikli vs 600 000 Realflow

Houdini 5 klatek vs Realflow 1 klatka"

Lecz bez wzgledu na predkosc, Houdini ma bardzo duza przewage nad innymi softami z powodu 'sop solvera' w ktorym na poziomie symulacji mozna wprowadzac bardzo latwo swoje wlasne nody i bez potrzeby skryptowania manipulowac symulacja dowoli zmuszajac np taki fluid to czegokolwiek chcesz. Solver sam w sobie jest otwarty i mozna go przerobic badz nawet zbudowac swoj wlasny solver na nowo

Dla przykladu :

 

 

 

Ale nadal nie wiem co masz na mysli mowiac o tym meshowaniu bo wg mnie meshowanie w houdinim to wlasnie duza przewaga nad rf i naiad i wszystkie fluidy wlasnie meshuje w houdinim ktoryjako jedyny daje mi bardzo ladna, quadowa siatke i wiele roznych algorytmow meshowania do wyboru.

 

 

Krakatoa to tak jak wspomnial Apaczos to renderer wiec tez bys musial sprecyzowac o jaki 'efekt' ci chodzi .. O ruch tych czasteczek czy shader?

Jedno i drugie jest to uzyskania w houdinim.. Spod palca moge tylko zalinkowac jakies proste testy kolegi macha z roku 2010:

Edytowane 4 Marzec 2012 przez tmdag

[czaps]

Przems

 

A kto tutaj mówi , że w Maya czy innym sofcie się "nie da" ?

 

1500x1500x1500 rozumiem , ze to wielkość containera / rozdzielczość grida? i static grid ? to możesz sobie to jeszcze nawet do 5000 powiększyć śmiało... też da radę w Mayi na jednym ramie...

 

pozdro

 

czaps

[przems]

1500x1500x1500 rozumiem , ze to wielkość containera / rozdzielczość grida? i static grid ? to możesz sobie to jeszcze nawet do 5000 powiększyć śmiało... też da radę w Mayi na jednym ramie...

 

czaps -density.velocity/temperature/fuel-dynamic grid ...of course, trwało to kilka godzin, raz maya wpadła w kartofle.

 

w takim trzeba będzie zacząć obserwacje, pod kątem kilku spraw, niestety jedynym ograniczeniem jest długość dnia ;)

[czaps]

czaps -density.velocity/temperature/fuel-dynamic grid ...of course, trwało to kilka godzin, raz maya wpadła w kartofle.

 

w takim trzeba będzie zacząć obserwacje, pod kątem kilku spraw, niestety jedynym ograniczeniem jest długość dnia ;)

 

Czyli jednym słowem .... da się ;) w każdym sofcie , w jednym dłużej innym krócej itd. itp. kwestia gustu i indywidualnych przwyczajeń pewnie no i... cierpliwości przede wszystkim.

 

Pozdro

 

czaps

[SYmek]

a tam, trochę cierpliwości i stara szkapa Maya też potrafi, dzisiaj wypuściłem takiego nuke-grzybka-

1500x1500x1500 box ;) jako przykład że da się na 1-nym Ramie, możliwe że i więcej by się dało wydusić...

 

Hej, bardzo fajny rezultat, dzięki. Jak przypuszczałem, maya rulez! :) Pewnie 80% wszystkich fluidów jest robiona w Mai, i to od wielu, wielu lat, dla mnie to pionierzy. Problem o ile mi wiadomo polega na tym, że to black box, co fabryka dała, a jak ci się look nie podoba, to masz problem. Niemniej 1500^3 jest imponujące. Ile ramu to zjadło? Możesz to zrzucić na dysk do jakiegoś formatu i zmierzyć, ile zajmuje density field? Jaką to ma głębię bitową?

 

zrobili coś w stylu hybrido? ;)

 

Nie liczyłbym, że jakikolwiek soft(Maya, Hudy, Max, Softimage) dostanie takie wsparcie..

 

Widzę, że tu totalne zamieszanie panuje. Jak Albert napisał hybrido to marketingowa nazwa flipa w RF, który podobnie jak Naiad i Houdini przeskoczył na inny pomysł z SPH, ponieważ SPH jest kompletnie nieskalowalne, złożoność obliczeń rośnie wykładniczo do ilości cząsteczek.

 

Flip wprowadzili do branży ludzie od Naiada: http://www.cs.ubc.ca/~rbridson/docs/zhu-siggraph05-sandfluid.pdf implementując go zdaje się najpierw w softwarze dla MPC. Jest dostępny w Houdinim od wersji 9.0, (2007!), jako Sand Solver, ale oczywiście nie nadawał się do niczego poważnego.

 

Coś w tym jest, że program do wszystkiego, nigdy nie będzie tak sprawny w jednej dziedzinie, jak dedykowana aplikacja, ale kombajn wnosi swoje dobre strony. Jak Albert zauważył, może render-time meshing w RF jest sexy, ale w produkcji, kiedy jakość siatek ma znaczenie, kiedy je poprawiasz, selektywnie cieniujesz, fakt, że masz do dyspozycji całe SOPy i VEX ma gigantyczne znaczenie.

 

(Na marginesie, render-time meshing w HDK robi się w 15 minut. Wszystko, co potrzebne jest gotowe, nie rozumiem, dlaczego SESI tego nie napisało...)

 

Odnoszę wrażenie, że problem polega na tym, że patrzycie na aplikacje przez pryzmat fajnych ficzerów (szczególnie gdy są nowe, i widziane na vimeo), a tak naprawdę a aplikacji liczy się pipeline, a nie ficzer.

 

Jeśli chodzi o wydajność nowego Flipa, jestem zupełnie spokojny. Stoi łeb w łeb z RF2012, co zostało sprawdzone na tej scenie:

 

 

ja poczekam aż zrobią w Houdym postęp z meshowaniem fluids jak w Rf i efektami jak krakatoa, wtedy zacznę myśleć o mozolnej nauce.

 

E, tam. Ludzie od Mai też nie śpią i pewnie smażą teraz nowy update, podejrzewam, że chodzi o gruntowną przebudowę Mai na w pełni proceduralny pakiet. Jest to jedna rzecz, która Mai brakuje. Zły model abstrakcji, zły dostęp do danych, skopana obiektowość.

 

Co do Krakatoa, jest to fajna rzecz, ale ponieważ w H. od co najmniej 5 lat renderuje się do 80 milionów cząsteczek, chęć przyjrzenia się wersji SR jest jakby mniejsza. W H12 można na domowej maszynie renderować miliardy cząsteczek. Znów, dedykowane narzędzie ma pewnie wiele zalet, ale możliwość całego systemu trudno jest przecenić. Koniec końców wybiera się pipeline, a nie sexy ficzer. :), chyba że nie ma się wyboru, wtedy robi się wszystko w pluginach czekając, aż ogólnoświatowy postęp umożliwi zrobienie ujęcia, które wszystkie potem wyglądają tak samo...

Edytowane 4 Marzec 2012 przez SYmek

[przems]

a dziękuję, czasem coś tam wyjdzie;) do pełni realizmu można by było pokusić się o przełączenie z chmury volume na surface

wówczas efekt byłby miazga realistyczny, niestety na domowym sprzęcie raczej para by poszła w pudła...

[tmdag]

Flip wprowadzili do branży ludzie od Naiada: http://www.cs.ubc.ca/~rbridson/docs/zhu-siggraph05-sandfluid.pdf implementując go zdaje się najpierw w softwarze dla MPC.

 

poprawiam jako ciekawostke - Jeden z tworcow Naiada pracowal dla DoubleNegative/UK i wlasnie tam napisal pierwszy solver, jako plugin pod maya. Co ciekawe jest on na tyle dobry, ze firma nadal korzysta z tego i nie maja zamiaru przesiadac sie na Naiada ;)

 

MPC zas, korzysta z flowline, strorzonego przez niemiecka firme Scanline.

[SYmek]

DN nie Mpc, dzięki Albert.

[przems]

E, tam. Ludzie od Mai też nie śpią i pewnie smażą teraz nowy update, podejrzewam, że chodzi o gruntowną przebudowę Mai na w pełni proceduralny pakiet. Jest to jedna rzecz, która Mai brakuje. Zły model abstrakcji, zły dostęp do danych, skopana obiektowość.

 

true, nie znam Mai12 ale aż prosiłoby się o rozwiązania w stylu nodów jak w Houdini, pełna kontrola tego na czym zależy w danym momencie. Na podobne zwrócił uwagę Macha (z przykładów) zmęczył go system pipelines jak twierdził. Ekipa robi postępy, np.ostatnio naprawili system shards na voronoi, mocno niedoskonały w poprzednich wersjach. Tym większa zaleta konkurencji ekipy od Houdiniego że inne firmy zmuszone są brać się za robotę aby utrzymać poziom i klientów.

 

ps. co do pomiarów "chmury" podczas animacji brało cał ram 12gb, proc. ok 20%. Na prawdziwe pomiary miałbym możliwość gdybym pracował gdzieś...i na renderfarmie, nie domowym pc

Edytowane 4 Marzec 2012 przez przems