SYmek

O co chodzi z tymi Żydami? Wszędzie te menory (dziewięcioramienne!), wagony takie jakby z Holokaustu, postacie w tałesach, nie rozumiem, w jaki sposób to dotyczy Ciebie? Masz coś może do powiedzenia o losie Żydów czy co? Straciłeś rodzinę w obozie? Jeśli tak, to szkoda, że tak mało masz o nich do powiedzenia. To nie tylko jest grafomania, ale i uzurpacja. Pozwalam sobie na mocne słowa, bo czuję, że ktoś to musi powiedzieć, a sądząc po wpisach na vimeo i ciszy tutaj, nikt inny Ci tego nie powie. Tu nie idzie o to, że Twoje filmy są kiepskie technicznie, tylko że Twoje podejście do tematów jest zasadniczo błędne, żeby nie powiedzieć infantylne. Zastanów się, po co marnujesz swój czas na te produkcje. Jak znajdziesz odpowiedź, może zrobisz pierwszy, może jeszcze nie dobry, ale przynajmniej szczery film. Zabierasz się za Żydów, a nie chcę Ci się sprawdzić, jak wygląda jeden z najświętszych symboli tej religii! Ile dziadku masz lat, 12?

I tym sposobem, zdaje się już po raz trzeci, panowie z Side Effects odbiorą w tym roku nagrodę Akademii za osiągnięcia techniczne. Tym razem doceniona została Mantra: http://www.oscars.org/press/pressreleases/2012/20120105.html Gratulacje dla SESI!

@danilo2: rozumiem Cię i do pewnego stopnia się zgadzam (tj. widzę zagrożenie zaczynania od lipy). Zdaje się, że opieram opinię na osobistym doświadczeniu :). Ci zdolniejsi może powinni zaczynać od C, ale zwróć uwagę, że kawał historii programowania dotyczy propedeutyki nauczania - basic, pascal powstały w tym celu.

Problem ze studiami zaocznymi jest taki, ze ich jakość dramatycznie spada w porównaniu z dziennymi. Widać to jasno po ich programach, tj. tych uczciwszych uczelni, które nie mają złudzeń, ile da się nauczyć zaocznie, więc uczą specjalistów w wąskich praktycznych dziedzinach. Choc nie bagatelizowalbym wiedzy profesjonalnego programisty, powinieneś wiedzieć, że sztuką nie jest umieć programować, ale mieć co zaprogramować. Dużo ważniejsza jest wiedza z matematyki, niż z inżynierii programowania. Przeglądarkę Objtów napiszesz sam bez studiów w miesiac, ale coś bardziej użytecznego wymaga przede wszystkim matematyki. Twój kod może nie będzie 100% production quality, ale będzie potrafił robić pożyteczne rzeczy. Od tego są TD :) Jeśli Twoje zasoby czasu i pieniędzy są ograniczone stawiałbym na matmę, a nie programowanie jako takie, którego możesz sie uczyć sam, na boku, zaczynając oczywiście od Pythona, jako dobry wstęp do OOP. Potem C/C++ wchodzi *znacznie* łatwiej. Jeśli znajdziesz fajne studia (zarówno PW jak UW mocno tną program studiów zaocznych, może PJWSTK?), zwróć uwagę na poziom algebry liniowej, m. dyskretnej i (!) metod numerycznych. Studia polegające na nauce jakiegoś API (DX) to nieporozumienie i niestety częsta praktyka.

Sens jak zwykle okazał się najtrudniejszym elementem...

