Jump to content
n-pigeon

Blender - NEWS oraz dyskusje

Recommended Posts

Obejrzałem dokładnie jego ostatnie filmiki wygląda to spoko ale tam jest jeden ogromny błąd designowy. Da się referencować Obiekt/Krzywą/Teksture tylko poprzez wybranie ich z menusa nody. To jest problem dlatego że gdy będziemy robić nodegrupę ogólnego użytku to nie będzie się jej dało tak po prostu wykorzystać w innych projektach (tak jak np shadery Cyclesa), a nawet na innych zestawach obiektów w scenie. Wszystko będzie na sztywno zespolone z plikiem + sceną + jednym zestawem konkretnych obiektów.

Po załadowaniu takiej nodegrupy do innego pliku trzeba by ją rozbebeszyć i szukać które nody wykorzystują obiekty. Przy kilku subgrupach, gdzie każda ma kilkadziesiąt nodów w środku, to będzie albo cholernie uciążliwe albo po prostu niemożliwe do zrobienia bez dokładnej instrukcji gdzie co jest schowane. Fatalny błąd który może skutecznie udupić praktyczne zastosowanie tego projektu.

 

To powinno działać tak że jest noda do referencowania Obiektu i ma output typu Object. Nody które wykorzystują dane z obiektów mają wtedy input Object zamiast menu. Dzięki temu informacja o obiektach może swobodnie przechodzić przez sieć nodów co umożliwia tworzenie zaawansowanych node group które które korzystają z dowolnych obiektów.

 

Na przykładzie Cyclesa dla jasności. Nie da się zrobić w Cyclesie nodegrupy która korzysta z wymiennych tekstur. W ImageNode da się ustawić konkretną texe i zamykając to w grupę zapisujemy tą texe na sztywno w tej grupie. W wielu wypadkach zadziała zwykłe podpięcie obrazka do grupy ale problem pojawia się jak chcesz jednocześnie modyfikować wektory mapowania tekstur i je ze sobą miksować (czyli podstawy!). Żeby to wykonać na obecnym systemie musisz zrobić 2 grupy i pomiędzy nie powsadzać ImageNody.

W większości rendererów czy silnikach gier ten problem nie istnieje bo zamiast umieszczania na sztywno obrazka w sieci nodów umieszcza się SLOT na ten obrazek, nazywany zazwyczaj TextureSamplerem. Dzięki temu w gotowych materiałach możesz wymieniać texy nawet bez odpalania widoku nodów (tak działa to w Unrealu).

Cyclesowa ImageNoda to złożone narzędzie, ma wiele rzeczy już wbudowanych. Jest fajna bo pozwala na szybie wrzucenie texy na obiekt. Problem w tym to hi-level'owe narzędzie które nie do wszystkiego się nadaje. Nie mamy natomiast dostępu do narzędzia podstawowego dzięki któremu bardziej techniczni userzy mogliby zrobić co dusza zapragnie.

 

kti2NOM.png

Z lewej wyżej opisana kombinacja, na przykładzie powszechnego efektu Tri-Planar Mapping. Zwróć uwagę że 3 razy wywołuje tą samą teksturę, nie da się inaczej. Z prawej jak to powinno wyglądać.

 

 

Planowałem pisać w sprawie tego TextureSamplera do Cyclesa ale widzę że to jest ogólnie problem z koncepcją systemów nodowych w blendku. W cyclesie to raczej uciążliwa pierdólka. Niestety w przypadku ObjectNodes to może być coś co zniweczy ten projekt. Kto będzie chciał robić złożone narzędzia które zadziałają tylko jeden raz?

Pocisnę maila na listę w weekend.

Edited by Monio

Share this post


Link to post
Share on other sites

A nie wystarczy napisać prostego skryptu do podmiany obiektów wybranych w menusach?

Nie widze tez problemu zeby taki node dopisać.

Share this post


Link to post
Share on other sites

Nie wystarczy. Żeby to działało to musi opierać się na dynamicznym kontekście, dodatkowo każda node grupa będzie miała swoją własną konstrukcje więc skrypt musiałby mieć własną logikę. Tak na prawdę dla każdej nodegrupy trzeba by było pisać oddzielny addon... To by było abstrakcyjnie upierdliwe i odbiłoby większość potencjalnych userów. I tak nody z innych plików nie mogłyby działać bo nie da się ich modyfikować.

Co do dopisania custom nody to nie ma szans. Jeśli system nie wspiera socketów konkretnego typu danych (tutaj referencja obiektu) to da się tych danych nigdzie przekazać. Tak jakbyś próbował odpalić plik audio przeglądarką obrazów.

 

Lukas odpisał mi na

.

+Monio4 I'm aware of this issue. The internal "bvm" system underlying these nodes is designed to treat such object references like any other datatype socket. The only problem wrt. node groups and similar nested node graphs (object components) is the custom-property system and the UI side: how to store pointers in sockets, per node group instance, and them use them internally. Node will also need to distinguish constants and variables, so that valid connections become more transparent.

Czyli to co jest teraz to rozwiązanie tymczasowe, system wewnątrz wspiera przekazywanie referencji obiektów. Mogę spać spokojnie. ;)

Share this post


Link to post
Share on other sites

Ciekawa, techniczna dyskusja między Brechtem i Dietrechem https://developer.blender.org/D1721 przy okazji wprowadzenia OpenVDB Smoke Cache do mastera. Najbardziej z pomysłu wdrożenia OpenVDB przez Dietricha interesowała mnie część poświęcona particle mesher'owi (https://developer.blender.org/D1008), ale projekt utknął w miejscu:

"Closing this, as talked with Campbell months ago, the approach used by this patch does not fit with the current modifier system."

Share this post


Link to post
Share on other sites

Tamta integracja OVDB nie była zbyt dobrze poprowadzona, nie byłoby z niej nic poza tym jednym modyfikatorem. Coś w stylu: wypluj dane z blendera > policz wybranymi funkcjami z biblioteki > wyciągnij nowe dane. Nie tak to powinno działać. Dietrech teraz pracuje nad bardziej elastyczną integracja która zaowocuje casheowaniem, remesherem, lepszym renderowaniem i tak dalej. Integracja a nie traktowanie OVDB jak zewnętrzy plugin. Trzeba poczekać co tam Lukas i reszta wymyślą ze zunifikowanym systemem nodowym (Object Nodes), to bedzie miało duży wpływ na to jak będzie się pracowało z meshowaniem za pomocą OVDB.

 

http://wiki.blender.org/index.php/Dev:Ref/Release_Notes/2.77/More_Features

Jak na razie cały czas są prowadzone prace nad desphgraphemi powoli zaczyna je być widać. Przez kilka następnych wydań będziemy torpedowani zajebistymi speedupami poszczególnych funkcji blendera. Nowy desphgraph jest też potrzebny do zrealizowania wyżej wymienionego ObjectNodes. Krótko mówiąc bebechy blendka zamieniają się w super solidną architekturę która za parę lat zrobi z tego programu soft tak elastyczny jak majka czy hudy. :)

Share this post


Link to post
Share on other sites

@Monio, no właśnie dziwi mnie, że gość który wziął się za integrację blendera z bądź*co bądź skomplikowaną biblioteką jaką jest OpenVDB, dopiero odkrył to po roku pracy nad patchem :p

Share this post


Link to post
Share on other sites
Super dodatek, bardzo przydatny podczas modelowania.

 

 

A gdzie go znaleźć?

Share this post


Link to post
Share on other sites

Meh. To nieoficjalny custom branch zrobiony na hakach. Shadery kompilują się jakoś tak 100 razy za wolno. Na bank nigdy nie wejdzie do mastera.

Share this post


Link to post
Share on other sites

Tak? Myslalem ze to oficjalne. W takim razie spoko bo jak rozumiem po oficjalnym powinienem sie spodziewac czegos lepszego? ;)

Share this post


Link to post
Share on other sites

Cześć wszystkim.

Ten addon Perfect Shape tak trochę od czapy napisałem i wrzuciłem, nie sądziłem, że będzie takie zainteresowanie i się rozniesie po sieci :) Aktualnie jestem w trakcie przepisywania i wprowadzania nieco bardziej zaawansowanego "shapera". Póki co to wersja mocno testowa. Pozdrawiam.

Share this post


Link to post
Share on other sites

To na pewno. System shaderów będzie wzorowany na papierach Disneya i rozwiązaniach EPICa.

Share this post


Link to post
Share on other sites

Taka ciekawostka... Pewnie patrząc na to "od kuchni" nie ma w tym nic zaskakującego, ale dla mnie to dość niespodziewane zachowanie.

 

attachment.php?attachmentid=100969&d=1453284748

 

Jakby się zastanowić, że wynik nie musi być zależny liniowo od parametru Roughness, to nie ma w tym nic dziwnego, ale nawet jak oba shadery z lewej będą miały parametr Roughness 0.5, to i tak render wyjdzie nieco inny niż gdybyśmy wykorzystali tylko jeden shader Glass z Roughness 0.5.

Share this post


Link to post
Share on other sites

To jest jedyne prawidłowe działanie. Mieszasz ze sobą 2 oddzielone instrukcje shadera a nie inputy jednego uber-shadera. To tak jakbyś na siebie nałożył 2 inne rendery (z innymi parametrami) a nie miksował 2 tekstury i zrobił jeden render. Jakby to działało jak w pierwszym przypadku to nie dałoby się tworzyć poprawnych fizycznie materiałów.

Share this post


Link to post
Share on other sites

roughtness opisuje jak bardzo przypadkowe są tory promieni przechodzących przez glass.

Jak pomieszasz roughtness=0 po połowie z roughtness=1, to połowa promieni przejdzie "prosto" (równolegle do siebie), a połowa będzie bardzo przypadkowa.

 

jak jest jeden glass roughtness=0.5 to wszystkie promienie są przypadkowe, tylko mniej przypadkowe, niż jak by było r.=1.

 

jeśli pomyślisz o tym w ten sposób, to nie ma zaskoczenia.

Share this post


Link to post
Share on other sites

Tak myślałem, że Wy będziecie wiedzieli o co chodzi ;) Moja konkluzja jest taka, że coś co pozornie wydawało mi się bez sensu (czyli miksowanie dwóch takich samych shaderów) jest nie dość, że sensowne, to jeszcze przynosi doskonałe rezultaty. Wcześniej myślałem, że dwa te same shadery zmiksowane z różnymi parametrami, można zastąpić jednym. Myślę, że nie jestem odosobnionym przypadkiem, dlatego się tym dzielę.

 

Dzięki Ikkiz za obrazowe tłumaczenie, zdecydowanie przemówiło mi do wyobraźni.

Share this post


Link to post
Share on other sites

No i zajebiście. Już chyba 4 soft który będzie miał cyclesa. :)

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

×
×
  • Create New...

Important Information

We are using cookies. Read about our Privacy Policy