SYmek

Dobre to to!

Ja sobie żartowałem, sam mam na bakier z AMD i od lat nie kupiłem niczego, w czym maczali palce, ale fakt faktem, że zbitka Twoich utyskiwań z ich sukcesami rynkowymi jest trochę zabawna, nieprawdaż? Trudno mi natomiast uwierzyć, że Apple zostało czymś zaskoczone a propos kart AMD. Po pierwsze primo nikt tak nie zna OpenCL jak Apple, po drugie primo, Apple sam pisze swoje sterowniki GPU, po trzecie primo, to nie są pierwsze Maki z kartami AMD. Dobrze wiedzieli, co robią.

AMD? Masz na myśli tę firmę, która dostarcza procesory GPU do Xboxa, Playstation, najnowszego Maca pro i prowadzi w większości rankingów wydajnościowych :) ?

Znalazłem w tym wywiadzie ciekawą puentę do powyższego newsa: technologia przeniesienia skomplikowanych powierzchni RSL do środowiska Optixa polegała po prostu na upieczeniu albedo wszystkich powierzchni i cieniowanie tej tekstury na GPU, co jest bardziej produkcyjnym hakiem, niż nową technologią previzu. Może to właściwie wykonać każdy w domowych warunkach.

Ci to mają talent do autopromocji, drugi sneak-peek, znowu cząsteczki i 8 minut na klatkę FEA... mogli zrobić 1000 tetrahedra (a nie 52K) i 2 sub-stepy (a nie 10), ale żeby było przynajmniej poniżej minuty. Są solvery działające w realtime na CPU...

Przecież nie ja go przywołałem jako guru. Ja pokazałem, ile są warte cytaty z internetu :) Axis zaczął używać Houdiniego w okolicach 2008 roku przede wszystkim do renderowania, więc sprawa taka świeża nie jest. Nie wiem natomiast, co masz na myśli mówiąc o "nieakceptowalności". Jest masa studiów używających Houdiniego w warunkach produkcyjnych deadline'ów, ale chyba nie ma co robić offtopa. No właśnie nie mieli, stąd wcześniejszy cytat o tym, że musieli zacząć zabawę od zera. Dobra, kończę, bo liska szkoda! skk.

Nie to, żeby chciało mi się jakoś specjalnie bronić Fura w Houdinim - zrobiłem w nim wystarczająco dużo, żeby za nim nie przepadać. Nie pracowałem też w Yetim, więc porównania nie mam, ale wcale bym się nie zdziwił gdyby ludzie, którzy zjedli zęby na futrze przy kilku australijskich filmach animowanych, wiedzieli jak napisać takie narzędzie - tym bardziej że złamali przy tym patent Joe Altera, na co SESI nie mogło sobie pozwolić oraz, że Fur nie zmienił się od 5 lat ani o jotę... (ku**a mać). ale... jeśli już powoływać się na internet: tenże sam Raynor: ... czyli z "completely new" zrobiło się "adapted". A sama reklama przywołana przez jarasa, powstała oczywiście z GI na futrze w pełnym PBR, podobnie jak wiele innych futer z dwunastki +, więc "lata świetlne" między Mantrą a Arnoldem można sobie między funboyowe bajki włożyć. No i w końcu: dlaczego Raynor, Maya TD z The Mill zawraca sobie głowę nauką Houdiniego, skoro może zrobić fura lepiej w narzędziach, które zna i ma do nich dostęp..? pozdrawiam, skk.

Pierwsze zdanie Helpa Vop SOPa odpowiada na Twoje pytanie.

W Houdinim, aby wiedzieć ile mamy włosów, trzeba policzyć powierzchnię siatki i pomnożyć przez density... Moim zdaniem lisek wygląda na teledysku gorzej nie tyle z powodu futra, co animacji. Jest też pewna różnca między deep shadow mapami z 3delighta, a pełnym path tracem z Arnolda :). Tak czy tak, solidnie delighting.

Fajny lisek. A pamiętasz może, ile miałeś włosów na stworze?

