SYmek

Nieco chaotyczny, ale bardzo ciekawy masterclass o nowym solverze cloth. Godne polecenia, bo ten solver nie jest bynajmniej zabawką (continuous collision detection, resolution independent, support for changing cloth topology, plastic deforms, tangent drag, 64bit precision, adaptive substepping, ...)

1) Trzeba powiedzieć wprost, sklejanie programu z cudzego kodu okazało się być genialną strategią biznesową. Jak wygląda taki kod w środku, wie każdy kto praktykował garbage development. Trudniej jest o taki kod dbać, rozwijać go, znajdować bugi zanim zaczną się odzywać. Koszmar każdego programisty. Nie jest przypadkiem, że większość udanego oprogramowania jest owocem pracy małych zespołów traktujących swoje dzieło bardzo osobiście. 2) Pisanie programu, który musi być łatwy w użyciu, sexy, bo musi się podobać przeciętnemu użytkownikowi, nie pozostaje bez konsekwencji dla jego konstrukcji. Rozwiązanie optymalne przegrywa, bo będzie wymagać od użytkownika czegoś, co nie mieści się w założeniu be easy. 3) Nie da się robić programu dla wszystkich, albo jest dla nierozgarniętego architekta, albo dla TD, albo dla grafika komputerowego. Koniec końców nie będzie friendly dla nikogo. 4) To nie są problemy Adsk. Jak każda korporacja, nie zajmują się pisaniem oprogramowania, tylko robieniem kokosów. Gros tej pracy polega na ograniczeniu możliwości wyboru konsumenta i kreowaniu jego potrzeb (vide Adobe Creative Cloud). To dotyczy w równej mierze herbaty co oprogramowania.

No... nie wiem w jaki sposób VRay miałby wpaść w kłopoty, rozszerza popularność na nowe rynki i jest w tym bardzo skuteczny. Arnold, celujący właściwie tylko w jeden segment rynku (tak zwane produkcje filmowe), najwyraźniej nie przejawia w ogóle takich ambicji, żeby z VRayem konkurować. VRay dla Nuke'a wynika z obserwacji oczywistych potrzeb w branży. Chaos wykazał się tutaj dużą czujnością. Nuke ma fatalny renderer scanline. Zauważyło tu już Juppiter Jazz robiąc plugin na 3delightcie dla Nuke'a. Aż się prosiło o taką wtyczkę, i dziwne że jest ich tak mało, bo API Nuke'a jest przygotowane na tę okoliczność od wielu lat. (Kilka studiów ma oczywiście własne rozwiązania na różnych rdzeniach renderujących, tylko nie było czegoś takiego w sklepach z zabawkami).

To już widać!

Nie chce zaśmiecać wątku, ale nie masz racji. Znajdź mi taki kawałek o reżyserach trailerów z Digica, Bluru, Axisu etc. Żadna tradycja, a analogii z Jacksonem nie ma. To jest pochodna tego, że PI od lat wyciera sobie gębę nominacją Tomka Bagińskiego w calach czysto merkantylnych, który firmuje tym sposobem pracę setki ludzi, często nie mniej zdolnych od niego - delikatnie mówiąc (nie, nie sądzę, żeby T.B. osobiście kiedykolwiek na tym zależało...). A radą na to byłby krótki mail do Onetu.

Świetne, gratulacje!

