Skocz do zawartości

Rekomendowane odpowiedzi

Napisano
Czyli tlumaczac z pedalskiego na polski po prostu system partikli:P A co do mayi i architektury jej to sie nawet nie wypowiadajcie jesli nie siedzicie w tym sofcie i nie skryptujecie.

 

Coz za miazdzaca argumentacja :D

I co? Chcesz zmienic rzeczywistosc czy moze przekrzyczec wszystkich?

ICE Deform to tez tylko partikle? Node z jakimkolwiek kodem to nadal partikle wedlug ciebie?

Cytat z CGSociety (pogrubienia do przemyslenia. Myslenie to taki proces poznawczy, w ktorym starasz sie dociec prawdy a nie tylko przekonac wszystkich wokolo ze masz racje):

"ICE will allow artists to explore, learn and modify the robust library of particle-based visual effects and deformation tools that will ship in SOFTIMAGE|XSI 7 software, or simply build new ones from scratch."

  • Odpowiedzi 95
  • Created
  • Ostatniej odpowiedzi

Top Posters In This Topic

Napisano (edytowane)

Zabawna wymiana opinii, jeśli można to tak nazwać.

 

Jeśli chodzi o meritum sprawy: ICE najwyraźniej kontroluje wszystkie atrybuty geometrii w scenie, a szczególnie atrybuty punktów. Do czego to grafikowi posłuży, jego wola. Z pewnością nie jest to tylko system cząsteczkowy.

 

Co do Houdiniego i jego cząsteczek: Ice NIE jest odpowiednikiem POPs w H. Jest połączeniem POPs (Particles Operators), VOPs (VEX Operators) i częściowo HDA (Houdini Digital Assets), czyli tego, co w XSI nazywa się Compounds.

Jeśli to już gdzieś było to tylko w Houdinim, który z tego co mi wiadomo nienajlepiej radzi sobie z wielowątkowością jak na razie (choć tu mogę się mylić).

Rzeczywiście POPs nie są wielowątkowe, kiedy je pisano, tj. 10 lat temu, nie było takich zabawek PC. To, że w ogóle wytrzymują porównanie z nowszymi systemami jest miarą ich jakości, choć rzeczywiście są wolniejsze od większości nowych systemów cząsteczkowych. Tyle o POPs. Natomiast VOPsy są wielowątkowe, działają w architekturze SIMD i są bardzo szybkie. Dowcip polega na tym, że wszystko, co mogę zrobić w POPsach, mogę też zrobić w VOPsach i tak się obecnie robi trudne sylumacje w Houdinim. Rodzi się cząsteczki w POPs, ale wszystkie operatory tworzy się w VOPs obchodząc w ten sposób wąskie gardło leciwej architektury. Edytowane przez SYmek
Napisano

SYmek - za cienki jestem w nadgarstkach zeby dojsc do tego - czy zatem nowe XSI umozliwi stworzenie jakichs roslin podobnych tym ktore ptakun onegdaj wystrugal w houdinim? Rozrzucic je ladnie po terenie z pewnoscia bedzie mozna ale co z sama geometria..? Z tego co doczytalem na xsibase to nody - nawet custom nodes - nie moga tworzyc geometrii. Co z roslinami wiec..? Pozostaje rozrzucanie po terenie wariacji podanej geometrii?

 

----

 

Nie karm trolla Nezumi, nie ma sensu. Jesli gosc uwza ze ICE = Particle, to niech tak sobie uwaza :)

true.

Napisano
Rzeczywiście POPs nie są wielowątkowe, kiedy je pisano, tj. 10 lat temu, nie było takich zabawek PC. To, że w ogóle wytrzymują porównanie z nowszymi systemami jest miarą ich jakości, choć rzeczywiście są wolniejsze od większości nowych systemów cząsteczkowych. Tyle o POPs. Natomiast VOPsy są wielowątkowe, działają w architekturze SIMD i są bardzo szybkie. Dowcip polega na tym, że wszystko, co mogę zrobić w POPsach, mogę też zrobić w VOPsach i tak się obecnie robi trudne sylumacje w Houdinim. Rodzi się cząsteczki w POPs, ale wszystkie operatory tworzy się w VOPs obchodząc w ten sposób wąskie gardło leciwej architektury.

 

Czyli SESI ma jeszcze duzo do zrobienia ;)

A jak dobrze dziala wielowatkowosc w hudym? Tzn. ile rdzeni moze efektywnie wykorzystac? 2, 4, 16? Pytanie tyczy sie rowniez Mantry i DOPs.