masz spacje w nazwie pliku, więc funkcja w ogóle nie działa (zwraca domyślną wartość parametru). op:[spacja]`opinpupath()...`

Delikatnie mówiąc nienawidzę tej kampanii, podobnie jak poprzednich, kiedy próbowano mnie zainteresować tzw. sztuką powstałą w Houdinim. Wszystkie te rzeczy są po prostu bez gustu, co wynika z prostego faktu, że robią je stażyści. Inna sprawa, że to nie są filmy adresowane do menadżerów, ale właśnie do adeptów grafiki 3d. To o nich bije się SESI. Może to tłumaczy poziom tej produkcji* skk. * - "tak jak w Blenderze, tylko odpłatnie!" :P

Takie można odnieść wrażenie, ale prawda jest taka, że w obrębie jednego filmu studio zawsze będzie dążyło do jednego renderera, żeby nie generować dodatkowej pracy i kłopotów z biblioteką materiałów, równaniem rozmycia ruchu etc. Rozdzielenie pipeline'u zawsze jest kompromisem i koniecznością, a nie wyrazem twórczej swobody :)

To rzeczywiście kończy rozmowę.

To jest po prostu 30 klatek na sekundę, jak stare dobre NTSC...

Dzięki. Mi chodziło o starcie na polu dużych studiów, tam gdzie ta przyjazność nie ma wielkiego znaczenia. Zastanawiam się po prostu, czy hybrydowy renderer ze wsparciem dla wszystkich ważnych pakietów (unlike Mantra) nie jest lepszym rozwiązaniem od Arnolda, który jest jednak drogim kamikaze. Jak się czegoś nie da path-tracować to już amen w pacierzu (na przykład nie ma to czasu albo ramu). Przyznam, że to jest rzecz, którą bardzo cenię w Mantrze. Jak jest czas, jedziemy na pełnym path tracie, a jak nie ma, przełykamy żabę i rzeźbimy w reyesie. Szczerze mówiąc trudno mi sobie wyobrazić życie bez takiej alternatywy. Ach ta jakość 3delighta... [edit]: znalazłem odpowiedź na swoje pytanie na stronie z darmową wersją: "IMPORTANT NOTE: The all new version 11.0 will be available for download before the end of November 2013"

Przyszło Ci do głowy, że nie masz bladego pojęcia o tym, jak przebiega proces renderowania wysokobudżetowego filmu, więc trudno jest Ci ocenić, czy techniki obecnie używane w KAŻDYM dużym studio animacyjnym na świecie dają się czy też nie dają się zamienić na silniki gier? Jeśli chodzi o TWOJE potrzeby to oczywiście wiesz lepiej. Nawet w nodepadzie można w realtime wygenerować obrazek. Tyle. Szczerze mówiąc, szkoda mi czasu na tę rozmowę. pozdr. skk.

3delight w bezpośredniej rywalizacji z Vrayem i Arnoldem... ciekawe jak się przyjmie. Wiadomo, kiedy 11 Studio Pro ma się ukazać?

hint, hint:

Podaje przykład Pixara i Dr.D, bo sam się odniosłeś do Happy Feet, a nie dobranocek w TV. Rozmawiamy o jakiejkolwiek animacji, czy animacji która wytrzyma porównanie z z Happy Feet, co zdajesz się twierdzić powyżej? Jeśli mówisz o jakiejkolwiek animacji, to owszem, Twoje twierdzenie jest nie tylko prawdziwe, jest także trywialne. Renderman posiada ray tracing od ponad 10 lat. Pixar nie musiałby przepisywać pipeline'u, wystarczy zmienić renderer. Właśnie to niemal zrobili (podobnie jak ILM), bo nowy PRMan ma zupełnie nowe bebechy, nową metodologią, shadery, światła itd. Dr.D (przywołane przez Ciebie) powstało od zera na potrzeby Happy Feet i również musiało kupić rendermana, bo po prostu nie da się jeszcze zrobić animacji na poziomie Happy Feet w silniku gry. Przed GPU nie stoją zresztą wyłącznie problemy jakości czy skomplikowania scen. Żyjemy w czasach poprawność fizycznej, to jest normalny krok do przodu, kiedy po latach fake'owania ludzie oczekują jakości. W tych warunkach oczekiwanie, że silniki gier, które opierają się od A do Z na oszustwach podbiją serca ludzi, którzy przesiedli się właśnie z szybkiego PRMana na wolnego jak diabli Arnolda, tylko dlatego, żeby mieć fizyczne mięso w pikselach, jest grubą naiwnością. To tak jakby sądzić, że ktoś przejmie się real-time'owymi riggami na GPU w czasach, gdzie ludzie w ogóle odchodzą od riggów i zaczynają symulować kości, mięśnie i skórę. A że da się robić filmy animowane w silnikach realtimowych to wiadomo, tylko jak one wyglądają? Jak Final Fantasy, film sprzed 13 lat. edit: na marginesie, większość technik GPU jest rozwijana do realiów produkcji gier. W praktyce należałoby najpierw sprawdzić, jak taka metoda się sprawdzi, kiedy ilość poligonów zmienia się ze 100K do 100M. No i są to poligony, nie trójkąty..., no i tekstury są 16float, no i 8K, i nie mogą być sprytnie popakowane, bo wciąż się na nich pracuje, nadpisuje etc a patent GI powinien działać także dla dymu, nie tylko siatek. Innymi słowy "w nadchodzącej dekadzie" a nie "2013".

To jest w ogóle bardzo ciekawy i dość zawiły temat. Na szczęście w Twoim przypadku, sprawa jest nieco prostsza - o ile rozumiem intencje. Są oczywiście statystyczne metody mierzenia szumu, tym pomocniejsze im lepiej wiemy jakiego szumu szukamy (w przypadku path tracera wiemy), tylko że Ciebie nie interesuje bezwzględna wartość globalna a nawet lokalna, ale różnica między dwoma identycznymi klatkami, które różnią się tylko charakterem szumu. No, a to bardzo ułatwia sprawę. Nie potrzeba żadnego specjalistycznego oprogramowania, wystarczy Photoshop lub Nuke. Blurujesz nieco (np. 3 pixele) obraz A i B, które chcesz porównać i oba odejmujesz od oryginałów. Dostaniesz A' i B' - czyli high pass A i B, w którym będzie szum i ostre krawędzie. Potem już tylko mapujesz A' do kanału r a B' na przykład b i dostaniesz mapę szumu, który jest w jednym renderze a nie ma go w drugim. Oto przykład, dwa pozornie identyczne rendery, jedyną różnicą jest inny sampling na światłach. Wyraźnie widać po cieniach jak jedno ze świateł zaszumia bardziej. To jest do zrobienia w dowolnym kompozytorze za pomocą blura i operacji na kanałach. [ATTACH=CONFIG]91716[/ATTACH] Powyższa metoda nie rozróżnia szumu od szczegółów na teksturze etc, ale bez zawracania głowy można wiele zobaczyć (na przykład porównać, który render szumi bardziej w cieniach, a który na fakturach, rozmyciu ruchu etc). Oczywiście można sobie skomplikować życie jakąś analizą sygnału, ale wątpię, żeby gra była warta świeczki. Poniżej standardowa dewiacja dla tego renderu (liczona jako lokalne maksima): [ATTACH=CONFIG]91717[/ATTACH] Słaba jakość, bo nie chciało mi się robić tego porządnie (obliczenia robiłem na geometrii, a nie pikselach). No i na koniec super metoda statystyczna, czyli analiza głównych składowych (PCA): [ATTACH=CONFIG]91718[/ATTACH] Niby coś tam widać, ale biorąc pod uwagę stopień skomplikowania, nie ma to chyba wielkiego sensu. Chociaż w tym przypadku ciekawostką jest, że klatki wyraźnie różnią się także w jasnych punktach, bez cienia (czego się nie spodziewałem), co widać po różnych kolorach nad stożkiem (góra/lewo i góra/prawo obrazu), widać sampling świateł ma także znaczenie przy wykonywaniu shadera światła a nie tylko cienia...

