SYmek

Deadline - doświadczenia bardzo pozytywne. Polecam. Za chwilę ma wyjść także wersja dla Linuksa. pozdr., skk.

Z tym akurat nie ma żadnego problemu. Jak wszyscy pewnie zauważyliście ;), uwielbiam się wymądrzać. Jak do tego dodasz bandę wymiataczy z odforce.net, możesz czuć się zupełnie bezpieczny :). @polka dot: Jutro Ci powiem! Stani's Python Editor - wystarczy raz odpalić skrypt a edytor zapamięta wszystkie deklaracje i zacznie podpowiadać ;). Co do edytora dla VEX, pomóc nie mogę, zdaje się Jedit ma kolorowanie składni VEXA. Dawno nie używałem, ale, jak wiadomo, wymiatacze w RSL I VEX używają tego: http://www.fundza.com/. Jeśli przywykłeś do VC, to możesz przysłużyć się ludzkości przygotowując helpa, color syntax itd dla VEX w VC. Na pewno jest na to metoda, żeby customizować to IDE na potrzeby innych języków. ;) pozdr., skk.

Niby bym mógł, to znaczy powiem nieskromnie, ze wszystko co się ukazuje ostatnio nie wnosi do mojej znajomości tematu wiele. Parę lat w tym siedzę. Ale z drugiej strony to nie takie proste. Posługuję się na przykład zupełnie sprawnie Vexem, ale znać język a znać wszystkie zakamarki engine'u to dwie różne sprawy. Uczyć Vexa nie ma sensu, bo wystarczy przeczytać trzy shadery dostępne w Houdinim, żeby poznać ten język (prawie zresztą identyczny z C) - o ile programowanie w ogóle nie jest nam obce. Jeśli jest, to lepiej zacząć od innej dziedziny niż VEX czy RSL. Choćby Python. Uczenie programowania w Vex to jest uczenie programowania shaderów a nie składni języka. Tj. trygonometria, algebra wektorów, geometria, algebra liniowa, i po prostu Renderman. Ja się nie czuję na tyle silny w tych tematach, żeby ich uczyć. Nawet jeśli 90% tego, co warto wiedzieć jest banalne i potrafi to każdy, komu się chce. Dlatego łatwiej jest mi odpowiadać na konkretne pytania niż przygotować tutorial na jakiś temat. Co chciałbyś wiedzieć? HOM? VEX? Python? pozdr., skk.

no, no, jadą równo. Ja mam takie wrażenie, że SESI wkurzyło się na 3dbuzz, który zajęty Mayą, nie wywiązywał się z terminów i uderzył do innej firmy. I teraz dwie firmy robią to, co miała robić jedna. Bo z tego, co wiem Digital-Tutors mocno korzystają z pomocy developerów z SESI przy opracowywaniu tych DVD. A za kilka dni dwa DVD dla TD z 3dbuzz... pozdr., skk. PS Ja tylko czekam, kto zrobi w końcu DVD o riggowaniu i animacji, bo najbardziej brak ludzi, którzy potrafiliby przygotować w Houdinim postać do animacji...