Napisano

Ale mogą tworzyć instancje (jest takie słowo?) za pomocą różnych nodoów możesz kotrolować/ generować sobie linie ich kształt (turbulencje) długości itp. Do tego dojdzie też pewnie kolizja między elementami. Nie widze problemu żeby generować cudne roślinki z ICE'm.

Napisano

Proponuję ICE-a na każdą rozpaloną głowę, tak dla ochłody...

Mimo wszystko trochę wiedzy z programowania i tak trzeba będzie mieć lub ją zdobyć. Pewnie będzie dobry updejt dla userów, ale nadchodzą chyba także czasy nauki rendermana...

Napisano

Nezumi, wydaje mi się że za pomocą ICE można zrobić rośliny, ale wymaga to trochę prostej matmy. Mianowicie trzeba osiągnąć skończone zapętlenie przypominające fraktale. Trzeba by było stworzyć w ICE "skrypt" który tworzyłby kopie twojego obiektu odpowiednio pomniejszone, usadowione na twoim obiekcie i tak dalej na kopiach tego obiektu. Wystarczyło by wtedy modelować samą łodygę a wszystkie kopie wyglądały by tak samo lub dodać jakiś dodatkowy deformator by zachowywały się jak konkretne rozgałęzienie. Coś w tym stylu.

Napisano (edytowane)

piotrek:'To te czasy już dawno temu nie nadeszły?'

 

Dla xsi?

W tej chwilli mental też szybko może stać się 'wąskim gardłem', co widać na filmikach promocyjnych ICE, a właściwie jego brak (mentala).

Edytowane przez peteRlo
Napisano

Rośliny w Ice na pewno jakieś da się wydziubać, chociaż z moich dotychczasowych obserwacji wynika, że jak na razie panowie skupili się tylko na modyfikacji istniejących punktów, czyli roślinka bedzie z kawałków - każdy nowy, rosnący element nie byłby połączony z resztą siatki, co raczej i tak nie jest zbyt wielkim problemem. Nie widze tu potrzeby od razu zanużania się w pętle, bo to chyba zbędne, programistyczne podejście do tego zadania. Zwykła emisja partikli, które rodzą kolejne galęzie-particle.

Napisano

mokramyszka666 zgadzam się z tobą do pewnego stopnia, twój sposób jest dobry jeśli tworzymy roślinę która jest bardzo gęsto uliściona i ma drobne gałązki z drzewami i innymi większymi roślinami byłby problem. Struktura rośliny wygląda na chaotyczną ale jest bardzo uporządkowana każda następna odrośl ma wyznaczoną odległość od poprzedniej a odległości te są malejącym ciągiem(chyba)geometrycznym, dla każdej rośliny różnym. Pętla była by tu najlepszym rozwiązaniem bo dała by nam dużą kontrole oraz prostą strukturę, a po wygenerowaniu wystarczy użyć jakiegoś modyfikatora siatki i gotowe. Tworzenie roślinek proste i przyjemne.

Napisano

Nie jasno się wyraziłam. Przecież po wymemitowaniu kolejnej gałązki na poczatku małej, wręcz niewidocznej, możesz przeprowadzić na niej szereg deformacji określając i animujac kształt. Nawet po wyemitowaniu swoich 'podgałązek' dany fragment może ciągle roznąć, wyginać się w stronę światła grać na flecie czy robić inne rzeczy. Ja bym to nazwała raczej rekurencją niż klasyczną pętlą.

Napisano (edytowane)
Czyli SESI ma jeszcze duzo do zrobienia ;)

A jak dobrze dziala wielowatkowosc w hudym? Tzn. ile rdzeni moze efektywnie wykorzystac? 2, 4, 16? Pytanie tyczy sie rowniez Mantry i DOPs.

 

Wszystko zależy od przypadku. To nie jest Afx czy Max, które są w miarę spójnymi środowiskami (mniej więcej). Houdini to jest system operacyjny, a nie pojedynczy program.

 

Największym kłopotem Houdiniego jest to, że GUI działa w jednym wątku. Większość operatorów działa zatem w jednym wątku. Ale VOPS (Vex tak naprawdę) to jest język programowania, który z definicji działa na dowolnej ilości wątków. Tak działa SIMD. Wyjątkiem są operacje na Point Cloudach, które źle działają w wątkach (dzielony dostęp/zapis do pliku, ciężka sprawa). W ich przypadku czasem trzeba wyłączyć wielowątkowość.

 

