SYmek

Mnie się jednak wydaje, że Mari się szybko przyjmie. Po prostu dlatego, że czyni przygotowanie tekstur dla modeli organicznych takim, jakim powinno być od zawsze. Prostym, przyjemnym i intuicyjnym. To naprawdę nowa jakość. Jej wydajność sprawia, że naprawdę nie ma powodu malować tekstury w PS, skoro tę samą interaktywność + pracę w 32 bitach na kanał (żenada PSa), eksport do exrów kilku tektur jednocześnie (diff, spec, etc) można otrzymać bezpośrednio w viewporcie programu 3d wyświetlającego choćby ciężki animowany model. A do tego za 500$... Pewnie na początku będzie szwankować to i owo, pewnie minie trochę czasu zanim pędzle zaczną leżeć ludziom w dłoniach, ale spodziewam się zasadniczej zmiany. skk. ps - o ile wiem, Mari nie ma w tej chwili żadnego wsparcia dla PTexa.

Dzięki za zainteresowanie! Kończymy już w czerwcu. Nie wiem natomiast kiedy i gdzie będzie można film zobaczyć. Chyba pod koniec roku w TVP(?). Kinowa premiera jest w trakcie domawiania. Na pewno damy znać!

Moja sympatia nie wygra z faktami ;): wyraźnie, na pytanie Pawła, uczyniłem rozróżnienie miedzy użyciem "systemowym" a przygodnym. WETA nie używa Houdiniego, a robota Arka przy Avatarze była wyjątkiem. Na tysiąc pracowników WETY jeden ptakun... Massive użyto do propagacji roślin, przecież nie ich modelowania! Są nawet na to dowody: ;) Dajcie pokój, sami słyszeliście, że demo marniutkie ;) pozdr., skk.

Wymieniłem tylko studia, które dużo używają Houdiniego (jako ważny element worflow'u), WETA nie używa go prawie wcale, ILM czy Pixar, o ile wiem, tylko trochę. Studiów, które używają go od czasu do czasu jest bez liku (włączając w to Polskę ;) ). Zrobił się funboy offtop relay performance. skk. ps zapomniałem o RSP...

Nie użytkownicy, tylko studenci, to różnica. Miałem na myśli po prostu renderer dedykowany wolumetryce. W praktyce to najczęściej oddzielny program (jak Afterburn albo 5x5 czy storm, albo moduł standardowego rendera). Mantra to w istocie kilka rendererów w jednym programie. Miedzy innymi właśnie "volumetric renderer". Mantra traktuje voxel, jak zwykły mikropoligon (z dodatkowym atrybutem dPdz) co sprawia, że może na nim wykonać te same operacje, co na zwykłych powiechniach: displacement, motion blur, deep shadows, dowolny shader (także shader zwykłej powierzchni). Po prostu nie robi jej różnicy, czy geometria jest płaska (jak poligon), czy ma trzeci wymiar, jak voxel ;).

Gwoli formalności, te ujęcia robią studenci na praktykach w SESI. Jedna lub kilka licencji jest w każdym dużym studio fx. Poważne pipeliny w oparciu o Houdiniego, ma tylko kilka studiów (DD, R&H, Sony, Framestore, Cinesite, Dr. D, CIS i to chyba tyle. Ponoć Blue Sky cały dział fx stawia teraz na H, ale mówi się o tym od lat, więc może to ściema). Tym niemniej dominuje podejście, że używa się go od przypadku do przypadku, kiedy akurat się sprawdza*. skk. * Na przykład Mantra jest w tej chwili bardzo dobrym (i jednym z niewielu dostępnych komercyjnie) silnikiem wolumetrycznym, więc to normalne, że firmy, które nie mają własnych rozwiązań w tym temacie, używają jej do dymków (np. o dziwo Image Engine (całe na Mai)).

Wygląda słabo ;)

Rozumiem, że nietrudno o pomyłkę, ale Realflow niewiele ma wspólnego z Maxem. Wyjątkowo ;)

Mistrzem świata w tej konkurencji jest Scratch, 3.5MB za 50.000 Euro ;)

Zawsze można było, bo to zwykłe kanały we kamerze są, które Nuke eksportuje we wspólnym formacie z Maya i Houdinim. To są zwykłe kolumny liczb (+ nowy Nuke będzie miał eksport fbx). Z ostrych zabawek polecić warto 3d equalizera.

