SYmek

Pewnie jest tak, jak mówisz. Zdaje się, że HPC kilka lat temu przesiadło się na różnego rodzaju akceleratory, ponieważ wiadomo było, że z standardowe CPU osiągnęło limit możliwości a nowych technologii nie było. Rozwijając klaster na Cuda, niekoniecznie musi chodzić o wiarę w tę technologię, ale raczej o rozpoczęcie długiego procesu transformacji kodu działającego na klastrze na inne technologie. Nie chcę się wymądrzać, bo niewiele na ten temat wiem (ale wiem, czego nie wiem). Pierwszy z brzegu pdf, który fachowo tłumaczy temat - ale te wnioski stosują się tylko do HPC (nie do rendererów): https://verc.enes.org/ISENES2/documents/Talks/WS3HH/session-4-hpc-software-challenges-solutions-for-the-climate-community/markus-rampp-mic-experiences-at-mpg Pada tam ciekawe zdanie, że na marzec 2014, Cuda właściwie nie ma konkurencji jeśli chodzi o programowanie GPU (swoją drogą ciekawe, czy chodzi o stan samego OpenCL, czy o stan sterownika OpenCL Nvidii). Btw z jakiś powodów od pewnego czasu nie kupuje się procesorów AMD na klastrach - chyba chodzi o prąd, ale nie jestem pewien. Są też rzeczowe testy pokazujące, że GPU w zastosowaniach HPC daje realnie x2-x3 wzrost wydajności, czyli niewiele biorąc pod uwagę koszt rozwoju oprogramowania. Jak wspomniałem, wygląda na to, że nakład pracy w klastry na GPU to głównie inwestycja w rozwój oprogramowania, które łatwiej będzie przepisać na nowe architektury (intela i innych). DISCLAIMER: Co do kart graficznych AMD, ich możliwości etc., całego tego zamieszania, o którym tu prawicie, nie wypowiadam się, nie znam się, nie chcę się znać. Jeśli AMD robi hurtowo procesory dla producentów konsol i wymagającego Apple, to chyba nie jest tak z nimi źle? Moja wypowiedź z początku tego wątku dotyczyła wyłącznie sterowników OpenGL od AMD, które przez lata wołały o pomstę do nieba i to wiem na pewno. Niestety przy obecnym stanie OGL, pisanie sterowników jest męką i bez gigantycznego nakładu pracy, nie da się tego robić dobrze. Intel jak i AMD przez lata zaniedbywały sprawę oddając miejsce Nvidii w rynku aplikacji profesjonalnych CGI, co niekoniecznie musi mieć znaczenie dla graczy, konsol. EDIT: Co do Indigo, Lux: ich istnienie świadczy o tym, że napisanie path tracera na OpenCL jest możliwe, natomiast nie świadczy o tym, że wybór OpenCL, zamiast Cuda, było optymalne dla rozwoju tego oprogramowania. Oba są open source (indigo też zaczynało jako open source tak?), oba są z natury powolne i mówiąc najkrócej technologicznie odstają od komercyjnych aplikacji (znacznie odstają).

