SYmek

Osobiście nie poruszałem żadnej z zalet technicznych architektury reyes celowo, aby nie wdawać się w rozmowę o wyższości jednej techniki nad drugą, ale rozmawiać o jego filozofii, bo tutaj jest, moim zdaniem, clue sprawy. Na przykład, gdybym miał się zabawić w advocatus diaboli, powiedziałby, że cóż mi w ad 2011 z szybkiego displecementu, którego nie da się pogodzić z szybkim raytracem? Gros efektu, o który chodzi dzisiaj w CG opiera się na tym drugim, nie pierwszym. Zarówno rendertime subdivision jak i displacement były potężną bronią w czasach 32bitowych komputerów, kiedy siatka 100K poly zabijała render. Dzisiaj chłopcy na domowych pecetach liczą miliony poligonów w sekundę albo dwie i jak trzeba, zagęszczają siatkę we viewporcie, który te miliony ciągnie w realtime. I tak można bez końca... Szybki disp., rozmycie ruchu, głębia ostrości? Tak, ale są tego koszty, i nie koniecznie one czynią z prmana standard w filmie. Choć oczywiście to przyjemne nie wiedzieć, co to jest post-pro motion blur... :)

Konkretnym rozwiązaniem będzie wyłączyć gdzieś pre-multiply, ale nie wiem, w którym miejscu, bo jak mówiłem, nie mam Nuke'a na podorędziu. ps Co do uwag językowych, chodziło mi nie tyle o terminy, co o pisownie, bo zarówno "alfa" jak i" maska" przyjęły się w j. polskim. Nie jestem purystą, co łatwo stwierdzić, czytając moje wypowiedzi. Szukam po prostu jakiegoś konsensusu w tej sprawie :).

To raczej kwestia pre-multiplikacji. Niestety nie mam Nuke przed sobą, więc nie pomogę, ale tak z innej beczki: "dodawanie masek" albo "mask addition", ale nie oba jednocześnie. Podobnie "alfę", nie "alphe". Coraz więcej takich koszmarków, swoją drogą, ja to rozumiem, sam mam z tym problem, ale jak się potem czyta takie intro do V-Raya, opublikowane na tym forum niedawno, to ręce opadają... Skoro informatycy potrafią utrzymywać kulturę języka, to graficy też powinni potrafić. Bez obrazy :) pozdro, skk.

Adsk tradycyjnie nie udostępnia triala pod Linuksa. edit: piotrek był szybszy...

Dla mnie super! Drobiazgi z czasem się dotrą. Dzięki!

http://cgru.sourceforge.net/afanasy/doc/index.html Ten radziecki skurczybyk daje radę...

@jaras,Baggins: nie mam pojęcia o czym mówicie, żadnych osobistych wycieczek w swojej wypowiedzi nie widzę, gratuluję autorowi efektu i przyznaję, że znać technikę to jedno, a użyć jej twórczo do drugie. Za negatyw mimo wszystko dziękuję. skk.

Prawda. Blurowanje iluminacji dla uzyskania efektu wielokrotnego rozproszenia swiatla wewnatrz obiektu (BSSRDF) jest stare jak sama grafika 3D, tylko nie kazdemu udaje sie uzyskac tak ladne* obrazki i to jest chyba zasadnicza roznica :) To nawet dosc zabawne patrzec jak sie komus wydaje, ze odkryl Ameryke, ale Nenow ma prawo, w koncu jest rez., a nie TD, a prawde mowiac przecietny przedstawiciel srodowiska Maxa wie tyle o 3D, co Hemingway o drukarstwie. Tak czy inaczej swietna robota, gratulacje! Skk. * - dlaczego pisze sie o nich "fotoreal" skoro sa wyraznie stylizowane?