Ja nie rozumiem tych uwag co do tempa czy wyglądu, to jest po prostu świetne (może dlatego, że się nie rusza? :) ). Jest też bardzo sprawnie wyreżyserowane (co nie jest takie oczywiste w pracach PI). Kadry, budowanie napięcia, dozowanie informacji, wszystko tip top. Podoba mi się również to światło jak z packshotów. Niby nierealistyczne, ale w tym przypadku to właśnie działa na historię (w przeciwieństwie na przykład do tego kawałka o zabójcach króli, gdzie plastik-look pasował jak pięść do nosa). Na balans kolorów dałbym nagrodę, za nadmiar dyspersji (który to już raz!) nie. skk. ps Tekst Onetu o Tomku Bagińskim, który stworzył koleje arcydzieło jest niesmaczny. Pozostaje nadzieja, że to nie sprawka ludzi z PI. (Chociaż pr'owcy PI nie jedno mają na sumieniu w takich kwestiach i mam obawę, że tekst powstał przy współpracy z nimi...).

http://code.google.com/p/rat4nuke ja też :)

No właśnie o to idzie, że niczego nie polecam. PyGame jest przykładem prostego środowiska OpenGL dla Pythona, ale to ślepa uliczka (aczkolwiek prosta sprawa). No, nie wiem, poza tym, że tam po prostu już są, co Ciebie, jak rozumiem, nie interesuje. Generalnie to dobre środowisko do gmerania na niskim poziomie, ale jeśli chcesz programować geometrię w Pythonie, to może nie jest to najlepszy pomysł. Raz, że robienie rekursywnych systemów na nodach jest mało eleganckie w ogólności, więc nawet jeśli możesz (a możesz) zrobić lsystem tylko na nodach, chyba nie o to idzie. Dwa, że VEX (ganialny patent w Houdinim) się nie nadaje, bo nie tworzy geometrii, tylko ją modyfikuje. Zostaje Ci więc Python albo C++. Implementacja Pythona w H. jest wzorowa, ale dość ograniczona jeśli chodzi o generowanie geometrii (bo po co, jeśli wszystko jest na nodach...), choć z drugiej strony zawsze możesz Pythona rozwijać przez C++, co jest genialnie proste. C++ przez SDK jest super, ale można to robić w każdym sofcie.Wprawdzie, żaden program nie da Ci takich możliwości technicznych, ale jeśli chodzi o samo kodowanie L-Systemu i jego wyświetlenie, to Blender może być lepszy, a także Max czy Maya, po prostu dlatego, że w Houdinim geometrii się nie programuje (tylko noduje), a w pozostałych programach owszem.

Uśmiechnąłem się na tekst o nowince, która zwiększa wrażenie głębi u widza :). Ani to nowinka, ani głębia u widza. Tylko tyle. Owszem, bo w większości przypadków nie jest potrzebne, za to bardzo obciążające. Wątek Cortexa dotyczył konwersji Rat do Dtex, aby komponować w Nuke'u, czyli ktoś to musiał renderować :) (ale komponować mógł tylko w Houdinim, o ile nie napisał sobie własnego pluga, co wielu zrobiło). No, nie chcę się spierać, ale generalnie nie :), nie wszyscy, tylko Ci, którzy nie mogli, bo Maya (bez rendermana), XSI, nie wspominając Maxa, mają solidne wsparcie dla deep rasterów od skandalicznie niedawna. :) pozdro, skk. ps tak sobie piszę trochę dla sportu ;)

Świetna strona, gratulacje. Ekspozycja twórców na pierwszej stronie też zacna.

Z jednej strony stawiasz processing, czyli wysokopoziomowe środowisko do robienia grafiiki, a z drugiej języki C# czy Pythona... nie rozumiem. Jeśli znajdziesz podobne środowisko w C# czy Pythonie (a są takie), to wtedy możemy rozmawiać i porównywać, ale na razie tak zwany brak danych. 1) Ma być real time, czy nie? 2) Ma być wieloplatformowe, czy nie? 3) Chcesz się pobawić l-systemami, czy chcesz zrobić coś, co będzie wyglądało, ruszało się etc. 4) Chcesz to dalej rozwijać, cz nie? 5) Zależy Ci na środowisku czy na konkretnym języku? - Jeśli real time, to nie Python, nawet jeśli są środowiska real time na pythona to są złe. - Jeśli real time, i ma to być szybka piłka, to processing jest bardzo dobre. Ma dobre 3d, tylko tyle, że zrobić ładne 3d jest trudno, więc ludzie robią raczej ładne 2d, bo w processing siedzą ludzie, którzy lubią ładne. Poza tym Twoje l-systemy mają dobre towarzystwo na każdej platformie, kamera, mokrofon, Kinex, etc. - Jeśli wieloplatformowe, to nie C#. - Jeśli ma być realtime, chcesz mięć całe środowisko i nie programować od zera, ma być wieloplatformowe, chcesz to rozwijać, ma dobrze wyglądać i nie przeszkadza Ci C++, to zobacz Cynder albo OpenFrameworks (Cynder tylko Win i OSX). - Jeśli nie musi być real time, ma to być szybka piłka, i może być Python, to wystarczy dowolny program DCC, Maya, Max, Softimage, Blender. Oczywiście najlepiej Houdini ;) pozdr., skk.

