SYmek

Nawet oryginalna technologia nie pomogła R&H. Petycje i zielone kwadraciki nie są dla putinów, tylko dla morale. Ludzie muszą się zjednoczyć, żeby dokręcić śrubę politykom (wojna z subsydiami) i studiom (ochrona warunków pracy). Problem polega na tym, że złe warunki pracy w tej branży są przyczyną złego prawa handlowego między producentami a studiami i vice versa, mając wolną rękę przy wykorzystywaniu grafików, studia godzą się na niegodziwe umowy z producentami. Zakaz korzystania z zagranicznych subsydiów + związki wymuszające na studiach lepsze warunki pracy mają powodować zmiany zasad współpracy między producentami a studiami. Już to kiedyś napisałem, ale się powtórzę: paradoks Life of Pi i bankructwa R&H polega na tym, że żadne inne studio na ziemi nie potrafiłoby zrobić tego filmu, czyli R&H nie musiało się obawiać, że producent zabierze im film, jeśli nie pójdą mu na rękę. Tymczasem w imię prestiżu i przyszłych projektów zgodziło się podpisać kontrakt, który doprowadził ich do bankructwa. Kontrakt jest kwestią uznaniową i zwyczajową. Aktywistom chodzi o zmianę zwyczaju, który wykańcza ich pracodawców. Wystarczyłoby, żeby przez trzy miesiące nie powstała w US jedna klatka do filmu wielkiej piątki. Putiny zaczęłyby inaczej gadać. Szczególnie gdyby korzystanie ze subsydiów przestało im się opłacać (zostałoby opodatkowane, jak tego sobie życzą aktywiści).

Upadek SI ma niestety przyczyny w błędach popełnionych przez managerów studia wiele lat wcześniej. Zabicie SI3D spowodowało utratę rynku na korzyść Mai. To raz. Dwa, że XSI miało problem koncepcyjny z umieszczeniem się na tym rynku od nowa. Zainwestowano masę pieniędzy w konika głównych architektów, tj. w animację, ale jednocześnie odcięto XSI od dużych studiów koncentracją na Windowsie (co było konsekwencją wykupienia przez MS). Czyli robisz narzędzie, które rządzi w animacji postaci, ale nie chcesz go sprzedawać studiom animacji, tylko małym studiom reklamowym. A owe potrzebują znacznie większej palety możliwości, albo niższej ceny, żeby samemu dobierać sobie brakujące narzędzia. Nie po to płaci się kilkukrotność ceny LW, żeby potem wszystko poza animacją robić w LW albo Maxie - choćby z powodu braku alternatywnych rendererów. XSI to nie jedyny błędnie zarządzany produkt tej firmy. Zanim powstał ICE, który w końcu był trafioną inwestycją, Softimage marnował czas i pieniądze na tworzenie takich fenomenów jak Behaviour, Matador czy Face Robot. Wszystkie te produkty łączy pewna zależność: innowacyjność technologiczna przy kompletnym niedopasowaniu do realiów rynku i grupy docelowej (no i znów skupienie się na małym rynku animacji na złej z gruntu platformie). Adsk kupiło SI za jedną szóstą jego oryginalnej ceny właśnie z powodów takich błędów. A że nie kupowało programu, tylko święty spokój od konkurenta, było wiadomo od początku...

Chyba nikogo to nie dziwi? Dawno się na to zapowiadało.

Implicite a propos: http://rhythm.com/labs/

A projekt masz? ...bo zapomniałeś o najważniejszym. Jak będziesz miał projekt to reszta sie znajdzie :)

Tak, jest w tym filmie kilka niezgrabności, od obsady zaczynając, ale właśnie na tym polega magia oryginalności, że się te błędy wybacza, pozostając pod wrażeniem całości. Dlatego wtórność w filmach kategorii "wow" jest zabójcza. Zabawny trailer, dzięki! skk.

My tu gadu, gadu, a materiał stygnie. FEM w teorii i praktyce: H13 Masterclass | Finite Elements

Nikt tu się nie kłóci. Pacific Rim miało jedną wadę, wszystko to już było...

Jednak efekty to nie tylko symulacje, a w innych kategoriach to jest prawdziwe pionierstwo i mistrzostwo świata. Zresztą symulacje takie znowu banalne nie są. To, co zwykle zasłania się dymem i ogniem, tutaj trzeba było pokazać w szczególe i na ciemnym tle. Mam wrażenie, że niejeden osiwiał przy tych destrukcjach...