ile razy jeszcze umieścimy to video? Raz zrobiłem to sam: http://www.max3d.pl/forum/showpost.php?p=911934&postcount=15 ...następnie mnie poprawiłeś: http://www.max3d.pl/forum/showpost.php?p=922352&postcount=16 ...a teraz poprawiłeś sam siebie. Poczekamy tydzień i znów to wrzucimy?

Zgoda. w Afx można składać filmy, i o tyle jest bardziej elastyczny w zastosowaniu, niż Nuke. Myślę, że się rozumiemy. Scanline renderer to engine, który bierze pod uwagę zawsze tylko jedną linię obrazka. Jeśli zatem masz kompozycje z 20 plików OpenEXR, Nuke wciągnie z dysku jedną linię z każdego pliku i wykona na nich Twoje operacje, a nie będzie próbował przechować w pamięci 20 plików w 4K i jeszcze coś na nich liczyć (o ile nie skompresujemy naszego exr'a piz-etem, albo nie użyjemy formatu, który trzeba wciągać w całości jak jpeg). Dlatego Nuke doskonale radzi sobie z ciężkim materialem, deeprasterami itd. Fusion miał przez wiele lat problem ze swoim rendererem, nie potrafili w nim na przykład zaimplementować render-region, Tiling to dzielenie renderu na prostokąty (czyli na buckety, jak renderer 3d), ale ile jest to warte można się przekonać w ciężkiej scenie. Zresztą programy kompozycyjne są w założeniu proste, jak budowa cepa. Co czyni je skomplikowanymi, to szczegóły implementacji, takie jak obsługa drzewa DAG, cache czy optymalizacje renderingu właśnie. Na przykład duża ilość nodów (np. powyżej kilkuset), rozkładała na łopatki GUI świetnego skądinnąd programu Shake. Renderowane odbywało się wciąż szybko, ale praca stawała się uciążliwa. Tymczasem Nuke może pracować na tysiącach nodów bez wyraźnego zwolnienia. Ktoś o tym pomyślał ;) skk. ps co mnie absolutnie odpycha od Fusion, bez względu na milion nowych ficzersów od jego producenta, to fundamentalny brak kultury programistycznej, która wzbudzałaby zaufanie. eye-on to po prostu nie są ludzie, którym potrafię ufać (niekoniecznie jest to bardzo racjonalne podejście, może raczej fobia, ale nic na to nie poradzę). Lata pakowania nowych funkcji, bez rozwiązywania starych a poważnych problemów, bardzo niestabilne buildy finalne, wsparcie dla jednej platormy z wartą śmiechu wersją Fusion na Wine, Lua i karygodna implementacja Pythona... ja dziękuję.

O ile porównanie Nuke'a i Afx jest dość proste, bo służą do czegoś innego i rządzą się innymi zasadami, o tyle DF i Nuke nie dają się tak łatwo rozróżnić - to po prostu dwie implementacje tego samego konceptu. Jedni wolą jeden program, a inni drugi. pozdr., skk. ps lej na Fusion - po co Ci znajomość dwóch krapiastych programów! :P

hello, nie napisałem, że ma kiepskie wsparcie teraz, tylko że darmowe programy, dodawane w pakiecie mają zazwyczaj kiepskie wsparcie, bo z czasem tracą uwagę producenta. Dlaczego? Bo służą zazwyczaj krótkiej potrzebie chwili, polityce, a nie są wartościowym produktem, który opłaca się rozwijać i sprzedawać dla niego wsparcie. Dzisiaj, zaraz po debiucie (re-debiucie), mogą łatać ten program, ale poczekajmy dwa lata, kiedy utrzymanie Toxika na poziomie konkurencji stanie się kosztowne i kłopotliwe. Niestety historia zna setki takich przypadków, jak choćby matchmover pro, żeby nie szukać daleko... Temat rzeka, nie ma co się rozwodzić, marketing był może i kiepski. Tyle, że w tej branży marketing nie ma wielkiego znaczenia. To nie handel burakami. Jak kupujesz licencje on-site dla całego studia za bańkę dolarów, nie robisz tego na podstawie ulotek reklamowych, tylko rozmawiasz z ludźmi tworzącymi soft, testujesz go w walce, bierzesz pod uwagę reputację firmy, jej politykę i perspektywy na przyszłość. A potem podejmujesz decyzję. Toxik powstał do filmu i w filmie się nie przyjął. ps swoją drogą ciekawe dlaczego Ty go nie kupiłeś, kiedy Ci go zachwalali. Był szybki jak cholera, dodali pythona, wywalili bazę danych, która ludzi wkurzała... po co męczyłeś się w Afterku, skoro od 5 lat mogłeś mieć Toxika? Aż tak kiepiski marketing? Mnie Adsk Toxika 1.5 (?) dawał za free, bylem tylko go używał i pisał skrypy do internetu. I nie skusiłem się, choć taki marketing uważam za udany :)