Możesz precyzyjniej napisać, jaki efekt chcesz osiągnąć? Bo nie rozumiem, z czym masz problem. Które elementy Twojej sceny są 3d a które nie? - odbicia mogą być generowane w trybie raytrace - reagują na otoczenie automatycznie, więc się także animują o ile otoczenie się porusza. - mogą być również mapowane z enviromental maps (np. w formacie HDRI), i wtedy również mogą się animować, o ile wygenerujesz sekwencję zamiast pojedynczej mapy. HDRI to po prostu 32bitowy format pliku, taki jak każdy inny, więc odpowiedź na Twoje pytanie jest pozytywna. Tak możesz wygenerować HDRI z animacji, zapisując animację po prostu w 32bitowym formacie plików.... chyba że.... ... masz na myśli, że samochody są nagrane kamerą i chciałbyś to mapować na słup, który jest w 3d. To również jest wykonalne, chociaż nie będziesz mieć prawdziwego HDR. Możesz jednak podbić sztucznie zakres kolorów w postprodukcji (osobiście zrobiłbym odwrotnie - tzn mapował wersję low-range, zapisał reflections w oddzielnym passie i "naciągał" kolory w kompozycji. Większa kontrola. Ale to gdybania, bo ja chyba nie rozumiem, co chcesz osiągnąć. pozdr., skk.

Zalety Linuksa w renderowaniu widać dopiero, kiedy renderujesz na dziesiątki/setki komputerów. Używasz wielu rendererów, posyłasz na farmę wiele zadań takich jak symulacje, wypluwanie plików renderera i sam rendering. Kiedy używasz referencji od rozproszonych obiektów, zarządzasz assetami sieciowo etc. Wtedy Linux rulez. Jest też pewnie 10% szybszy z powodu mniejszego zużycia ramu, szybszego I/O, większej stabilności. Natomiast w sytuacji 2-5 komputerów, kiedy pracujesz na Maxie, nie masz czego żałować. Zawsze możesz renderować spod Maxa na mental ray'u pod Linuksem. Ale wątpię, czy by Ci się chciało... ;). Że brak Maxa na Linuksa to jego minus? Pewnie tak, ale który z użytkowników Maxa ma z ty problem? Chyba nie ma takiego. Bo gdyby miał z tym problem, pewnie pracowałby w Mai, XSI czy Houdinim. pozdr., skk.

Jesli to mozliwe (a chyba tak) wyeksportuj scene razem z obiektem referencyjnym i zobacz jak porusza sie w Maxie. Co to znaczy, ze "ulozyles boxa w sposob pasujacy do perspektywy na filmiku"? Czy odleglosc boxa od kamery zgadza sie z odlegloscia do obiektu, ktorym sprawdzales scene w Boujou? Jesli Twoj box ma te sama orientacje, lecz lezy dwa razy dalej ( i jest dwa razy wiekszy, wiec nie widzisz roznicy), to nie bedzie pasowal do ruchu kamery. Do umieszczania obiekow w scenie sluza nulle, ktore boujou eksportuje do aplikacji. Musisz ich uzyc jako referencji w przestrzeni. Jesli Twoj obiekt porusza sie bardziej niz bys sie tego spodziewal to pewnie lezy za blisko ( o ile oczywiscie wszystko w Twojej scenie jest ok). @Hindus: nie widze powodu, dla takiej opinii. pftrack pracuje rownie dobrze jak Boujou i pare innych matchmoverow. Wielkich roznic w ich mozliwosciach nie ma, a Boujou ma ugruntowana pozycje od lat. Poza ewidentnym liderem w postaci 3dequlizera, peleton jedzie w kupie ;). pozdr., skk.

... dobre sobie, tylko gdzie ja na to znajdę czas? ;)

Jak znasz c++ nic Cię nie zatrzyma! Tego Ci zazdroszczę ;). Zajrzyj do katalogu soho. Masz tam przykład exportu do pygame, który ma 300 linii kodu. Nie da się łatwiej. pozdr., skk.

Wszystkie zmienne w shaderze powierzchni są w camera space... :) Krótko mówiąc, cały świat w IFD jest opisany względem kamery. Wyjątkiem mogą być te zmienne, które są wołane wewnątrz illumiance loop (na przykład L), te są zdaje się w przestrzeni obiektu. Czyli jakbyś liczył lambera to obie zmienne w tym: -dot(N, normalize(L)) są w object space. HDK? Zwariowałeś? Chyba bym oszalał, przecież ja ledwo dukam w C++. Python. Stanowczo Python ;) Poza tym, właśnie po to napisano SOHO, żeby przy pisaniu exporterów nie trzeba było sięgąć po HDK. Przecież większość exporterów ma banalnny kod i konieczność ciężkiego programowania w C nie ma w tych przypadkach sensu. Używając SOHO za pomocą kilku liniek kodu inicjującego dostaję pełny opis sceny. A wszystko odbywa się z prędkoscią C++, bo SOHO to przecież funkcje HDK z pythonowskim interfacem... pozdr., skk.