DOPs są generalnie wielowątkowe, ale w tym przypadku to nie oznacza liniowego przyrostu, a raczej minimalny. Każdy mikro solver na własny sposób stara się dzielić pracę na wątki. Na przykład detekcja kolizji w cloth solverze jest wielowątkowa, ale pozostałe mikro solvery w Cloth solverze już nie... i tak dalej.

 

Mantra jest wielowątkowa prawie w całości (np. generowanie shadow map chyba nie jest), ale to wcale nie znaczy, że należy używać max dostępnych rdzeni w każdym przypadku. I to wcale nie jest przypadłość Mantry. Generalnie czasami lepiej jest liczyć na mniejszej ilości wątków. Kłopot Mantrze w tym temacie czynią głównie instancje. Trzeba robić testy i liczyć sekundy... innej drogi nie ma.

 

 

SYmek - za cienki jestem w nadgarstkach zeby dojsc do tego - czy zatem nowe XSI umozliwi stworzenie jakichs roslin podobnych tym ktore ptakun onegdaj wystrugal w houdinim? Rozrzucic je ladnie po terenie z pewnoscia bedzie mozna ale co z sama geometria..? Z tego co doczytalem na xsibase to nody - nawet custom nodes - nie moga tworzyc geometrii. Co z roslinami wiec..? Pozostaje rozrzucanie po terenie wariacji podanej geometrii?

 

To jest takie gdybanie, trudno powiedzieć. Na pewno w XSI, nawet bez ICE można zrobić piękną roślinność. Jeśli chodzi o cuda ptakuna, to kluczem do sukcesu nie są LSystemy czy VOPsy, tylko renderowanie. Najmocniejszą stroną Houdiniego, zaraz po fizyce, jest sposób w jaki Mantra wpięta jest w ten program. Przecież tych kwiatów w ogóle nie ma. Ptakun ich nie modeluje. Powstają w rendererze, za pomocą shaderów i atrybutów rendertime primitives, podobnie jak PRMan liczy włosy. Dlatego może ich być miliony.

 

Na koniec: o ile rozumiem, o co biega w ICE, to nie jest to po prostu wizualny język skryptowania, jak niektórzy tutaj sądzą. ICE nie wykonuje poleceń w takim sensie jak Python czy JScript. ICE *modyfikuje* atrybuty na geometrii, którą mu podasz. Z definicji działa jak loop, iterując po elementach obiektu, czy będą to particle, czy skin.

 

pozdro.

Edytowane przez SYmek
Napisano

'ICE *modyfikuje* atrybuty na geometrii, którą mu podasz. Z definicji działa jak loop'

Nikt nie twierdził, że jest inaczej. Czyż jądrem niemalże każdego programu nie jest jeden, główny 'loop'? Niewiele twoje stwierdzenie zmienia, prawdę powiedziawszy. Tak czy inaczej są funkcje - tutaj node'y - które orzymują paremetry na wejściu i zwracają jeden lub kilka rodzajów wartości. W moim mniemaniu na tym głownie polega programowanie - na kontrolowanym przepływie danych. Skoro z założenia operacja jest wykonywana na zbiorze punktów to logiczne że albo ty sam, albo tak jak w tym przypadku - system - czynność iteracji będzie musiał wykonać.

Napisano
'ICE *modyfikuje* atrybuty na geometrii, którą mu podasz. Z definicji działa jak loop'

Nikt nie twierdził, że jest inaczej. Czyż jądrem niemalże każdego programu nie jest jeden, główny 'loop'? Niewiele twoje stwierdzenie zmienia, prawdę powiedziawszy. Tak czy inaczej są funkcje - tutaj node'y - które orzymują paremetry na wejściu i zwracają jeden lub kilka rodzajów wartości. W moim mniemaniu na tym głownie polega programowanie - na kontrolowanym przepływie danych. Skoro z założenia operacja jest wykonywana na zbiorze punktów to logiczne że albo ty sam, albo tak jak w tym przypadku - system - czynność iteracji będzie musiał wykonać.

 

hmm... chyba wziąłeś do siebie coś, co miało innego adresata, zresztą bliżej nieokreślonego. Powiedziałem tylko, że taki moduł jak ICE nie jest General Purpose Script Editor, którym można automatyzować czy modyfikować dowolne parametry sceny (typu: stwórz torus, przesuń w prawo, nadaj mu materiał, zdeformuj, a potem skopiuj x1000). Bardziej przypomina shader, niby kawałek kodu, ale wykonywany w bardzo specyficznym kontekście, właśnie w pętli i na homogenicznych elementach kolekcji, inaczej nici z SIMD. Zresztą wiesz, o czym mówię ;)

 