Pewnie nie warto rozmawiać z młodzieńcem, który bierze w tej dyskusji udział chyba tylko po to, żeby popisywać się wiedzą, a nie coś zrozumieć, albo komuś coś wytłumaczyć, ale że wątek czytają także inni... To jest pomieszanie z poplątaniem. Oczywiście, że wektoryzacja nie odbywa się bez kosztów i nie jest rozwiązaniem na wszystko, ale mądrzy ludzie robią coś, co jest możliwe w danej sytuacji (a "sytuacją" jest ograniczony dostęp do pamięci z CPU), a nie opowiadają, co byłoby najlepsze. Wektoryzacja zmniejsza nawet taktowanie procesora..., więc magic bullet to to nie jest, ale reszta argumentu to czysta demagogia... Procesorów z takimi rejestrami nie kupują ludzie, których można przekonać megapixelami, tylko ludzie, którzy stawiają klastry obliczeniowe, robią testy na zoptymalizowanym kodzie i podejmują decyzje zakupowe w oparciu o to, ile gflopów wyciągną per watt i per dolar. I do takich ludzi przemawia Intel poszerzając wektory. Zdaje się, że poszło mu to nieźle, skoro Phi jest sukcesem na rynku HPC, czyli tam, gdzie miał być. Tyle a propos studenckich teoretycznych mądrości. W zadaniach, o których tutaj mowa, czyli renderowaniu, kod zawsze się optymalizuje, nie ma więc sensu porównywać wzrostu wydajności kodu bez optymalizacji. Dlatego zresztą niewątpliwe zalety OpenCL, są dla rendererów wątpliwe. OpenCL nie jest w stanie sam z siebie wyciągnąć maksimum wydajności zarówno pod CPU jak i GPU, właśnie dlatego implementacje rendererów w Cuda są zawsze szybsze od OpenCL (o ile jest dostępne). Cuda wspiera jedną architekturę, więc może być zoptymalizowane pod jedno GPU i wyciąga z niego więcej niż kod OpenCL, który się sprytnie sam optymalizuje (aczkolwiek faktem jest, samo wyrażenie algorytmu w OpenCL, daje wzrost wydajności na CPU w porównaniu do C(++)). Wektoryzacja nie przekłada się automatycznie na znaczny wzrost wydajności w większości aplikacji, ale w generowaniu grafiki, w zoptymalizowanym kodzie, przekłada się bardzo, co najlepiej widać po 20% wzroście wydajności VRaya, kiedy włącza się w nim Embree. A przecież to jest BARDZO zoptymalizowany kod ludzi, którzy zjedli zęby na asemblerze. Tylko tylko, że żaden duży program nie zaryzykuje szerokiego wsparcia na AVX (nie mówiąc o AVX2), bo te programy pracują na starych klastrach SSE4 (albo nawet SSE2), a na ręczną optymalizację dla każdej wersji Intela mało kogo stać. No chyba, że Intel dostarczy Embree, które posiada oddzielne ścieżki dla różnych architektur, więc można się szarpnąć. Reasumując, może Cuda jest z założenia ch**wa (a jest, bo zamknięta, bo niskopoziomowa) , ale była dotąd jedyną REALNĄ alternatywą dla ludzi, którym zależało na kontrpropozycji wobec rendererów CPU. Być może Luxrender może sobie działać na OpenCL, bo z założenia jest powolnym path tracerem unbiasowym. Redshift, którego "selling point" polega własnie na tym, że oferuje A) praktycznie wszystkie ficzery VRaya B) robi to szybciej C) jest płatny i ma działać z minimum ryzyka komplikacji, takiego komfortu nie ma. Podobnie Maxwell. Inaczej trudno byłoby wytłumaczyć decyzje ludzi, którzy je stworzyli. A Redshifta zdaje się napisało 3 gości, którzy wcześniej pisali 15 lat enginy do gier. Chyba się znają na GPU.

Nie, naprawdę? O matko, dopiero zaczynam rozumieć, że rozmawiam z 20 latkiem. Średnio zaawansowany programista sobie napisze coś, co średnio ogarnięty student miłośnik AMD uzna za dowód na coś. Miłych wakacji, pozdrawiam! skk.

Rozumiem, że dodali później, choć sami piszą, że działa wolniej na OCL. Wybacz, ale to video nie jest żadnym argumentem. W ogóle, w kilku miejscach (także w innych postach), zdajesz się twierdzić że Path tracing jest prostym algorytmem i że na OpenCL od dawna "śmiga". To jest strasznie naiwne myślenie, a śmiga nic nie znaczy. Jest przepaść między implementacją programu z Twojego video a jakimkolwiek, nawet najprostszym rendererem takim jak Vray RT. Tak, path tracing to koncepcyjnie prosty algorytm, ale profesjonalny renderer to nie algorytm, który, jak wiadomo można zapisać w 100 liniach kodu C, tylko skomplikowana maszyneria, a śledzenie promieni jest tylko niewielką jej częścią. Może tak, może nie. Jakieś konkrety? Dlaczego konkretnie OCL2.0 jest lepsze od Cuda 7.5? Poza tym, że jest otwartym standardem? Jeśli ktoś optymalizuje, to oznacza, ze OCL nie potrafi kompilować równie wydajnie na CPU i GPU, co mnie zresztą nie dziwi. Nikt tego nie potrafi. I w tym cały problem. I jeszcze raz, produkcyjna implementacja path tracingu nie jest prostym algorytmem! Setki ludzi i miliony dolarów wydano na jego rozwój. Skąd wziąłeś taką opinię? Radeon Rays jest amd'owska wersja OptiX'a, więc nie ma co go porównywać do Cudy. Inżynierowie Intela najwyraźniej uważają inaczej. Głupcy. Ludzie kupujący komputery w korporacjach uważają inaczej... Także miliony użytkowników tego systemu, którzy nigdy w nic nie grali a nadal go używają do pracy. Nie są na nic skazani. Mogą używać zarówno Cuda jak i OCL.

