coLorfooL - fun with nodes - oder: Abenteuer im D|S Shader Mixer

Nun also doch ein Kapitel aus maXe's Universal-Handbuch 'Wie beschäftige ich die CPU meines Rechners während des Rendervorgangs zuverlässig? - oder: Mööönsch, dat' Pixel muss doch dout zu kriegen sein!". Wollte ich eigentlich schon länger machen, hatte allerdings angenommen, dass es wahrscheinlich ohnehin niemanden interessiert. (Sollte meine Einstellung in dieser Hinsicht wohl grundsätzlich überdenken ... oder vielleicht auch einfach nur mal mit meinem Therapeuten bequatschen ...) Gibt hier zwar auch bereits andere Shader-Mixer-Threads, aber ich gehe an so etwas generell 'etwas anders' heran und aaaußerdem ... 'will ich meinen eigenen ... mööönsch!'

*****
Am Anfang steht eine Idee ... nicht selten auch eine 'fixe' ... und der schlichte Umstand, dass sie sooo jetzt zunächst nicht wirklich umsetzbar scheint, hat bei mir gewöhnlich mitnichten zur Folge, dass ich diese verwerfe. Im Gegentum! Meine fixe Idee waren: Gradients (Farb-Verlaufs-Fähigkeit) in DAZ|Studio Shadern. Wird gewöhnlich ja über Texturmaps bewerkstelligt. Ich wollte eine Textur-freie, procedurale und generell etwas flexiblere Möglichkeit. (Könnte jetzt auch noch über das Warum? und Wieso? und die Frage, warum eine einzelne Farbe pro Kanal desöfteren nicht wirklich der Reißer ist, schwafeln, aber das schenke ich mir an dieser Stelle ...) Habe so etwas nirgendwo in den Weiten des WWW auftreiben können und deshalb begann dieses Abenteuer ...

Ich weiß zwar, dass gern propagiert wird, man solle sich zunächst mit den 'Basics' befassen, um die Grundlagen zu erlernen. Ist soweit eeeigentlich auch richtig, aber ich finde es bei so einer Herangehensweise persönlich immer uuunheimlich schwer, die Motivation zu finden. Ganz abgesehen vom 'Sinn dahinter'. Was soll ich bspw. mit einem 'reproduzierten D|S Default Shader', wenn das Original einen hervorragenden Job macht und die SM-Version nicht nur 'funktional eingeschränkter', sondern auch aus Performance-technischer Sicht die schlechtere Wahl wäre? Die 'Basics' kann man auch bei(m Versuch) der Umsetzung einer 'fixen Idee' lernen.

Allerdings sind ein paar wirkliche Grundlagen für einen halbwegs geschmeidigen Umgang mit dem Shader-Mixer tatsächlich Voraussetzung.
Auf jeden Fall muss ein Grundwissen darüber vorhanden sein, wofür einzelne Shader-Kanäle (Diffuse, Ambient, Specular, etc.) überhaupt und ganz allgemein verantwortlich sind. Ebenso werde ich hier erstmal sooo direkt nicht auf den grundlegenden Umgang mit dem Shader-Mixer-Tab eingehen. Dafür möchte ich auf die SM-bezogenen Tutorials auf shadowmap.de verweisen, die einem Einsteiger sehr schön zeigen, wie die Arbeitsfläche grundsätzlich gehändelt werden kann. Und neben ersten Erfolgserlebnissen ist das Ergebnis zudem ja auch ein funktionierendes 'Produkt' (Shader, Camera), das bereits praktisch und/oder als 'Ausgangsbasis' für weitere Experimente genutzt werden kann.

... und dann möchte ich auch noch ein bisschen 'Bettlektüre' wärmstens ans Herz legen:
zum einen das Shader Mixer Tutorial von Zigraphix auf DAZ3D (aktuell und schon seit Längerem 'für lau' - ob es so bleibt, wenn jetzt hunderte, begeisterte Leser dorthin stürmen, kann ich allerdings nicht sagen) und eine Shader Mixer Brick Reference (ebenfalls von Zigraphix), die ich allerdings lediglich als PDF Suchmaschinen-seitig im Netz gefunden habe. (Hoffe, es ist okay, wenn ich deshalb hier den direkt-Link poste.) Beide Sachen sind zwar auf DS3 gestrickt, aber ansonsten nach wie vor aktuell, wenngleich auch nicht mehr auf dem neuesten Stand. Ersteres zeigt das verfügbar-machen Textur-fähiger und Tile-barer Shader-Kanäle, sowie die Standard- Bump/ Displacement/ NormalMap -Sektion zum 'Abgucken'. Zweiteres erklärt die meisten Bricks im Einzelnen und gibt allgemeine Informationen darüber, was wo angepinnt werden kann.