Futro to jeden z najtrudniejszych elementów CG, nie oczekuj łatwych efektów. Mental ray nie jest orłem w tej dziedzinie, chociaż potrafi renderować futro (głównie via rasterizer + detail shadow maps). Poszukaj na sieci tutoriali na ten temat (np. pierwszy z brzegu). Podstawowy problem jest taki, że futro, czyli miliony krzywych NURBS, słabo nadaje się do ray tracingu, właściwie standardowe mechanizmy akceleracji, które w ogóle pozwalają sensownie używać śledzenia promieni, zawodzą w sprawie futra a jeszcze bardziej długich włosów. Ponieważ mental to klasyczny ray tracer, stąd Twoje problemy. Kot w Shreku nie był liczony w mentalu, to pewne. Większość studiów używa rendermana (+ masa własnego kodu w shaderach i bakowania scatteringu), albo własne renderery dedykowane włosom - zazwyczaj wolniejsze od rendermana - głównie po to, żeby nie świecić ich deep shadow mapami, które dają solidny efekt, ale są pracochłonne i źle komponują się z GI. Najnowsze wynalazki, typu naj-nowszy VRay, naj-nowsze Modo, naj-naj-nowszy Arnold czy naj-naj-naj-nowsza Mantra, potrafią renderować fur w pełnym ray tracingu, ale zostały w tym celu zmodyfikowane. Reasumując futro wymaga specyficznego podejścia, trzeba trochę na ten temat wiedzieć i wybrać odpowiednie do swoich potrzeb i możliwości narzędzie. W Twoim przypadku będzie to pewnie Scanline, którym za pomocą kilkunastu światłem możesz zbliżyć się do światłą z Vraya. Alternatywnie, jeśli masz dostęp nowy Vray+Ornatrix może Ci przyjść z pomocą. pozdro, skk.

Nie idzie o to, co jest teraz, tylko o to, co będzie później. Jeśli ktoś pisze kod pod badania akademickie, to jest mu obojętne, czy za rok się wykona, ale jeśli chce go rozwijać i sprzedawać przez dekadę, to myśli inaczej. To, że Cuda związana tylko z hardwarem nvidii była złym pomysłem, potwierdziła nawet Nvidia (wspierając x86), a otwiarcie Cudy - żeby mogła w ogóle konkurować z OpenCL w dłuższej perspektywie - tylko to potwierdza. Co do ma do rzeczy? Podaje te przykłady, żeby pokazać, że jest różnica, kiedy mówimy o prostym ray tracerze napisanym przez jednego człowieka w mniej niż rok, a programach pisanych latami przez duże zespoły. Houdini 12, który pokaże się w publicznej becie pewnie na początku roku (luty?), ma wsparcie dla OpenCL'a w kilku micro-solverach levelset (Gas*), adwekcje, analizę pól (blur, curl, diffuse etc) i inne może robić w OpenCL (także na CPU). Obiecują także 'otwarty' solver, któremu możesz podać własny kernel. Na stronie SESI jest prezentacja 12tki. Testowałem już ten solver, rzeczywiście nawet na słabych Quadro (3500/3600fx) działa szybko, ale oczywiście bez pamięci wiele się nie zawalczy. 100 klatek symulacji w 100**3 to chyba max, co udało mi się osiągnąć (tylko dym, bez ognia, bo tam dochodzi kilka innych pól i nawet tyle bym nie uciągnął. O ile pamiętam także Chaos Group pokazując swoje zabawy z Cuda zapowiadało, że czeka na OpenCL. Racja, trudno to uważać za wolną wolę. Nie zmienia jednak faktu, że problemy OCL są przygodny (zła jakość kodu) a nie istotowa (zamknięta własność dostawcy sprzęty, któremu zależy na wyłączności). Otwarcie Cudy zmienia i komplikuje sprawę, pytanie tylko czy Intel i AMD podejmą pałeczkę czy zostają w swoich piaskownicach (bo sądząc po jakości OCL od Nvidii, ta się do 'obcego' produktu przekonała.

