SYmek

Właściwe większość współczesnych rendererów filmowych zostało w ostatnich latach przepisanych do zera ze starego kodu CPU na... CPU. Także tak.

Jest wiele powodów, żeby zostać z Mayą i kilka z nich wymieniłeś, ale jeden z nich właśnie znika. Koszty licencji dla wszystkich animatorów w studio, to był poważny wydatek, który miał się amortyzować przez wiele lat odraczając ewentualną zmianę. Ale skoro koszty są stałe i coroczne... raz do roku możesz swoją decyzję zmienić bez strat i kopnąć w zad starą kobyłę (którą niektórzy tak lubią, bo dzięki niej mogą się opierdalać całymi dniami pisząc coś, co można było w XSI w zrobić trzema kliknięciami, a w Houdinim jednym nodem).

Go Autodesk, go! Jeden powód mniej, żeby zostać z Mayą. Skoro wynajmujesz program na rok, w każdej chwili możesz bez strat zrezygnować.

Hej, pełne poparcie i krzyżyk na drogę :)! Raz w tygodniu to za często jak na mój gust, ale Wasza sprawa. Trudno będzie o materiał na prezentacje, a to, moim zdaniem, warunek dobrych spotkań, żeby 1-3 osób przygotowały jakiś materiał. Anyway, dajcie znać co i jak, pozdrawiam! skk. ps Grupa FB też jest do używania, nie wiem, czy ktoś czegoś potrzebuje (uprawnień, żeby nią kierować).

Nie łam mi serca :)

Zakładam, obijając rafy teorii spiskowych, że w tym temacie robią, co mogą. Wydaje się to jakoś uzasadnione, skoro jedyny konkurent, dopiero co, po latach starań, dogania ich wydajnościowo... anyway, jeśli nie można szybciej, można przynajmniej taniej - dla mnie na to samo wychodzi. Ceny procesorów są z sufitu i podejrzewam, że jedynym powodem jest brak konkurencji. 500$ za nowoczesny procesor brzmi rozsądnie :) 4K$ nie...

I teraz intel obniża ceny...

Używamy w produkcji od kilku miesięcy. Może to sprawa systemu, bibliotek? To to samo.

A już myślałem, że to mój internet przez telefon taki zawodny... Fajne ficzery, szkoda tylko, że z adaptive sampling nie zdążyli w mantrze. Trochę odstają od konkurencji w tym temacie. W ogóle słowa o mantrze, dziwne..., albo Mark Elendt pojechał na urlop, albo szykują coś dużego :)

ależ oczywiście, że się da i jest to częsta metoda 'sprzedawania' swojego talentu. Autor Carve posiada pełne prawa do swojego kodu. Publikuje go jako GPL popularyzując go w ten sposób. Jeśli jednak chcesz go użyć w komercyjnym produkcie, musisz zgłosić się do niego po kod z inną licencją. Kod jest ten sam, ale dołączona licencja inna. Autor kodu ma prawo dystrybuować go z różnymi licencjami. Mniejsza o to...

Czyli, o ile rozumiem GPLv2, musieli kupić inną licencję, o ile nie chcieli udostępniać kodów Mai...?

W sensie, że wzięli kody z Blendka GPL i ukradli przyszłe kody z zetki i włożyli do H? :) Rozbawiło reklamowanie miniatur na COPsach, dawno je mieli, tylko wyłączyli kilka lat temu. Także radial menu są właściwie zabawne... Jedno trzeba gościom przyznać. Maya miała ch**owe booleany, Adsk kupił licencje Carve i zrobił trochę mniej ch**owe booleany. Houdini miał trochę mniej ch**owe booleany (były na poziomie majowych, pod upgradzie do Carve), kolesie napisali od zera całą bibliotekę do znajdowania intersekcji z dowolną precyzją i zrobili zupełnie nowe Booleany. Znajdź różnicę. Nie możesz? Dlaczego? Jeśli jeden upgrade jest w stanie zmienić Twoją decyzję, nie wróżę powodzenia. Pracujesz sam? Możesz tak po prostu zmienić software z projektu na projekt? Nie masz całego pipeline'u, pluginów, opartego na Mai?

