D|S re-CYCLES > teleblender3 unleashed ;)

Da 'D|S-softbody-dynamic-' @Rogerobb1 (hast du eigentlich gesehen, dass es auf der Seite von mCasual auch ein Script für einfache Rigid-Body-'Dynamics' gibt?) gequengelt und vor längerer Zeit schonmal mit dem sprichwörtlichen Zaunpfahl gewunken hat, mal ein paar Hinweise und Tipps zum generellen Workflow. Meine Erfahrungen mit dem Exporter-Script (und mit Blender sowieso) sind zwar bestenfalls mäßig, aber es funzt zumindest.

Benötigt wird DAZ|Studio, Blender und teleblender3 (zu finden auf der Seite von mCasual/Jaques ... kann ich zum Zwecke der Verlinkung allerdings gerade nicht erreichen). Erfahrungen mit und Kenntnisse in Blender sind zwar nicht zwingend nötig, aber überaus hilfreich. Ohne dies, wird lediglich ein Bruchteil des Potenzials genutzt. Ist aber auch eine schöne Möglichkeit, etwas über den Umgang mit Blender - zumindest in den Bereichen Rendering/ Beleuchtung/ Materialien - zu lernen.

Auf der TB3 Website gibt es zwei Archive zum Download. Beide werden benötigt.
mcjTeleBlender3 beinhaltet das D|S Exporter-Skript, mcjBlendBot ein Python-Script-Set für Blender. Ersteres kannst du innerhalb deines D|S-Content ablegen, wie du lustich bist, gewöhnlich unter content/scripts/mCasual (oder so), letzteres muss entweder in den modules-Ordner innerhalb deiner Blender-Installation oder du legst dir (wie ich persönlich es bevorzuge) einen separaten Ordner auf der Festplatte an, in den du generell Erweiterungen für Blender installierst und legst den Pfad in den Blender-Einstellungen fest. Diese Variante hat den Vorteil, dass die Sachen, die hier installiert werden, in allen Blender-Versionen verfügbar sind. Ansonsten müssen sie immer wieder neu in die entsprechenden Unterordner der Programm-Installation kopiert werden.

Anhang: B-pref-scriptpath.jpg
Der im Screenshot angegebene Ordner enthält einen Unterordner namens 'modules'. In diesen befinden sich die Dateien des mcjBlendBot-Archives.

Damit wären wir dann auch schon startklar.
D|S starten > Szene erstellen oder laden > DAZ-Script aufrufen.

Anhang: DS-scene.jpg
Der Einfachheit halber eine simple Szene, bestehend aus Figur, Boden und einem Distanz-Licht. Im Screenshot ist zwar auch noch ein UE2 zu sehen, aber dieses kann (und sollte) vor dem Export gelöscht werden, weil es ansonsten in ein Punktlicht konvertiert wird. Blender/Cycles hat generell ein 'Environment- Light' an Bord, somit bräuchten wir das ohnehin nicht. D|S' default Distanzlichter, Spots und Punktlichter werden komplett übernommen, Meshlight-Geometrie auch, nur muss das Material später ggf. angepasst werden, aber das ist auch kein Hexenwerk.

Anhang: TB-panel1.jpg
Die erste Seite des Skript-Dialogs. Oben die von mir gewöhnlich genutzten Einstellungen für nVidia-GPU-Rendering und experimentelle Shader (bspw. noch nötig für SSS in Cycles), unten reines CPU-Rendering ... um 'auf der sicheren Seite' zu sein.

Anhang: TB-panel23.jpg
Zweite und dritte Seite des Skript-Dialogs - meine aktuell bevorzugten Einstellungen (alle Dateipfade sind natürlich variabel). Genauere (und gute) Erklärungen zu den Parametern selbst finden sich in der mCasual-Anleitung. Besser könnte ich es auch nicht. ... naja, oder einfach nochmal hier nachfragen.

Nach einem Klick auf 'Export/open current frame' sollte D|S kurz rödeln, dann automatisch Blender starten und (in diesem Fall) etwas in dieser Art präsentieren:
Anhang: B-scene-imported.jpg

Dies ist eine einfache Szene, deshalb kann ich es mir erlauben, auch mal die Viewport 'Rendered' Preview zu aktivieren. Generell ist diese Einstellung aber mit Vorsicht zu genießen! Das ist Echtzeit-Rendering, also OBACHT!
Anhang: B-scene-displayrender.jpg

Die F12-Taste startet dann das 'tatsächliche' Rendering im von mir im Exporter gewählten 'progressive' Modus. Wurde diese Option beim Export deaktiviert, gibt's das 'Bucket'-Rendering. ESC bricht den Rendervorgang ab. Nochmals ESC kehrt zur Viewport-Ansicht zurück.
Anhang: B-scene-render-F12.jpg

Dies sollte auch erstmal nur zur Vorschau dienen. Jetzt ist es an der Zeit, die Blender Szene unter einen neuen Dateinamen zu speichern. Nur so ist gewährleistet, dass die Blender-Szene später komplett geladen wird. (Denn im Augenblick scheint das alles noch mit temporären Dateien verknüpft zu sein.) Danach Blender schließen, in D|S den Script-Dialog verlassen und Studio selbst beenden und die .blend Datei starten (oder Blender und dann die zuvor gespeicherte Datei öffnen). Ein F12 sollte wieder zum gleichen Ergebnis wie zuvor führen.

Alles Weitere ist dann reine (und viiiel, viel) Blender-Frickelei, was auch der Grund ist, warum ich dies hier im Blender-Bereich poste.
An alle 'Blender-Unkundigen', die es erfolgreich bis hier geschafft haben: Glückwunsch und suuuper!

Noch eine kurze Anmerkung zu Materialien:
Am besten funktioniert die Konvertierung mit D|S Standard-Materials. Das schließt weder die UberSurface noch Shader-Mixer-Mats ein. In der Regel werden für Blender diffuse/glossy Mix-Materialien, bei Bedarf einschließlich Bump, Ambient/Emission und Alpha-Transparenz generiert. Normalerweise ist meiner Erfahrung nach dann auch alles soweit vorhanden, aber eben 'nur grob eingestellt' ...

Jau, Cycles rockt!

Bild speichern: in der Render-Ansicht (UVImage-Editor) > Menüleiste > Image > Save As Image (s. Anhang) .. oooder über die [F3]-Taste.

Gör ist nackig: ... och ... naja ... also ... von müür aus ...

Edit: ... und DANKE! für den Link-Nachtrag.

Auf ShareCG habe ich schon vor einiger Zeit ein File gefunden, das Material-Node-Groups für aus D|S importierte Chars enthält, bin aber erst kürzlich in die Verlegenheit gekommen, es mir überhaupt mal näher anzuschauen. (Jaaa-ja ... ich bin eben auch ein Freebie-Hamster ...) Jedenfalls hat es mir sehr bei (m)einem kürzlichen Cornea-Problem geholfen und damit den Hintern gerettet ... oder zumindest ein paar weitere Stunden wüster try'n'error-Experimente erspart und somit empfehle ich es an dieser Stelle auch einfach mal ganz ungeniert weiter: Blender Cycles Materials for DAZ Studio Characters

Das .blend-File enthält, wie schon erwähnt, Shader-Node-Groups für die gebräuchlichsten Materialien bei Charakteren und ist insofern vermutlich recht nützlich, weil teleblender3 die Materialien aus D|S ja teilweise doch schon etwas abenteuerlich konvertiert, insbesondere, wenn es sich dabei um UberSurfaces handelt. Sie sind jetzt auch nicht die absoluten 'Überflieger' in Sachen Shading, aber auf jeden Fall besser als das, was tb3 teilweise so verzapft und allemal eine gute Ausgangsbasis für eigene Experimente. (Anhang: shader-groups-ds-chars.jpg)

Für Blender-Unkundige D|S'ler ein paar warme Worte zur Anwendung:

Blender's 'Smart Content' / 'Content Library' nennt sich 'Append', findet sich unter: Blender Hauptmenü > File > Append ... und öffnet einen Datei-Auswahl-Dialog für ein weiteres .blend-File. Das mag für D|S-Gewohnheiten zunächst etwas spartanisch erscheinen, aber mittlerweile finde ich dort die Sachen, die ich gerade suche, deutlich schneller und einfacher, als wenn ich mich erst ewig durch die D|S-eigene Content-Library scrollen müsste. Wird eine Datei gewählt, öffnet sich diese und in den Unterordnern findet sich alles, was diese Datei enthält. Bspw. enthält der Ordner 'Object' ebendiese und wird eines davon in die Szene geladen, kommen alle Materialien, die es nutzt, einschließlich aller Shader-Nodes/ Node-Groups mit. Lädt man Materialien, sind die Nodes / Node-Groups mit enthalten. Werden lediglich Node-Goups importiert, sind es auch ausschließlich diese. Das ist sehr praktisch, um tatsächlich nur die Sachen zu holen, die man auch wirklich braucht. Nicht mehr, nicht weniger.

In diesem Fall interessieren uns die Node-Groups, die im Prinzip eine Kombination mehr oder weniger aufwendiger Node-Setups sind und das Handling u.U. sehr erleichtern können. Zu finden sind diese im 'NodeTree' Unterordner. die einzelnen Namen in diesem File sind selbsterklärend und dürften den meisten bekannt sein. Mit gehaltener Shift-Taste können nun alle ausgewählt werden, die importiert werden sollen und der Button 'Append from Library' oben rechts importiert sie in unsere Szene. Alternativ kann auch das (einzige) 'Material' aus dem Ordner selben Namens geladen werden. Dies importiert alle Groups auf einmal.