Deep compositing nie jest śmieszny, jest genialny! Śmieszne jest reklamowane tego w 2013 roku jako testowanie nowej technologii, która daje widzom wrażenie większej głęb (!!!)i. Przecież ich własny PRman wypluwa pliki typy deep od jakiś 5 lat, podobnie jak Mantra Houdiniego, a nawet Vray od jakiegoś czasu. Pół Avatara zrobiono tą metodą i kilka innych filmów. Pliku typu deep zachowują wszystkie sample, które posiada renderer w trakcie liczenia, czyli nie są to jakieś nowe dane, ale dokładnie te same, których używa renderer kiedy komponuje finalny obraz z sampli rozrzuconych z przestrzeni. (pro forma: sample to miejsca w które trafił promień i dla których wykonał się już shader przypisany do danej powierzchni) Te sample nie są w jednej płaszczyźnie (płaszczyźnie poligona), bo niektóre promienie, szczególnie na krawędziach obiektu, nie trafiają w niego (albo przechodzą przez obiekt, jak w przypadku dymu), więc za finalny kolor pixela odpowiada chmura punktów rozrzucone nie tylko na szerokość i długość pixela, ale również w głąb. Tylko w ten sposób renderer może poprawnie skomponować finalny obraz i wygładzić krawędzie różnych obiektów. Właśnie dlatego, że plik finalny (jpeg/png/exr) zostaje "spłaszczony" programy kompozycyjne nie są w stanie wykonać pewnych operacji, DOF w post-produkcji wygląda fatalnie, komponowanie włosów to koszmar, wkładanie czegoś w dym wymaga rysowanie ręcznie masek. Dzięki plikom deep wszystkie te problemy znikają. Możecie policzyć płonący obiekt oddzielnie od ognia i spokojnie go z nim skomponować. Jest to zaawansowana kompozycja wykorzystaniem kanału głębi (możne też passy oddalać od kamery, przenikać ze sobą obiekty w osi Z bez błędów na krawędziach). Ta elastyczność okupiona jest rozmiarem plików, który dla klatki HD z łatwością przekracza gigabajt (deep pixels w half float i kilka deep rasterów). Jedna sekwencja w filmie może zająć terabajt i więcej. Dlatego zaleca się składanie w ten sposób tylko trudnych ujęć. Jakby nie było deep compositing to był hot topic dwa lata temu, bo wszyscy zaczęli tego używać, więc wiele do testowania tutaj nie ma. pozdrawiam, skk. [edit] Przechowywane są wszystkie wartości dla wszystkich pixeli w wszystkich deep plane'ach - czyli każdy pixel ma kilka kolorów w głąb. To, o czym wspominasz (dopiero teraz doczytałem wszystkie posty, sorry za powtarzanie po Tobie), czyli zapis tylko kilku wartości z-etki dotyczy maxowego RPFa o ile się nie mylę... ?

Tak po prawdzie, to zdziwilibyście się, ile liczą się Wasze klatki (w każdym razie powstające w studio na farmie), kiedy policzy się ich całkowity koszty cpu ( czyli czas renderu razy ilość corów) zsumowane dla każdej warstwy finalnego obrazka - bo takiej miary używa profesjonalny render wrangler (czasami normalizuje się ten wynik także dla 1Ghz, kiedy na farmie są maszyny różnej generacji). To jest jedyna miara, które daje jakiś ogląd sytuacji. Jeśli klatka HD reklamy liczy się 40 minut na pierwszy plan + 15 minut na drugi lub na dymiki/efekty na standardowej 8 rdzeniowej maszynie, to już mamy 7 godzin... ta-daa..!

W renderowaniu i7 mogą mieć lepszy stosunek wydajności do ceny, ale w symulacjach już nie. 32 wątki, duży cache i obsługa większej pamięci robią swoje. Czy to uzasadnia wydawanie tych pieniędzy na komputer to inna sprawa i bardziej zależy od tego, czy te pieniądze maja się zwrócić. skk. ps Co do dysków SSD, to przy symulacjach flip może mieć on duże znaczenie. Niestety cząsteczki na dysku bywają wielkie (+10GB na plik), więc i dysk musiałby mieć właściwą wielkość.

Cały pomysł na fotorealizm, żeby ratować prmana przed Arnoldem jest zabawny, ale powyższe zdanie to po prostu komedia.

Nie ma takiej opcji spod palca. Jest Xray, (prawy przycisk myszy na obiekcie), co działa dokładnie odwrotnie, czyli dany obiekt będzie widoczny wireframe kiedy jest przykryty innymi obiektami. 1) Możesz to zrobić shaderem, w zakładce OGL jest parametr ogl_alpha, który za to odpowiada. Można to zautomatyzować za pomocą na przykład selectscript, który zaaplikuje odpowiedni shader dla wybranych obiektów, kiedy są wybrane w viewporcie. 2) Inny trick to ustawić Xray we właściwościach viewportu dla geometrii template. Zrobi się przeźroczysta o ile będzie miała flagę template włączoną. Inna, jeszcze głupsza metoda, to zabawa z domyślnym shaderm GLSL.. :( skk. ps Ta opcja była banalnie prosta w Houdini 8.0, bo można było podać vieportowi własny shader OGL dla obiektów w różnym stanie (np. wybranym/xray etc).

No fajne, masz oko, estetyka jest tip top. Z filmem gorzej. 1) Film to nie ilustracja jakiejś tam, choćby nie wiem jak mądrej, myśli. To znaczy, jak tam sobie chcesz, ale w ten sposób ograniczasz swój film do poziomu ruchomego piktogramu. Tu są dwa poziomy, raz że postacie ilustrują myśl Pascala, co nigdy nie jest dobrym pomysłem, ale jeszcze ujdzie. Dwa, że w tym wysmakowanych obrazach dzieje się coś, jak gra w zgadywanie (ja pokazuje, a wy zgadujecie tytuł filmu). A to jest strasznie mało. To nigdy nie jest dobre dla filmu. Ja nie wiem, co tam się dzieje, mogę się domyślać, ale to nie ma znaczenia, bo zabierasz moją uwagę od ekranu i każesz mi myśleć o jakiś metaforach. Metafora jest wrogiem sztuki (wbrew temu, co myślą o tym źli artyści). 2) W życiu nie widziałem obrandowanego filmu. Fatalnie to wygląda. Ale kawałek ma klimat i jest na co popatrzeć! pozdrawiam, skk.