a sneak peak ujrzał właśnie światło dzienne: https://www.sidefx.com/community/houdini-16-launch-streaming-on-february-6/

This is because, as I presume, we (Ha) and them (PI) are constantly looking for Houdini artists :), rest assured demand is big.

Podziwiam Baggins Twoją cierpliwość, ale i nieprzemakalność. Problem z tymi "filmami" jest taki, że są o niczym. Bardzo trudno jest zrobić śmieszny film o niczym. Gdyby scenarzyści mieli cień pomysłu na odczytanie baśni/legend (zrozumienie, o czym są), może potrafiliby napisać film o czymś. Komedia filmowa powstaje tak, że robi się poważny film ze śmiesznymi scenami. Kabaret robi się tak, że robi się śmieszne gagi i dialogi, a ludzie się śmieją, bo wiedzą, że to zabawa i jarmark. Jesteście niebezpiecznie blisko tej drugiej możliwości. Coś tam się rysuje na horyzoncie, ale to malizna (wspomniane już tutaj buta i charakter człowieka jako siła przeciw losowi). Niestety jeśli scenariusz jest o niczym, to Twoje decyzje też są do niczego, nie wiadomo dlaczego takie kadry, a nie inne, taka ich długość, a nie inna, na co patrzeć, na co zwracać uwagę. To, co opowiadasz jest tak marne, że nie ma znaczenia, jakiego środka użyjesz, żeby to opowiedzieć (byle się świeciło i wyglądało pro). Zostaje wrażenie drogiego filmu studenckiego. Zupełnie jakby syn Kim Chong Una zdał do szkoły filmowej i bawił się w kino. A to jednak obciach dla człowieka z Twoją pozycję. Takie filmy są anomalią polskiego rynku medialnego, w którym Wy obiecujecie swoim klientom coś, czego nie dostarczycie, ale za to zrobicie coś dla siebie (vide Twoje portfolio, przyszła fabuła, rozwijanie skilla zespołu etc). W normalnym kraju (czyli na dojrzałym rynku), takiej kupy po prostu nikomu nie chciałoby się robić, bo po co? Szkoda, bo potencjał jest. Legendy istnieją i są zapominane w zalewie amerykańskiej szmiry. Kto wie, może Bazyliszek skłonił kogoś do myślenia w zespole Allegro? Serdecznie Ci tego życzę. skk. PS aczkolwiek, po prawdzie, wydaje mi się, że to jest poziom treściwości większości animatików i krótkich animacji, jakie widziałem w życiu.

Rzadko zaśmiecam to forum, mam nadzieję, że tym razem to nie problem. Ciekawy artykulik, bo uzmysławia, w jakim miejscu znalazł się ostatnimi czasy Houdini, nawet w takich fortecach imperium zła® jak Disney: http://www.sidefx.com/stories/disney-animation-studios-zootopia ps kto by pomyślał, że w drugiej dekadzie XXI wieku, ktoś będzie symulował sierść na chopach :) ps2 a tak w ogóle, czy mi się wydaje, czy Disney przebił Pixara w storytellingu...?