Rechts im Blender-UI findet sich 'by default' oben der 'Outliner' (Scene-/Object-Manager) und darunter die verschiedenen 'Tabs'. Wählen wir oben unser Objekt aus, können wir im unteren Bereich die jeweiligen Einstellungen vornehmen. Über die Icons in der oberen Leiste wählen wir das entsprechende 'Tab'. Normalerweise werden Tooltips angezeigt, sobald man mit dem Mauszeiger darüber ist. Wir brauchen das 'Material' (eine Kugel, recht weit hinten ... bei [lexicon]Polygon[/lexicon]-Geometrien i.d.R. das Vierte von Rechts). Im entsprechenden 'Tab' ist oben die Liste der Materialien des Objekts und darunter zunächst ein Auswahl-Menü mit allen in der Szene vorhandenen Materialien, dann folgen Vorschau und Material-Einstellungen. Alle Bereiche können durch Klick auf den Titel ein- oder ausgeklappt werden. 'Surface' enthält die Einstellungen für Oberflächeneigenschaften (Diffuse, Emission, Glossy usw.), 'Volume' ggf. die Volumeneigenschaften wie Absorbtion oder Scatter, und 'Displacement' das Bump[lexicon]mapping[/lexicon]. (Echtes Geometrie-Displacement läuft - wenn mich nicht alles täuscht - ausschließlich über Modifier ... und das ist wieder ein gaaanz anderes Thema ...)

Anhang: B_add-open-node-groups.jpg
Damit wir nun unsere importierten Nodegroups auch nutzen können, müssen wir in den Node-Editor wechseln, für jedes Material die entsprechende Group laden und mit dem 'Material Output' verbinden: 'Surface' zu 'Surface', 'Bump' zu 'Displacement'. (Ich nutze für den Node-Editor immer das selbe Fenster wie für den Viewport ... brauche einfach viel Platz zum 'Node-Schubsen' und F12 startet eigentlich immer ein Rendering, egal, in welchem Editor ich mich gerade befinde.) Alle anderen (bereits vorhandenen) Nodes können getrost gelöscht werden (anklicken zum Selektieren, Entf-Taste zum Löschen). Normalerweise sollte der Node-Editor auch in der Shader-Auswahl starten. Ist dies nicht der Fall, in der Menüleiste des Node-Editors das erste Symbol (Shader Nodes) auswählen. Mit dem Scrollrad über der Arbeitsfläche kann diese gezoomt werden, die Leisten Rechts und Unten verschieben die Arbeitsfläche. Ist die Node-Group mit dem Material-Output verbunden, werden auch deren 'Surface'- und 'Displacement'-Parameter im 'Tab' rechts verfügbar.

Ich bevorzuge den Node-Editor, weil ich ihn einfach übersichtlicher finde, insbesondere wenn's dann etwas komplexer wird. Wer damit so gar nicht klarkommt, kann im Grunde auch alles in den Einstellungen des 'Material-Tabs' erledigen. Dazu einfach den Button hinter 'Surface:' anklicken und in der rechten Spalte der sich öffnenden Auswahl die entsprechende 'Group' selektieren. Das muss für 'Displacement:' dann allerdings auch nochmal gemacht werden. Anschließend bei den Parametern, die auf 'Tex' enden jeweils den Button (ganz rechts) klicken und 'Image Textur' auswählen. (Im Node-Editor unter Menü > Add > Texture zu finden.) Damit wären wir jetzt auch Textur-fähig. ... und da eigentlich alle Maps auch noch in der Szene vorhanden sein sollten, können diese jetzt auch einfach über das Dropdown-Menü zugewiesen werden.

Das muss für jedes Material im Grunde nur einmal gemacht werden. Danach allen Materialzonen, die auch dieses Material nutzen einfach das selbe Material zuweisen. Ich empfehle, immer jeweils die erste Textur-Map (ohne angehängtes .001 .002 ...) zu verwenden, um diese ganzen unnötigen Texturinstanzen loszuwerden. (Sollten dann bei einem erneuten Öffnen der Szene weg sein.) Am besten auch die Materialien gleich 'anständig' benennen und am Ende das Speichern des .blend-Files nicht vergessen. (Übrigens fragt Blender beim Beenden, ob es geschlossen - und nicht etwa wie D|S - ob die Szene gespeichert werden soll. Ein übereiltes 'Yes' kann hier schnell mal Stunden der Werkelei zunichte machen ...)

Zukünftig können dann via 'Append' die selbst erstellten Materialien aus dieser Szene geladen und ggf. lediglich neue Texturen zugewiesen werden. Wird ja vor allem interessant, wenn man dann auch noch ein bisschen an den Shader-Nodes 'geschraubt' hat ...

(Hoffe, das war jetzt nicht zu 'konfusionierend'? )

Hey, @Bluepix ... danke ... freut mich, wenn's dir gefällt.
... wobei deine 'Pipeline' ja eigentlich eher in die andere Richtung geht (Blender > D|S > Octane), oder?

Aber, wie dem auch sei: dann genieß' die Show!

Tach!
(Bin zwar zur Zeit mal wieder in einem gaaanz anderen Bereich (des 'kreativen Selbstausdrucks' *hust* ) unterwegs und 3D kommt dabei leider - wie ja auch nicht ungewöhnlich - gerade ein bisschen zu kurz, aber wollte diese Sache hier dann doch nicht so gaaanz einschlafen lassen ... btw.: wollte an dieser Stelle eigentlich auch schon länger mal ein paar 'Tipps-n-Tricks'-Sachen oder so zum Besten geben, aber weiß jetzt gar nicht: besteht derzeit überhaupt 'Bedarf' an sowas?)
~~~~~

Eine der Stärken von Blender ist ja auch die Möglichkeit der 'Integration' zusätzlicher Render-Engines. Bei manchen funktionierte das in der Vergangenheit besser als bei anderen, die eine lediglich als 'Exporter', die andere lässt sich nahezu komplett oder in jeder Hinsicht in Blender - bis hin zum Render-Vorgang selbst - nutzen. Manche verwenden spezielle, separate Blender-Builds, andere lassen sich via Plugin in jede beliebige Programmversion installieren.

Zur Gruppe Letzterer gehört auch Mitsuba, eine weitere (Open Source) 'Physically Based' Render-Engine (... jaja ... noch eine! ...) und kann mit Hilfe des entsprechenden Blender-Plugins nahtlos integriert werden. Die Entwicklung der 'Stand-Alone'-Engine selbst scheint vor längerer Zeit (bei Version 0.5.0) 'stehen geblieben' zu sein, aber man sollte sich durch diese Versionsnummer nicht täuschen lassen. Denn, was #Mitsuba so an 'Features' auffährt, kann sich durchaus sehen lassen und scheut auch den Vergleich mit 'den größeren Geschützen' nicht. Das Plugin, welches diese Engine in Blender 'integriert', scheint sich allerdings weiterhin in relativ intensiver Weiterentwicklung zu befinden (letztes Update: Dez. 2015). Allerdings sind hierüber nach wie vor (noch?) nicht alle Mitsuba-Features komplett verfügbar.

Insbesondere einige Renderings und 'Vergleichs-Shots' haben mich bereits vor meinem Blender-Wiedereinstieg neugierig gemacht, weil sie auf mich - im Gegensatz zu vielen anderen PBREs - vergleichsweise kontrastreich und 'knackig' wirkten und vor einiger Zeit habe ich dann schließlich auch 'der Versuchung' nachgegeben. Erster Eindruck: gaanich' maa' schlecht!

... aaaber: im Internet gibt es allgemein nur seeehr wenig Material und der überwiegende Teil der Informationen, die ich bisher so gefunden habe, sind - insbesondere in Bezug auf das Blender-Plugin bzw. dessen Funktionen und Funktionsweisen - missverständlich oder (vor allem!) veraltet und längst überholt. So lese ich bspw. immer wieder, dass Mitsuba-in-Blender keine Material-Nodes unterstütze. Das ist längst Geschichte, denn das Plugin bringt einen ganzen Sack voll Nodes und ein gesundes Maß an Standard-Shadern mit. Vielleicht nicht ganz so umfassend, wie man es von #Cycles gewohnt sein mag, aber allemal ausreichend, um für die meisten Situationen angemessen gewappnet zu sein. Darüber hinaus haben die meisten Shader 'werksseitig' bereits eine ganze Palette an Standard-Material-Presets im Gepäck. #Mitsuba selbst ist erstklassig (PDF-) dokumentiert, die Blender-Integration für Cycles-Kenner ohnehin gewissermaßen 'intuitiv', weil sich die entsprechenden Einstellungen an den selben Stellen befinden, so dass zumindest in dieser Hinsicht keine Umgewöhnung vonnöten ist. Der Funktionsumfang erscheint auf den ersten Blick etwas geringer, aber das täuscht im überwiegenden Teil der Fälle. Weniger ist manchmal eben doch mehr.

Installation:
Mitsuba selbst kann an einem beliebigen Ort auf der Festplatte installiert und als Stand-Alone-Engine von hier aus gestartet werden. Das Blender-Plugin muss in den 'addons' Ordner der Blender-Programm-Installation (siehe hierzu ggf. auch das Eingangs-Posting dieses Threads). Nach Aktivierung des Plugins in den User Preferences (Add-ons > Render > Render: Mitsuba) steht 'Mitsuba' als Render-Engine Auswahl-Option (ganz oberste Blender-Menüleiste, wo ansonsten 'Cycles Render' ausgewählt ist) zur Verfügung ... and we're ready to go.