Nie jestem ekspertem od trójki, ale to zdaje się tak właśnie wyglądało, że powstała dla idei spójności naprawiając wyjątki i nielogiczności, których Python nabawił się w okresie niemowlęctwa. Ponieważ Python to jest twór sztuczny, nakładka syntaktyczna na mechanizmy działające niżej w C, nie jest wykluczone, że interpreter 2.7 ma wszystkie architektoniczne nowości 3.X, tylko dopuszcza inną składnię. Te różnice to nie to samo, co skok z C++98 na C++11. Właściwie każda aplikacja udostępnia swoje wnętrzności Pythonowi za pomocą SWIG'a. Pytanie tylko, ile z tych wnętrzności można i warto udostępniać. Sytuacja Houdiniego jest tutaj dość wyjątkowa, ponieważ Houdini nie posiada ani odpowiednika MEL'a, czyli języka dowodzącego rdzeniem programu, ani stabilnego SDK dla zewnętrznych developerów, takiego jak Maya SDK. Ani Hscript ani HDK nie nadają się do wrappowania Pythonem, tak jak to zrobiła Maya z MEL'em i SDK. Houdini potrzebował czegoś zupełnie nowego i tak powstał HOM, który jest API w C++ dla Pythona lub czegokolwiek innego (via SWIG). HOM jest w pełni rozszerzalny, więc w tym sensie możesz do Pythona w Houdinim dodawać więcej wnętrzności wedle upodobań, ale tę pracę trzeba wykonać ręcznie, ponieważ HDK jako takie nie nadaje się do tego, jest za duże i zbyt skomplikowane, nie spełniałoby po prostu swojej roli. Inna sprawa, że jak już tego Pythona zrobili, zrobili to dobrze. HOU jest mega eleganckie, czego o natywnym Pythonie w Mai powiedzieć nie można (w każdym razie sądząc po istnieniu PyMel). Python w Nuke'u jest niekompletny, o burdelu w XSI nie wspominając... A jak dodam do tego inlinecpp, które bez kompilacji w locie umożliwia mi korzystanie z obiektów i metod C++ w kodzie Pythona, tudzież możliwość wołania VEX w Pythonie, to nawet brak czegoś na kształt MayaSDK w Houdinim łatwiej mi przełknąć :)

Różnice z punktu widzenia własnego API, takiego jak PyMEL czy HOM są minimalne.Opóźnienie, moim zdaniem, wynika między innymi z potrzeby zgodności z zewnętrznymi modułami (w tym z pipelinem studiów), oraz ze zwykłej niechęci do zbędnego zawracanie głowy. Dla Mai czy Houdiniego Python 3 nie ma wielkich propozycji. Utrzymywanie dwóch wersji interpretera w aplikacji będzie uciążliwe, a przesiadka na trójkę bez pewności, że wszyscy już tam są, nie byłaby przyjęta z entuzjazmem. Krótko mówiąc, jeśli ktoś pisze w Pythonie webowy framework, przesiadka na trójkę może być kusząca. W VFX Python to wrapper wokół natywnych API + rozwijany od lat pipeline, więc wpływ samego języka jest minimalny. Plusem trójki może być na przykład łatwiejsze zagnieżdżanie Pythona czy rozwiązanie problemów z wielowątkowością, ale to inna historia.

Obawiam się, że łatwiej przeskoczyć z 2.7 na 3.x niż odwrotnie, a jeśli pracujesz w branży to jeszcze przez rok, dwa, albo trzy interesuje Cię wyłącznie Python 2.x, bo... Maya, XSI, Nuke, Houdini, Qube, Deadline, Cortex, Blender, whatever, name it... Co do IDE, polecam dowolny wypasiony edytor..., choćby taki jak sublime, 50$ i pełnia szczęścia. IDE jest dla zgredów z tysiącami linijek centralki telefonicznej na warsztacie.

Zawód tych panów polega właśnie na tym, żeby Cię zastraszyć i zniechęcić do walki o swoje prawa. Oni doskonale widzą, że nie mają racji, dlatego grożą, a nie działają. Zresztą w większości przypadków taka walka się kompletnie nie opłaca, ale jak rozumiem, Ty już nie masz co liczyć na dalszą współpracę z nimi...