Gotowy, opensource engine (i raczej na OpenGL ;) ).

Owszem, porównanie jest nie fair ;). A można w Mai nadać im dowolny shader - także swój - rzucają cienie, jest na nich motion bur, można zmieniać tekstry w zależności od Pz i można je liczyć na farmie? Słyszałem o tych spritach wiele dobrego, ale nie wiem na ile są tak naprawdę elastycznym narzędziem. Piszę teraz exporter do enginu realtime dla H. poczekaj jakieś pół roku, to będziesz sobie mógł policzyć sprity z H. na GPU ;) pozdr., skk.

no właśnie! ;) Smażysz coś smacznego? Będzie można zobaczyć? pozdr., skk.

"wraca do łask" zakłada, że kiedyś miał te łaski... ;) A on po prostu robi się trochę bardziej popularny... pozdr., skk.

Jestes z epoki kamienia, ale przygotowujesz 120 minut animacji..? Wszystko zalezy od tego, jakiego rodzaju reczna animacje masz na myli. Wlasciwie zaden toon shader nie da Ci pelnej jakosci animacji tradycyjnej - a juz na pewno nie te dostepne standardowo w pakietach... Mozna takie efekty osiagac i rzeczywiscie robi sie 2d w 3d, ale nie ma to na prostej drogi. Stosuje sie techniki kombinowane, projekcje animowanych tekstur, mocna post-produkcje, reczne podmalowki, czasem kazdy obiekt powstaje w inny sposob etc. Krotko mowiac, trzeba dokladnie wiedziec, jaki efekt chce sie osiagnac i potrzeba mocnych patentow. Jest to zabawa raczej dla zaawansowanych niz poczatkujacych. Znacznie latwiej jest w stillach oczywiscie. Ale zrobic animacje klasyczna w 3d... hmm... nie ma na to chyba magicznego przycisku...

Ogólny efekt bardzo przyjemny, najbardziej mi się podoba, że to przemyślane jest. Warstwy, dobra kontrola całości. Niestety dynamika kuleje. Nie wiem, czym i jak to robiłeś, ale ani czaszka nie spada jak by się tego oczekiwało, ani cząsteczki nie reagują jak należy. Kwestia rozpadania się to już Twoja decyzja artystyczna, bo z założenia nie jest to efekt realistyczny. Ale reakcje obiektów na siebie i otoczenie powinny być bardziej przekonujące. Ale shot stanowczo warto poprawek (czyli, że fajny ;) ) powodzenia! skk.

Masater stara się to właśnie Ci wytłumaczyć: framework taki jak Orge powstaje po to (takich narzędzi jest bez liku), żebyś nie musiał programować samego OpenGL. Tworzy uniwersalne struktury, obiekty, które same zawierają obsługę niskopoziomowych API i dbają o to, żebyś nie musiał babrać się w szczegółach, tylko możliwie szybko stworzył swój świat. Mimo tego, że framworki, gotowe enginy i inne narzędzia ułatwiają pracę nad grafiką, nie jest to zabawa dla początkujących. Po prostu programowanie grafiki 3d (nawet w oparciu o Orge) to jest wyższa szkoła jazdy w programowaniu i grafice w ogóle. Jeśli nie masz nawet jasności co do tego, czy obiekt w grze jest modelem czy renderem z Maxa, może powinieneś sięgnąć - jak Masater uparcie i bez skrupułów sugeruje - po jakieś podstawy. Nie chodzi o c++ ani nawet OpenGL, ale o grafikę przestrzenną w ogóle. Do rzeczonego Orge jest na przykład kilka książek. Są również pozycje dla początkujących w programowaniu gier. Jeśli piszesz w Pythonie a chciałbyś szybko łyknąć początki używania jakiegoś enginu, zobacz VPython, albo całą masę innych narzędzi na: http://wiki.python.org/moin/PythonGames Dzięki temu może szybciej ugryziesz zależności między enginem, OpenGL'em, contentem i swoimi chęciami. powodzienia, skk.