Tak, Flare można wyłącznie dokupić do posiadanego Flame'a.

Impreza pierwsza klasa. Gratuluję i dziękuję za świetne wykłady. pozdro! skk.

...wszystkie pakiety dawnego discreeta (inferno, flame, smoke, flint, fire etc) mają prawie identyczne gui, które są niemal nie do odróżnienia dla laika (może poza smokiem). Combustion zostało po prostu zrównane do tego standardu, po przejęciu przez adsk. Dlatego przypomina Flame'a. Na szczęście nie mają wspólnego kodu (pewnie poza wtyczkami typu klucze czy paint).

Wszystkie zachodnie studia produkujące pełnometrażowe animacje 3d pracują na Linuksie: Pixar, Sony Animation, Dreamworks Aniamation, Blue Sky, The Core (+), Dr. D (to chyba wyczerpuje listę tych dużych (?)). Wszystkie duże studia filmowe stoją na Linuksie: ILM, DD, R&H, Weta, Imageworks, Framestore.. żeby wymienić największe... Wszystkie duże pakiety 3d oraz wiele rendererów ma doskonałe wersje linkusowe (Maya, Houdini, Softimage (...ale |3d działał jeszcze pięknie!), PRman, 3delight, mental ray, V-Ray etc etc) Także programy kompozycyjne używane do składania 3d mają wersje linuksowe (i to jest ich pierwsza platforma): Shake, Nuke, Toxic...). Większość programów do trackowania kamer ma wersje linuksowe (PFtrack, Boujou, 3dequlizer). Linux jest jedyną platformą, na której można malować w 32 bitach na kanał. A także symulować tłumy za pomocą Massiva (w pełnej wersji). Jest także jedyną sensową możliwością, jeśli idzie o zarządzanie render farmą... Tyle tylko, że z tego wcale nie wynika, że Linux nadaje się dla Ciebie do używania w 3d. Na przykład dla 90% ludzi na tym forum linux oznacza więcej kłopotów niż pożytku...

Flare nie ma nic wspólnego z Combustion. To jest softwarowa wersja Flame'a, którą ADSK sprzedaje tylko użytkownikom wielkiego brata. Służy jako wsparcie dla niego, żeby zadań typu szparowanie nie robić na drogiej maszynie. Co do Toxika vel Composita: przyzwoity soft, z nowym i bardzo interaktywnym kodem, ale warto pamiętać, że takie produkty (darmowe wrzutki) mają zazwyczaj kiepskie wsparcie producenta, nie są rozwijane, nie naprawia się w nich bugów i z czasem stają się martwym bublem. Właśnie dlatego, bodaj żadna firma z dziesiątkami licencji Mai, nie zrezygnowała z Nuke'a dla chwilowej acz sporej oszczędności... za jakiś czas musieliby wydać znacznie więcej. Oczywiście Toxik powola wydajnością kogoś, kto pracował dotąd tylko na Afx czy Combustion. W przypadku Shake'a czy Nuke'a to raczej standard. pozdro! skk. @Olaf: kurczę, przepraszam Cię, ale ile Ty masz lat! Może byś poprawił byki. To raz. Dwa, Combustion nigdy nie służył do składania w dużych rozdzielczościach. To był z założenie soft dla TV. To właśnie Toxik był odpowiedzią Adsk na Shake'a a potem Nuke'a, napisany z myślą o dużych studiach, z obsługą bazy danych, mocnym wsparciem dla pracy grupowej, jakiego nie ma bodaj żaden inny soft (może poza Fusion+Generation). Tyle tylko, że został absolutnie zlany przez branżą. Z kilku zresztą powodów... a teraz ma życie po życiu ;)