Po co mi tłumaczysz, o to jest hydra, skoro wiedzę na ten temat czerpiesz, jak widać, z szybkiego skanu po internecie. Mówię o Hydrze, ponieważ używam jej i wiem, do czego służy. A wspominam o niej, ponieważ jest dobrym przykładem tego, jakie problemy stoją przed projektantami vieportów i gdzie Vulkan mógłby im pomóc. Twoje wyobrażenie o vieportach związane zdaje się z amatorskim używaniem Blendera albo edytora gier, nie obejmuje takich wyzwań jak wyświetlanie tysięcy deformujący się (na cpu) obiektów w różnorodnej topologii, od krzywych po nurbsy. Kolejny przykład o tym, jak bardzo nie wiesz, o czym mówisz, bo po prostu nie zajmujesz sie ta działka, ale idiotyczne ekstrapolujesz swoje marne doświadczenia na inne pola. A do tego, jak przystało na latorośl, zakładasz, ze wszyscy poza Tobą na tym forum są idiotami. A na koniec: mówisz, ze pixar czy filmowe narzędzia Cie nie interesują, ale z drugiej strony w kółko wypowiadasz tezy ogólne, bez zastrzeżenia, ze dotyczą Twojej działki. Byc moze w Twojej działce platform GPGPU AMD jest porównywalna z NV, ale w świecie CG/VFX nie jest. Niekoniecznie zreszta z powodu słabszych procesorow (mnie akurat Twoje argumenty techniczne wydaja sie całkiem przekonujące, tylko nie wynika z nich, ze AMD jest propozycja dla mojej branży lub HPC - które ma wiele wspólnego z moja praca wbrew temu , co Ci sie wydaje) . Inne powody są równie ważne dla profesjonalistów. Fanboja interesują tylko liczby. Ps. decyzje AMD wyraźnie wskazują, ze ta branża ich nie interesuje. Nie produkują akceleratorów, nie pozwalają nawet odpalić OCL bez Xsów, mnie sie to wydaje rozsądne. To jest mały rynek, trudny i zupełnie logiczne jest, ze ktoś woli robic procesory do grania i do konsol. Nie wiem, po co udowadniać coś, do czego oni sami nie sa, jak sadze, przekonani.

Posty materalii są uroczą mieszanką erudycji i młodzieńczej głupoty. 1. Całe stronice o renderowaniu, a potem się okazuje, że wie na ten temat tyle, co amator bawiący się Luxem, a PBR kojarzy mu się wyłącznie z ustawieniami high-quality w enginach gier. 2. Tyle wie o kartach, ale o ich jakości przesądza dla niego fps w grach i ilość ramu. 3. Gdzie i do czego używana jest Cuda sądzi po własnym researchu (sprawdziłem kiedyś, i nie ma ich tak wiele, a dla każdej jest alternatywa), co już sama w sobie jest kuriozum, za które można by mu przyznać tytuł matołka miesiąca (że niby jak to sprawdził sam i skąd jest pewien, że dla każdej jest alternatywa?). 4. W końcu Vulkan "nie przynosi korzyści aplikacjom poza grami", na co podaje sensowne argumenty (!), które mógłby rozwinąć, aby wyjaśnić kolegom, co ma na myśli, ale pisze zamiast tego, jak szkolniak: "ale na poziomie używanych obecnych viewportów..." - z czego wynika, że zna wszystkie obecne viewporty, widział kody kilku i je porównał, wie z jakimi borykają się problemami etc. A przecież widać, że poza Blenderem, Unity i przeglądarką objów, którą napisał w akademiku, żeby zaimponować dziewczynie, żadnego viewportu nie widział i po prostu nie ma pojęcia, z jakimi problemami radzi sobie na przykład Hydra, dla czego powstała etc. Ot, dziedzina skłonność do widzenia świata w poziomu własnej piaskownicy. A wystarczyło by trochę pokory, zamiast robić z siebie ministra Ziobro tego forum.

O, pewnie, że się przyda, dzięki! Widzę, kolejny zapaleniec :)

Nie wakacje, ale faktycznie siedzę przy grubiej sprawie i prokrastynuję :)

Argument o tyle nietrafiony, że kilka postów wyżej od Ciebie sam napisałem, że path tracing można zaimplementować w 100 linijkach kodu, sam to zrobiłem 10 lat temu, jak większość moich kolegów napaleńców. Z tego, co piszesz wnioskuję że znasz się na hardwarze, masz masę ciekawych informacji, ale nie masz pojęcia, co to jest nowoczesny renderer, nie wiem, po co się wymądrzasz. Brzmisz, jak człowiek, który twierdzi, że zna się a programowaniu, ale nie wie, co to jest kompilator. Odpuść sobie. Twoja ocena mojej wiedzy jest mało umotywowana, ani się na tym znasz, ani nie pokazałeś mi, gdzie się mylę (a nawet jeśli gdzieś się mylę, wezmę to na klatę, a nie, Twoim zwyczajem, zmienię temat).