Temat produkcyjnych rendererów jest kompletnie nieprzenikniony z punktu widzenia domowego użytkownika, bez znaczenia, czy jest to profesjonalista freelence viz, czy kompletny amator. Zestaw problemów, z którymi musi sobie poradzić taki renderer po prostu tych ludzi nie dotyczy (prawdopodobnie nie wiedzą nawet o ich istnieniu). Poza rzadkimi przypadkami nie dzieli się klatek na kawałki w filmie, bo to się nie opłaca. To się opłaca tylko w przypadku, jeśli chcemy obejrzeć jedną klatkę jak najszybciej. Dzielenie klatki działa wolniej i nastręcza problemy techniczne. Mało tego, jak napisał praetorian, o ile RAM pozwala, opłaca się zmniejszyć liczbę rdzeni per klatka, co wynika z prostego faktu, że żaden renderer nie skaluje się liniowo z ilością rdzeni. Zawsze jest jakaś strata, która się powiększa wraz ze wzrostem ilości rdzeni, choć faktem jest, że prostackie renderery mają tę stratę relatywnie małą (bo nie podmieniają geometrii na wersje refined, tylko liczą prosto z trójkątów).

Średnio poważne to porównanie, 400x300, ambient occlusion, zero materiałów i szczątkowa geometria.

Ok, jakieś tutaj małe nieporozumienie, pewnie z mojej winy, sobota, wybiegałem z domu, na szybko pisałem. Przepraszam, jeśli namieszałem chaotyczną wypowiedzią. Szczerze napisałem, że przykro mi słyszeć, że nie jesteście zadowoleni ze swojej sytuacji. Choć z drugiem strony nie jest to zaskoczenie o tyle, że dużo się pisze o kryzysie w studiach VFX. Co do "starszych braci", to faktycznie tak jest, że wielu 40+ wyjadaczy, który pozakładali rodziny, z filmu przenosi się do reklamy, bo daje im większe szanse na stałe zatrudnienie, a nie pracę na kontrakt. Wielu, nie wszyscy oczywiście. Tak czy inaczej życzę Wam, żeby jakaś przystań się znalazła i taki był sens tej wypowiedzi. Co do mojej kariery, to jest inna sprawa. Nie planowałem nigdy zahaczyć się w Ha na stałe, tak jak nie planowałem nigdy wyjeżdżać - z powodów osobistych, a nie sytuacji na rynku, perspektyw etc. skk.

Bo w rozmowie porównuje się renderery dostępne pod Mayę i ewentualne korzyści z przesadki z mental raya do komercyjnych zamienników, a'la Vray, Arnold, 3delight etc - więc temat Blendera jest po prostu od czapy.

Smutno się Was słucha Panowie, bareja, tmdag, ale wszystko to zgodne z oczekiwaniami. Wielu starszych braci z VFX po prostu znajduje kotwicę gdzieś w reklamach, o ile zbytnio się nie wyspecjalizowali w "symulowaniu wodospadu do 4K kubików wody/h". Bo stały staff z dobrego studia reklamowego jest jednak w nieco innej sytuacji. Branża podła, szczególnie jak człowiek dorośnie... skk. ps wydaje mi się, czy jakiś trolling tu odchodzi...

Mało mnie to dotyczy, ale kawałek Ravela jako zamysł marketingowy w pierwszym spocie od razu podbił moje serce. Chciało mi się oglądać dalej... więc włączyłem dwa pozostałe, a tam kicha... nie rozumieć, nie rozumieć...

Prawie na pewno VRay i Arnold w tych samych warunkach oświetleniowych da takie same efekty, ale whatever suits you - przecież na głowę nie upadłem, żeby kogoś przekonywać do VRaya ;). Testuję regularnie, zacny program, ale jako użytkownik Mantry, nie znajduje powodu na wydanie kilkudziesięciu tysięcy euro na coś, co dostaję w cenie Houdiniego. Te nieliczne przypadki wyraźnej różnicy wydajności dla mnie powodem nie są (ale mogą być powodem dla innych rzecz jasna). Inaczej sprawa ma się z Mayą oczywiście. Tutaj trudno o lepszy wybór dla filmu (chociaż nowy 3delight może to zmienić). Ten przykład jest mylący w kontekście tej rozmowy, ponieważ rozważa zalety modelu Cook-Torrence'a z punktu widzenia klasycznego renderera, gdzie refleksy od punktowych świateł psują efekt realizmu. W rendererze fizycznym, gdzie 100% iluminacji pochodzi z powierzchni świecących (światłem własnym lub odbitym), Cook-Torrence jest po prostu jednym z wielu modeli powierzchni chropowatych - zresztą niepoprawnym, bo nie przestrzega zasady zachowania energii - odbija więcej niż dostaje. Ale zalety dobrego modelu BRDF świetnie pokazuje link do pluginu GGX dla VRay'a, zgoda. Zresztą GGX jest podstawowym modelem w Imageworks (afaik), jest zaimplementowany w OSL, więc powinien być też w komercyjnym Arnoldzie.