Zdaje się, że materalia zwraca słusznie uwagę, że te warunki są spełnione. ...a na ten czekamy. Pamiętaj, że AMD robi procesory dla XBOXa, Playstation i Maców Pro... rynek 3D to jest jakaś nisza dla nich. Swoją drogą to jednak ciekawe, że w żadnym z tych przypadków sami nie piszę sterowników... :P, czyli jednak jest coś na rzeczy z ich ch*wym softem :)

No jednak się mylisz i to w takim miejscu, że gdybyś chciał zrozumieć, dlaczego się mylisz, rozmowa stałaby się bardziej na temat. Nie rozmawiamy o tym, czy OpenCL jest lepszym pomysłem niż CUDA i czy karty Nvidii są przereklamowane i przeszacowane. Rozmawiamy o tym, że skoro: a) Chaos Group wybrał Cudę dla VRayRT b) Octane też c) Maxwell też (bo właśnie wydają wersję pod Cuda) d) Arnold również ma demo na GPU pod Cudą to oznacza, że zastosowaniach związanych z renderowaniem Cuda musi mieć coś, czego nie ma OpenCL. Celowo nie wymieniam Cycles, skupiam się na komercyjnych dostawach, którzy nie mogą sobie pozwolić na marnowanie czasu i to takich z najwyżej półki. OpenCL 2.0 coś zmieni? Może, ale stan na dziś jest taki, jak widać. No to właśnie może znaczyć, że coś się zmienia. Ma znaczenie jak renderujesz na renderfarmie. . Dopóki nie możesz napisać w pełni działającego algorytmu w jego formie state-of-the-art na dzisiaj, to praktycznie nie ma. OpenCL 2.0? Będzie się dało? Nadal wątpię, żeby TEN sam kod renderera działał równie dobrze pod CPU jak i GPU. Będzie się dało co najwyżej to, co w Cuda, czyli napisać kod po GPU i oddzielny pod CPU. Dlatego twierdzę, że heterogeniczność OpenCL może nie mieć takiego znaczenia dla developerów rendererów. Znaczenie może mieć zgodność z kartami AMD i Intela. W Polsce chyba? Na świecie w tej branży jest standardem. Od 10 lat widuję Windowsa, jak muszę coś zmontować (czyli raz na 4 lata). Pisząc najpopularniejszy miałem na myśli wszystkie procesory świata.. nie tylko te od 3D :) Tu się zgodzę. Gdybym nie musiał, trzymałbym się z dala od całej awanturki. Intel z szerokimi rejestrami (floatx512) i po sprawie :)

Akurat Linux jest najpopularniejszym systemem operacyjnym na ziemi... od wielu, wielu lat. Swoją drogą renderery niekoniecznie muszą być wyznacznikiem uniwersalnej przydatności jakiejś technologii, ale w przypadku desktop / high performance / graphics, Cuda rules.

Arnold GPU również tylko CUDA for now. ps heterogeniczność OpenCL nie ma dla rendererów wielkiego znaczenia, ponieważ przy obecnym stanie technologii kod i tak trzeba optymalizować pod konkretną platformę dla maksimum wydajności. Podstawowa wada Cudy, staje się jej zaletą. Jeden dostawca sprzętu, oprogramowania i sterowników...

Jeśli to prawda, byłaby to bardzo dobra wiadomość, ale od niedawna. Faktem jest, że wielu poważnych graczy po prostu czeka na OpenCL, żeby zacząć poważnie rozważać programowanie na GPU. Skąd masz takie dane? Na marginesie warto zauważyć, że odbiory tych technologii mogę się od siebie nieco różnić. Czym innym jest pisanie desktopowej/interaktywnej aplikacji dla jednej branży, a czym innym pisanie kodu, który ma działać na klastrze i mieć szerokie zastosowanie w przemyśle. Gdybym pisał plugin do Maxa, a Cuda dawała mi 40% większą wydajność albo ważną funkcjonalność, nie wahałbym się specjalnie. Ale akceleracja nodów w aplikacji a'la Nuke... wolałbym OpenCL. Albo, mając takie zasoby jak jego producent, po prostu napisałbym własny język, który kompiluje się zarówno na CPU jak i GPU. Wiesz dlaczego Blink nie działa po prostu na OpenCL? Właśnie dlatego, że 5 lat temu, kiedy startowały takie projekty, i kiedy programiści podejmowali decyzje a propos GPGPU, OCL było jeszcze w lesie...