Nie mam pojęcia o co chodziło, ale jest kawałek filmu. Gratulacje! pozdrawiam, skk. ps Co do szczegółów, to odnoszę wrażenie, że cokolwiek zlekceważyliście pre produkcje, czyli koncepty i scenariusz... ps mam też wątpliwość natury ogólnej, dlaczego szkoła wybiera/godzi się na projekty w całości animowane, czyli najtrudniejsze? Zrobić pełnowartościową animację po niespełna roku nauki graniczy z cudem, co musi mieć swoje odbicie w efekcie końcowym.

http://www.oscars.org/press/pressreleases/2011/20110819.html

A ten pan zajmuje się Houdinim jakieś dwa lata, może trzy - toż to on nawet H8 nie widział, nie mówiąc o H4.1 :), no i mieszka na wschodzie, w Japonii.

Słyszałem, że ludziom zdarza się wyprać kota, ale mp4? Gdzie tu sens... :)

Nie zrozumieliśmy się. Prowincjonalizm != prowincjonalność. A dwa, że najlepszą oznakę tego pierwszego, jest właśnie ustawiczna potrzeba potwierdzania, że tak nie jest, czyli szukanie polskich nazwisk w creditsach abo zapatrzenie w "innych", o co się żachnął Nezumi. W sensie, że jakiekolwiek? Poza galerią SESI, z której właściwie tylko prace ptakuna dają radę, nie znam wielu przykładów. http://www.sidefx.com/images/stories/community/gallery/cactus_full.jpg http://forums.odforce.net/index.php?/topic/5534-flowersos-difussos/page__view__findpost__p__37541 edit: andy boyd ma niezłą kolekcję (ale nie wszystko to mantra): http://www.andyboyd3d.com/cgwork.htm

Video (breakdown) na pierwszej stronie wywiadu. Jak na moją umiejętność liczenia, to jakieś 22 lata ;), ale masz rację, prowincjonalizm mamy we krwi. Lata treningu.

A tu taki ładny smoczek zrobiony w mentalu :) http://www.pixologic.com/interview/framestore/1/

Od blisko roku już nie ;) Dokładnie. Nie ma co teraz wchodzić w szczegóły. Skomplikowana sprawa, tym bardziej, że akurat mental ray może bardzo wiele w kwestii kontroli, ale od strony API, a nie tego, co udostępniają aplikacje. Załączam przykład... pozdro, skk. ps W tej scenie jest jedna kula z jednym materiałem, trzy lustra z jednym materiałem i podłoga z jednym materiałem + 4 światła. Można by też podmienić jedno odbicie na zupełnie inny model, ale czas mnie goni, sorry! edit: zwróć uwagę, że odbicia także rządzą się swoimi prawami jeśli chodzi o światła i cienie, czego być może nie widać na tym przykładzie, poza cieniami właśnie.

Zgódźmy się, że potrzebne są kompetencje. W moim przekonaniu na poziomie jednak wyższym od studenckiego. Owszem, to archwizer bez kompresji, pakujący drzewo katalogów. Sceny Houdiniego można rozpakowywać/pakować, a wszystkie jej elementy są plikami. To świetne rozwiązanie dla plików do kilkudziesięciu megabajtów, ale już nie gigabajtów.

To bez znaczenia. Plugin, nie plugin, zawsze to będzie znane pierwszoligowe komercyjne narzędzie kontra Blender, jeśli mówimy o decyzjach ludzi z biznesu (w firmach, studiach etc) - a ja wypowiadam się wyłącznie o znalezieniu przez Blendera miejsca w profesjonalnym biznesie.