Chodzi właśnie o to, że nigdzie tego nie powiedziałem. Ty zaprzeczyłeś, że użycie AVX zwalnia taktowanie procesora, a kiedy powołałem się na źródło, powiedziałeś że to oczywiste, żeby chwilę później zarzucić mi braki w wiedzy inżynierskiej (które zresztą posiadam, jako że nie jestem inżynierem). Brawo, zajebista logika. Nie masz pojęcia o renderowaniu. I dobrze, nikt nie wie wszystkiego, ja na pewno, ale jak ktoś prowadzi wśród grafików rozmową w sposób taki, że argumentów strony przeciwnej nie chce mu się nawet zrozumieć, tylko wali k*** nad klawiaturą, to oczekiwałoby się większego rozeznania w temacie. PBR nie ma nic wspólnego z silnikami realtime. Termin został przez nie zapożyczony ze świata offlinowego renderingu (nie real-time). Jest raczej nieostrym określeniem zmiany paradygmatu w algorytmach, w którym fizyczne zachowanie światła i powierzchni stanowi podstawę modelowania algorytmu. Koniec. Staramy się liczyć całkę równania renderowania w taki sposób, żeby energia nie ginęła ani nie pojawiała się znikąd, używamy terminów z radiometrii, oraz staramy się poprawnie modelować właściwości powierzchni, co w większości przypadków oznacza rezygnację z analitycznych modeli cieniowania na rzecz modeli empirycznych lub fenomenologicznych (stąd przejście ze starego dobrego Phonga na BBX w większości nowoczesnych rendererów, pojawienie się prawa Fresnela w każdej interakcji, a nie tylko refrakcji itd itd, zabawy z polaryzacją, modelem spektralnym etc). Krótko mówiąc staramy się, żeby algorytm był motywowany fizyką światła. Nie znaczy to nic konkretnego, ale kiedy w literaturze pojawia się termin PBR po Arnoldzie, Rendermanie, Mantrze, znaczy to właśnie to. A kiedy pojawia się w kontekście silników realtime, znaczy to, że silniki te aspirują w ramach swoich możliwości do podobnych rozwiązań (czyli zamiast chamskiej pętli lamberta i phonga po światłach, samplują otoczenie wewnątrz jakiegoś modelu micro-faced). Jak się rozumie, co PBR znaczy i skąd się wziął, wie się że kilka lat temu nie było to możliwe, bo wie się, co jest potrzebne, żeby zsamplować światło na umotywowanym fizycznie modelu powierzchni), Jasne, że nie pomożesz, ale zdanie masz, i tupet, żeby w publicznej dyskusji gadać głupoty na tematy, o których nie masz pojęcia. Zamiast zapytać, dlaczego Redshift jest dla ludzi w mojej branży jedynym rendererem GPU wartym uwagi, wolisz napisać, że jestem zaślepiony, bo Redshift jest na wrednym Cuda. Wychodzi na to, że nie masz pojęcia, jakie zalety lub wady OpenCL może mieć dla rendererów, bo za mało o nich wiesz. Ot gównarzeria.

Sam wcześniej temu przeczyłeś, rozumiem, że dla sportu... połowa Twojej wypowiedzi to trywialne fakty (co jest wąskim gardłem procesora na przykład), które nijak mają się do moich argumentów. Wkładasz mi też w usta rzeczy, których nie powiedziałem a potem z nimi polemizujesz. Rozumiem, że jakoś niedawno dowiedziałeś się, że wektoryzacja nie jest jedyną metodą optymalizacji i chciałeś się tą wiedzą podzielić. No dziękuję, jakoś do mnie dotarło wcześniej. No i nadal nie rozumiesz co to jest i co zmienia PBR. Gdybyś rozumiał, wiedziałbyś, co daje Kowalskiemu, ba nawet Tobie, i dlaczego nie dało się tego robić praktycznie jeszcze kilka lat temu. Zachęcam jednak do lektury. Za informację o top green dziękuję, przeczytam, choć to jeszcze gorsza wiadomość dla AMD, bo jeśli nie chodzi o prąd, to dlaczego tak sobie słabo radzą w HPC.. Proszę, podaj mi alternatywę. Stawiam butelkę dobrego wina (albo co tam sobie chcesz). Ale jeśli jej nie znajdziesz, to zachowaj się jak dorosły człowiek i przyznaj, że alternatywy nie ma.