Definite reference jak to mówią. Niestety drogie, rzadkie i bez sensu (bo za chwilę będzie nieaktualne), ale dla kogoś, kto poważnie interesuje się mrayem, jest to kawał wiedzy.

Z technicznego punktu widzenia jest to totalnie możliwe (i praktykowane przez wiele rendererów), tylko potrzebny byłby shader, który pakuje wymagane passy do beauty, ale być może nikomu nie chciało się pisać takiego shadera dla Vraya. Rozwiązanie to wymodelować zwykły shader, żeby zachowywał się jak wymagany pass. Nie wiem, ile można zdziałać z materiałami w Vray, ale na przykład w XSI można spokojnie zrobić shadow matte shader dwoma nodami, podobnie jak odbicia itd ( w prmanie czy mantrze to w ogóle standard). Zdziwiłbym się, gdyby nie było na to sposobu w Vray (aczkolwiek uwaga Miłosza3ds jest zasadna, im render bardziej fizyczny, tym logiczne rozdzielenie passów trudniejsze).

Bardzo fajne, gratulacje! Bardzo podoba mi się również sposób prezentacji. Efektownie, ale bez ściemy i klarownie. pozdrawiam, skk.

Swoją drogą najbliższy oryginalnemu tematowi jest pomysł na pracę o modelowaniu ze zdjęć (świetny). Jest masa materiałów na sieci wkoło tematyki "Structure from motion", oraz masa otwartego kodu. Złożenie tego do kupy w prototyp aplikacji klienckiej, którą odtworzysz rzeczony budynek ze zdjęć automatycznie, a nie ręcznie, będzie solidną pracą inżynierską. Potrzeba do tego trochę programowania i rozeznanie w temacie computer vision na poziomie undergraduate. Zagnij promotora :)

Beny ma absolutnie rację, choć punkt 3. brzmi może nazbyt górnolotnie, można go sprowadzić do prostego: "czy moja inżynierka będzie dobrym zaczątkiem pracy w wyuczonym zawodzie?". A wyuczony zawód to inżynier informatyk, a nie grafik, praca inżynierska powinna dawać Twojemu przyszłemu pracodawcy namiastkę tego, czemu chcesz się w swoim zawodzie poświęcić, czy będziesz pracował dla producenta oprogramowania, czy uczelni robiąc doktorat. Tyle teorii, a rzeczywistość jest taka, że jesteśmy na szarym końcu świata w jakości kształcenia, większością polskich dyplomów można się podetrzeć, a za dużą część tego procederu płacicie Wy i Wasi rodzicie - w żywej gotówce, rok w rok, od ponad 20 lat, miliardy złotych. Spędzenie 5 lat na publicznej uczelni zakończone takim dyplomem graniczy z defraudacją. Problemem jest oczywiście promotor, nie Pierog, ale kto wywali promotora z uczelni, skoro był studentem dziekana i dostał pracę na uczelni tylko dlatego, że nie był od niego mądrzejszy i nie publikował więcej...

Nie twierdziłem, że to wymysł Adsk, to zabieg wszystkich firm, które kantują na cenach. Jeśli firma ma sprzedaż w jednej walucie na cały świat, jakoś nie zastrzega takich warunków (vide theFoundry, Sidefx). Problem polega na tym, że takie zapisy w umowach są niezgodnie z przepisami handlowymi (przynajmniej w EU), więc nie dojdziesz do tego, czy kupując taki program, zgodzisz się na jej zapisy, czy tylko godzisz się na zapisy zgodnie z przepisami, bo na inne i tak nie mógłbyś się zgodzić...pętla bez wyjścia.

Co jest kompletnie bez sensu, nie wiadomo pod jaki paragraf podpada i można to równie dobrze olać podobnie jak sprawę odsprzedawalności. Problem polega na tym, o co się bijesz. Chodzi o legalny program, czy o support i update? Nikt nie zmusi Adsk to honorowanie takiej licencji, tak jak nikt nie znajdzie paragrafu na to, żeby Cię ukarać. Jeden z wielu absurdów licencji oprogramowania. Jak słyszę, że Max kosztuje 4000euro, to mi się nóż w kieszeni otwiera.