Ze swojej strony powiem, że według mnie rozmowa nie dotyczyła jakości implementacji OpenCL przez AMD, tylko stanu standardu OpenCL w ogóle, w tym jego wszystkich implementacji - w szczególności kilka lat temu. Moja teza jest taka, że rozwijał się zbyt wolno, żeby dorównać praktycznej (nie papierowej!) funkcjonalności CUDA. Nie muszę tego dowodzić, dowodzi tego rynek, który w większości rozwiązań end-userskich opera się na CUDA. Dlaczego end-userskich? Bo tam nie możesz kontrolować środowiska wykonania. Ma działać i już. OpenCL okazał się pieśnią przyszłości. To nie jest wina AMD czy Kronos. To raczej normalna konsekwencja tego, że OpenCL był tworzony przez znaczenie szersze grono zainteresowanych, z założenia na heterogeniczne środowisko, a to po prostu jest trudniejsze i zajęło znacznie więcej czasu. Jak to ma się do sterowników AMD, czy są lepsze czy gorsze od sterowników innych dostawców sprzętu (w tym Intela), nie wiem, nie interesuje mnie to. Wiem, że CUDA dawała już dawno większe szanse powodzenia projektu, więc ludzie (w pewnych zastosowaniach w każdym razie) zagłosowali nogami. Jak to ma się ma do idea open source, to nie moja sprawa. Bliżej idei. Dobrze powiedziane. Ale bliżej rzeczywistości codziennego programowania była Nvidia. Tak, teoretycznie OpenCL jest lepsze dla renderfarm, w praktyce nadal najlepsze jest x86_64. Kropka. Cuda nie nadaje się na renderfarmy, dlatego mało kto pisze oprogramowanie, które ma z założenia działać na farmie w Cuda. Cuda osiągnęła względny sukces (w porównaniu do OCL), tylko w zastosowaniach end-userskich. Jest ponoć jakiś rynek HPC na Cuda, ale o ile mam wierzyć temu, co słyszałem od ludzi budujących te klastry faktyczna użyteczność klastrów Cuda jest znacznie mniejsza, niż oczekiwana. Jeśli sprzeczność jest jawna, to jest jawna, czyli zamierzona. Przykro mi, że moja subtelna ironia umknęła ostrzu Twej inteligencji. Nie rozmawiajmy o ideach, tylko o faktach, a fakty są takie, że poza wąskim kontekstem HPC, to kompilator decyduje o tym, jakie konkretnie mikro-instrukcje wykona procesor, i to kompilator powinien wspierać architekturę i jej specyfikę. Już dzisiaj można pisać w prostych przypadkach kod C++, który wykona się na x86/Cuda/OpenCl. I to jest przyszłość.

Gelato nie było na CUDA i nie przyjął(o) się, bo był poronionym pomysłem nastawionym raczej na eksplorację nowych terenów, niż faktyczne korzyści. Gelato tylko shading robiło na karcie, raszta była na CPU, właśnie wchodził ray tracing do użycie powszechnego, więc największy koszt i tak miało wysyłanie promieni. Ani dla zwykłych ludzi, albo dla studiów, naprawdę nie wiadomo dla kogo był ten renderer (może dla Larrego Gritza, który właśnie stracił swoje dziecko (Entropy) o chciał szybko napisać coś nowego za pieniądze korpo).. To jest właśnie generalizacja, o której sam pisałeś...