Nie foldery reklamowe, tylko instrukcję procesora napisaną dla twórców kompilatorów. Jest w niej oficjalnie mowa o zwolnieniu procesora w przypadku dużego użycia instrukcji wektorowych, a do tego odniosłeś się a propos wektoryzacji. Nie chce mi się z Tobą wykłócać i biorę w tej dyskusji udział w dobrej wierze, więc najkrócej mówiąc użyłem "PBR" przy niektórych nazwach, żeby zaznaczyć, że te silniki mogą lub mogły do niedawna pracować w trybie, który nie nadaje się do bezpośredniego porównywania z Lux. Dopiero kiedy włączy w nich tryb PBR, takie porównanie ma sens. I w takim porównaniu ani Lux, ani Cycles, ani Indigo nie wypadają korzystnie - dla ludzi w mojej branży, czyli robiących filmy w komputerach. Obawiam się, że są to subtelności, które uchodzą Twojej uwadze, bo a) nie używasz zawodowo rendererów b) zbyt krótko się zajmujesz tematem. Potwierdzałoby to zresztą to, co napisałeś o PBR. Dzięki za wyjaśnienie, to ciekawa perspektywa, ale obawiam się, że wynikająca z bardzo ograniczonego doświadczenia kogoś kto bawi się trochę marmo toolbag czy czymś podobnym... PBR jest rewolucją w grafice komputerowej, która wywróciła go góry nogami życie niejednej firmy. Zabawne, że podejrzewasz mnie o ignorancję w temacie, z którego żyję, po czym wykładasz się na podstawowym temacie... Prawdę mówiąc szkoda mi czasu na walczenie z Twoją arogancją. Wiesz, interesujesz się, tylko podejście masz ch**we, zamiast spokojnie rozmawiać, walisz tutaj farmazony do ludzi, którzy 15 lat pracują zawodowo na tych narzędziach... Życzliwie radzę, znajdź sobie w internecie kursy z Siggraphu o PBR na przykład. Sam piszesz, że od niedawna, a ja od początku podkreślam, że mówimy o stanie na dzisiaj, co w świecie rozwoju oprogramowania znaczy, że mówimy o stanie sprzed kilku lat. Inna sprawa, że możliwość implementacji algorytmu, a środowisko, stabilność sterowników, debugger, narzędzia do optymalizacji etc, zarządzanie pamięcią, no i w końcu wsparcie OCL od głównego gracza, Nvidii, to insza inszość. To by ucieszyło wielu ludzi, bo woleliby pracować w OCL, choć podejrzewam, że kernel OCL, który ma tę samą wydajność co CUDA, będzie miał kiepską wydajność na CPU. Zgadzam się i również mi się to nie podoba, co nie zmienia faktu, że jak mój szef mówi, żebym zrobił coś, żebyśmy mogli pracować szybciej, to po długich rozważaniach, testach, rozmowach z ludźmi z innych studiów moje oczy padają na Redshifta, dla którego alternatywny nie ma. I taką decyzję podejmuje 99% wszystkich ludzi na moim miejscu. Nie siedzę w głowie ludzi od Redshifta, ale idiotami nie są sądząc po efektach. Dlaczego wybrali Cuda? Bo wiedzieli, że mam w studio, jak inni, +50 GPU Nvidii i Cuda da najlepsze efekty, przy najmniejszych problemach. Ale mam te GPU nie dlatego, że nie lubię AMD czy OCL, tylko dlatego, że od wielu lat sterowniki OpenGL dla kart ATI nie nadawały się do użytku pod Linuksem. A potem otwieram pdf, który zamieściłem wyżej i patrzę na liczby, jak to klaster isnt. Maxa-Plancka ma 600 K20, i martwię się, bo wiem, że skoro klastry jadą na Cuda, choć wolałyby nie, to cały programistyczny bajzel, debuggery, biblioteki etc, wszystko ma boost za pieniądze z grantów i to dlatego Cuda jest dopracowana a OCL będzie się nadal wolno rozwijał. A dlaczego Max-Plank liczy na Cuda? Bo Nvidia olewa swoje OCL? Tylko dlatego? No dobrze, ale dlaczego nie ma tam kart AMD? A bo AMD nie robi akceleratorów... ale dlaczego nie ma tam procesorów, dlaczego AMD straciło rynek HPC? A, bo zjadają za dużo prądu, nie są szybsi, za to mniej kompatybilni etc. I w ten sposób dochodzimy (nieco oczywiście upraszczając) do wniosku, że nie wszystko jest winą złej Nvidii, tylko istnieją realne problemy technologiczne, które utrudniają AMD konkurowanie z Intelem i NV. A efekt jest taki, że jak chce się kupić profesjonalne oprogramowanie korzystające z GPU, to jego twórcy kilka lat temu wybrali prawdopodobnie Cuda. No ch**owe, ale co zrobisz. O nic mnie dotąd nie prosiłeś. Ten rynsztok, to normalna analiza, który musi wykonać stojący na ziemi szef technologii (czyli taki, co nie bierze w łapę, tylko ocenia co dla niego dobre) - odsyłam do pdfa. Panowie po prostu optymalizują, mierzą i wiedzą czy wektoryzacja i szerokie rejestry są opłacalne czy nie - dla niech. To jednak różnica niż analiza typu: "ludzie kupią bo są idiotami, i myślą, że jak więcej to lepiej, a w ogóle Intel marnuje czas na ślepą uliczkę, bo wystarczy dodać rdzenie, a nie poszerzać rejestry, a wiem to, bo kolega napisał path tracer i mu wyszło, że lepiej dodać wątek, niż użyć AVX zamiast SSE4". Chociaż zgadzam się, że dla aplikacji, której wąskim gardłem jest znajdywanie intersekcji, skok z SEE4 do AVX (i dalej) wiele nie wnosi, tyle tylko, że jeśli mowa o rendererze, to ten obok śledzenia promieni, filtruje tekstury, integruje sample, ewaluuje shadery na wirtualnej maszynie SIMD i robi parę innych rzeczy, które idealnie nadają się do wektoryzacji.