Edit*: Ahso ... beim Aktivieren des Mitsuba-Plugins in Blender's User Preferences unbedingt auch noch den Pfad zur Installation der Stand-Alone-Engine angeben (Plugin-Eintrag aufklappen und Pfad wählen).

Features:
Okay ... die eigentliche (und sicherlich berechtigte) Frage ist vermutlich: "Was kann Mitsuba, das Cycles nicht auch hinbekommt?" ... und deswegen beziehen sich meine Aussagen i.d.R. auch auf ein "- im Vergleich zu Cycles -" ... und wohlbemerkt ausschließlich auf die Mitsuba-Blender-Integration. Wie bereits erwähnt, ist hier noch nicht alles implementiert und ein 'mehr' lässt sich lediglich über nachträgliches 'zu-Fuß'-Bearbeiten der Export-Dateien bewerkstelligen ... und bitte nicht falsch verstehen: ich steh' toootaaal auf #Cycles und sehe #Mitsuba deshalb auch keineswegs als 'Ersatz', sondern vielmehr als brauchbare Erweiterung für spezielle(re) Render-Situationen.

Aus meiner - wohlbemerkt ganz persönlichen Sicht - bietet #Mitsuba erstmal vier gravierende Vorteile (nur drei, wenn man berücksichtigt, dass sich die entsprechende 'Funktion' auch ohne Schwierigkeiten auf anderem Wege ersetzen lässt): zunächst wäre da die große Auswahl verschiedener Integrator-Presets. Neben verschiedenen Pathtracing-Typen, sind sowohl bidirectional Pathtracing, Photon-[lexicon]Mapping[/lexicon], als auch eine Auswahl diverser MLT-Integrators an Bord. Das macht #Mitsuba besonders in Hinblick auf Caustics-Rendering interessant, so lange #Cycles 'lediglich' pathtrace-t. Außerdem hat #Mitsuba eine größere Anzahl verschiedener Pixel-Filter zur Auswahl. #Cycles bietet lediglich 'Box' und 'Gaussian', welche häufig zu einer gewissen 'Weichheit' im Rendering führen. #Mitsuba kommt hier mit deutlich mehr um die Ecke, einschließlich des von mir bevorzugten Mitchell-Netravali Filters ... knackig, knackig, knackig! ... (Dies ist der bereits oben erwähnte 'Vorteil', der sich allerdings grundsätzlich auch durch leichtes Nachschärfen des Bildes im Image-Editor des Vertrauens relativieren ließe, auch, wenn's nicht gaaanz das Gleiche ist.)

Mitsuba ist schnell! Berücksichtigt man, dass es sich hier um einen reinen CPU-Renderer handelt, gehört diese Engine zu den ganz Flinken und kann es (abhängig von der Anzahl der CPUs/GPUs) sogar durchaus mit Cycles GPU-Rendering aufnehmen, das ja bekanntermaßen auch nicht eben von schlechten Eltern ist. Cycles' CPU-Rendering wird locker und um Lääängen getoppt und ... nichts für Ungut, liebe LUXer, aber so cool, etabliert und solide eure Engine auch sein mag: für euch hat #Mitsuba bestenfalls ein nachsichtiges und mitfühlendes Lächeln übrig (... fiel mir nur gerade ein, weil das Mitsuba-Blender-Plugin - so weit ich das mitbekommen habe - wohl auf die LuxRender-Version aufbaut oder basiert oder so ...)

Und last but not least: weil Mitsuba von seiner Natur her eine Stand-Alone-Engine ist, kann die entsprechende Szene auch gerendert werden, ohne dass Blender selbst in aktiver Benutzung ist. Dies lässt sich ganz simpel über einen Szene-Export und anschließendes Laden über Mitsuba's GUI bewerkstelligen. Mir ist auch schon aufgefallen, dass wohl auch aus diesem Grund ein Rendervorgang, der eigentlich (über Kommandozeilen-Aufruf) in Blender selbst ausgeführt wird, weiter läuft, selbst wenn Blender zwischenzeitlich aus-welchem-Grund-auch-immer abschmiert (was ja gelegentlich schonmal vorkommen kann).

Es gibt allerdings auch ein paar Nachteile, die ich nicht hinter'n Berg halten möchte: Standard-Lichtquellen (Spots, Distanz- und Punkt-Lichter) haben ausschließlich harte Schatten. Das will heute eigentlich niemand mehr. Nienich! Für Soft-Shadows sind entweder Area- oder Meshlights nötig, die aber imho ohnehin auch den besseren Job machen. Lichtquellen werden als Objekte angezeigt und gerendert. Wer bisher #Cycles genutzt hat und sich damit halbwegs auskennt, wird sich grundsätzlich recht schnell zurecht finden, aber es ist eben speziell in Bezug auf Integrator-Presets und Material-Nodes nochmals eine kleine Einarbeitung nötig. Zudem werden auch noch nicht alle Blender-'Features', insbesondere im Zusammenhang mit 'Simulationen' unterstützt. Andere Sachen, wie bspw. Blender-Haar-Partikel funktionieren hingegen super! (Hab' ich nämlich schon probiert. ) ... i.a.R. dauert es ein bisschen länger, bis der eigentliche Render-Vorgang startet, eine 'progressive Rendering' Option habe ich bisher nicht finden können und wird eine Cycles-Szene für #Mitsuba gewandelt, erscheint die Szene als Ganzes zunächst etwas dunkler, was wohl in den meisten Fällen ein 'Nachtunen' der Lichter zur Notwendigkeit machen dürfte. Und leider, leider nutzt #Mitsuba nur ein 'gewöhnliches' Gaussian-Blur für Unschärfe-Effekte und kann damit (natürlich) in keinster Weise mit Cycles' imho großartigem Bokeh-Blur mithalten.

In Bezug auf Materialien ist häufig zu lesen, dass ein Klick auf den 'Add Mitsuba Nodetree'-Button (in den Material-Einstellungen) Cycles-Materials problemlos konvertiert. Das trifft jedoch bestenfalls auf Cycles 'Basis-Shader' zu. Komplexere Cycles-Node-Setups werden nicht erkannt und einfach ins Mitsuba-Default-Material gewandelt. Somit ist man dann doch schon gezwungen, sich auch hier mit den Material-Optionen auseinander zu setzen, die - zugegebenermaßen - zunächst auch ein bisschen verwirrend sein können. Möglicherweise haben hier (wie auch bei den Integrator-Presets in den Render-Einstellungen) aber Nutzer, die ähnliche Optionen aus anderen Render-Engines kennen, einen Vorteil (möglicherweise ja sogar ein Gefühl von 'Vertrautheit' ... besonders bei den Render-Integrators erinnerte mich doch schon so Einiges an den alten LuxRender-Exporter der Blender 2.4x-Versionen. ).

Das Ende vom Lied:
Tja, was soll ich sagen? Im Prinzip finde ich #Mitsuba als zusätzliche Option gar nicht übel. Das 'Dreiblatt' wird bei mir ganz sicher nicht #Cycles als 'Default'-Engine erstetzen, aber für den ein oder anderen Render-Fall - insbesondere auch wegen der wirklich guten nahtlos-Integration und interessanten Möglichkeiten - sicherlich Verwendung finden. Hinzu kommt, dass viele der 'Blender-Special-Features' wie Haare - und Partikel ganz allgemein - problemlos unterstützt und identisch gerendert werden. Daneben sind bei einem 'internen' Rendering auch die Optionen vorhanden, die Blender-Internal und Cycles bieten (Film-Einstellungen und -Effekte, Composite-Nodes, etc.) und auch die Render-Geschwindigkeit könnte durchaus zu einem kleinen 'Swap' verleiten, wenn Cycles' GPU-Rendering aufgrund zu großer Szenen nicht mehr möglich ist. Das Bildergebnis wirkt etwas kontrastreicher und 'knackiger', was je nach Einzelfall, mal positiv, mal negativ empfunden werden kann. #Mitsuba ist - all dieser Aspekte wegen - für mich definitiv eine der interessanteren Engines, die ich 'über die Jahre' so ausprobiert habe ...