To zdanie nie ma niestety uchwytnego sensu. Path tracing działa bardzo ładnie nawet w Pythonie, jak sobie ktoś go napisze, ale w pełni funkcjonalny renderer niestety wciąż łatwiej napisać na CUDA. I zdaje się właśnie dlatego Cycles wybrał CUDA - kilka lat temu ta różnica była znacznie większa. Podobnie zresztą jak Redshift, Vray i inne profesjonalne narzędzia (akcelerowane kodeki, korekcje koloru, zestawy montażowe etc etc). Myślę, że dla nikogo nie było to dobre rozwiązanie, ale ludzie, którym zależało na funkcjonalności i wsparciu technicznym nie mieli wyjścia, szczególnie kilka lat temu. OCL 1.2 może coś zmieni, o ile doczeka się implementacji wszystkich graczy. Model programowania CUDA jest przestarzały? Co masz na myśli? Co roku się zmienia do tego stopnia, że właściwie można już dzisiaj pisać w czystym C++. Niestety obecne implementacje OCL ( Znów jakaś logiczna zagadka. W niektórych zastosowaniach działa, w innych nie działa. Windows, Linux, OSX wszystkie mają mocne i słabe strony, które zależą zwykle do tego, w co włożyli pracę ich główni architekci. W pewnych zastosowaniach Linux nie ma sobie równych, w innych nie nadaje się do użytku. Jak to w życiu. ps Nvida otworzyła źródła kompilatora CUDA, więc nie jest to już zamknięty standard (właściwe nie otworzyła, ale dała możliwość rozwijania wsparcia dla własnej platformy sprzętowej).

To nie hejt, tylko obserwacja, że AMD straciło rynek aplikacji profesjonalnych z powodu słabych sterowników, a nie jakości procesorów.

Jedyna strategia, jaką AMD potrzebuje to tych ~80 programistów, którzy nieustannie łatają sterowniki Nvidii, sprawiając że karty częstokroć gorsze wyparły z rynku pro sprzęt AMD. Co mi po krzemie, którego żaden program, może poza Catią, nie potrafi użyć.

https://distrowatch.com/dwres.php?resource=major Wybierz którąś z popularnych dystrybucji. Zasadniczą pytanie dla użytkownika domowego nie jest wybór dystrybucji, ale "Gnome or not to gnome?" :) skk. ps Yo! Kroopson!

Maya 1 nie miała :)

Cryptomatte nie działa na depth mapie i banalne nie jest, choć rocket science też nie. Przy renderowaniu scen z dużą ilością obiektów BARDZO ułatwia pracę oświetlaczy i kompozycji.