Maya działa bardzo dobrze pod wieloma Linuksami. Czasami problem może być z instalacją, shellem itp. Ale generalnie sporo ludzi tutaj pracuje na Mai w Linuksie. Nie mówiąc już o dużych studiach, gdzie Linux jest podstawowym środowiskiem pracy i Maya pracuje głównie na nim.

E tam! ;) Chciałeś zrobić coś nowego, fajnego, i dobrze się przy tym bawić ;). Z punktu widzenia ekonomii, było to przecież mało opłacalne - pisać skrypt w matlabie, zamiast postawić parę kluczy czy wstawić noisa dla mocy światła. Pomógł przenieść więcej informacji z video, co Cię raczej nie interesuje, bo jak rozumiem, nie chciałeś animacji łączyć z video. Piszę ten post trzeci raz, kurcze, bo nie wiem,co napisać. Z punktu widzenia praktyki, całe przedsięwzięcie miałoby sens, gdyby przenosić z video dane na temat koloru i dynamiki światła. Co bez HDRI jest mało możliwe. Jeśli chodzi o przeniesienie skoków w luminancji, to jak napisałem, robi się to w kompozycji, dzięki czemu łatwo to zmieniać i poprawiać almost realtime. Co nie zmienia faktu, że skrypt ciekawy i mógłbyś to popchnąć dalej. To znaczy zrobić HDRI, bez HDRI i z animowanym światłem. Nagraj chromową kulę. Potraktuj może materiał rozciągając sztucznie zakres światła i zapisz we float. Zamiast liczyć wartość dla całej ramki, podziel ją na części i sampluj tak jakby rzucona była na półsferę. Wartości mapuj na światła w light-dome. a viola! (taż zabawa, tylko trochę ciekawsza) powodzenia, skk.

Fajna zabawa, ale żeby to sie sprawdzało w praktyce, musiałbyś mieć system HDRI realtime. No i liczyć luminancje dla każdego sampla na hemisferze, a nie dla całej ramki. A to istnieje i się nazywa... LightStage (pdf). Gdybyś zrobił coś takiego w domu... hmm... W tym przypadku, używasz matlaba, żeby policzyć względną zmianę luminancji między klatkami, czyli coś, co w praktyce, o którą kannu pyta, robi się od lat w kompozycji. Pass dynamicznego światła renderuje się oddzielnie i statycznie. Potem oblicza się w dowolnym programie kompozycyjnym to, co Ty liczysz w matlabie, i spina (np. mnoży) z owym passem, a potem dodaje do reszty. Mógłbyś na przykład wykorzystać HDRShop z jego pluginami do generowania light-dome (olewając kwestie HDRI rzecz jasna). Sfilmować sferę, obliczyć w HDRShopie serię luminancji w kolejnych klatkach dla każdego światła i wykorzystać to w 3D. To, co robisz w tej chwili nie ma po prostu zastosowania praktycznego, chyba że coś umyka mojej uwadze ;) ale zabawa przednia! pozdr., skk.