W takich samych warunkach oświetleniowych ustawionych np. Mai z area lightami? Bardzo wątpię, ale jeśli tak, to jest to jakiś błąd, ponieważ jeśli "wzory" są te same, i zmienne są te same, to efekt jest ten sam - z definicji wzoru. Owszem GGX daje radę. To po prostu mało prawdopodobne, żeby Arnold miał jakieś magiczne modele, których nie ma VRray, Maxwell, Mantra, co tam jeszcze. Te techniki są dziś powszechnie znane, nikt nie pisze ultra wydajnego renderera zostawiając w nim prostego Blinna, jako jedyny model specular. Słyszę któryś raz ten argument, a to po prostu mało prawdopodobne - w każdym razie łatwo to sprawdzić, robiąc test, który zrobił Emmanuel we wspomnianym przeze mnie wątku. Jeśli masz Mayę, Arnolda i Vraya łatwo mnie przekonasz ;)

Czytam to już drugi raz w tym wątku i się dziwię. To jest jakieś gigantyczne nieporozumienie. Model Cook-Torrence'a był bodaj pierwszym praktycznym modelem dla powierzchni chropowatych (mico-faced), ale od jego czasów powstało kilka innych, lepszych, choćby dlatego że Cook Torrence jest dość kosztowny oraz niepoprawny fizycznie. Inna sprawa, że nie ma bodaj dzisiaj żadnego renderera, który nie oferowałby jakieś wersji modelu powierzchni micro-faced. Zdziwiłbym się, gdyby VRay nie miał takiego shadera, więc idę na stronę dokumentacji i oczywiście znajduję tam model Warda, czyli znacznie lepszą wersję modelu Cook-Torrence'a. Powiadam, to nie jest żadne osiągnięcie. Wiele rendererów, nawet jeśli nazywa model Phongiem, czy Blinem ma pod spodem coś znacznie lepszego, ponieważ nazywa w ten sposób kształt rozkładu odbicia - pokrewny z modelem Phona (liniowy), lub Blina (wykładniczy), a nie sam model BRDF. Wyraźna różnica między jakością odbić w path tracerach i ray tracerach pochodzi głównie ze świateł. Światła punktowe nie są w stanie wygenerować ładnych odbić, path tracer prawie zawsze pracuje na area lights, które nawet z Blina mogą zrobić ładne odbicia. skk. ps Przypadkiem odbyłem ostatnio tę rozmowę ze znajomym. Nie wiem, jak Ty to robisz, ale walisz prosto w stronę Dziadka3d. Szczerze Ci tego nie życzę.

Nie ma łatwej odpowiedzi na to pytanie. Idea, która stoi za Arnoldem mówi, że renderer może być relatywnie wolny, ale musi być niezawodny, prosty w obsłudze i na tyle poprawny fizycznie, na ile jest to praktyczne dla jego użytkowników. Innymi słowy filozofia Solid Angle mówi, że renderer X może być szybszy od Arnolda w pewnych, specyficznych okolicznościach, ale w przypadku niemal każdego poważnego zadania w branży, dla której powstał, czyli ujęcia z dużą ilością geometrii subdiv/displacement, realistycznym światłem, rozmyciem ruchu etc, koszt finalny (czyli koszt pracy grafika + koszt pracy farmy) będzie niższy, nawet jeśli czas renderowania jednej klatki netto jest wyższy, tym bardziej, jeśli weźmiemy poważnie pod uwagę jakość, bo wyciągnięcie z renderera X jakości Arnolda jest albo niemożliwe, albo graniczy z cudem. Komputery nieustannie przyspieszają, więc stać nas na komfort czekania dłużej na render, o ile szybciej możemy go posłać na farmę. Tyle mówi teoria.

...ale Taziowi zdaje się nie o to chodzi. Chciał symulować obiekty, które mają upieczoną deformację ręcznie (z Mai), a dopiero w trakcie kolizji trzeba je symulować. Tazio, to jest kilka kliknięć. Musisz użyć ActiveStateDOP z odpowiednią komendą (np. $FF > 20 jeśli impact jest w klatce 21). Obiekt powinny mieć atrybut velocity (policzone np. z TrailSOP), RBDObject DOP musi mieć włączone dziedziczenie velocity z punktów. Ważne też żebyś wyzerował velocity na punktach po klatce 21, inaczej nadaj będzie wpływać na symulacje. Załączam przykład, niestety nie wiem, jak to zrobić z RBD Packet Object, bo nie ma na ich "Use Deformation". Pewnie jakoś się da... anim_sphere_fractured.zip

Nie jestem tylko pewien, czy H13 używa ścieżki GPU dla OpenSubdivide. Wydaje się raczej, że geometria jest pieczona dla vewportu jako subdiv, ale na CPU....