Łatwo jak łatwo. Niestety, jakie materiały będą wykorzystane w scenie wie dopiero naprawdę SOHO, i customizacja SOHO to byłaby prawdopodobnie najlepsza metoda (można zarówno znaleźć wszystkie eksporty jak i dodawać plane'y). Houdini jest po prostu zbyt skomplikowany... na przykład materiału, który będziesz renderował w ogóle może nie być w scenie (delayed load albo packed prims). Przejrzeć materiały, które są w /shop jest łatwo, dodać plane'y też, ale które z tych materiałów będą użyte trywialne już nie jest, bo jest za wiele metod ich aplikacji. Załączam małą ilustrację. Powinno działać z materiałami object level i primitive level, ale skrypt już musi iterować po wszystkich prymitywach w scenie... słabo, a jeszcze materiały per punkt, i na packed prims... chyba że się założy, że parsujemy parametry MaterialSOP tylko, będzie szybko, ale nie zadziała dla obiektów na dysk (które mają atrybuty już na sobie)... czyli soho, albo filtr IFD rop = hou.node("/obj/out").selectedChildren()[0] candidates_obj = [obj for obj in hou.node("/obj/").recursiveGlob(rop.parm("vobjects").eval(), \ filter=hou.nodeTypeFilter.Obj) if obj.isObjectDisplayed()] # to samo dla force object.... candidates_sops = [obj.renderNode() for obj in candidates_obj] prim_materials = [attrib for attrib in sop.geometry().primAttribs() \ for sop in candidates_sops if attrib.name() == 'shop_materialpath'] prim_materials = list(set([prim.attribValue(attrib) for prim in \ attrib.geometry().prims() for attrib in prim_materials])) obj_materials = [hou.node(obj.parm("shop_materialpath").eval()) for obj in candidates_obj] materials = list(set(prim_materials + obj_materials)) # Teraz pętla dla materiałów: idx = rop.parm("vm_numaux").eval() rop.parm("vm_numaux").set(rop.parm("vm_numaux").eval() + len(materials)) for mat in materials: variable_name = 'vm_variable_plane' + str(materials.index(mat) + idx) channel_name = 'vm_channel_plane' + str(materials.index(mat) + idx) export_name = [parm.eval() for parm in mat.parms() \ if parm.name().startswith("MASK_")] # Zakładam, że export nazywa się jak pewien parameter. whatever. rop.parm(variable_name).set(export_name) rop.parm(channel_name).set(export_name) # itd

Się porobiło... przez lata nikt sobie matte'ami głowy nie zawracał, ale teraz to jest gorący temat :) Nie ma dobrego sposobu na masowe produkowanie masek... Niby wszystko proste a w praktyce zawsze coś... Oczywiście możesz sobie na wiele sposobów ułatwić sprawę, poskryptować, ale naprawdę dobre rozwiązania są dopiero w drodze, jako że zrobiła się ostatnio moda na auto-matte'y różnych maści. Sam mam swój projekt, PsyOp opublikował właśnie swoją metodą, Dreamworks ma swoją i jeszcze kilku innych. Generalnie wszystkie te patenty sprowadzają się do tego, żeby nie spłaszczać w pixelfiltrze sampli opacity, tylko przenieść je rozdzielone do kompozytora i w ten sposób umożliwić generowanie masek on-demad :). Chyba stary dobry rpf(?) tak robił, kto by pomyślał, że MAX był taki postępowy... no, ale to przyszłość. Shader nie może dodawać plane'ów, może tylko eksportować zmienne, a i tak te muszą być zdefiniowane w parametrach funkcji shadera, co wybitnie utrudnia skryptowanie eksportów, muszą tam być od początku expressis verbis. Można by się pobawać macrami w VEX, tak jak jest to zrobione w eksportach w illuminance loop per światło, ale nie próbowałem tego choćby dlatego, że trzeba by podmienić wbudowane VOPy, albo edytować voplib.h, co jest mało production friendly... można to chyba ogarnąć łatwiej. Najprostsza metoda to zrobić sktypt, który przejrzy wszystkie shadery na obiektach i stworzy plane'y dla eksportów, ale jak sam zauważyłeś, jest to mało inteligentne. Nieco bardziej zaawansowana metoda polega na filtrowaniu IFD'ka Pythonem. Nie możesz wprawdzie dodawać image plane'ów, ale możesz je stworzyć wcześniej w dużej ilości i wyłączyć. Potem robisz callback w Pythonie, który kolekcjonuje shadery. Callback zwraca Ci shader string, czyli nazwę shadera ze wszystkimi parametrami, które nie mają wartości domyślnych. Czyli masz shader bunny_mat i na nim parametr mask=1 (a domyślnie 0), więc callback zwróci Ci /shop/bunny_mat diff 0.6 0.3 0.1 mask 1. Mając te informacje, możesz włączyć jeden plane i ustawić mu potrzebne dane. Jeśli renderujesz własnym skryptem (polecam), możesz edytować scenę w trakcie generowania IFD tak, że grafik nigdy nie zobaczy tego bajzlu, który generujesz :). Czyli: 1) dodajesz plane'y do Mantra ROP przed generowaniem IFD 2) filtrujesz IFD Pythonem czytając z shaderów szczegóły potrzebne dla masek. W takim przypadku w ogóle nie musisz ustawiać nic na geometrii czy materiałach, ponieważ callback w trakcie filtrowania IFD może to zrobić za Ciebie, musisz tylko mieć odpowiedni eksport na shaderach (i plane'y dodane "na zapas"). Jest pewnie kilka innych metod. W naszym pipelinie nawet kompozytor mając listę materiałów lub obiektów, może spod Nuke'a sam puścić render potrzebnej maski (bo mając beaty pass wie, z jakiego ifd powstało, i może użyć go jeszcze raz z odpowiednim python filtrem), ale ta technika się nie przyjęła :) Jak mówiłem, wszytko to jest nieco męczące. Mam nadzieję, że za chwilę ustali się jakiś standardowy format dla auto-mattów i będziemy mieli selekcje obiektów i materiałów w kompozycji w standardzie.

A wiesz, że teraz to nie wiem :). To się zmienia. Mieliśmy kiedyś własny shader rozwijany w kodzie. Potem własny Vop jak podstawa, z którego robiło się shader. Teraz zdaje się jedziemy na standardzie, który w miarę potrzeb jest modyfikowany (plus swoje Vopy) i zapisywany do HDA dla każdego obiektu. U nas lead robi materiały, ludzie świecą i renderują. Jak trzeba coś zmienić, albo proszą leada, albo sami robią swój materiał. Principled shader chyba najmniej..., ale Mantra renderuje 99.9% naszych klatek niezmiennie od 8 lat :)