~~~~~
PS*: ... bisher leider nur ein einzelner, schlichter 'Vergleichsshot', aber wenn ich mal mehr davon machen sollte, hänge ich sie hier mit an ... Gleiches gilt für eventuelle Test-Render. (Das kleine Bild in der Mitte zeigt, die Szenen-Helligkeit, nachdem die Szene von #Cycles auf #Mitsuba umgestellt wurde.)

EDiT/UPDATE [2016-02-29]
Blender-Partikel-Haar Vergleichsshot. (siehe Mitsuba und Blender-Folikel für weiterführende Erläuterungen)

(Habe überlegt, wohin ich das Anhangs-Bild wohl verfrachten könnte und da dies vermutlich der Fred ist, in dem ich - hinsichtlich irgendwelcher Blender-/ Cycles-Experimente und/oder speeektakulääär neuer Erkenntnisse - von Zeit zu Zeit wohl am ehesten etwas zum Besten gebe, packe ich's jetzt einfach mal dazu. So. )

Nochmal kurz zum Thema: #Fireflies in Cycles:

Hab' vor einiger Zeit wieder gezielter mit Cycles-Nodes herumgespielt, weil ich mir mal selbst einen 'Glossy-SSS-Plastic' (oder so) Shader zusammen stümpern wollte. Dabei war natürlich irgendwie schon damit zu rechnen, dass diese kleinen Plagegeister auftauchen und hab' dann auch einfach die Gelegenheit genutzt, ein paar von @Kushanku 's Tipps durchzuprobieren. Hängen geblieben, bin ich letztendlich an der 'Clamp'-Funktion in den Render-Einstellungen (Render-Tab > Sampling > Settings: Clamp Direct / Indirect) und weil ich ohnehin 'zu Gange' war, habbich gleich auch ein paar Vorschauen komplett durchrendern lassen.

Zur Erklärung:

Die ersten beiden Bildausschnitte sind mit jeweils beliebigen, sich unterscheidenden 'Seed'-Werten gerendert (Render-Tab > Sampling > Settings: Seed). Dies hat eine unterschiedliche Berechnung des 'Bildrauschens' (Noise-Maske) zur Folge, so dass die Fireflies (hoffentlich) an verschiedenen Stellen auftauchen. Werden diese beiden Render in einem Bildbearbeitungs-Programm via 'Abdunkeln' übereinander gelegt, bleiben lediglich die weißen Pünktchen übrig, die in beiden Renderings vorhanden sind (Ausschnitt 3). Diese Methode reduziert die Biester schon ganz ordentlich, hat aber u.U. auch eine gaaanz leichte 'Verdunklung' der Szene - insbesondere im Bereich weicher Schatten - zur Folge. Aber man hat eben auch nicht immer Zeit und/oder Muße, die komplette Szene zwei Mal zu rendern ...

Die beiden letzten Ausschnitte sind jeweils Einzel-Render. Zunächst mit einem Clamp-Wert von 1.0 sowohl für 'Direct' als auch 'Indirect' und wie man unschwer erkennen kann, wird in der Tat jede Spur von Fireflies restlos aus der gesamten Szene getilgt ... ebenso, wie jedes Glanzlicht, jede etwas knackigere Reflektion und teilweise sogar hellere diffuse Flächen (siehe 'Bodenkreise').

Ganz rechts stehen beide Werte auf 20.0 - in diesem Fall ein recht annehmbares Mittelmaß. Es sind zwar nach wie vor Ansätze von Fireflies wahrnehmbar, aber auch die Glanzlichter sind noch knackig genug. (Dies in Kombination mit der 'Doppelrender-Nummer', dürfte wohl in den meisten Fällen schon ein richtig gutes Ergebnis liefern.) Generell habe ich mit Clamp-Werten zwischen 15 und 25 die besten Erfahrungen gemacht. (Je niedriger der Wert, umso krasser der Reduktions-Effekt in den Highlights.) Zudem reicht es häufig auch, lediglich den Indirect-Wert zu ver-clamp-en, weil es in erster Linie diese 'Kanäle' sind, die zum Rauschen neigen.

Eine gute Möglichkeit, dem oder den Übeltäter(n) auf die Schliche zu kommen ist btw. das Aktivieren der einzelnen Render-Passes (Render Layers-Tab (2. von Links) > Passes). Dadurch kann auch bereits während des Render-Vorgangs beurteilt werden, ob irgendwelche Kanäle aus der Reihe tanzen und wenn, welche genau. (Im überwiegenden Teil der Fälle ist bei mir Glossy Indirect der Übeltäter, manchmal auch 'synchron' mit Diffuse Indirect.)

Zum Abschließ am Abschluss noch kurz etwas eher Allgemeines: das Clamp-en betrifft die komplette Szene und reduziert alles, was da auch nur ansatzweise blitzt oder funkelt. Deshalb sollten zuvor nach Möglichkeit alle anderen zur Verfügung stehenden Wege ausgetestet werden, angefangen beim Material selbst. Gewöhnlich sind es ja bestenfalls ein oder zwei Shader, die Fireflies verursachen und deshalb den Dynamikumfang der gesamten Szene zu reduzieren, bringt vielleicht auch mehr Nach- als Vorteile. (Ich persönlich bevorzuge diese Reihenfolge bei der Problembehebung: erst Material, dann Licht und erst danach - und wenn alle Stricke reißen - die gesamte Szene ...)

Wünsche ein schönes Wochenende!  

Och, @Bluepix ... nun staple mal auch nicht zuuu tief. Ich nehme ja ohnehin an, dass du im Grunde sowieso mehr weißt, als du weißt, dass du es weißt. (Gaaanz davon abgesehen, dass ich mir auch nicht sicher bin, ob man manche Sachen, von denen ich gelegentlich so schwafle, überhaupt irgendwie wissen muss. )

Zitat von Kushanku

Ich setze die Clamp-Werte meist in Höhe der Lichtstärke des Hauptlichtes.

Hattest du ja auch schonmal in deinen 'erweiterten' Tipps mit angegeben ... und hab' ich soweit auch zur Kenntnis genommen. Dass ich in dieser Hinsicht nochmal etwas experimentiert habe, liegt wohl einfach daran, dass ich - insbesondere bei solchen 'Szene-weiten' Einstellungen - möglichst viel 'Overhead' lassen möchte (... bloooß nicht mehr 'begrenzen', als uuunbedingt notwendig ...) Danke für den Reminder und Input! ... habe gleich nochmal 'ne kleine 'Testreihe' durchlaufen lassen:

... selbe 'Szene', bei allen Tests den selben Seed-Wert, Hauptlichtquelle: SUN-Light / Strength: 3.85 / dezentes (orange-)gelb, Pathtracing mit lächerlichen 256(! ) Samples (... zwar noch ein kleinwenig 'noisy', aber Cycles ist doch einfach mal sowas von cool! )

Unterm Strich: jop! Clamp Wert auf Höhe der Lichtstärke beseitigt in diesem Fall alle Fireflies (bis auf eine Ausnahme, die offenbar recht hartnäckig ist) zuverlässig, selbst, wenn nur indirect ge-clamp-t wird. Dadurch bleiben dann auch die eigentlichen (direkten) Glanzlichter komplett erhalten. Habe zusätzlich auch spaßenshalber mal noch den 4-fachen Wert genommen und die beiden Versionen direkt nebeneinander plaziert, damit der Vergleich etwas einfacher ist. "Wie Sie sehen, sehen Sie nichts" ... weder dass eine Erhöhung des Clamp-Wertes hier eine wahrnehmbare Verbesserung bringen würde (obwohl ich mir bei den Original-Renderings einbilde, eine gaaanz leichte Detail-Erhöhung in den Spiegelungen zu erkennen), noch dass dadurch die Leuchtkäfer auffällig zunähmen (mit Ausnahme des einen-besagten-welchen und noch ein oder zwei anderen). Naja, so betrachtet, gibt's hier ja auch nicht aaallzu viel 'indirect glossy', an dem sich so etwas gut festmachen ließe. (Wäre auf der anderen Seite sicherlich interessant, das auch mal mit Caustics zu testen, aber bei meinem Leichtgewicht von Render-Sklaven ist mir das 'zu Testzwecken' irgendwie echt zu berechnungsintensiv ...)

Habe bei beiden Werten auch die direct+indirect-Clamp Version dazu gepackt, um einfach mal einen Eindruck von der Stärke der 'Beschneidung' zu bekommen. Auch, wenn's hier ja eeeigentlich irrelevant ist.

Tach!

Um hier zunächst ein bisschen 'gut-Wetter' zu machen, zwei Links zu online-Material-Sammlungen für Blender/Cycles (die ich eigentlich schon länger mal posten wollte) und falls noch nicht bekannt: [entfernt, da tot] und Blendermada. Das Repertoire reicht von auf Cycles' Standard-Shader basierenden Materialien bis hin zu komplexeren Node-Setups. Vielleicht ist ja für den ein oder anderen etwas Verwertbares dabei ... (via 'Append' in die Szene laden und im Material-Tab zuweisen)
-----

Eines der Oktahedronse aus dem Rounded Edges (Timesavers Serie) Pack von @spacebones musste mal wieder für ein Experiment herhalten. (Wer btw. gelegentlich Bedarf an 'erweiterten Grundkörpern' in entsprechender Qualität hat, kann hier ruhigen Gewissens ein paar [definition='1','0']Rendi[/definition] investieren und zuschlagen. Ist guter Stoff! ...)

Habe wieder ein bisschen mit Mitsuba 'rumprobiert und diesmal lag der Schwerpunkt auf Blender's Haar-Partikel. Cycles bietet ja gleich mehrere Möglichkeiten, diese zu ver-materialisieren: einen eigens dafür vorgesehenen(?) Hair-Basis-Shader, den Velvet-Basis-Shader, der sich sicherlich auch zweckentfremden lässt, wenn vielleicht anstelle von Haaren, 'fusselige Klamotten' auf dem Plan stehen und last but not least: die generellen Node-Optionen, wie Edge-Blend, Fresnel und/oder anisotropische Glanzlichter ... zur freien Gestaltung für die gaaanz schmerzfreien Material-Bastler. Mitsuba ist in dieser Hinsicht doch ein wenig begrenzter. Hat zwar ein paar Kleidungs-/Stoff-Algorithmen, aber eigentlich (und auf den ersten Blick) erstmal nichts hier wirklich 'Verwertbares'. Und auch an 'Funktions-Nodes' mangelt es noch etwas. Deshalb musste für diesen Test zunächst auch ein ganz schlichtes diffuses Material reichen.

Habe hierbei im Übrigen auch heraus gefunden, dass die Sonne des SunSky-Systems in Mitsuba - im Gegensatz zu den normalen Distanzlichtern - auch weiche Schatten wirft. Damit kommt Selbiges auch mit auf die 'pro-Mitsuba-Liste'. Cycles schwächelt in Sachen 'physical SunSky' ja leider doch noch ein bisschen ... Habe bei dieser Gelegenheit auch gleich nochmal die Tiefenunschärfe unter die Lupe genommen und in dieser Hinsicht enttäuscht Mitsuba in diesem Fall wirklich ... finde ich. Grundsätzlich würde ich sagen, dass Mitsuba die Blender-Folikel merklich 'fluffiger' (feiner) rendert, als Cycles. Mag manchmal sogar ganz interessant sein, aber kann sicherlich auch etwas stören, wenn's denn mal 'solider' wirken soll. Bei sehr diffusem Licht (HDRi) scheint Mitsuba deshalb hier auch einen Hang zum 'Vermatschen' zu haben ...

In der Szene sind - neben der 'Umgebungsbeleuchtung' i.w.S. - drei weitere Lichter, die ich einfach aktiv habe, weil das Hauptlicht in Cycles durch ein HDRi-Panorama erzeugt wird. (Nutze diese Szene auch, um Materialien in Cycles zu erstellen/testen und für Reflektionen und dergleichen kommt das schon ganz gut. Aber brauche gelegentlich auch mal etwas, das 'richtige' Glanzlichter erzeugt ...) und hab' diese Cycles-Distanzlichter in Mitsuba wieder in Area-Lights umgewandelt. Erstes Bild: in einer abendlichen SunSky-Stimmung in Mitsuba (Himmel und Sonnen-Distanzlicht), die anderen Bilder nutzen das selbe HDRi-Panorama (und in der gleichen Intensität) im Environment. Wie schon erwähnt, ist das Material in Mitsuba rein diffus, hat aber die selbe Farbe, wie die Cycles-Shader ... für den Vergleich. In Cycles habe ich einfach den Basis-Haar-Shader und einmal den Velvet-Shader probehalber verwendet, ohne groß daran herumzuschrauben. (Wollte ich einfach mal wissen ...) Keines dieser beiden Materialien wurde beim Umstellen auf Mitsuba konvertiert, sondern wieder schlicht Standard-Mitsuba-Material. Klappt also doch nicht bei allen Basis-Shadern.

EDiT/UPDATE [2016-02-29]
Habe zusätzlich zwei weitere Testshots angehängt. Einmal in Cycles ebenfalls mit dem normalen Diffuse-Shader gerendert und die gleiche Mitsuba-HDRi-Szene mit um ein Drittel erhöhtem Children-Wert in den Haar-Partikeln, um der 'optischen Ausdünnung' etwas entgegen zu wirken.  (Erinnert mich ja irgendwie schon so ein bisschen an einen bereits leicht mitgenommenen Kunstplüsch-Badewannen-Vorleger oder sowas ...) Hat hier nun gut 66.000 Haare, die Mitsuba erstaunlich geschmeidig wegsteckt ...

Bild 1 - Mitsuba, SunSky, PathTracing: 256 Samples
Bild 2 - Mitsuba, HDRi, PathTracing: 256 Samples
Bild 3 - Cycles, HDRi, Hair-Shader, PathTracing: 1024 Samples
Bild 4 - Cycles, HDRi, Velvet-Shader, PathTracing: 1024 Samples
Bild 5 - Cycles, HDRi, Diffuse-Shader, PathTracing: 1024 Samples
Bild 6 - Mitsuba, HDRi, PathTracing: 256 Samples

(... nur so am Rande: habe vorgestern die beiden Mitsuba-bezogenen Postings noch vereinzelt um Anhänge erweitert ...)

Zitat von Bluepix

... aber auch noch viele böhmische Dörfer für mich.

Was konkret ist denn da 'böhmisch'? Vielleicht kann ich ja auch vieles ein bisschen 'vereinfachen' ... stecke wohl echt schon dermaßen tief im 3D-Sumpf, dass ich teilweise gar nicht mehr realisiere, wenn ich zuuu weit über's Ziel hinaus schieße. ... sooorry!

... und danke für dieses Feedback!

Howdy!

Nach den Seitensprüngen, Tests und Seitensprung-Tests der letzten Zeit nun wieder etwas, das doch tatsächlich auch einen praktischen Zweck erfüllen kann ... nuuur mal sooo der Abwechslung halber ...

Cycles' Emission-Standard-Shader macht einen ausgezeichneten Job, sofern sich das Objekt nicht direkt im Sichtbereich der Kamera befindet: Farbe auswählen, Stärke/Intensität einstellen und jut is'. Um ihn jedoch auch im Blickfeld der Kamera für #Meshlights (wie bspw. Neonröhren, LEDs, beleuchtete 'Reklametafeln' oder 'Schaukästen' u.ä.) nutzen zu können, ist er jedoch in der 'Grundversion' erstmal nicht sooo gut geeignet, weil es sich hierbei von Natur aus um einen 'constant-Shader' handelt. Will heißen: er wird in keinster Weise von anderen Elementen in der Szene beeinflusst und verhält sich somit im Prinzip ganz ähnlich wie normale Ambient-Shader in Raytracern oder Scanline-Renderern.

Dies ist in Cycles natürlich auch erstmal keine große Sache, denn durch die Node-basierte Shader-Architektur lässt sich dieser Shader ja nach Herzenslust mit anderen kombinieren, so dass er am Ende doch etwas 'ansehnlicher' wird. Problem gelöst ... aaallerdings gibt's dann auch noch eine zweite Hürde zu nehmen, denn die Lichtemission ist im Verhältnis zur relativen Helligkeit des Objekts recht gering. Erhöhe ich die Lichtstärke, wird automatisch auch das Objekt heller. Ist 'physikalisch betrachtet' ja soweit auch korrekt, nur gibt es eben auch eine Vielzahl von Situationen, in denen ich dies eben nicht möchte. Und wenn ich einen bestimmten Effekt zu erzielen gedenke, interessiert mich 'physical correctness' eigentlich herzlich wenig ...

Und weil ich aktuell gerade so etwas brauche, hab' ich mich einfach hingesetzt und ein simples Emissions-Material ausgeheckt, das sowohl Glanzlichter/Reflektionen beinhaltet, eine gewisse 'Räumlichkeit' hat und bei dem die Stärke der Lichtemission unabhängig von der 'augenscheinlichen' Helligkeit des Objektes geregelt werden kann. Es gibt sicherlich verschiedene Varianten solcher Materialien im Netz, aber da ich so etwas bei Bedarf auch gern selbst reproduzieren können möchte, hab' ich da auch gar nicht weiter geschaut, nicht lange gefackelt und das Ganze nach eigenem Gutdünken zusammen geschustert. (Hatte sowas in meiner Cycles-Anfangszeit und auch in/für D|S' 3Delight schonmal verbrochen, aber hier nun eben die aktuelle Version, basierend auf meinen derzeitigen 'Kenntnisstand'.)

Basis ist zunächst ein Emission-Shader, zu dem ich einen Diffuse-Glossy-Mix addiere. Damit interagiert das entstehende Material mit der Szene (Lichtquellen, Schatten, Spiegelungen) und emittiert gleichzeitig - aber relativ wenig - Licht. Erhöhe ich nun die Lichtstärke, wird mein Meshlight aber simultan auch heller und das will ich ja nicht. Hier kommt nun ein wirklich pfiffig ausgeklügeltes Ding aus der 'Input'-Sektion des Node-Baukastens zum Zuge: Light-Path. Light-Path weist die Render-Engine im Prinzip an, was sie ggf. anders zu tun hat, als sie es 'normalerweise' tun würde. In diesem gaaanz simplen Fall sagt diese Funktion im Fac-Input des Mixers inetwa so viel wie: "Ist der Render-Strahl ein Kamera-Strahl (das, was die Kamera direkt 'sieht'), verwende Material 2, ansonsten Material 1." ... Material 1 ist hier ein ganz simpler Emission-Shader, der ausschließlich für die Lichtabstrahlung zuständing sein soll. Dessen Stärke kann ich beliebig erhöhen, ohne dass das für die Kamera sichtbare Material verändert wird. Material 2 ist der Diffuse-Glossy-Emission-Mix, der zuvor erstellt wurde. Die Stärke der Emission in Material 2 steht (und bleibt) auf 1.000 und somit wird genau die Objektfarbe ausgegeben, die ich wähle. (btw. betrifft dies ggf. auch andere Spiegelungen in der Szene, so lange sie von der Kamera 'gesehen' werden.)

Im Screenshot sind für den Farbinput zwei Farbwähler und eine Fresnel-Node vorhanden, weil ich ungern völlig homogene (einfarbige) Materialien verwende. Ist aber eher so ein ganz persönliches Ding meinerseits und vermutlich eeeigentlich heutzutage auch nicht mehr wirklich nötig, weil die PBREs ja in aller Regel Farbvariationen in Abhängigkeit des Blickwinkels mit einbeziehen, aber die Macht der Gewohnheit eben ... außerdem mag ich diesen Effekt der gaaanz leichten Farbvariation. Zudem erhöht dies ein bisschen den Eindruck von 'Räumlichkeit' und hebt das Objekt auch nicht selten etwas mehr vom Hintergrund ab. (In diesem Fall bestimmt die Fresnel-Node zudem die Verteilung von diffuse zu glossy, aber ist im Grunde nun wohl wirklich unter 'Spielkram' zu verbuchen ...)

Hier ließe sich nun auch noch viel an eigene Vorstellungen oder Gewohnheiten anpassen, aber diese Variante funktioniert für mich im Moment eigentlich ganz gut und die Glanzlichter/Reflektionen lassen sich gut über die glossy-Farbe regeln. Und eine Sache ist an diesem Material noch klasse: weil es für alles - von der Kamera abgesehen - nach wie vor ein reines Emission-Material geblieben ist, erweist es sich bei mir (und in Blender 2.76b) als zu 100% Firefly-resistent ... vielleicht sogar ein Lösungsansatz für derartige Probleme mit anderen Materialien ...?

Habe die Suzanne-Szene (wollte dat Suzannchen doch auch endlich mal verwenden ...) für Interessierte als .blend-File mit angehängt und hier variiert der Farb-Input ein bisschen. Ich bin häufiger ja auch reichlich faul und deshalb hab' ich den zweiten Farb-Input durch einen HSV-Regler ersetzt. Diesen dürften die meisten aus normalen Bildbearbeitungs-Programmen kennen und auf diese Weise wird die zweite Farbe durch eine leichte Verschiebung von Farbton, Sättigung und/oder Helligkeit quasi 'automaisch' und 'synchron' in Abhängigkeit von der gewählten Grundfarbe generiert. Somit müssen nicht jedes Mal zwei Farben ausgewählt werden ... und damit schließt sich der Kreis, denn auch hier reicht es jetzt aus, eine Farbe zu wählen und die Lichtstärke/-Intensität einzustellen und jut is' ...

Cheers!

Vor ein paar Tagen habe ich mich nun auch mal ein bisschen mit der 'teleblender-for-Poser'-Nummer auseinander gesetzt, insbesondere, weil einiges aus dem Poser10-'native'-Content partout nicht in D|S tut. (*grml* ... und da beklagen sich viele Hardcore-Poserianer über DAZ's Genesisen und so :gaehn ...)

Naja, tb und Poser ist zum aktuellen Zeitpunkt ja eher ein etwas stiefmütterlich behandeltes 'Side-Project' (wie auch die Carrara-Version) und der Workflow (wie auf der mCcasual-Seite beschrieben) vereinfacht nicht aaallzuviel im Vergleich zum 'gewöhnlichen' .OBJ Ex-und-Import. Kurz zusammengefasst: Szene als .OBJ und Collada-File exportieren, in Blender: das Objekt importieren und im Anschluss das blendbot-Script manuell ausführen, um die Materialien in Cycles-Nodes zu wandeln ... ich mutmaße, Blender-'Unkundige', die nur mal eben mit Cycles rendern möchten, können damit wohl schon an der ein oder anderen Ecke hängen bleiben ...

Allerdings wird auch auf ein Python-Script verwiesen, das 3dOutlaw vor längerer Zeit für #Poser verzapft hat und auf seiner Website zu haben ist: Poser OBJ Export to Cycles Hierbei handelt es sich um ein einzelnes direkt! aufrufbares Poser-Python-Script, das die Szene als .OBJ in einen Ordner der Wahl verfrachtet und auch alle verwendeten Texturen dazupackt. Ist der Blender-Programm-Pfad innerhalb des Scripts korrekt, wird anschließend Blender automatisch gestartet, das .OBJ importiert und mit Cycles-MATs vesehen. Darüber hinaus wird die aktuell in #Poser genutzte Kamera inklusive Bildformat/-größe übernommen und auch ein Umgebungslicht erzeugt (Blender's World-Settings). Damit wäre die Szene gewissermaßen schonmal 'ready-to-Render' ... naja zumindest iiirgendwie ...

Allerdings gibt's auch wieder ein paar Sachen, die dann doch noch erledigt werden müssen. Wie bei der D|S-Version von tb auch, werden die Materialien insbesondere in Bezug auf Glanzlichter etc. grob mit den im Script angegebenen Werten erstellt. Darüber hinaus werden Texturen nur für Diffuse, Bump und ggf. Transparenz angewendet. (Sachen wie Specularity- oder SSS-Maps etc. müssen später selbst eingestöpselt werden.) Es wird keine der Poser-Lichtquellen übernommen sondern tatsächlich nur ein Umgebungslicht erstellt, dessen Werte auch fix vom Script vorgegeben werden. Somit müssen Lichtquellen dann entweder nachträglich manuell eingefügt werden oder man ist mal gaaanz pfiffig und prostitu... *emm* ... positioniert in Poser ein paar einfache Planes, die später in Blender kurzerhand zu #Meshlights gemacht werden ...

Und es gibt noch eine Sache, die nicht so glücklich geregelt ist: die gesamte Szene ist in Blender lediglich ein einzelnes Objekt. Das kann zwar auch von Vorteil sein, wenn man nicht von der Anzahl der Einzelobjekte erschlagen werden möchte und bspw. nur einen Charakter mit Haaren, Klamotten und Props exportiert, aber komplexe Szenen sind dann schon ein bisschen fisselig, weil eben alles nur über Materialien geregelt wird. Das kann erfahrungsgemäß recht schnell unübersichtlich werden und bietet viel Chaos-Potential. Deshalb als kleiner Tipp: lediglich 'zusammen gehörende' Elemente (z.B. Charakter+Klamotten+Haare) exportieren, den Vorgang ggf. mehrfach für andere Szenen-Anteiile wiederholen und dann in Blender via Append wieder zusammenfügen. (Geometrie, die in Poser 'ausgeblendet' ist, wird btw. auch nicht exportiert. So kann man relativ einfach steuern, was nun jeweils exportiert werden soll.)

Leider hat das Poser-Script kein GUI, sodass alle Einstellungen direkt im Python-Script 'zu Fuß' angepasst werden müssen. Das Wichtigste ist vermutlich der Blender.exe-Pfad, der auf die korrekte Location verweisen sollte (siehe Anhang - entsprechend ändern!), so man direkt aus Poser starten will. Ansonsten befindet sich im Szenen-Export-Ordner auch eine .BAT-Datei, die bei Doppelklick Blender starten und die Szene importieren sollte. (Darin kann der Pfad auch nachträglich angepasst werden. Rechtsklick > Bearbeiten) Und wer ohnehin schonmal im Python-Script ist, kann vielleicht auch gleich noch die Farbe für's Umgebungslicht anpassen; ist 'by default' relativ stark gesättigtes Hellblau; ich bevorzuge für den Anfang ja eher ein Reinweiß oder so. :gaehn Lässt sich zwar auch in Blender einstellen, aber so spart man schon wieder ein paar Klicks.

Beim Download des Scripts speichert der Browser dieses möglicherweise als .TXT-Datei. Dann sollte .TXT in .PY umbenannt und das Script in den ScriptsMenu-Ordner des Haupt-Runtimes ([Poser-Programmordner]\Runtime\Python\poserScripts\ScriptsMenu\..) verfrachtet werden. Dann lässt es sich jederzeit aus Poser's Hauptmenü aufrufen. (Die Datei selbst kann im Übrigen auch in 'was-auch-immer-du-lustich-bist' unbenannt werden.)

Ich hatte ein paar Huddeleien mit der Skalierung, denn meine Vic4 war in Blender etwa 3,5 Meter groß. Das liegt - wie ich vermute - daran, dass ich die Maße in Poser generell auf metrische Skala umgestellt habe. So musste ich noch an ein paar zusätzlichen Parametern im Script drehen, aber das Blickfeld (FoV) passt dennoch nicht so recht (wie auch im Anhang zu sehen). Finde ich jedoch jetzt auch nicht sooo tragisch; Die Kamera zu verändern, ist ja (noch) eine der leichteren Übungen. Wer Poser's 'default' Maßsystem nutzt, dürfte in dieser Hinsicht wahrscheinlich keine Probleme haben (wobei das im Prinzip ja ohnehin keine allzu große Rolle spielen würde, so man die Szene 'einfach nur' rendern will).

Getestet mit Poser10 und mcjBlendBot 3.15

Anhang: Vic4 ... links in Poser10, rechts in Cycles (ohne dass ich an irgendetwas 'geschraubt' hätte ... einfach das Script aus Poser's Menü gestartet, im sich dann öffnenden Blender F12 gedrückt ... und stolz wie Oskar gewesen, weil's gleich auf Anhieb geklappt hat ...)

Nachtrag / Edit:

Ich habe noch einen Anhang beigefügt, der die 'default'-Render-Parameter zeigt, wie sie vom Exporter-Python-Script verwendet werden und wo sie überhaupt zu finden sind. Hier mit den Einstellungen, wie im Original vorgegeben. Passt man diese den eigenen Wünschen entsprechend an, erspart es in Blender vielleicht den ein oder anderen Klick. Kurze Erklärung: Blender verwendet für Parameter gewöhnlich ein '0-bis-1-System'. Das heißt, '0' entspricht 'Schwarz', '0%' oder auch '0' in RGB-Werten; '1' entspricht 'Weiß', '100%' oder auch '255' RGB, '0.5' wäre demnach ein 'mittleres Grau', '50%' oder '128' RGB.

setGloss ( Intensität/'Farbe', Weichheit/Roughness )
Der erste Wert bestimmt die Glanzlicht-Stärke, der Zweite die 'Unschärfe'. Blender/Cycles unterscheidet ja nicht zwischen Glanzlicht und Reflektion. Je geringer die 'Roughness' ist, desto 'spiegelnder' wird das Material. Höhere Werte 'verwischen' die Spiegelungen zu weichen Glanzlichtern. Werte, die sich im Laufe der Zeit für mich in der D|S-Version als gute Ausgangsbasis für Haut usw. erwiesen haben, sind ( 0.25, 0.5 ).

setRenderEngine
Hier könnte man im Prinzip auch eine andere Engine angeben, aber da sowohl dieses Skript als auch der BlendBot für Cycles ausgelegt ist, ist es eigentlich nur sinnig, diesen Parameter auch auf 'CYCLES' zu belassen.

setCyclesSettings ( Kernel, Prozessor, Typ, Samples )
Mit den Einstellungen, wie sie hier vorgegeben sind, rendert Cycles über CUDA-GPU mit experimentellem Kernel 100 Samples.

Der Kernel-Modus erlaubt die Werte 'EXPERIMENTAL' oder 'SUPPORTED'. Bei einem Poser-Charakter wäre die experimentelle Version erstmal eigentlich nur interessant, wenn man SSS über GPU rendern wollte. Da der Exporter jedoch keine SSS-MATs erstellt, ist es zunächst vielleicht eine gute Idee, den Parameter in 'SUPPORTED' zu ändern, weil dies das System weniger belastet. (Und da freut sich der Compi. ) Darüber hinaus bedeutet 'EXPERIMENTAL' eben auch genau das: experimentell, mit anderen Worten: u.U. unvorhersehbar und/oder etwas Bug-anfällig. :gaehn

Für den Prozessor kann zwischen 'CPU' und 'GPU' gewählt werden. Dieser Wert sollte sich vielleicht am ehesten an der Hardware-Ausstattung orientieren. Für GPU ist nicht der System-Arbeitsspeicher, sondern der Grafik-Speicher der genutzten GraKa relevant. Recht der Speicher nicht aus, meckert Cycles. Zur Orientierung: meine Demo-Vic4 verbraucht hier direkt nach dem Transfer knapp 700 Mb ... zum einen, weil jede Materialzone ein eigenes Material benutzt aber auch aufgrund verschwenderischer Poser-MAT-Presets, die unnötig viele unterschiedliche Texturen verbraten. Aber selbst mit reinem CPU-Rendering ist Cycles immernoch erheblich schneller, als Firefly. Der Prozessor-Typ ist natürlich nur bei 'GPU' relevant und es kann zwischen 'CUDA' (nVidia) und 'OPENCL' (ati) gewählt werden.

Die Anzahl der Samples ist hier Geschmackssache. Für Vorschauen reichen meist auch weniger aus. Bei der Vic4-Demo habe ich 64 genutzt (und bei mir auch als Standard-Wert für Previews featgelegt).

setSmooth ( True/False )
... schaltet die Polygonglättung global ein ('TRUE') oder aus ('FALSE'). Mein 'default'-Wert: 'TRUE'.

setEdgeSplit ( True/False )
... 'schneidet' das Mesh an schärferen Kanten, so dass diese auch 'scharf' bleiben und nicht mit geglättet werden. Dies ist in Blender ein 'Modifier', der auch nachträglich hinzugefügt oder entfernt werden kann. Da ich i.a.R. eher 'organische' Objekte aus Poser oder D|S transferiere, steht dieser Parameter bei mir auf 'FALSE', weil ich es irgendwann einfach leid war, bei jedem Objekt diesen Modifier von Hand abschalten/entfernen zu müssen.

setHorizonColor ( R, G, B, Stärke )
... legt sowohl die Farbe als auch die Helligkeit des erstellten Environment-Lights fest. '1.0, 1.0, 1.0, 1.0' wäre demnach 'Weiß' mit 100% Intensität (... wie auch in der Vic4-Demo genutzt).

~~
so far - so good - so long!

_{weitere Themen-bezogene Postings in diesem Thread:}

> alternative, bereits vordefinierte Umgebungsbeleuchtung in Blender's Startup-File

An dieser Stelle nun mal ein kleiner Erguss zum Thema Filmic! und Real-Camera in Blender, warum ich das einfach nur megacooL! finde und deshalb nie, nie, niiie! mehr 'ohne' sein möchte. :]  (Heieiei .. letzter Beitrag liegt run schon rund eineinhalb Jahre zurück .. meine Güte, wie die Zeit verrennt ..!)

Filmic!

.. ist - grob gesagt - ein erweitertes #Farbmangagement für Blender und führt das Programm nun auch in dieser Hinsicht ins 21. Jahrhundert .. indem die Szenen-Informationen für die Bildausgabe in einen anderen als den guten, alten sRGB-Farbraum konvertiert (oder hier: 'transformiert') werden.

Nein, ich werde den 'Beipackzettel' an dieser Stelle nicht wiederkäuen .. kann ja jeder selbst auf der entsprechenden Seite nachlesen und für ein tiefer-gehendes 'Studium' dieser Thematik liefert eine 'Filmic Blender'-Suche in der SuMa des Vertrauens tolle Ergebnisse. (Dabei aber ruhig darauf achten, dass nur Links der Blender-bezogenen Seiten besucht werden, denn entsprechende Themen in Communities anderer - auch 'großer' - Programme behandeln scheinbar lediglich das Thema: "Das will ich aber auch haben!" .. )

Ich beleuchte hier mal die praktische Seite ein wenig. Also: was macht das denn nun konkret?

Filmic erhöht im Prinzip den Bereich / Umfang der Helligkeiten, die in Blender abgebildet werden können auf (um die) 25 Blendenstufen. Das ist (glaub) rund das Fünffache dessen, was Blender von Hause aus schafft und etwa das eineinhalbfache des menschlichen Auges. Dadurch können bspw. Lichter in der Szene nun viel heller sein, ohne dass es zu 'Überbelichtungen' kommt. Dadurch erhöht sich quasi der 'Abstand' zwischen hellen und dunklen Bildanteilen, was wiederum eine generelle Kontraststeigerung zur Folge hat. Kurz gesagt: die Bilder werden 'knackiger'. (Dies ist btw. auch, was der Ausdruck 'High Dynamic Range' (=HDR) grob bedeutet.)

Bei der Real Camera

.. handelt es sich im Prinzip um sowas wie ein 'Frontend' für Blender's Standard-Kamera-Einstellungen mit - in erster Linie - einem gravierenden Unterschied: die Einstellungen für Blende, Verschlusszeit usw. haben auch tatsächlich einen direkten Einfluss auf die Belichtung des Bildes .. eben so, wie wir es auch von 'Echtwelt'-Kameras her kennen. Vorbei sind die Zeiten, in denen man fröhlich einfach-mal-so am F-stop-Wert schrauben konnte, um die Tiefenverunschärfung ein bisschen zu erhöhen, denn nun muss, so die Bildbelichtung letztendlich hinhauen soll, eben wie in der Realität auch bspw. mit der Verschlusszeit gegen-gesteuert werden. CooL! (Die einzelnen Parameter können alternativ aber nach wie vor auch unabhängig davon an den alt-bekannten Stellen vorgenommen werden und beeinflussen die Belichtung dann nicht.)

Die Real Camera greift dafür direkt auf die Farbmanagement-Daten zu, die mit Filmic kommen und somit ist dieses auch zwingend Voraussetzung.

Ich benutze mittlerweile beides standardmäßig in Kombination. :]

----

Na jut .. zurück zu Filmic! Theorie is' ja gut und schön, aber nu wird's auch mal Zeit für 'n paar bunte Bildchen.

Nicht vom Noise irritieren lassen!.. dazu komme ich später noch.

Lädt man eine bereits bestehende Szene, wird man auf den ersten Blick feststellen, dass sich u.U. erstmal gar nicht großartig etwas geändert hat. Die hellen Bereiche wirken etwas gedämpft, Stellen, die vielleicht ursprünglich leicht überstrahlten, tun's nun nicht mehr und dunklere Bildanteile erscheinen ggf. ein kleeeinwenig dunkler. Wie ausgeprägt diese Effekte sind, hängt natürlich in hohem Maße vom Ausgangsmaterial ab, aber i.a.R. stellt es sich mir schon so dar.

Blender-Standard vs. Filmic .. ohne irgendeine sonstige Parameter-Änderung

Was diesen ganzen Spaß jetzt soo 'toll' macht, ist im Grunde, dass die Stärke der Lichtquellen drastisch erhöht werden kann. Stärkere Lichtquellen = mehr direktes Licht (klar!) = mehr indirektes Licht (da den Lichtstrahlen aus 'energetischer' Sicht nicht so schnell 'die Puste ausgeht') = coooLe GI-Effekte.

In der Praxis konnte ich bei bereits-bestehenden Szenen i.a.R. die Stärke aller Lichtquellen locker auf das Doppelte bis 4-fache erhöhen. Wenn dann die Belichtung des Bildes entsprechend angepasst wird, landet man auch beinah wieder bei den Lichtverhältnissen aus der ursprünglichen Szenerie.

SunSky-Sonnen-Intensität verdoppelt, -Sky-Intensität vervierfacht und über die Bildbelichtung gegen-gesteuert, so dass es etwa auf gleichem Niveau ist.

Hier ist schon erkennbar, dass die Glanzlichter, die ursprünglich (links) nahe der Grenze zum 'Überstrahlen' waren, selbst durch diese erhöhten Lichtwerte in der Szene noch lääängst nicht an diesem Punkt sind. Außerdem wirkt das Ganze nun etwas kontrastreicher, weil sich im Prinzip der 'Abstand' zwischen direkt- und weniger- beleuchteten Bildbereichen erhöht hat.

Ein anderes neckisches Feature, auf das ich bisher noch gar nicht eingegangen bin, ist die ('automatische') Desaturierung (Farbentsättigung), je heller die Bildbereiche werden. Dies ist an und für sich ja ein bspw. aus der Fotografie bekannter (und u.U. verhasster ) 'Begleiteffekt', der im CGi-Bereich - wie viele andere Effekte dieser Kategorie auch - richtig klasse kommen kann. :]

Nix an der Szene selbst geändert, außer auf Filmic und Real Camera umszustellen ..

Desaturierung und leichte Kontrast-Erhöhung sind schon recht gut zu erkennen.

Na gut .. wieder zurück zur Lichtpower ..

Blender-Standard

vs.

Filmic + Real Cam .. mit gepimpten Beleuchtungs- und Belichtungswerten

Oookaaay .. zugegeben, die ursprüngliche Szene war nun natürlich auch 'n büsch'n duster, aber da war auch wirklich nicht mehr aaallzu viel Spielraum nach oben hin, bevor die direkten Sonnenlicht-'Einschläge' überstrahlt (ge-'clippt') hätten. Im Zweiten Bild ist dies noch längst nicht der Fall, auch wenn es auf den ersten Blick vielleicht den Anschein erwecken mag. .. da geht noch was!

Same here:

.. und da ist auch wieder dieses Bildrauschen (Noise)!

Nein, das sind keine #Fireflies, sondern ein Effekt der höheren Lichtstärken auf die volumetrischen ('atmosphärischen') Einstellungen in dieser Szene. Diese müssen nun von ihren Einstellungen her auch noch entsprechend 'nachjustiert' werden. Qualitätseinstellungen, die bisher 'noch vertretbar' waren, benötigen nun wohl - zumindest im ein oder anderen Fall - ein bisschen mehr Quali. :gaehn

Btw.: Filmic verändert nichts an den Daten in der Blender-Szene an sich, sondern lediglich, wie diese Daten für die letztendliche Bilddarstellung 'interpretiert' und umgewandelt / 'aufgearbeitet' werden.

Blender-Nutzer, die bisher die schicken, bunten 'Film(-Look)'-Einstellungen des Color-Managements gern genutzt haben, werden nun wahrscheinlich etwas enttäuscht sein, denn hier gibt es jetzt 'nur' noch Presets für unterschiedliche Kontrast-Kurven, eine einfache Graustufen-Konvertierung und 'Zusatz-Tools'. Somit wurde aus einem Spielzeug ein Werkzeug. :]