Tjoa ... und dann wären da natürlich auch noch die DS3 Shader Mixer Reference im DAZ Documentation Center, das Shader Mixer Kapitel im DAZ|Studio3 Manual und vereinzelt Threads hier im Forum (so weit ich sie gerade auf dem Schirm habe), die sich z.T. und im weitesten Sinne mit Aspekten dieser Thematik befassen: Shader Mixer | Ein paar Hintergrund-Fotos | Indirektes Licht - so gehts | Shader-Nodes: Wohin mit der Translucency?

Und noch ein paar Hinweise:
DAZ|Studio bringt von Hause aus ein paar Shader-Presets und Demo-Szenen mit. Diese zu 'studieren', ist u.U. überaus erleuchtend, insbesondere, weil sie häufig auf eine einzelne Sache beschränkt sind. Komplexere Shader-Networks, die gelegentlich mal im Netz zu finden sind, erschlagen häufig allein durch ihre Komplexität. Dennoch der Tipp: wenn dir so etwas über den Weg läuft: immer 'einsammeln'! (... denn sie sind sehr rar gesät.)

Ahso ... und weil's mir in diesem Zusammenhang gerade siedend-heiß einfällt:
der Shader-Mixer nutzt beim Laden und Speichern über das integrierte File-Menü eigene Datei-Erweiterungen.
.dbm > Surface Shader (Materialien)
.dbc > Camera Shader (Cameras)
.dbl > Licht Shader (Lichter)
(Hatte mal ein paar .dbm-Dateien im Netz ausgegraben und lange Zeit keinen Schimmer, wohin damit ...)

*****
Und bitte nicht vergessen:
ich beschäftige auch erst seit ein paar Wochen damit und habe die Weisheit wahrlich nicht mit Löffeln gefressen. Bin mir häufig selbst nicht sicher, 'ob das so jetzt korrekt ist', aber mache es eben nach bestem Kenntnisstand und Bauchgefühl. Und so lange es das gewünschte Ergebnis zur Folge und D|S' #3Delight nichts zu Meckern hat, ist das für mich erstmal auch okay. Allerdings bin ich jederzeit für Verbesserungsvorschläge und Tipps mehr als zu haben!

Und bevor die Frage aufkommt: warum nicht IRAY?
Erstens: bin ich ein Opportunist ... zweitens: PBR-Engines bringen i.d.R. bereits 'von Hause aus' die meisten Sachen mit, die ich derzeit so zu verbrechen in der Lage bin; drittens: wird's in absehbarer Zeit sicherlich noch viel Zeug dafür geben ... macht imho (noch) keinen Sinn, sich jetzt an Dingen die Zähne auszubeißen, die 'auch so' zu bekommen sind oder sein werden. Bei #3Delight wird sich das sicherlich anders verhalten und nur noch wenig-bis-kein neues Zeug mehr hinzu kommen. Und viertens ... auch hier gilt: möglichst nicht Äpfel mit Birnen vermischen, denn selbst wenn beide Bereiche im Shader-Mixer unter einer Oberfläche 'vereint' sind, bleiben es zwei völlig unterschiedliche Dinge. Und niemand, der ganz bei Sinnen ist, will einen 'Zwei-Fronten-Krieg' ...

*****
Soweit zum 'Vorwort' (und als kleinen vorab-Erguss für Diejenigen, die es nicht abwarten können, meine 'Memoiren' zu lesen ). Im Anhang noch ein paar visuelle Eindrücke, die inetwa zeigen, um welcher Art Dinge es sich hier wohl im Ansatz drehen wird.

Und noch etwas, das mir am Herzen liegt:
ertappe ich jemanden dabei, dass Sachen - seien es nun Texte, Screens, Presets oder was-auch-immer - einfach hieraus kopiert und anderenorts 'veröffentlicht' werden, gibt's 'was auf die Löffel! Auszüge, Zitate usw. mit Verweis auf diesen Thread sind absolut okay. Bitte nicht falsch verstehen: weder erhebe ich den Anspruch, sonderlich kreativ zu sein oder 'spektakulär Neues' zu verbrechen, noch habe ich etwas dagegen, dass Informationen an möglichst viele Interessenten weitergegeben werden - ganz im Gegenteil! - aber ich finde, wenn jemand über so ein Thema schreibt, sollte er auch verstanden haben, über was er da so schwafelt ...