Wymaga wiedzy technicznej, bo wszystko, o czym piszesz jest wiedzą techniczną. Niczego innego nie miałem na myśli, jak właśnie to, że trzeba wiedzieć jakie dane chcemy zapakować i w jaki sposób powinny leżeć na dysku/w pamięci, aby dostęp do nich był efektywny. Jak to nie jest wiedza techniczna, to jaka!? Przecież nie twierdzę, że chodzi o znajomość składni jakiegoś języka. No, a jeśli wiedza o tym, jak dane opakowane obiektami C++ leżą w pamięci, jaki jest koszt dostępu do nich, jak się to ma do L1,2,3 procerora, jak wybrany typ zmiennej ma się do rejestrów procesora i jakie to wszystko ma znaczenie dla efektywności pracy na twoich danych NIE jest, Twoim zdaniem, wiedzą programistyczną to albo nie wiesz o czym mówisz (wątpię), albo znów, dla zabawy gadasz głupoty, więc może przestań trollować? Tak, mi również się to podoba, od 12 lat Houdini tak zapisuje swoje dane, do wirtualnego systemu plików kompresowanych na dysku do formatu cpio (7zip na przykład otwiera pliki *.hip, jak zwykłe archiwa pokazując całą hierarchię sceny, jako ścieżki /path/etc). Tyle tylko, że to jest sposób elegancki i elastyczny, a nie wydajny. Collada to inny temat, stracony w pewnym sensie od początku, bo jeden uniwersalny format dla całej sceny, uwzględniający całą branżę, nie może przecież być idealny. Podobnie jest w przypadku FBX, choć pisała to jedna firma. W każdym razie, takie coś, z definicji, nie może zadowolić wszystkich. Być może ten kompromis jest najlepszą rzeczą, jaka mogła się Colladzie zdarzyć. Nie wnikałem w szczegóły. Za dwa lata Cycles będzie miał owe 90%, ale tych 10% mieć raczej nie będzie, to jest zasadniczy punkt wypowiedzi, tym bardziej jeśli zaraz zacznie się go przepisywać do OpenCL, a potem do czegoś jeszcze i jeszcze i tak bez końca. To w ogóle nie jest możliwe na poziomie pro. W tym cały sęk.

Ha, ha, znam ja już ten Twój lekceważący stosunek fachowca do technologii. Jasne, nie wymaga wybitnej wiedzy i właśnie dlatego mamy tyle wydajnych kontenerów danych... give me a break. Poza tym, owe "dogadywanie się" i stojące za tym lata doświadczeń w branży, jest ważniejsze od pisania. Mieć pomysł na software to nie jest prosta rzecz. Udane produkty zaczynają się od pomysłu, który je wyróżnia. Odnoszę wrażenie, że Blender wciąż jest na poziomie małpowania, a nie kreowania, ponieważ skupiony jest na udowadnianiu, że potrafi tyle, co komercyjne pakiety. Zresztą, może to i dobra strategia, nie wiem. Owe 10% przepaści między programem dla zapaleńców, a programem dla biznesu oznacza po prostu, że dymki w Blenderze będą się musiały mierzyć z fumefx, Cycles z Vrayem a włosy z shave&haircut itd. To jest znacząco inna perspektywa, niż entuzjazm fanbojów, jaki towarzyszy nowością prezentowanym na youtubie. Anyway, ja tu nie dyskutuje nad perspektywami Blendera, która najwyraźniej są bardzo dobre, tylko nad przekonaniem, że skoro pokonało się owe 90%, te 10% to kwestia następnych kilku 2.x. Bynajmniej.

Problem z tym całym Blenderem jest taki, że większość nowinek, które oglądam jest totalnie niedorobiona. To jest 90% roboty, często świetnej, ale najtrudniejsze jest właśnie ostatnie 10%. Prototyp idzie łatwo, a do ostatecznego produktu często nigdy nie dochodzi. Życzę Blenderowi jak najlepiej, przypuszczam że core aplikacji jest bardzo solidny (choć te ngony?), ale przykładowo pisany od zera przez jednego studenta system cząsteczkowy jeszcze przez wiele lat nie będzie TP, ICE czy POPs. To nie jest takie proste, jak się wydaje. Przykład "z pierwszej strony gazet": napisanie binarnego formatu geometrii leży w zasięgu początkującego programisty. Tymczasem dwie wielkie, legendarne firmy VFX w asyście kilku gigantów biznesu, okrągły rok piszą Alembic, który jest w dodatku oparty o gotowe rozwiązanie... i to pisane zdaje się przez NASA, od lat, na potrzeby astrofizyków. Czujecie różnicę? Inżynieria programowania na poziomie, którego wymaga ta branża, to coś więcej niż dobre chęci zapalonych studentów. Choć oczywiście, jeśli jest ich wystarczająco dużo i działają wystarczająco długo... tylko gdzie wtedy będą już komercyjne produkty?