Für meinen - ganz persönlichen! - Geschmack haben sich bisher eigentlich drei unterschiedliche Kontrast-Variationen als richtig gut erwiesen:

'Base Contrast' .. wirkt für mich eigentlich seeehr ähnlich zu dem, wie ich es von Blender her gewohnt bin: recht soft und verhältnismäßig gleichförmig. War mir in der Vergangenheit häufiger schon ein bisschen 'zu' soft, deswegen entwickelt sich ..

'Medium High Contrast' .. mittlerweile auch zu so etwas wie meinem persönlichen Standard. Das Ganze hat einfach etwas mehr 'Pep'.

Ich stelle mir ja immer vor, wie es sich 'anfühlte', wenn ich nun in dieser Szene stünde und mir die Sonne direkt auf die Haut braten würde. Bei der ersten Kontrast-Version hätte ich noch das Gefühl, dass sie durch einen leichten Dunstschleier scheint, hier im zweiten Fall ist es ein (schöner,) warmer Sommertag.

Die dritte Variation ..

'High Contrast' .. wirkt für mich schon wieder eher, als wäre sie mit einer der etwas älteren GI-Render-Engines erstellt: eben nicht mehr gaaanz so 'natürlich' .. aber nichtsdestowenigertrotz cool, insbesondere, wenn man es etwas mehr auf 'Effekt' anlegt.