Przeczytaj instrukcje Intela. Ludzi którzy żyją z renderowania, nie interesuje porównanie z Cycles. Interesują porównania z Maxwellem, Vrayem w trybie PBR, Arnoldem, Mantrą, Rendermanem PBR, 3delightem PBR, Redshiftem. Zarówno pod względem możliwości, jak i wydajności. Rozumiem, że nie masz pojęcia o czym mówię. Jeszcze raz Ci napiszę, że "śmiegają" nic nie znaczy, śmigają dla funboyów. Dla ludzi pracujących w branży nie ma ani jednego rendera OCL, który nadaje się do pracy, jeden pod CUDA, który się nadaje i kilka zabawek, które coś próbują zrobić. Reszta to CPU. I jeszcze raz, na spokojnie. Czy OCL dorównuje CUDA jeśli chodzi o możliwość wdrożenia CAŁEGO renderera może powiedzieć ktoś, kto podjął taką próbę w obu środowiskach. A ponieważ ani Ty ani ja nie zrobiliśmy tego, musimy oprzeć się na opinii innych. Tak się składa, że jedyne profesjonalne renderery GPU obecne TERAZ na rynku, używają CUDA. Stąd moje domniemanie, że CUDA ma (lub miała 3 lata temu), coś czego OpenCL nie ma. Koniec argumentu. Lux niczego nie dowodzi, bo nie mieści się w kategorii profesjonalnych narzędzi w branży CGI. Może CI się to nie podobać, ale zarówno Cycles jak i Lux są narzędziami dla entuzjastów i freelencerów, którzy pracując na Blenderze nie mają zbyt wiele możliwości. Uśmieszek na końcu zdania nie zmienia chamskiego wydźwięku całości (i braku argumentu). Jak bardzo chcesz bana, to ja o niego dla Ciebie poproszę. Na razie proszę, żebyś się zachowywał i nie obrażał ludzi na forum.