Cholera, chyba coś napiszę... Houdini ma jeden własny renderer, Mantrę, tyle że przychodzi z portami do rendermanów (PRMan, 3delight, Air) i pewną, ograniczoną możliwością współpracy z mental rayem (tzw. nie wspiera materiałów mr, bo jest to raczej ficzer dla dużych studiów, które radzą sobie same, a Houdini ma po prostu dostarczyć im pliki *.mi). Plusy: Mantra to renderer hybrydowy, ma w sobie zarówno architekturę REYES, czyli taką jak rendermany, jak i zwykły ray tracing. Posiada poza tym wydajny, w pełni produkcyjny path tracing. W sumie daje to cztery tryby pracy: full reyes, full ray trace, full path trace (tzw. Pysical Based Redering, czyli PBR), oraz MB PBR, czyli path tracing wymieszany z REYES, czyli Mantra tworzy mikropoligony, tak jak renderman, ale shading odbywa się w trybie path tracingu. Po co? Ano w ten sposób masz fizycznie poprawny shading, ale motion blur czy dof równie szybki jak REYESach czyli rendermanach. Owszem jest to skomplikowane, ale daje niesamowitą elastyczność. Możesz tymi trybami żonglować zależnie od potrzeb. Tryby się także mieszają, nawet w zwykłym REYES, możesz wywołać funkcję, która użyje ray/path tracingu. Mantra posiada programowalny engine cieniujący, czyli shadery, podobnie jak w rmanach, pisze się w specjalnym języku dającym praktycznie nieskończone możliwości dostosowywania powierzchni do swoich potrzeb. Co więcej ten engine stosuje się także do path trace. Cały PBR jest zaimplementowany w VEX, łącznie z MIS, czego nie ma żaden inny renderer, od prmana po Arnolda (jak próbowano wbudować w Arnolda OSL, zwolnił 100 razy). Co to znaczy? To znaczy na przykład, że cały mechanizm generowania fotonów, albo próbkowania świateł area, jest dostępny do użytkownika. Żadnych czarnych skrzynek, wszystko można zmieniać. Oczywiście kontrolowanie shadingu, czyli decydowanie, co w czym, od czego, kiedy i na jakich warunkach się odbija jest na poziomie prmana, czyli mental czy Vray mogą sobie tylko o tym pomarzyć (bez pluginów). Po prostu nie ma tak, że czegoś nie da się skontrolować, ograniczyć, wymusić. To jest programowalny ray tracing. Każdy ray pod kontrolą. Jeśli chcesz, żeby jeden obiekt odbijał się w innych obiektach za każdym razem innym kolorem, voila, no problem! Mantra nie jest najszybszym path tracerem, ani ray tracerem, ani REYESem, ale we wszystkich dyscyplinach trzyma się wysoko, a ponieważ przychodzi za darmo z Houdinim, w relacji cena/możliwości naprawdę nie ma sobie równych. Właśnie dlatego nieduże studia coraz częściej liczą w niej swoje duże projekty, żeby nie wydawać grubej kasy na rendermana (taki prman dla ubogich), duże natomiast liczą w niej cząsteczki i wolumetrykę. Dodaj do tego, że wyrenderowanie 50 milionów cząsteczek z motion blurem, własnym shadingiem i cieniami nie stanowi dla niej żadnego problemu (przy ok 8GB ramu), podobnie jak milionów włosów i oczywiście nawet bardzo ciężkiej wolumetryki, że liczy (w miarę) szybko instancje z dowolnymi wariacjami per kopia, że posiada rendertime subdivision, super szybki displacement, i powinieneś mieć jasność, że mental ray wyraźnie wygrywa właściwie tylko w jednej kategorii: architektura, czyli final gather (interior) oraz masa miękkich odbić - i to tylko, o ile nie włączysz motion bluru. Minusy: Mankamentem Mantry są materiały (są gorsze od mentalowych, VEX to nie RSL2.0, a VOPy są mniej poręcznie od Slima), jest wprawdzie coraz lepiej, ale SESI ciężko przychodzi dostosowanie programowalnego enginu do potrzeb zwykłych śmiertelników. Bywa także niestabilna w dość tajemniczych okolicznościach, które nie dają się zdebugować. Także metody akceleracji (fotony, irradiance map) są raczej prymitywne, także w tej chwili opłaca się najczęściej używać brutalnej siły path tracingu. Oczywiście mental ray ma znacznie bardziej rozbudowane API - jeśli ktoś ma ochotę go programować. Mantra poza rozszerzaniem VEXa, pozwala właściwie tylko na tworzenie obiektów proceduralnych w trakcie renderowania (via VRAY_Procedural). To niewiele zarówno w porównaniu z mentalem jak i rendermanami. Także format IFD (jej opis sceny a'la RIB), jest znacznie mniej elastyczny od formatu rendermana. Nie posiada LOD, ma raczej słaby pixel filtering. To znaczy licząc w trybie REYES, musisz ustawić wyższe wartości pixel sampling, żeby uzyskać efekty porównywalne z 3delightem (z moich testów wynikają nawet trzykrotnie różnice). Ma skopane zarządzanie pamięcią w trybie reyes (nie zwalnia pamięci po wyjściu z bounding boxa, jak powinna), ale to coraz mniej potrzebne, skoro wszyscy liczą na path tracie, gdzie zwalnianie pamięci i tak nie wchodzi w rachubę. Generalnie nie jest stuningowana do codziennej bezproblemowej pracy w reklamie, za mało dobrych shaderów, wciąż nienajlepszy SSS, no i jest raczej skomplikowana (cena elastyczności). Płata figle w niespodziewanych momentach (np. NaNy!), ale który engine nie płata? Na przykład mental wywala się głównie przez eksportery Maxa czy Mai, a sam w sobie jest raczej solidny. Także jednowątkowe soho, choć technicznie nie jest to część Mantry, daje w kość przy pracy w tym rendererze. Soho to takie coś, co odpowiada za przesłanie Mantrze danych z Houdiniego. Jest napisane w Pythonie, co, znów, daje nieskończone możliwości modyfikacji, ale sprawia, że eksport trwa bardzo długo. Duże sceny z instancjami potrafię się eksportować dłużej, niż trwa sam render. Ot, taki urok. pozdr., skk. ps nie pisałem oddzielnie o wolumetryce, bo trochę już przynudzam, ale generalnie tzw. ray marching, czyli technika renderowania dymków, jest natywnym zachowaniem Mantry, czyli robi mniej więcej to samo, co renderery dedykowane wolumetryce (voxel bitch). Czyli radzi sobie nieźle. Ma także własne wydajne formaty tekstur i tekstur 3d, więc renderowanie scen >20GB tekstur nie stanowi żadnego problemu.

Możesz przenosić w obie strony wszystko. Tutaj masz plugin dla Mai do czytania/pisania bgeo: http://www.houdinistuff.com. W ogóle bardzo rzadko renderuje się ujęcia w wielu rendererach, bo przestają się zgadzać szczegóły takie jak motion blur. Poza tym musisz duplikować workflow materiałów i świecenia, co jest dalekie od optimum. Bgeo to zajebisty format geometrii. W Houdinim zapisuje wszystko od fotonów, przez point cloudy, particle, poligony i Nurbsy aż do wolumetryki. Niestety ten plug obsługuje chyba tylko poly i particle (?).

A sterowanie view-portami nie jest identyczne, poza spacją zamiast Alt?

Można, to jedno z głównych założeń standardu. Jak inaczej sensownie wczytać animację, która ma np. 12GB? Co więcej, dane są hierarchiczne i można je wczytywać selektywnie.