SYmek

Panowie, w przypadku animacji postaci wybór softu nie ma żadnego znaczenia. Dostajesz rig i zaczynasz animować. Są ludzie, którzy dostawali pracę na Mai w największych studiach, a nigdy Mai nawet na oczy nie widzieli. Po tygodniu animowali równie dobrze jak inni.

E, tam! Nie ma czego wykładać, wiadomo w czym się robi filmy ;) Pytanie natomiast jak to się ma do przyszłego autora animowanego shorta powstającego w Polsce? O, to jest dopiero pytanie! - na które nie ma zresztą prostej odpowiedzi... 1). Bardzo wiele zależy od tego, co to będzie za film, co na nim widać, w jakiej stylistyce powstaje. 2). Jeszcze więcej zależy do tego, co sam potrafisz zobaczyć, jaki poziom doskonałości estetycznej i technicznej Cię interesuje. Jakie są Twoje wymagania. 3). No i w końcu wiele zależy od tego, jak bardzo chcesz się umoczyć po drodze, tj. ile jesteś gotów zainwestować czasu, żeby to wyglądało tak, jak sobie tego życzysz. 4). Istnieją ujęcia, które zrobione w VRayu będą nie do odróżnienia od tych z PRMana. Istnieją też takie, w których te różnice trudno będzie nie zauważyć. 5) . Istnieją takie rzeczy, z którymi żaden program, poza PRManem, sobie nie poradzi, ale może to oznaczać, że ja, Ty, czy mathix również sobie z tym nie poradzimy, więc rozsądniej będzie pójść na kompromis i nie robić w ogóle takiego ujęcia... Mało też jest takich ujęć, których nie dałoby się uprościć, szczególnie jeśli stajemy przed dylematem: mniej albo wcale. 6). No i w końcu zawsze może się okazać, że to, iż coś wygląda kiepsko, nie ma dla nas znaczenia, co również może być cnotą... 7). Jeśli ktoś planuje pracę w XSI jest naprawdę w doskonałej sytuacji. XSI ma genialną implementację mental raya a po niedawnym wydaniu 3delighta na XSI, masz to, co najlepsze z dwóch światów i to w wyjątkowo wygodnym opakowaniu. 8). Wydaje mi się, że o ile nie ma się bardzo wyśrubowanych oczekiwań, albo projekt nie zasadza się na bardzo specyficznych założeniach, można z powodzeniem realizować shorta nawet w maxowym scanlinie. 9). Studia filmowe wybierają swoje narzędzia choćby ze względu na rozmiar produkcji. Jak masz 1500 procesorów na farmie, to musisz używać programu, który potrafi się w tym odnaleźć, czyli na przykład kompresuje transfer sieciowy, rozdziela pracę na etapy (czyli GI cache, mapy cieni. odbić, proceduralne obiekty i wiele innych elementów sceny, może liczyć przed powstaniem samego obrazka), używa plików opisu sceny (najchętniej ASCII), potrafi działać zarówno wielowątkowo jak i wieloprocesorowo etc. Wiele takich dupereli, które nawet nie zahaczają o jakość obrazka czy szybkość renderingu ;) 10). Jakość renderera to nie tylko jego prędkość, niezawodność czy uroda obrazka. W niektórych zastosowaniach przeważająca może być kolekcja dobrych shaderów a w innych taka drobna właściwość jak to, że w pewnych programach możesz zapisać na dysku (automatycznie) 1000 prostych obiekŧów a renderer sam złoży z nich 10-tysięczną armię niepowtarzalnych robotów, z wariacjami shaderów, tekstur czy animacji. I do tego zrobi to na 512MB RAMu ;)... pozdr., skk.

Co to znaczy najlepszy renderer? Nie ma takiego. To zależy od tego, czym chcesz się zajmować. Pod XSI masz mental raya i 3delighta i... niczego Ci więcej nie potrzeba, o ile chcesz robić animacje, a nie Viz. VRay? Zamienił stryjek siekierkę na kijek... pozdr., skk.

...hmm, większa część tej książki od dawna jest w sieci, legalnie. Nawet nie wiem, czy nie całość. A skąd ten cytat, jeśli można wiedzieć?

Wybór między tymi programami jest bardzo nieoczywisty. Na jedno wychodzi. Bodaj tylko VFX jednoznacznie przesądza o przewadze Mai. Ale animacja już nie. No i na pewno nie rendering. Wybierz ten, który Ci lepiej leży w ręce ;). pozdr., skk.

Wielokrotnie poruszano już ten temat. Choćby tu: http://www.max3d.pl/forum/showthread.php?t=47589 Nie wydaje mi się, żeby Twój wybór narzędzia miał znacznie przy decyzji pracodawcy o zatrudnieniu - o ile będzie to jedno z wiodących rozwiązań. Znacznie bardziej liczy się to, jakim jesteś grafikiem. Chyba, że Twoje narzędzie wnosi nową jakość, na której zależy firmie, na przykład poszukują kogoś od Realflow itp. pozdr., skk.