Alle drei haben imo für die unterschiedlichen (bestehenden) Szenen jeweils so ihre Vorteile und bisher habe ich sie auch alle eigentlich damit ver-Kontrast-iert. :]

----

Tjoa .. aber, wo Licht, da bekanntermaßen auch Schatten ..

Der gravierendste Nachteil bei dieser ganzen Sache ist, dass bestimmte Compositor-Nodes (in Teilen) für's erste nicht mehr verwendet werden können-sollten-dürfen, weil sie nach wie vor auf das 'alte', in Blender verwendete sRGB-Format basieren. Blöderweise sind dies aber genau diejenigenwelchen, die auch meist für die Mischung anderer Nodes verwendet werden (Mix-Node). Hier muss man nun andere Möglichkeiten aushecken, so man die 'echten' Filmic-HDR-Daten auch in der Bildexport-Datei erhalten möchte. (Näheres dazu findet sich auch in der Standard-Filmic-Beschreibung.)

Dies betrifft allerdings auch nur die Compositor-Nodes. Shader-Nodes bspw. sind hiervon nicht betroffen, da sie der ganzen Filmic-Geschichte ja quasi 'vorgeschaltet' sind und somit bei der letztendlichen Bilderstellung adäquat 'übersetzt' werden.

Die Real Camera kann u.U. schon ein bisschen durcheinander kommen, wenn sich diverse Kameras in einer Szene befinden und die RC für mehrere von diesenhiesen aktiviert/verwendet wird. Außerdem werden hier bei mir in der Version 2.x dieses Addons nicht die bereits bestehenden Kameradaten (Brennweite, Fokus, Blende) automatisch übernommen und müssen zu Fuß nachgetragen werden. Das war in Version 1.x noch anders.

