mokramyszka666

@Shogun 3d: obawiam się że większa część użytkowników maxa pracuje w taki sposób. Tym osobom z miejsca współczuję...

Dziękuje, ale patrzmy na pełen obraz a mianowicie creditsy. W kontekście TP zarządzili przy tym projekcie, również - a może przede wszystkim - Leru i Bartek Grzybowski. Szacun panowie. :)

Jak dla mnie dość szczegółowy opis: * Custom render element pathing. * Custom file type pathing including EXR. This tracks parameters for output file formats, as well as formats, and, in the case of EXR, includes render elements, gbuffers, bit depth, color channels, and more. * iray and Quicksilver render parameter tracking. * Better UI interaction through render-dialog refreshing. * Tracking of viewport layouts. * MAXScript exposure. * Object and solid scale tracking to After Effects. * Ability to copy state sets. * Tracking of V-Ray object properties. * Tracking of V-Ray cache. Pomijam już fakt że w przypadku render_states sprawię załatwia punkt 'maxscript exposure'... No comments.

Mam wątpliwości co do godziny :) Czas UTC(0) czyli Greenwich to w Polsce UTC+1 czyli 17:00. Może to potwierdzić ktoś obeznany w temacie?

Ja jednak odnoszę wrażenie, że ludzie przede wszystkim nie zdają sobie sprawy co to znaczy rozwijać soft, który ma bazę 400,000 zarejestrowanych użytkowników, że już nie wspomnę o tych, którzy legalnej wersji nigdy nie widzieli, a krzyczą najgłośniej :] Teraz zmiany są bardziej widoczne, niż np. przy wersjach 2008-2010, ale nie uważam żeby wynikało to ze zmiany podejścia ADSK. Widzę po sobie, że najbardziej przydatne okazują się nowości i poprawki, które są, jak na złość, najmniej chwytliwe marketingowo. Czy zachęcisz nowego klienta (który nie miał styczności z 3d) mówiąc mu, że teraz będzie robić bardziej złożone i ciężkie sceny? :) Max od zawsze był softem totalnie uniwersalnym żeby nie powiedzieć 'masowym'. Trudno sprawić, żeby wszyscy byli zadowoleni. Zatem nie zaklinajmy rzeczywistości - nie ma obowiązku używania tego programu.

Grave: Zrób sobie dla odmiany jakiś większy projekt w maxie 9. Wtedy wszystko będzie jasne :]

Tempo rozwoju maxa jest takie, jakie było zawsze :) Kilka kroków za całą resztą, nadrabiane (często z nawiązką) za pomocą plugów. Zawsze można narzekać, ale jak przychodzi co do czego to nagle okazuje się że aktualny max (2012) przy swojej 15 letniej architekturze spokojnie dźwiga sceny, które poprzednia wersja ledwo otwiera. Oczywiście to żaden argument, bo teraz zostały już tylko turlające kostki... Zwiększenie wydajności Nitrousa w kontekście partikli, nowy typ obiektów zoptymalizowany pod deformacje, wymiana danych między CATem i MotionBuilderem, State Sets, zupdatowany MassFX z clothem. Dla niektórych ciągle z jakiegoś powodu wazniejszy jest gradient w viewporcie. To już chyba kwetia gustu, więc nie wnikam. Bo niestety żadnej logiki nie jestem w stanie się tutaj dopatrzyć...

Nie. Uważam, że komentowany filmik jest totalną pierdółką, ale tak czy inaczej, to się po prostu przyda, nawet jeśli nie wszystkim - i tak nie zaszkodzi. Natomiast poza przedstawionymi do tej pory bzdetami w postaci poprawek interfejsu itp. wiadomo również o kilku nowościach, które w/g mnie rekompensują tą roczną opłatę subskrypcyjną, więc zwyczajnie nie rozumiem po co te dziwne komentarze dot. wersji, która jeszcze nie została oficjalnie potwierdzona :) Gdyby chociaż 10% tego czasu poświęcić na konstruktywne uwagi, bug reporty itd. w ODPOWIEDNIM do tego miejscu (nie uważam za takowe max3d ani cgTalk) to może byłoby więcej ciekawych tematów do rozmowy. Np. Zed pisze o sensownych rzeczach, tylko kto z odpowiedzialnych za soft ludzi to przeczyta? W dużym uproszczeniu wygląda to trochę jak marudzenie na rząd przy wódce i nie chodzenie na wybory ;) EDIT: @Grave, a masz jakiś powód żeby nie cieszyć się z każdej poprawionej dupereli?

Jak prezentują fajny ficzer to 90% mądrali nawet nie wie na co patrzy. Jak pokażą poprawione duperele, to jest płacz że słabe. Czasem niestety rozumiem dlaczego ADSK ma w poważaniu swoich użytkowników :]

3-etapowy nie oznacza w tym wypadku 3-letni (niestety).