Przepraszam za przeoczenie ;) Wydaje mi się, że nie o to chodzi - a w każdym razie, nie tylko o to. Po pierwsze, części z tych problemów w Maxie się nie rozwiązuje i udaje się, że ich nie ma - a z kolei w Mai naprawdę ich nie ma, bo Maya jest programem napisanym od podstaw z myślą o "produkcji" - to znaczy dużych fabrykach obrazu (filmowego). pozdr., sk.

Zaczyna się. Chyba się wciągnę ;) 1). Jest dokładnie odwrotnie niż mówisz. Maya jest bardzo techniczna, Max jest bardziej... [EDIT] sorry, byłem przed druga kawą ;) 2). Dominacja Maxa bierze się z bazy użytkowników. Max, 10-15 lat temu był jedynym dostępnym i zrozumiałym programem pod Windows. Najłatwiej też go było ukraść. To znaczy używać cracka, stąd najłatwiej było się go nauczyć. Ilość materiałów do nauki jest pochodną tego efektu. Dostępność = baza ludzi = dużo materiałów, tutków, księżek etc. Drugi powód dominacji Maxa w Polsce, to specyfika rynku produkcyjnego, który nie ułatwia, delikatnie mówiąc, specjalizacji pracowników. Efekt jest taki, że mało jest ludzi o kompetencjach czysto technicznych, którzy potrafiliby rozwiązywać problemy związane z produkcją. To sprawia z kolei, że preferuje się gotowe rozwiązania, czytaj: Max + 1001 pluginów. 3). Bardzo wiele studiów w Polsce używa zarówno Mai jak i XSI. Niektóre nawet w całości oparte są o Mayę. Większość ma mieszany tool set. Kwestię tego, czy Max lepiej sprawdza się w mniejszych produkcjach, zostawiam otwartą. Najwyraźniej po prostu się sprawdza . pozdr., skk.

No właśnie dlatego, że się nie zajmuje siatką, poligonami, prymitywami etc. Jak wiesz, REYES zaczyna od stworzenia sobie reprezentacji geometrii widocznej w buckecie w mikro-poligonach. Kiedy ma już mikropoligony zapomina o geometrii, niczego nie zagęszcza, przesuwa, interpoluje, nic z tych rzeczy. Ma chmurę punktów w przestrzeni i pracuje tylko na nich - do czasu wywołania raytracingu przez shader oczywiście. To tak, jakbyś oblepił rzeźbę piaskiem. Bez względu ma to, jak gęsta, skomplikowana itd rzeźba by nie była, sprowadza się do ziaren piasku, których ilość jest zależna od wielkości na ekranie (między innymi). Możesz nawet zapisać te mikropoligony na dysku i nigdy więcej nie sięgać po samą gemetrię, która posłużyła do jej powstania. Zostanie tylko forma odlana z punktów. To ma swoje niebagatelne konsekwencje, wiele konsekwencji. Na przykład odpowiednio zapisana chmura punktów nie musi rezydować w pamięci w całości (brickmaps!), a dostęp do okolicznych punktów jest śmiesznie tani w porównaniu z innymi metodami (point clouds). No i przemieścić taki punkt (displace) jest także śmiesznie łatwo w porównaniu z gęstą siatką poligonów na których pracuja raytracery. To tak z grubsza ;) pozdr., skk.

Fajne demko, jak zwykle. Tyle trochę nudne. Kiedyś więcej uwagi przykładali do tego, co podają na talerz. O połowę ciach!, kilka ujęć z fabuł, kilka z reklam, "Arka" na deser i już. Więcej nie znaczy lepiej, tym bardziej jeśli ujęcia prezentują równy, żeby nie powiedzieć jednostajny, poziom. Były kiedyś reele XSI zorientowane na grafikę i motion design, "tu pracują artyści" - chciały zgodnie z filozofią marki, powiedzieć. Teraz mają miszmasz bez charakteru. O, ponarzekałem sobie od rana ;) pozdr., skk.

Masz absolutną rację ;). Ale nam sie wiki rozmowa zrobiła :) Shogun 3D, nie chciałbym Ci robić przykrości, ale nie masz racji, he he. To znaczy masz tylko w połowie. Displace oczywiście odkształca powierzchnię, ale czy to jest siatka, czy się ją zagęszcza itd, to już inna historia... Wymieniłeś tylko jeden ze sposobów, ten gorszy ;) pozdr., skk.