In diesem Sinne ..

Häbbie (re-)CYCLing!

Nachtrag | Anmerkung

btw. funktioniert Filmic! auch hervorragend im Zusammenspiel mit externen Renderengines, die das Bild in Blender selbst ausgeben (wie bspw. Mitsuba).

* Mistuba-Folikel-Testszene aus dem alten Posting etwas überarbeitet und mit Filmic! gerendert

Buntes Allerlei No.1 :: Tipps, Tricks, Anmerkungen und Updates zu vorangegangenen Beiträgen ::

Mal ein kleiner Hinweis in Bezug auf teleblender für Poser ..

Da ich in jüngster Zeit mal wieder desöfteren über das Poserskript nach b|Cycles exportierte, hab' ich eine höchst-erfreuliche Entdeckung gemacht.

Wenn Blender nach dem Export aus Poser startet, wird als 'Augangsszene' ja das normale Startfile von Blender verwendet .. also, im einfachsten Fall, die klassische Würfel-Szene, die immerwährend allerwelt Herzen mit Freude erfüllt.. Wird diese 'Default'-Szene nun ganz allgemein den eigenen Wünschen entsprechend angepasst und wieder als solche gespeichert, sind diese Veränderungen auch nach dem Poser-Export standardmäßig am Start. CooL!.. denn dies eröffnet - je nach Blender-Kenntnisstand - natürlich schon viele wunderbare Möglichkeiten ..