Szkoda, że nie miałeś szansy oświecić ludzi z Pixara czy Dr.D, żeby sobie nie zawracali głowy renderowaniem na CPU. Wystarczyłoby przecież, żebyś pokazał coś, co sam zrobiłeś, żeby im uświadomić ile czasu i pieniędzy marnują. Masz jakiś gorszy dzień, czy coś..? Nie chcę się nad Tobą znęcać, ale gadasz po prostu głupoty. A tak poważnie to wszystkie przykłady na jakie się powołujecie są prototypami, które zajęły więcej czasu na wymyślenie i napisanie, niż suma czasu wszystkich rdzeni na renderfarmie, które wykonałaby to na CPU. Wszystkie bajery możliwe dziś na GPU: path tracing, out-of-core rendering ciężkiej geometrii, włosy, sss, displacement, gigabajty tekstur, rozmycie ruchu i dof (oraz wolumetryka, deep compositing, geometria proceduralna, programowalny shading) etc etc, muszą się znaleźć w jednym filmie, czasem jednej klatce, zrobione w jednym rendererze (albo dwóch) i w czasie mniej więcej jednego roku (i nie, nie zawsze da się je rozdzielić, szczególnie nie w czasach renderingu poprawnego fizycznie). Filmy już dziś powstają na silnikach gier, tyle że są na tyle złej jakości, że są albo intrami do gier, albo filmami niskobudżetowymi. Blockbustery zaczną powstawać na GPU dokładnie wtedy, kiedy będzie to możliwe technicznie, czyli jeszcze nie teraz, bo teraz żadna ramka, która liczy się na GPU w czasie zbliżonym do realtime'u nie wytrzymuje porównania z wysokiej jakości klatką CPU liczoną godzinami przez Arnolda czy PRMana/3delighta. Ludzie odpowiedzialni za te sprawy w dużych studiach naprawdę wiedzą, co robią i bynajmniej nie są w zmowie z Intelem czy Amd. Zresztą wkład różnych technologii GPGPU w produkcje filmów stale rośnie - vide Panta Ray Wety, symulacje w MPC, system previzu Pixara etc. Dokładnie nie tyle stać teraz GPU, ale z całą pewnością nie stać go na rendering w jakości offline. Ray tracing zaczął być używany w filmach wtedy, kiedy było to możliwe, a nie wtedy, kiedy jeden czy drugi zapaleniec amator renderujący kulki w domu dziwił się, że jeszcze tego durnie w wielkich studiach nie wymyślili*. skk. * - mówi to zapaleniec amator, który ad 2000 dziwił się, dlaczego ILM nie używa Radiocity w LW - chociaż DD przynajmniej raz je użyło w 1999 roku.

ubuntu, fedora, coś z w miarę nowym gcc (4.6 na przykład). Ja siedzę na Centosie, ale tutaj kompilator jest raczej stary (4.4.7)

Myślę o testach przeprowadzanych za pomocą syntetycznego oprogramowania. Mógłbym jakieś przygotować do testów. Więcej by to mówiło o zmianach w architekturze procesora, różnicach między SSE4 a AVX, wpływie hyper threadingu czy wielkości cache'u na wydajność procesora. O ile chciałoby Ci się uruchomić to na kilki procesorach rzecz jasna (raz zainstalowany Linux uruchomi się na większości maszyn, więc wystarczy przekładać dysk jeśli w grę wchodzą różne płyty, albo nawet zrobić boot z płyty CD). Myślałem o tym: http://code.google.com/p/blaze-lib/wiki/Benchmarks albo o tym: http://ispc.github.io/perf.html Jeśli chodzi o rendering to ciekawy byłby test z embree: http://embree.github.io/ (zdaje się, że jest tam nawet kompilacja dla Windows, ale warto wymusić pracę na jednym rdzeniu porównując procesory).

Dzięki, bardzo ciekawe. Przydałoby się trochę bardziej syntetyczne testy - także pojedynczego rdzenia. Masz możliwość testów pod Linuksem? Dziwne, że tegoroczny procesor nie ma AVX2, ale to zdaje się wciąż przyszłość.