Jak mówię, nie pracuję na tym, więc nie chcę się spierać, ale wydaje mi się, że powyższe wątki mówią po prostu o tym, że normal mapy lepiej wywiązują się z imitacji przesunięcia, bo lepiej definiują normalne powierzchni. Nie przesuwają jej jednak. Nadpisują N. Najwyraźniej bump mapy ( i przeliczanie N na nowo po ich aplikacji) radzą sobie z tym zagadnieniem gorzej niż myślałem ;) Ale faktem jest, że z samej natury normalnych wynika, że łatwiej jest za ich pomocą definiować kształt powierzchni, niż za pomocą bumpa. Tu, zdaje się, masz rację.

Hmm, wydaje mi się, że różnica między normal mapami a bump mapami jest trochę inna i niekoniecznie ma związek z przekształceniami powierzchni w jednej osi lub trzech osiach. (Choć przyznam szczerze, że ponieważ używa się je głównie w grach, nie mam wielkiego doświadczenia z normal mapami, mogę więc coś mieszać ;) ) Technicznie rzecz biorąc obie służą do tego samego: podają funkcjom odbicia (reflectence model), które definiują kolory powierzchni "błędne" informacje w celu imitacji mikro wypukłości. W jaki sposób? Do obliczenia koloru powierzchni w najprostszym przypadku potrzebujesz: P - położenia punktu na powierzchni I - wektora od tegoż punktu do kamery L - wektora od tegoż punktu do światła N - normalną punktu W przypadku bumb-mapy udajemy, że punkt nie znajduje się w punkcie P, tylko w punkcie przesuniętym wzdłuż jego N o wartość podaną w mapie (dajmy na to "lum"): fakeP = P + (N*lum) potem musimy jeszcze raz obliczyć jego normalną, która może się zmienić (szczególnie dla okolicznych punktów. nN = computenormal(N) Nie następuje prawdziwe przesunięcie, to dzieje się w przypadku displacemant shader, ale kiedy takie N podamy funkcji obliczającej kolor, np. najprostszemu lambertowi: lambert = cos(nN, L) ...to dostajemy kolor nie dla P zdefiniowanego przez geometrię, ale jakby przesuniętego. Tak jakbyśmy pytali: jaki byłby kolor P, gdyby go przesunąć o tyle a tyle wzdłuż jego normalnej? Jak łatwo się domyślić z powyższego normal mapa jest czymś szalenie podobnym. Zamiast hipotetycznie przesuwać punkt, obliczać dla niego nową normalną i podawać to do funkcji odbicia (takiej jak diffuse, phong, blinn, cook-torrance etc), dostarczamy jej "udawne" normalne, a funkcje te, podobnie jak w przypadku bump mapy obliczą "niewłaściwe" światło. Dlaczego więc wymyślono normal-mapy, skoro bump działa podobnie? Nie znam zapewne wszystkich przyczyn, ale jedną z nich jest dokładność. Bardzo nieoczywistym punktem w tej opowieści jest ponowne obliczanie normalnych dla zmodyfikowanego P. Liczy się je za pomocą cross produktu (wektor prostopadły do płaszczyzny dwóch wektorów), dwóch bardzo nieoczywistych wartości: pochodnych z S i T powierzchni (s i t to takie UV implicite zawarte w każdym prymitywie). Otóż obliczanie tej wartości nigdy nie będzie dokładniejsze od wartości normal map z Zbrusha, ponieważ obliczane jest w przestrzeni ekranowej i zależy od wielu parametrów, takich jak rozdzielczość ekranu, sampling, AA, sposób rasteryzacji powierzchni etc. Dlatego właśnie najgorzej wyglądającą częścią obrazka "zbumpowanego" są krawędzie między przesuniętymi punktami a tymi, które zostały na miejscu. Wyglądają bardzo niedokładnie, prawda? Ponieważ normal mapa definiuje kierunek zwrócenia powierzchni, oczywiście musi być kolorowa... ;) No i zdaje się, że normal mapy z Zbrusha są w tangent space a nie camera space. A skoro tak, to robi się to jeszcze trochę bardziej skomplikowane ;) pozdr., skk.

Fajowy projekt, też chciałbym taki licencjat pisać! ;) Poszukaj na sieci materiałów o "divergence-free noise". Jedyny sposób, żeby nie używać tutaj fluidów, jak mi się wydaje. Powodzenia! skk.

Tego żaden z Nas nie może wiedzieć na pewno, ale skoro oba programy są równolatkami, oba działąją na nodach (czy jak to się tam w Mai nazywa), to nie wydaje mi się, żeby były tu jakieś zasadnicze różnice. Spodziewałbym się raczej, że chodziło im o zgodność wstecz, jak już napisano, no i zwykłe korporacyjne lenistwo... po co zmieniać coś, co działa i się sprzedaje?