.. an dieser Stelle nur mal eine kleine Spielerei in Bezug auf die Umgebungs-Beleuchtung.

Wie im o.g. Beitrag erwähnt, kann im Export-Skript lediglich Farbe und Intensität der 'World'- Umgebungs-Beleuchtung festgelegt werden. Wird die Blender-Startdatei nun jedoch dahingehend verändert, dass man dort bereits eine Umgebungsbeleuchtung definiert - vielleicht durch eine Sky-Textur oder Bild-Umgebungsmap - werden die im Skript definierten Werte komplett übergangen. :] Somit startet Blender/Cycles dann auch sofort bspw. mit einer HDR-Environment-Textur .. wie in diesen Fällen:

* Miki2 direkt nach dem Export aus Poser, lediglich auf die Real Camera umgestellt und mit Filmic! gerendert

Dazu 'einfach' mal Blender starten, den 'World'-Settings-Tab im Parameters-Panel wählen (die Weltkugel / viertes Icon von Links) und dort unter 'Surface' zunächst 'Background' und anschließend im sich darunter auftunden 'Color'-Feld entweder 'Sky Texture' (für die Blender-interne SunSky-typische Himmels-Textur) oder 'Environment Texture' zum Laden einer beliebigen Bilddatei (vozugsweise einer sphärischen HDR-Umgebungstextur) in den Umgebungs-Beleuchtungs-Kanal festlegen.

Danach muss nur noch die Szene als Startdatei festgelegt werden (Blender-Hauptmenü > File > Save Startup File) und wir sind dauerhaft im Geschäft.

Wer sich hier zumindest ein bisschen auskennt, kann im Node-Editor natürlich auch ein etwas erweitertes Setup erstellen, um bspw. die Möglichkeit zu haben, die HDR-Textur rotieren oder deren Gamma-Werte verändern zu können (unterer Abschnitt im Screenie). Und bei dieser Gelegenheit könnte man nun auch gleich mal den fetzigen Würfel löschen und/oder die Render-Einstellungen ganz allgemein etwas präziser den eigenen Standards entsprechend anpassen. Auch diese kommen dann i.a.R. eigentlich immer gleich nach dem Poser-Export zum Tragen. :]

In diesem Sinne: häbbie reCYCLing!

Weil Kushanku in einem Galeriebild das Thema Bodentextur zur Sprache brachte, poste ich hier mal das Node-Setup ebenjenigenwelcher, wie sie von mir in dem Bild verwendet wurde. (Urprünglich stammte das Basis-Setup aus einem BlendFile, in dem es allerdings primär um etwas anderes ging, weshalb ich gerade auch nicht sagen kann, wer es verbrochen hat. Stammte - glaub' -seinerzeit von BlendSwap. Ist aber eh auch eines von diesen Materialien, die bei mir im Laufe der Zeit immer weiter-evolutuionieren =).. und deshalb ohnehin schon ein gutes Stück weit vom Original entfernt.)

Also, im Groben sieht dat Dingens so aus:

.. aber da der Screen nicht gerade der Übersichtlichste ist und zudem Node-Groups enthält, bei denen die Node-Struktur auch nicht unbedingt auf 'nem Screenshot klar ersichtlich ist, mach' ich's mir ganz ungeniert leicht und hänge ein Dummy-.blend-File mit an, in dem das Material auf dem schicken Blenderwürfel klebt.

Da lässt der ganze Spaß dann ggf. mal in aller Ruhe angucken.