In diesem Sinne: welcome to the show!

Zitat von Rogerobb1

So einen guten Aufsatz habe ich schon länger nicht mehr gelesen ...

Erzähl' das mal meinem Deutsch-Lehrer. ... hat der Esel mir doch glatt 'ne '6' auf's Auge gedrückt: Thema verfehlt!

Zitat von Rogerobb1

Und das Bild mit dem Rüssler ist wohl das Dynamic Cloth Problem gewesen

Jop. Hatte ja irgendwie gehofft, 'Dynamic C'-Rogerobb1 wüsste dazu etwas zu sagen, aber offenbar gibt's da wohl einfach nicht mehr, das der Rede wert wäre.

(Will mich so langsam mal an die Gradient und die Cloth-Like Versionen des TraLu-Shaders machen und wollte als Vorschau dafür etwas 'mehr' als 'nur so'n olles, hängendes Tuch'. )

Zitat von Lessa

Gerade sowas wie diese Brick-Übersicht hab ich schon lang vermisst. Das hat mir schon mal viel weitergeholfen, auch, wenn ich nach X Seiten doch irgendwann den Anschluss verloren hab muss ich mal an einem weniger späten Zeitpunkt noch mal versuchen.

Naja, nur die Ruhe!

Was wirklich interessant und relativ gut durchzuarbeiten ist, ist das DAZ-Tutorial, wegen dieser ver-Texturierungs-Geschichte. Aber wenn du das ein-/zwei Mal praktisch gemacht hast, ist das 'drin. Dann 'taugt' dieses Tut nur noch ein Weilchen, um die Displacement-Sektion abzugucken. Aber auch die ist reeelativ schnell 'verinnerlicht',
Diese Brick-Referenz muss nun wirklich nicht 'auswendig gelernt' werden. Deine favorisierten #Bricks wirst du ohnehin recht schnell kennen und die anderen können ja jederzeit nachgeschlagen werden.

Zitat

"Man muss nicht alles wissen, nur, wo es steht."

Übrigens:
wer Schwierigleiten damit hat, sich wegen der 'vertauschten Seiten' in den DS3-Tutorials zurecht zu finden, kann im Shader-Mixer auch die Anzeige umkehren. Allerdings wird sowohl in den shadowmap-Tutorials als auch von mir generell 'von links nach rechts gearbeitet' (also umgekehrt). Aber lässt sich ja jederzeit wieder umdrehen.

Edit Menü des Shader Mixers > Preferences
'Brick Flow' > 'From Right To Left' (aktiviert = DS3 Tut-Style ... deaktiviert = 'normal')

So, bevor's ans wirklich Eingemachte geht, noch ein paar prinzipielle Tipps für's Shader-Mixing:

Zitat

keep it simple / keep it clean !

Auch, wenn ein multifunktionaler und universell einsetzbarer Shader eine feine Sache ist, macht so etwas im SM zu erstellen, nur bedingt Sinn. Solch einen 'Allrounder' gibt es bereits mit der #UberSurface und somit ist die Notwendigkeit nicht unbedingt gegeben. Der Shader Mixer ist eher dafür gedacht, ganz spezielle Shader für ganz spezielle Zwecke zu erstellen. Im Prinzip könnte man auch sagen: um sie für die aktuellen Bedürfnisse 'maßzuschneidern'. Und bereits mit ein wenig Übung im SM ist das auch tatsächlich eine super Sache und im 'ganz normalen Workflow' machbar. (Bestimmt die Hälfte meiner aktuell verbrochenen SM-Shader sind auf diese Weise 'nebenbei' entstanden, weil ich 'jetzt gerade mal sowas brauchte'.)

Überlege dir vorher, welche Kanäle du für diesen Einsatz benötigst bzw. verwenden möchtest und lasse alle anderen außen vor.
Zu viel 'Gewusel' auf der Arbeitsfläche erhöht die Gefahr, dass sich an irgendeiner Stelle aus Schusseligkeit ein Fehler einschleicht (und mit Schusseligkeitsfehlern kenne ich mich aus! ) oder irgendetwas nicht 'richtig kompatibel' ist und dies dann zu finden kann wieder unnötig zeit- und nerven-raubend sein. Im Prinzip passt auch hier der Leitspruch: "So viel wie nötig - so wenig wie möglich."

Außerdem überlege dir auch bereits im Vorfeld, ob die einzelnen Kanäle bspw. am Ende vielleicht zusätzlich 'Textur-fähig' sein sollen. (Kann ja eigentlich nie schaden.) In diesem Fall macht es natürlich Sinn, gleich zu Beginn das Image-Map-Brick anstelle eines 'einfacheren' zu verwenden, denn somit erspart man sich das im-Nachinein-austauschen. (Birgt ja im Prinzip auch wieder das Potential für 'Flüchtigkeitsfehler'.)

Darüber hinaus ist es auch sinnvoll, den vorhandenen Platz großzügig zu nutzen, zwischen den einzelnen 'Sektionen' (Diffuse, Ambient etc.) etwas Platz für das ggf. spätere Einschieben weiterer Elemente zu lassen oder besser noch: diese generell weiträumig zu trennen. Mag sein, dass du für einen Kanal vielleicht zunächst nur eine Farbauswahl mit oder ohne Textur angedacht hast, aber kommst du später vielleicht auf die Idee, das Ganze vielleicht auch noch etwas zu erweitern, geht die Schieberei los. Zugegeben: das 'Schieben' geht in 4.8 wirklich super, aber dem lässt sich im Großen und Ganzen auch im Vorfeld bereits aus dem Weg gehen.

Werkle lediglich an einer 'Sektion' zur Zeit und checke regelmäßig im Viewport, ob es auch funktioniert. Die SM-interne Preview kann zwar ganz gut genutzt werden, um Sachen wie Farbe oder Glanzlichter zu begutachten oder um zu sehen, ob eine bestimmte Funktion jetzt 'überhaupt tut, wie angedacht', aber einen wirklich realistischen Eindruck, wie es im späteren Render aussieht, vermittelt sie nicht. Und für Lichter und Kameras ist sie generell nicht verfügbar.

Beim 'Übernehmen' des Setups werden Kameras und Lichter grundsätzlich jedes Mal neu erstellt, Materialien auf die selektierten Materialzonen des ausgewählten Objekts angewendet.

Grundsätzlich ist es auch empfehlenswert, für die Material-Preview im Viewport ein Objekt mit 'realistischen' Proportionen zu verwenden. Natürlich kann man sich auch eine 10m-Kugel in den Viewport werfen, aber spätestens, wenn der nach diesen Maßstäben erstellte Shader dann auf ein Objekt in 'Poser-Größe' angewendet wird, geht (vor allem bei der Verwendung proceduraler / fraktaler Texturen) die wilde Skaliererei los.

Speichere die SM-Setups regelmäßig und in verschiedenen 'Entwicklungs-Stadien' separat. So hast du mit der Zeit ein paar schöne Presets, die du als Ausgangsbasis benutzen kannst, so dass nicht immer wieder ganz von vorn angefangen werden muss.

Wenn die Bricks miteinander verbunden sind, benenne sie adäquat, denn du kannst nicht sicher sein, dass du in zwei Wochen noch weißt, was 'Mix (24)' jetzt eigentlich genau macht oder zu welchem Kanal 'Image Map (42)' gehört. Was das Umbenennen betrifft, habe ich hier (Posting ff.) schonmal etwas zum Besten gegeben.

Vielleicht interessant zu wissen:
Shader Mixer Lichter funktionieren i.d.R. mit AoA's Atmospheric Cameras, was bspw. bedeutet, dass Punktlichter 'sichtbar' werden.

Und noch ein paar warme Worte an die 'Perfektionisten':
versucht um Himmels Willen nicht, sämtliche Parameter und Optionen sofort zu verstehen / auszuknobeln. Beschränkt euch am besten auf das, was gerade (und häufig) gebraucht wird und blendet den 'Rest' zunächst weitestgehend aus. Sonst wird das echt zu viel! Ihr müsst jetzt nicht alles kennen und erstrecht nicht wissen, wie es funktioniert. Das Erschließen dieses Mysterium geht dann Schritchen für Schrittchen und 'beinahe' von ganz allein. ... mehr dazu von mir dann später an den entsprechenden Stellen und im Detail.