pozdr.,

skk.

Napisano
ok.ok.

Jeszcze jedna sprawa. Symek: czy jesteś pewien że w dobrym kontekscie używasz skrótu SIMD? bo odnosze wrażenie że stosujesz go zamiennie z multithreadingiem, co nie do końca jest słuszne.

 

Jeśli tak, to z pośpiechu ;) To oczywiście nie jest to samo. Wykorzystanie SSE nie oznacza wielowątkowości, ale czyni ją łatwą do wykonania. Albo inaczej, jeśli zadanie nadaje się dla SSE, to prawie na pewno łatwo je paralelizować.

Napisano

No tak chyba nie do końca ;) To że można jakieś obliczenia sprowadzić do postaci wektorowej (gdzie najcześciej jest wykorzystywane SSE) nie musi oznaczać od razu prostego zadania dla wielowątkowości.

Napisano
No tak chyba nie do końca ;) To że można jakieś obliczenia sprowadzić do postaci wektorowej (gdzie najcześciej jest wykorzystywane SSE) nie musi oznaczać od razu prostego zadania dla wielowątkowości.

 

No chyba nie do końca ;). Pożytek z SSE będzie żaden, jeśli dane, które poślemy do enginu nie będą uporządkowane (lineup). To jest wymóg SIMD, aby mógł je załadować równolegle do rejestrów i wykonać jednocześnie tę samą operację.

 

Jak sądzę, to jest właśnie powód, dla którego SIMD jest poręczny w grafice, tablice (na przykład raster) doskonale spełniają powyższy wymóg. Podobnie działa wielopotokowy engine GPU.

 

A skoro kilka elementów kolekcji można obrabiać jednocześnie (dowolnych elementów) to znaczy, że samą kolekcję również można podzielić i obrabiać jednocześnie w kilku wątkach. Ergo związek SIMD z wielowątkowością... :)

 

pozdr.,

skk.

Napisano

No jednak się nie zgodzę ;P. 128-bitowe rejestry SSE mieszczą po 4 floaty i każda operacja na rejestrach działa za jednym razem na nich wszystkich (stąd Single Instruction Multiple Data). Uporządkowanie (a właściwie wyrównanie) nie jest konieczne, ale znacznie przyspiesza odczyt/zapis do pamięci - nic poza tym (tablice wyrównuje się do 16bajtów).

 

Masz rację że sprawdza się to w grafice (początki tego były już przecież w MMX, które są niczym innym jak SSE na integerach). Jednak welowątkowy (czy jak to nazwałeś wielopotokowy) GPU to już inna bajka. GPU tak samo jak CPU składają się z rdzeni (najnowsze mają już chyba po 256). Jenak w przypadku grafiki sprawa jest o wiele prosta. Np. rendering trójkątów, vertex shaderów czy po rostu fragmentu ekranu to kwestia podzielenia wszystkiego na równe kupki - po każdej dla rdzenia i tyle.

w Przypadku CPU i obliczeń w 3d, sprawa wygląda inaczej. Najbardziej mylisz się co do przekonania o możliwości wykonywania obliczeń na kilku DOWOLNYCH elementach jednocześnie. Tu własnie nie ma dowolności, ani 'kilku alementów'. SIMD nie pozwalają na obliczenia na kilku punktach jednoczesnie. Dają mozliwość wykonania obliczenia na dokładnie 4 zmiennych typu float. w intelach to po prostu instrukcje do operacji na wektorach. Korzystając z nich zamiast liczyć każdą składową osobno, traktujemy pozycję lub inna warotość wektorową jako jedną zmienną. Można je wykorzystac w każdej funkcji operującej na punktach w 3D i znacznie przyspieszy to działanie (2-3 krotnie), ale (!) nie oznacza to że można tą funkcję łatwo przepisac na wielowątkowość. Ponieważ :) może się okazac, że wynik obliczenia dla pozycji jakiegoś wierzchołka jest zależny od pozycji innego, który siłą rzeczy musi być policzony wczesniej. W takiej sytuacji sprawa wielowatkowości bardzo się komplikuje, a często jest to niemożliwe.

Napisano

ja też wole czytać bardziej treściwe posty ale fajnie byłoby jescze coś z tego rozumieć :D przy dłuższych wypowiedziach się poddaje gdzieś w połowie jakby były pisane w innym języku ;)

 

a tak btw kto to jest ten XSI zna go ktoś :D :D

Napisano