E tam, musieliby po prostu napisac cale API, a nie zwarpowac starte API Pythonem. Myslisz, ze HOM oznaczal przepiasanie calej archtektury H.?

Dzięki za ogarek! pozdr., skk. PS Swoją drogą obiektowość Pythona byłaby lepiej widoczna, gdyby samo API w Mai było obiektowe. Nie jest, i podstawowa rzecz, którą zajmuje się nasz obiektowy kod, to generowanie nieobiektowych komend Mai - to jakby bawić się XML'em bez żadnego DOM'mu. Wprawdzie, jak piszesz, popularność Pythona nie tu żadnego znaczenia, bo nie da się używać go w Mai bez znajomości MEL'a, ale jeszcze jedną różnicą, którą wprowadza Python jest czytelność i elegancja kodu. Komendy te same, ale porządek w parametrach, zmiennych, pętlach itd jakby większy ;)

...+60 zdjęć..! Zajęło mi to 20 minut i dostałem w prezencie kupon na wycieczkę do Turcji...

Czy Java expressions umożliwiają w AFX dodawanie warstw, przypisywanie footage do warstw? Chyba tylko kanały w już istniejących warstwach można modyfikować za pomocą expressions, ale nie jestem pewien, dawno nie widziałem Afx na oczy. Wiem natomiast jak to łatwo zrobić poza Afx i prawie za darmo ;) (99$)... Co więcej nawet ostatnio musiał zrobić identyczną rzecz dla +60 zdjęć.

FBX ma wsparcie dla point cachu, ale wszystko zalezy od tego, jak go zaimplementowano w programie.

ano wlasnie, myslalem ze chodzi o export do mdd... pozdr., skk.

1) Czy Ty dzialasz w Blenderze tylko po to, zeby dostac md2? W innym watku chyba o to pytasz - czyli, ze gdybys mogl wypluc z Mai md2, robilbys w Mai? 2) Czy md2 to to samo co mdd?

... to było przejęzyczenie, rozumiem, że kolega miał na myśli Maxa. I Pan dobrze powiedział. Maya jest nieporównanie bogatszym softwarem, co nie znaczy, że należy wybierać ją, a nie Maxa. To są w ogóle pytania z du*y. Daruj sobie. Te sprawy są dużo bardziej skomplikowane a jednocześnie mniej skomplikowane. Można miesiąc o tym rozmawiać i zostać w kropce. Każdy z tych programów powstawał w innym środowisku, innym celu, innymi środkami i dla innych ludzi. To, co Ci się wydaje różnicą implementacji, jest często jedynie powidokiem ich historii. Autodesk naprawdę niewiele ma wspólnego z Mayą. Kupił gotowy, dojrzały produkt - który w żaden sposób nie pasuje do jego portfolio - tylko dlatego, że miał te 180 milionów dolarów w gotówce i nie chciało mu się walczyć z konkurencją. Po co się starać, jak można wykupić..? Poczytaj na sieci o historii tych programów i firm. Wiele Ci się wyjaśni. pozdr., skk.

Shadow map to tekstura stosowana w technice Shadow Deph (albo Deep) mapping . To technika obliczania cienia. Shadow map to zwykły Zbuffer z punktu widzenia kamery. Zapisuje odległość punktu na powierzchni od źródła światła. Potem, w trakcie cieniowania tego punktu sprawdza się na tej mapie, czy punkt jest widoczny dla światła czy nie. Jeśli nie jest, znaczy się, że jest zacieniony... Rozszerzeniem tej techniki jest Deep Shadow Map, która próbkuje przestrzeń wielokrotnie - a nie tylko w punkcie na powierzchni i zapisuje "widzialność" tejże powierzchni z punktu widzenia światła biorąc pod uwagę wszystkie przeszkody na drodze od światła do powierzchni. Ambient Occlussion nie jest de facto obliczaniem cieni. Nie bierze pod uwagę pozycji, koloru, ani natężenia światła. AO to po prostu stopień w jakim dany punkt na powierzchni jest wystawiony na światło z hemisfery. Im punkt jest bardziej zasłonięty (tak jak róg pokoju) tym mniej światła do niego dociera. AO nie oblicza swiatła! Oblicza procent(!) możliwego światła, który dotrze do tego punktu. Dla ludzkiego oka efekt jest podobny do cienia. Ale nie jest tym samym. Jest wiele implementacji AO, które różnią się od siebie. Niektóre biorą pod uwagę kolor hemisfery, który dotrze do punktu, inne zwracają tylko miarę zacienienia w skali od 0 do 1. Dobre implementacje pozwalają również określić kont, dla którego oblicza sie AO. Occlusion dla światła diffuse liczy się dla 180 stopni a dla reflectance 90. pozdr., skk.

Zapytaj na zajeciach w Palacu Kultury!