Hej, nie chciałem Cię zniechęcać, tylko zaznaczyć nadchodzące kłopoty :). Wiem, że to może być wygodne! Po to właśnie dodali MMB na Vopach, które mogą dodawać tekstry, noisy etc (menu jest edytowalne i możesz dodawać własne rzeczy). Także shelfy działają w ten sposób, ale też pokazują ograniczenia techniki. Kilka uwag: - zdaje się, że obowiązujący paradygmat (który oczywiście możesz mieć głęboko) jest taki, że nadmiar parametrów się ukrywa. Po to dodali niedawno warunek hidden when dla parametrów. - kłopot zaczyna się przy wielokrotnym użyciu parametru, bo jak raz ustawisz noise, potem texture a potem znów noise, to drugi noise musi działać nieco inaczej, co dla programowania jest niedobre etc. Nic, czego nie da się ogarnąć, tylko kod się komplikuje. Trochę jak w przypadku shelfa, 4 pierwsze kliknięcia działają, potem już nie :). Usuwanie starych rzeczy, kontrolowanie, co do czego jest obecnie podpięte... - rozważyłbym zrobienie własnego noda, która ma w sobie zaszyte elementy i logikę i który sam może się poszerzać (dodawać warstwy), masz wtedy kontrolę nad tym, co dzieje się w środku. A na zewnątrz tylko vector. To są luźne myśli w oparciu o własne doświadczenia. Swoją drogą może jest to teraz przyjemniejsze, bo HOM dla Vopów jest nieco lepszy (dodali setNamedInput(), kiedyś trzeba było szukać inputów po indeksach). Powodzenia! skk.

Hej, sorry za późną odpowiedź. Nie wiem, czy już uporałeś się, ale technicznie jest to oczywiście możliwe, chociaż nie wiem, na ile ma to sens. Mam wrażenie, że to, o co pytasz się wybitnie niepraktyczne dla większych shaderów. Taka funkcjonalność jest na poziomie VOPów pod MMB na inputach btw. Jak stworzysz dowolny materiał w SHOPie, możesz dodać do jego parametrów na przykład OrderedMenu. Potem ustawiasz dla niego callback script. Komplikacją jest, że dopóki Twój materiał nie jest zapisany w HDA, tego skryptu nie zapiszesz na nodzie, ale przypuszczam, że shader i tak będziesz chciał zapisać w HDA. Callback może zrobić wszystko co chcesz, dodawać tekstury etc, tyle tylko, że im bardziej skomplikowany setup, tym trudniej będzie to ogarnąć skryptem... Załączam przykład. Callback jest zapisany w hou.session, więc razem z hipem. Materiał nie jest w hda. pozdrawiam, skk. ps Ordered menu jest obok parametru diffuse na /shop/vopmaterial1 shop_menus_example.hip.zip

Musisz mieć minimalny dystans między cząsteczkami (pscale*2) i zaaplikować jego połowę, jako rozmiar największej z osi bounding boxa dla obiektów. Nie jest to jednak idealne rozwiązanie. Najlepiej jest po prostu symulować prawdzie obiekty w DOPach - razem z kolizjami. Bullet powinien sobie radzić z tysiącami obiektów. Po co POPy?

Cały pipeline Delayed Load odchodzi powoli do lamusa ponieważ packed primitives są bardziej uniwersalnym konceptem, ale rzeczywiście od czasu do czasu trzeba się do tego wrócić. Rozwiązaniem nieco bardziej zaawansowanym jest własny skrypt hrender, który wykonuje opisane przez Ciebie kroki w trakcie eksportu IFD na farmie w sposób niewidoczny dla użytkownika - czyli na kopii sceny wysłanej do renderowania. Tak mniej więcej działało to przed wersją 8.0, gdzie deleyed load działał automatycznie.

Możesz, o ile nie stosujesz jej do pracy, w szczególności, o ile dobrze pamiętam, licencja mówi wprost, że nie powinieneś instalować Apprentice ma komputerze, na którym używasz komercyjnej wersji Houdniego. W ogóle w studio, w którym jest komercyjny Houdini nie powinno być Apprentice (do tzw. testów czy nauki). Natomiast nie dotyczy to innych programów komercyjnych. Nie tylko wolno mieć Apprentice na komputerze z Mayą, ale nawet należy, żeby od czasu do czasu sprawdzać, w jak głębokiej d* jesteś nadal używając Mayę :) !