Dziwny ten swiaaaaaat..... jest.. la la. Dziwne jest to, ze tak mocne narzedzie jest tak malo znane. Znowym ICEem wgniata. Xsi na chlopski rozum - to taka mayka: lepiej ubrana, lepiej napisana, z lepszymi narzedziami (wbudowanymi), bardziej intuicyjna - odnosnie animacji i riggowania, skinowanie - najlepsze na swiecie ;] , Jezeli chodzi o modelera.. to myslalem, ze ciezko mi sie bedzie przesiasc z wysluzonego maxa - po krotkim czasie doszedlem do wniosku, ze zylem/pracowalem w sredniowieczu.

Napisano (edytowane)

Uznalem ze nie bede zasmiecal kolejnym newsem i wrzuce to tutaj:

 

Online XSI 7 Launch Event

 

Czwartek w poludnie czasu wschodniego nastapi onlajnowe, oficjalne odpalenie XSI7. Mam nadzieje, ze oznacza to rowniez iz na przeciazonych serwerach Softimage'a pojawi sie trial XSI7 ;)

 

[edit]

No i doczkalo sie newsa na glownej :D

 

[edit]

No jasne ze w poludnie a nie o polnocy...

Edytowane przez Nezumi
Napisano

Zawsze mialem problemy z tym problemy przez lacine... P.M. = post meridiem czylo PO poludniu. a 12 godzin PO poludniu wypada o polnocy, stad mi sie pierniczy ;) Dzieki za poprawke :D

Napisano

Jak ogłądałem - i mam jeszcze większą ochtę dorwać go w swoje łapki :) Co cieszy jest bardzo dużo compounds dla particli, które sprawiają, że ich tworzenie jest równie proste jak w maxowym particle flow

Z innej strony przyznaje racje Symkowi - jak ma się dużo nodów, to kod jednak jest wygodniejszy, no bo zkumaj o co chodzi w takim np. zestawie:

ice1gr9.jpg

ice1gr9.5c6bf02a48.jpg

Napisano

Nie musisz kumac o co chodzi w takim zestawie.

 

Zrobia to za Ciebie inni, udostepniajac gotowe do sciagniecia sety ;)

 

 

Bylem sceptyczny, ale jak poczytalem wypowiedzi beta-testerow, to sie troche uspokoilem;)

Napisano

Poza tym jak dostajesz od razu set to przytlacza jego skomplikowanie i nie wieadomo o co biega. Ale ide o zaklad ze jak sam go robisz to sie doskonale orientujesz.

Napisano

Tylko jak za pół roku do niego wracam to i tak już nie pamiętam co robiłem... całe szczęście, że można grupować, komentować i zagnieżdżać kolejne compundy. I ciągle licze na node do pisania kodu -na video nigdzie nie widziałem.

Napisano

Boziu, ilu się programistów znalazło, a zwykle słychać było utyskiwania "ja nie chcę programować, chcę tworzyć, jestem artystą!" ;)

Napisano

"ja nie chcę programować, chcę tworzyć, jestem artystą!"

Jedno drugiemu nie przeszkadza :)

 

Ja nie da się tego zrobić za pomocą kodu to rzeczywiście troszkę lipa, ale nie koniec świata.

Napisano

Hehehehe...., Symek ;D

 

wracajac...

 

jak ma się dużo nodów, to kod jednak jest wygodniejszy

 

Mercedes w pewnym momencie jest lepszym wyjsciem niz Maluch. Tylko ze nie wszyscy maja Merca, a Maluchem, chociaz wolniej i mniej wygodniej, tez dojedziesz.

 

;)

Napisano

No to nie jest dobre porównanie - bo maluch nie ma żadnych atutów przy mercu... bardziej, że bolid (mało ludzi potrafi jeżdzić, ale daje ogromne możliwości choć nie jest za wygodny) jest czasem lepszy od powiedzmy forda (dużo ludzi potrafi jedździć, jest wygodny, ale też nie ma takich osiągów)

Jeśli chcesz dodać odpowiedź, zaloguj się lub zarejestruj nowe konto

Jedynie zarejestrowani użytkownicy mogą komentować zawartość tej strony.

Zarejestruj nowe konto

Załóż nowe konto. To bardzo proste!

Zarejestruj się

Zaloguj się

Posiadasz już konto? Zaloguj się poniżej.

Zaloguj się



×
×
  • Dodaj nową pozycję...

Powiadomienie o plikach cookie

Wykorzystujemy cookies. Przeczytaj więcej Polityka prywatności