Aplikacje, o których wspominasz, nie miały wyboru, bo powstawały, kiedy OpenCL raczkowało, o czym doskonale wiesz. Niektóre już się przesiadają na OpenCL, nie oglądając się na jakość wsparcia AMD z powodów, o których także wspominasz. Swoją drogą Octane czy Cycles to może i aplikacje dla użytkowników, ale raczej zabawki, niż poważne narzędzia. Można je przepisać w tydzień. Ale taki Bullet czy Houdini to już inna sprawa. Zdziwiłbym się, gdyby ktoś z własnej woli opierał przyszłość swojej aplikacji na bibliotece należącej do dostawcy hardware'u. Oczywiście otwarcie CUDA może to zmienić. Nie jestem pewien, czy to dobrze. Ciekaw jestem reakcji Intela, pewnie to zleją po wydaniu własnego OpenCL'a (nie wiem wprawdzie, ile jest warta implementacja Cuda na x86 od Nvidii).

A to szkoda, ale swoją drogą, skoro można zrobić własny instancer, który nie ma tych ograniczeń... W Houdinim jest to zresztą rozwiązane ch*jowo. Nielogicznie, niekonsekwentnie i bardzo wolno, ale może lepsze to, niż nic. dzięki, skk.

Rozumiem, o czym piszesz, ale wydaje mi się, że programiści woleliby raczej, żeby sterowniki OpenCL od AMD były jakości CUDA, albo chociaż dorównywały tym od Nvidii (i Intela). Pisanie tylko pod Cuda jest (było?) co najwyżej mniejszym złem. Może "akademikom" to rybka, ale end-userskie aplikacje wyraźnie czekały na stabilizacje OpenCL, nie ładując się w Cuda dalej, niż to zrobił np. VRay.

Hej M!, czy dobrze rozumiem, że w pluginie 3delight dla Mai, nie da się posłać do instancji własnych atrybutów per point?

Trudno w to uwierzyć, ale najwyraźniej ludzie nie podeszli zbyt entuzjastycznie do pomysłu, że ich kod ma się wykonywać *tylko* na procesorach NVIDII:). No i mamy OpenC(uda)L?

Poprawne testy wpływu architektury na czas renderingu trzeba by robić na jakimś otwartym kodzie i to w miarę prostym, żeby wykluczyć jak najwięcej zależności. Tutaj można założyć, że winien jest kod, który nie został zoptymalizowany pod 64 bitowe kompilatory. Może konwersja została wykonana automatycznie? Może wykorzystają z jakiegoś garbage collector czy shared pointers, które działają na 32bit i trzeba je tłumaczyć na 64bity? Miliard zależności, połowa Windowsa to wciąż 32bitowe aplikacje (Linux zresztą też). Co z instrukcjami SIMD, które używa się w rendererach prawie wszędzie? Może aplikacja używa jakiś wybitnie złych fragmentów systemu? Na przykład Windows Vista miał bardzo poważne problemy z zarządzaniem pamięcią heap. Był to podstawowy powód wywalania się Visty przy pracy na poważnych aplikacjach. W każdym razie tak duża różnica w czasach renderingu po prostu nie najlepiej świadczy o jakości wersji 64bit. Co do samej zasady, może się zdarzyć, że program używa cache'u znacznie mniejszego od Ramu, a kiedy go przekracza, wywala z niego cześć obiektów (które potem muszą być tworzone od nowa) i w tym sensie zwiększenie zużycia ramu może przyspieszyć rendering. W innym przypadku, im mniej tym lepiej (choćby dlatego, że alokowanie pamięci też zabiera programom czas). skk. ps systemy 64bitowe są odrobinę wolniejsze, co zazwyczaj jest równoważone różnymi przyspieszeniami związanymi z nową architekturą, ale odrobinę!

No cóż, nie da się ukryć, że Świteź liczyła na więcej, ale niezbadane są wyroki niebios. Powodzenia dla Damiana! skk.

