[Houdini]Podpinanie parametrów particli pod shader

[mathix]

W jaki sposób podpiąć atrybuty z POP netowork pod parametry shadera?

 

Mam taką sytuację:

zrobiłem popneta ze Sprite nodem na końcu. Następnie stworzyłem SOP-a z POP Mergem, którym importuję przygotowane cząsteczki. Na SOP-a zawierającego zaimportowane particle nałożyłem Procedural Shader typu Mantra: Sprite Procedural i zwykły surface shader z parametrem id. Nie wiem co zrobić, żeby surface shader używał cząsteczkowego parametru id.

 

UPDATE:

Poradziłem sobie :P przepraszam za niepotrzebny wątek. Wystarczy dodać nazwę atrybutu w shaderze typu Mantra: Sprite Procedural, w polu Attributes :]

[SYmek]

no właśnie! ;)

 

Smażysz coś smacznego? Będzie można zobaczyć?

 

pozdr.,

skk.

[mathix]

Smażysz to niewłaściwe określenie jako, że robię śnieg ;P Jak mi wyjdzie to wrzucę hipa.

 

Strasznie wolno się renderują sprite'y w houdinim na mantrze. Pewnie mam takie wrażenie, bo w mayi renderują się bardzo szybko jako, że wszystko leci na GPU.

[SYmek]

Owszem, porównanie jest nie fair ;). A można w Mai nadać im dowolny shader - także swój - rzucają cienie, jest na nich motion bur, można zmieniać tekstry w zależności od Pz i można je liczyć na farmie? Słyszałem o tych spritach wiele dobrego, ale nie wiem na ile są tak naprawdę elastycznym narzędziem.

 

Piszę teraz exporter do enginu realtime dla H. poczekaj jakieś pół roku, to będziesz sobie mógł policzyć sprity z H. na GPU ;)

 

pozdr.,

skk.

[mathix]

To Ci odpowiem: nie można ;]

 

Oo ciekawa sprawa. Houdini + DirectX, czy eksporter pod jakiś gotowy engine?

[SYmek]

Gotowy, opensource engine (i raczej na OpenGL ;) ).

[mathix]

Nono fajne. Eksporter skrypcisz czy programujesz w HDK?

 

Jak w HDK to mam kilka pytań ogólnych: obiektowe to jest jak nowe API mentala czy strukturalne jak WinAPI i DirectX?

 

EDIT:

SYmek wiesz może skąd przy robieniu surface shaderów w VEX builderze wyciągnąć wektor prędkości liczonego punktu w układzie współrzędnych kamery?

[SYmek]

Wszystkie zmienne w shaderze powierzchni są w camera space... :)

Krótko mówiąc, cały świat w IFD jest opisany względem kamery. Wyjątkiem mogą być te zmienne, które są wołane wewnątrz illumiance loop (na przykład L), te są zdaje się w przestrzeni obiektu. Czyli jakbyś liczył lambera to obie zmienne w tym:

-dot(N, normalize(L))

są w object space.

 

HDK? Zwariowałeś? Chyba bym oszalał, przecież ja ledwo dukam w C++. Python. Stanowczo Python ;)

Poza tym, właśnie po to napisano SOHO, żeby przy pisaniu exporterów nie trzeba było sięgąć po HDK. Przecież większość exporterów ma banalnny kod i konieczność ciężkiego programowania w C nie ma w tych przypadkach sensu. Używając SOHO za pomocą kilku liniek kodu inicjującego dostaję pełny opis sceny. A wszystko odbywa się z prędkoscią C++, bo SOHO to przecież funkcje HDK z pythonowskim interfacem...

 

pozdr.,

skk.

[mathix]

No to muszę się przyjrzeć możliwościom skryptów w Houdinim. Python spoko, chociaż ja dla odmiany znam lepiej C++ i pewnie ten stan rzeczy sie utrzyma z racji studiów :P

 

A taki wygodny eksport by mi się bardzo z Houdego przydał.

[SYmek]

Jak znasz c++ nic Cię nie zatrzyma! Tego Ci zazdroszczę ;).

 

Zajrzyj do katalogu soho. Masz tam przykład exportu do pygame, który ma 300 linii kodu. Nie da się łatwiej.

 

pozdr.,

skk.

[mathix]

Nie trzeba zazdrościć, wystarczy kupić książkę i zacząć się uczyć :)

 

Noo nieźle to wygląda. Będę się musiał dokładniej tej bibliotece przyjrzeć.

[SYmek]

Nie trzeba zazdrościć, wystarczy kupić książkę i zacząć się uczyć

... dobre sobie, tylko gdzie ja na to znajdę czas? ;)

[mathix]

Z tym niestety nie pomogę :)