1) Woda wokół statku to dzieło panów Sykutów - z tego co wiem nie zaprzęgali to tego RF ;). Realflow był wykorzystany do splashy krwi. Hehe, akurat ten ciągnący siur, o którym wspomniałeś to czyste TP, z prostą turbulencją emitowane przy ogromnym subsamplingu przejechane Frostem. 2) No, jakby to powiedzieć.... destrukcja była symulowana warstwami (keszowaliśmy kolejne dynamic sety, dadając kolejne elementy), według wspólnego schematu, który był czasem trochę modyfikowany pod ujęcie, bo np. raz reja była 'nic nieznaczącym obiektem' a w innym ujęciu cięła cały pokład. wszystko dźwignięte przez ShapeCollision bez większych problemów :) System destrukcji nie wykorzystywał bitmap. To była najczęściej praca pod ujęcie, ponieważ animatik (nie bez powodu) był najwyższą świętością ;) 3) Właściwie każde ujęcie to osobna symulacja. Dla ciągłości cześć wypalonych elementów z poprzedniego ujęcia była wciągana do kolejnego. Staraliśmy się żeby do finalnej sceny nie wchodziło nic poza tym co konieczne. 4) Żaden szczególnie kosmiczny patent nie przychodzi mi teraz do głowy. Przyznaję że samo TP jest niesamowicie kompleksowym, przemyślanym i _działającym_ systemem...

Cześć, Dziękujemy za komentarze. Fajnie, że się podoba. Odniosę się bezpośrednio do pytań Beny'ego. Zespół był podzielony według specjalizacji z niewielkimi ruchami w trakcie produkcji. Leru: fumefx, Krakatoa; Marek Sulęcki: ciuchy (maya nucleus); Bartek Grzybowski: Thinking Particles; moja nieskromna osoba: wszystko po trochu + ciągłe zrzędzenie. Pierwsze setupy powstały na długo przed finalizacją animacji. R&D burzenia statku, cześciowe setupy ciuchów... Wiadomo, że później weryfikują ten stan kolejne ujęcia, ale baza do pracy powstała zawczasu. R&D dotyczyło głównie organizacji scen i pracy z TP. Było trochę walki z ograniecięm materiałów ze względu na ich ilość w scenie, ale również dlatego, że prawie każdy obiekt był potencjalnym celem do rozwałki. Dochodzi kwestia matID oraz kolejne zagnieżdzenia w shaderach, które i tak do lekkich nie należały. Ujęcia powstawały według dość 'elastycznych' priorytetów. Zależało to zazwyczaj od ogólnego statusu danego shota. Ogólnie rzecz biorąc, staralismy się uniknać bezsensownych przestojów na randerfarmie i to dyktowało kolejność prac. Większość (90%?) to faktyczna geometria. Maciek Jackiewicz pewnie wie lepiej ;) Najczęściej fragmentacja była dynamiczna (VolumeBreak), ale czasami Voronoi nie wyglądało najlepiej i wspomagaliśmy się Rayfirem. Praktycznie jedyny punkt wymiany był między Maxem i Maya, ale w ten sposób pracujemy od dłuższego czasu i zaryzykuje stwierdzenie, że przebiega to bez problemów. Całość była bardzo sprawnie zarządzana przez system do 'batchowania' napisany przez Markusa. Co do ostatnich tygodni (było więcej niż 2 ;) ) trafiłeś. Poza tym było w miarę spokojnie, chociaż jak nietrudno zgadnąć, to nie był jedyny projekt z FXami w tym okresie :)

Hmm.... symulacja tworzenia i rozpuszczania piany też była możliwa w 4.3... Mimo wszystko wolę Filter Daemon. Widzisz chyba różnicę między jednowątkowym kodem w pythonie a normalną implementacją... Odnoszę dziwne wrażenie, że jeszcze zanim odpaliłes nową wersję uznałeś ja za zbędną bo nie zawiera dokładnie tego co byś chciał...

To by było doskonałe rozwiązanie, gdyby voxele zwiekszały rodzielczość adaptywnie przy niedostatku detalu, kolizjach itp. Podejrzewam, że przeszło im to przez myśl, ale może innym razem... Czy ty już miałeś okazje testować nowego realflowa? ..bo jak widzę cały wachlarz nowych możliwości przy emisji splashy (po krzywiźnie, vorticity, velocity), przy kontaktach z obiektem, wszystko spod paluszka w emitterze to oczekuję sporego wzrostu komfortu pracy. do tego distance fieldy, poprawione generowanie map... Określenie wodotryski jest bardzo adekwatne, nie rozumiem tylko dlaczego piszesz, że zbędne. ps. o co chodzi z wersją 5.5? Hybrido było i jest w wersji 5.0.1. Swoją drogą to najnowsza wersję oznaczyłbym właśnie jako 5.5....

Z tego co widać to dodatkowy parametr grida, więc raczej działa globalnie. Na pewno nie będzie to spowalniać symulacji tak jak zwiększanie resolution. Większość ciężkich obliczeń odbywa się tu na voxelach a nie na partiklach, więc nie spodziewałbym się jakiegoś dramatu. Bez wątpienia zwiększy to dokładność kolizji i ParticleMesha. Co do kamuflowania splashami... skoro tak to musisz nazywać :) Dla mnie to nieodłączny, a często kluczowy element symulacji w Hybrido. Cieszy również przyspieszenie w tej wersji operacji I/O, chiciaż tutaj już Albert misiałby się wypowiedzieć, czy widac poprawę. Przy cięższych symulacjach, gdzie kesze sięgają 2GB na ramkę, dłużej się czeka na ładowanie grida niż samą symulacje splashy... ale dla Ciebie to też pewnie kosmetyka, więc już się niepotrzebnie nie podniecam.