30 złoty to jest uczciwa cena za pismo, bądź co bądź, niszowe. Płaciłbym nawet 50zł za dwumiesięcznik lub kwartalnik o treści, która odpowiada tej cenie. Myślę, że komuś tu zabrakło pomysłu, jakie pismo chce robić. "PCExpert" z poradami dla ciotek posadzonych nagle przez zmienne koleje losu przed komputerem czy pismo dla profesjonalistów. O dziwo, rynek jest już na tyle dojrzały, że nie da się tego pogodzić. Co jest, że powtórzę, objawem dojrzałości, do której Szanowna Redakcja i Szanowny Wydawca muszą się chyba dostosować. Jakoś czarno to widzę. Ciekawe ile egzemplarzy trzeba sprzedać, żeby się to zaczęło opłacać. I żeby Szanowny Wydawca zechciał wyposażyć Szanowną Redakcję w środki pozwalające jej na zrobienie przyzwoitej gazety... bo marność pierwszego numeru wyraźnie bierze się z niedofinansowania. A to jest strzał w stopę, co ktoś celnie zauważył. Wracając do kwestii decyzji, których zabrakło myślę, że nie ma dziś czegoś takiego jak "profesjonalista" w ogóle lub "3D" w ogóle. Rozdźwięk doświadczeń, narzędzi, oczekiwań wobec pisma, między kimś, kto robi wizualizacje a kimś, kto robi animacje, jest zasadnicza. Warto to wziąć pod uwagę i podzielić pismo wyraźnie na działy. Być może ułatwi to trochę recepcję materiału, bo zawodowiec w animacji, widząc artykuł dla początkującego w Viz, nie będzie się czuł oszukany. Po prostu wciśnie fast forward. To, że pismo dla tak małego rynku jak polski, musi być możliwie uniwersalne, żeby się w ogóle opłacało, to rozumiem, ale uniwersalne nie znaczy żadne, tylko bogate w propozycje dla możliwie wielu. powodzenia na przyszłość, skk.

kannu, moze niewyspany byles? Spotykam sie od czasu do czasu z taka opinia i mysle sobie, ze "Szczury" (ze tak sie wyraze, aby nie mocowac sie z francuskim) sa pierwszym filmem animowanym (z tej klasy), ktory zrezygnowal z prostej jak cep konstrukcji trzyaktowej dla dzieci. To nie znaczy, ze taka konstrukcja jest prosta w wykonaniu i nie znaczy, ze Szczury automatycznie sie udaly. To jest po prostu troche inaczej opowiedziany film. Jego srodki narracyjne sa, moim zdaniem, bogatsze. I zwroc uwage, ze automatycznie nie ma w tym filmie zbyt nachalnego dydaktyzmu. Masowy film aniomowany rozstaje sie po prostu ze swoja dotychczasowa forma, bo ta sie po prostu przezyla (czego dowodem sa "Auta", fenomenalnie usypiajacy film z moralem dla 7-latkow). Ja mysle, ze Oni po Autach poczuli, ze trzeba isc do przodu. Tyle.

Oczywiscie, ze mozna. Smialo mozesz caly film zrobic na jednym z darmowych enginow realtime. Takie filmy juz powstaja. A kiedys to bedzie norma. Zasadnicza problem w tej chwili to sampling. Renderery w wielu miejscach w pracesie generowania obrazka musza usredniac wartosci wielu sampli. Motion blur, DOF, AA, tekstury,GI itd itd. Nie ma na to prostej metody w standardowych technikach realtime. Ale jak wiadomo, to sie juz zmienia. Jak porownasz jakosc nawet najlepszego screena realtime z renderem filmowym zobaczysz, w czym problem. Kolejna niebagatelna sprawa to kontrola nad materialem. Przeciez film to jakas konkretna wizja. Nie jest latwo kontrolowac bardzo szczegolowe elementy obrazka z enginu gry w taki sposob, jak ma to miejsce w tradycyjnej animacji 3D. Ale oczywiscie, ze powtorze, to jest przyszlosc. pozdr., skk. PS @masater: reyes to wlasnie algorytm mikropoligonalny.

mental ray juz potrafi korzystac z GPU. Przede wszystkim jednak nie o karty i silniki pod Maxa tu chodzi! Mental Images posiada bardzo zaawansowana technologie VR. Meta-jezyk shaderow, RealityServer, za pare lat bedzie z tego w pelni zintegrowany system rzeczywistosci wirutalnej. Dawne podzialy straca sens, bo nie bedzie zauwazalnej roznicy miedzy gra, filmem a rzeczywistosci. Mentel posiada juz dzisiaj zaczatek takiej technologii. Stad ta transakcja. Swiat nie kreci sie w koło GI ;).

http://www.nvidia.com/object/mental_images.html