No nie wiem..., to znaczy wiem, że kompletnie nie rozumiem, skąd ta pewność, że nie istnieją powody, których nie znasz a które sprawiają, że takich systemów się nie rozwija. Dlaczego akurat lenistwo? Naprawdę zagadkowa opinia. Spodziewam się natomiast, że tych kilka tysięcy matematyków i inżynierów, którzy zajmują się rendererami zawodowo, a którzy stanowią, obok ludzi od symulacji, awangardę naukowców w tej branży, wie coś, co powstrzymuje ich od rozwijania modelu, który opisujesz. Chyba, że opacznie Cię rozumiem... Dzielenie renderowania na atomowe części i posyłanie ich innym, czyli poza cache procesora, nie ma najmniejszego sensu, ponieważ już dzisiaj bodaj największym "spowalniaczem" procesu nie są same obliczenia (algebra wektorów etc), tylko dostęp do danych, na których te obliczania mają być wykonane. Gdyby Xeony miały cache mieszczący w sobie całą scenę, rendering odbywałby się o rząd wielkości szybciej. To komunikacja na zewnątrz jest za wolna. Ty tymczasem oczekujesz (jeśli dobrze rozumiem?), że programiści wykorzystają jeden procesor do teselacji, drugi (najlepiej po drugiej stronie świata, jak to ma miejsce w cloudach) do filtrowania tekstur, a trzeci wykona kod shadera? Przecież to przepis na najwolniejszy renderer świata, a do tego najbardziej zawodny! Odnoszę wrażenie, że mylisz się też co do analogii z GPU. Marność obecnych rozwiązań bierze się właśnie stąd, że wszystkie dane, na których operuje taki renderer GPU muszą być upakowane do pamięci karty w optymalnej strukturze. Wszystko co nie mieści się w tym schemacie odbywa się wielokrotnie wolniej niż na CPU. Stąd te renderery to zabawki, potwornie ograniczone i nieelastyczne. Właściwie jedyne co potrafią dobrze, to wykorzystać 256 rdzeni do śledzenia promieni z wykorzystaniem wspólnej struktury akceleracji, która musi znajdować się w pamięci karty (i którą przygotowuje dla nich CPU). A jeśli trzeba przefiltrować dużą teksturę, wykonać długi shader z wieloma warunkami, otworzyć teksturę 3d albo policzyć kosztowny noise? Dupa. Przeładowania pamięci karty nie wchodzi w rachubę, obliczenie czegoś kosztownego poza GPU i przesłania na kartę zajmuje wieki. Reasumując, GPU to modelowy przykład tego, że renderingu nie da się sprawnie rozproszyć z wykorzystaniem platformy komunikacji o prędkości PCI, nie wspominając już o ethernet. Wygląda na to, że jest dokładnie odwrotnie niż opisujesz. Najlepszym, najbardziej efektywnym i niezawodnym rozwiązaniem, jest właśnie oddanie każdej klatki lub bucketa innej maszynie. Nikt tu nikogo nie spowalnia... żadna maszyna nie przeszkadza innym. Doskonałe rozproszenie. Sprawdza się to właśnie dlatego, że każdy klient przechowuje w pamięci swoją kopię danych. Bez superszybkiej pamięci współdzielonej (na poziomie wewnętrznych prędkości procesora) inne rozwiązanie nie ma praktycznego sensu. Inna sprawa to kompletnie zbędna komplikacja kodu, który trzeba by napisać dla takiego potworka. Po co? Przecież to proszenie się o kłopoty. Dobre rozwiązania, to proste rozwiązania.

Dlaczego wirtualizacja, na której opiera się cały cloud computing business, nie jest rozproszonym liczeniem? Mógłbyś sprecyzować, co w takim razie oznacza ten termin?

w Mai zrobi to 3delight. Chodzi o to, żeby shader kontrolować atrybutem zapisanym na geometrii. Wydawało mi się, że mental również to potrafi, ale gdzie i jak...?* * - zapewne tam, gdzie zmienia się kolor dla instancji ;)

Spokojnie, linuksowa była nawet alfa! I do tego ogólnie dostępna ;) pozro! skk. PS Mental Mill to zło (sic!)

Pragniemy zaprosić do współpracy na kilkutygodniowe kontrakty kompozytorów obrazu, którzy wspomogliby nasz zespół pracujący nad filmem animowanym. Mile widziamy wykształcenie plastyczne, doświadaczenie w pracy nad filmem oraz znajomość Nuke'a, minimalnym kryterium są sumienność i dobre oko do ruchomych obrazów. Zapraszamy! [email protected] human-ark.com tel: +48 22 227 77 88

. Zobacz, co jest w crash logu, a nie w hipie zapisanym w tmp, bo to jest po prostu zrzut sceny. W logu powinno być więcej. Możesz to spokojnie wysłać do supportu.