Sprawa była wielokrotnie walkowana. Większość firm będzie uparcie utrzymywać, ze licencji nie da sie odsprzedać. Niestety przepisy UE gwarantują to kupujacemu, czyli umowa licencyjna jest w tym punkcie nieważna. Sprowadza sie to do tego, jeśli ktoś zdecyduje sie na zakup takiego Xsi, moze sam siebie uwazac za legalnego, wygra pewnie z policja przemysłową, ale supportu niet, prawa do upgrade'u niet, tj. Adsk będzie twierdził coś innego.

W podanym tam linku (http://www.peterclaes.be/tutorials/PeterClaesThesis/index.html) jest właściwie wszystko, co powinieneś wiedzieć o fluidach w Houdinim. Nie pękaj :)

Coraz wiecej technologii typu renderowanie, symulacje, czy obrobka video korzysta z CUDA i OpenCL.

horror....

Nie ma żadnych widełek. Wszystko zależy od stopnia skomplikowania, długości animacji (sekunda z 5 sekund będzie droższa od sekundy z 30), oczekiwanej jakości, trybu pracy (na dziś, na jutro, na zaś). Z tego, co mówisz wnoszę, że nie chodzi tylko a animację postaci, tylko cały spot z postacią, tak? Krótko mówiąc, 8 tysięcy nie brzmi niewiarygodnie, ale mało która animacje jest tyle warta.

http://developer.nvidia.com/nvidia-texture-tools-adobe-photoshop http://registry.gimp.org/node/69

Niestety nie znam odpowiedzi, choć ludzie często piszą o tym problemie, w życiu się z nim nie spotkałem. 1) Piszesz bezpośrednio na dysk, czy z mplaya? 2) Możesz odpalić Houdiniego jako Administrator i spróbować jeszcze raz? 3) Próbowałeś renderować z linii komend, działa? 4) Renderuje pojedyncze klatki?

Tutaj dla przykładu wafel, który w ogóle nie istnieje w SOPach, ani jako volume, ani jako poligony. Dopiero mantra go generuje. Witam! Ano właśnie, a ludzie mówią, że nie ma takich. Potem się okazuje że po domach pół Polski rzeźbi w nodach

Dzięki Panowie w imieniu twórców za miłe słowa. Co do metrażu, to zdaje się, że odpowiada za niego wyłącznie gust reżysera. @Baggins: już chyba wspominałem, że ukazała się mocno skrócona wersja oryginalnego materiału. Niewykluczone, że będzie jeszcze okazja podzielić się szczegółami, których było w obfitości. Ciekawi mnie natomiast Twoja impresja co do natury Houdiniego. Techniczny? Owszem, ale chyba właśnie dlatego nadaje się do tricków. Mniejsza o to. Rola Houdiniego w Świtezi była jakby poboczna (choć kluczowa, jeśli to możliwe) ponieważ wykorzystaliśmy przede wszystkim jego siłę jako "systemu" do trawienia dużych scen. To znaczy, może poza tłumami, nie robił niczego, czego nie dałoby się w miarę łatwo zrobić w innym sofcie - ale umożliwiał bardzo wygodnym zarządzanie często naprawdę ciężkimi scenami. Drugą rolą był oczywiście rendering. Świteź musiała po prostu powstać w reyesie, więc opcji nie było za wiele. pozdrawiam, skk.

No tak, ale shader nie da rady zrobić struktury w 3d. Można by zrobić iso-surface w renderze, bardzo dokładne (tym bardziej jeśli użyć CVEX Volume Proceurala), ale skoro to ma iść do iRaya, to również nie ma sensu. Musi być siatka, i to będzie ciężka siatka. Tak jak kizia3d pisze można to isosurfacem machnąć. EDIT: W gruncie rzeczy to jest wszystko to samo, bo pod spodem działa dokładnie ten sam kod. Poligonizacje z wokseli zawsze robi ta sama funkcja w HDK, niezależnie, czy robi to Convert Volume czy Mantra czy iso-surfaceSOP. (ciekawe, kto to jest kizia3d z jednym postem... :))

No to fajnie. Super by to było zrobić w shaderze, lekkie i szybkie.