Node Editor Iray / Octane

Es gibt 37 Antworten in diesem Thema. Der letzte Beitrag () ist von esha.

  • Programme: 

    Iray in DS

    Octane in DS

    Gilt aber auch für die meisten anderen Node basierten Rendermaschinen



    Das von esha gepostete Bild in maXem's Tread hatte mich verwundertt, also habe ich mir den Iray Node Editor in DS genauer angesehen,

    weil ich fast nur Octane nutze, andererseits aber nicht recht glauben wollte, dass der Iray Editor so unkonfortabel sein soll.


    Erste Erkenntnis: doch, ist er leider. Ob das an der Zwangsintegrierung in DAZ Studio liegt oder Nvidia nichts besseres

    zustande gebracht hat, weiß ich nicht. Letzteres ist für mich schwer vorstellbar. Sehr schade für eine ansonsten sehr gute Rendermaschine.



    Node Editoren


    Gute Node Editoren sollten so aussehen wie in Vray, Modo, Octane, Blender, Vue, Terragen4, usw. usw. ...

    Und mit Ausnahme von vielleicht Terragen, sind sie sich in Sachen Auftritt und Handhabung alle ähnlich und man findet sich schnell zurecht.

    Eigentlich logisch, denn es geht immer nur um Material (Shader) und das hat nun mal - weil von der Natur vorgegeben - fast immer die gleichen Eigenschaften, egal in welchem Programm.


    Die folgenden Bilder von Octane sollen nur die Editor Schematik bzw. den Workflow zeigen, welcher auch in anderen Engines ähnlich anzutreffen ist.

    Also keine Octane Werbung, welche auch unnötig wäre, da Vray und Octane ohnehin die derzeit populärsten Rendermaschinen sind.

    Wobei Vray noch eine Stufe höher (auch im Preis) anzusiedeln ist, weil aktueller Industriestandard.




    Zuerst mal Octane, um zu zeigen wie ein Editor funktionieren kann, dann Iray...

    Octane

    Zunächst wähle ich unter Materials (1) eine Materialzone aus, also den Bereich eines Objektes, den ich oberflächentechnisch bearbeiten will.




    Dies kann ich manuell tun, unter Octane Render Materials (2) oder in den Scene Surfaces (3), oder aber - und damit intuitiv - direkt via Mausklick in den offenen Rend View.

    Der Editor zeigt mir dann den jetzt markierten Shader und die zugehörige Materialzone (Torso).

    Rechts außen wird gleichzeitig der gesamte Shader (4) mit all seinen Kanälen in der klassischen Listenform angezeigt. Und ein MK3 Skin Shader wie von RedSpec

    hat es nun mal in sich. Wenn ich die Liste rechts runter scrolle folgen 13 weitere Listenseiten. Übersichtlich und Anwender freundlich ist das nicht.




    Nun den Knopf "Node Graph Editor" gedrückt und schon änder sich das Bild.




    Wir sehen den gesamten Shader in einer grafischen Darstellung und damit gleichzeitig auch die Zusammenhänge in der Struktur,

    wer wo dranhängt und was beeinflusst. Die 13 Seiten Shader Kanäle sind in eine Grafik verwandelt. Die Liste rechts ist aber nach wie vor vollumfänglich.




    Ein Click auf einen der Shader Nodes ändert das. Aktiviere ich z.B. mittels Mausklick den Bump Node, respektive Shader Kanal (2)...




    ...zeigen sich rechts (1) auch nur noch die Kanäle, welche zu diesem Node, also der Bump Funktion gehören, welche ich nun ungestört bearbeiten kann.



    Natürlich kann ich in den Editor via Mausrad auch hinein zoomen oder die Grafik direkt mit dem Coursor verschieben. Übrigens ebenso das Bild im laufenden Render View,

    ohne das der laufende Render unterbrochen wird. Beides sehr hilfreich, wenn Shader und/oder die Gesamtszene komplex sind.






    Wem jetzt das reine justieren der Shader nicht genügt und er einzelne Kanäle erweitern will, oder gar komplett eigenen Shader basteln möchte, ...




    ...findet er alles dazu im aufklappbaren Slide Fensterlinks (1) aus dem via drag and drop jeder zusätzliche Node in den Editor gezogen werden kann.

    z.B. hier ein Metall Shader Node (2). Vorhandene Nodes lassen sich natürlich auch löschen oder kopieren und noch vieles mehr.

    Beim verkuppeln der Shader Nodes (alles via Maus Click) helfen a) die Farben zueinander passender Anschlüsse

    und b) das automatische Verweigern sinnloser Verbindungen. Man kann also nichts kaputt machen :S

    Und wichtig natürlich, jede Änderung wird sofort im Live Render View sichtbar.


    Und wie man Regler in einem Shader Kanals verstellt oder Knöpfe an und abschaltet, brauchen wir hier wohl nicht zu erklären.


    So verstehe ich ein Werkzeug für intuitive Shader Bearbeitung .


    Iray


    Iray hat sicher alles um das genauso gut zu können, nur wurde es leider nicht umgesetzt. Zumindest nicht in der DS Version.


    Derselbe Shader wie oben (sogar ohne die Redspec Erweiterung) sieht in Iray so aus...



    Kein Wunder das esha ins Schwitzen kam und wir Amateure gleich mal den Bildschirm abschalten um nachzuschauen ob auch nix kaputt gegangen ist.

    Die Bearbeitung im Iray "Shader Mixer" (Node Editor) scheitert schon an der Unmöglichkeit hier irgendetwas zu erkennen.

    Shader/ Texte sind in der Gesamtsicht nicht erkennbar/lesbar und zoome ich hinein sehe ich nicht mehr womit der Kanal

    irgendwo am anderen Ende verbunden ist.


    Des Weiteren wird die Surfaces Liste nicht auf den aktuell aktiven Shader Kanal reduziert. An der Sucherei änders sich nichts.

    Dafür kann man (teilweise) die Verstellungen direkt im Node vornehmen. Auch eine Lösung. Is in Blender glaube ich ähnlich.


    Es gibt haufenweise "Bricks" (Shader Nodes) in dieser Darstellung, die ohne ersichtliche Funktion sind.

    Zeigt Iray hier einfach alle Nodes die möglich wären, egal ob aktiv oder nicht? Daher vielleicht dieses Chaos?



    Solange ich einen einfachen und damit übersichtlichen Shader bearbeiten will wie hier zu sehen, ...




    ...funktioniert der Iray Editor von der Sache her gut, wenn auch viele der oben gezeigten Möglichkeiten nicht gegeben sind und etliche Funktionen wirkungslos bleiben.

    Aber für einfache Shader braucht niemand einen grafischen Editor. Dafür reicht die klassische Surfaces Liste. Bei komplexen Shadern spielen Node Editoren ihre Stärke aus.


    Was mir auffällt ist, dass Iray weit aus mehr "Bricks" (Node Typen) als Octane zur Verfügung stellt. Was vielleicht auch eine Erklärung für das Chaos im Editor sein könnte.

    Möglicherweise splittet Iray die Shader weiter auf als es z.B. Octane tut, weil Iray - ähnlich wie Vray - eine Rendermaschine mit mehr Kontrollmöglichkeiten ist, was von CGI Profis für spezielle Projekt bisweilen gefordert wird, aber den Hobbyisten in Schwierigkeiten bringt.


    Wie auch immer, bei der Integration von Iray in DS hat man wohl kein großes Interesse daran gehabt, dem Anwender ein intuitives Materialwerkzeug in die Hände zu geben.

    Die fehlende Bedienungsanleitung für den DS "Shader Mixer" bestätigt diesen Verdacht.

  • Interessanter Vergleich!


    Hier noch ein paar Dinge zur Erklärung für DS:


    Zoomen mit dem Mausrad geht im Shader Mixer durchaus, man muss nur wissen wie ;)

    Strg-Mausrad = zoom

    nur Mausrad = vertikales Scrollen

    Alt-Mausrad = horizontales Scrollen


    Und ja, beim Shader-Import in DS kommen auch unbenutzte Nodes mit, allerdings nicht alle.

    Der Iray Uber Shader besteht ja aus mehreren Layern: Base, Metallic Flakes und Top Coat. Wenn Metallic Flakes und/oder Top Coat nicht aktiv sind, werden sie beim Import ignoriert. Alle anderen Channels werden aber importiert, egal ob sie in Benutzung sind oder nicht.


    Mir scheint übrigens auch, dass der Octane-Shader etwas simplifiziert ist. Im DS Shader Mixer hast du wirklich Kontrolle über alles, bis hin zum Tiling und Offset für jede einzelne Map - dafür wird es dann aber auch sehr kompliziert. :rolleyes2:


    Fairerweise muss man sagen, dass ein "Normalanwender" gar nie in den Shadermixer muss. Der Iray Uber Shader bietet so viele Möglichkeiten, dass man das allermeiste damit machen kann, besonders wenn man 2D-Texturen verwendet. Daz bewirbt den Shader Mixer auch gar nicht. Ich persönlich habe den Verdacht, dass der mehr als internes Tool gedacht war, das halt irgendwann auch für die User zugänglich gemacht wurde, weil einige Vendoren drum gebeten haben. Das Tab hatte lange Zeit hindurch auch noch den Vermerk -Beta- drauf stehen. Das ist zwar jetzt weg, und er ist tatsächlich auch stabiler als früher, aber der Shader Mixer ist eigentlich gar nicht für die User gedacht (und der Shader Builder erst recht nicht).

  • Erste Erkenntnis: doch, ist er leider. Ob das an der Zwangsintegrierung in DAZ Studio liegt oder Nvidia nichts besseres

    zustande gebracht hat, weiß ich nicht.

    Sie wollen ja tonnenweise Shader verkaufen, und wenn's jeder könnte.... :D


    Gute Node Editoren sollten so aussehen wie in Vray, Modo, Octane, Blender, Vue, Terragen4, usw. usw. ...

    jenau!

    Im DS Shader Mixer hast du wirklich Kontrolle über alles, bis hin zum Tiling und Offset für jede einzelne Map - dafür wird es dann aber auch sehr kompliziert.

    Das hat man in Octane natürlich auch - nur etwas unkomplizierter ;)

  • Sie wollen ja tonnenweise Shader verkaufen, und wenn's jeder könnte....

    Jo, da ist natürlich auch was dran. Wir Vendors freuen uns natürlich, wenn sie uns eine Marktlücke offen lassen *g*


    Allerdings sind die meisten der "Shader", die auf Daz verkauft werden, nur Presets für den ganz normalen Iray Uber Shader. Wie es aussieht, wollen sich die meisten User nicht einmal mit den bereits vorhandenen, eigentlich recht benutzerfreundlichen Shader-Slots auseinander setzen ... :rolleyes:

  • Zoomen mit dem Mausrad geht im Shader Mixer durchaus, man muss nur wissen wie ;)

    Strg-Mausrad = zoom

    nur Mausrad = vertikales Scrollen

    Alt-Mausrad = horizontales Scrollen

    Danke für den Tip esha :) und im Post korrigiert...

    Wie Ehliasys schon anmerkte, gibt es bei der Transformation von Texturen (Tillig, Tesselation etc.) in Octane mehrere Möglichkeiten.

    Das ist aber glaube ich auch allerunterstes Grundvermögen einer jeden Material fähigen 3D Software ;)

  • Die Bearbeitung im Iray "Shader Mixer" (Node Editor) scheitert schon an der Unmöglichkeit hier irgendetwas zu erkennen.

    Joa, das ist wahr:gaehn .. D|S'ns Shader-Mixer ist nicht unbedingt einer der übersichtlichsten Node-Editoren. =)


    Aber das hat auch viel damit zu tun, was man hier wie bearbeiten möchte.

    Importiert man bspw. einen der D|S-Uber-Shader, die ja selbst schon sehr komplex sind, hat man natürlich bereits ein echtes Monster von Basis-Node. Häufig ist dann auch viel Kram dabei den man für das aktuelle Vorhaben vielleicht gar nicht bräuchte. Deshalb ist sowas IMHO auch hier in D|S nicht unbedingt das Mittel der Wahl. Sowas geht vielleicht noch (gerade so eben), wenn man (wie etwa in esha's Gem-Shader-Beispiel) lediglich die Inputs mit prozeduralen Texturen befüttern, ansonsten jedoch die 'normale Funktionalität' erhalten will.


    Kleines Beispiel .. Gradient-Inputs in D|S-3DL-Basis-Shader:



    Aber für Zwecke, wie bspw. esha's Gemshader, würde üüch wohl ohnehin eher einen neuen Shader erstellen, der tatsächlich nur das beinhaltet, was gerade gebraucht wird. (Ich leiere an dieser Stelle mal wieder einen immer und immer wieder von mir gern genutzten Spruch 'runter: "So viel wie nötig - so wenig wie möglich!")


    Im Gem-Shader-Fall wären vielleicht sogar zwei separate Shader sinnvoll: einen basierend auf Glas-mit-Absorbtion für kristalline Geschichten und einen Diffuse/SSS-mit-Coating für eher diffus wirkende Materialien. Das macht den ganzen Spaß schon deutlich übersichtlicher. Setzt allerdings auch ein gewisses Know-How voraus, weshalb ich eigentlich auch der Meinung bin, dass D|S'ns Shader-Mixer nun nicht unbedingt als 'Einsteiger-freundliches' Materrialsystem zu betrachten ist. =)


    Ein anderer - nicht ganz unwichtiger - Punkt ist, dass die Kanalinputs der einzelnen Shader-Kanäle durch die Natur des Kanals selbst beschränkt sind. Dadurch sind die Möglichkeiten dessen, was man dort einstöpseln kann eben schon stark begrenzt. Ja, ich weiß .. klingt erstmal 'n bisschen unverständlich:schiel .. deshalb mal ein kleines Beispiel: ich hatte daamaals (allerdings noch für D|S-3DL) das Problem, dass ich mit dem 3DL-Basisshader ein TraLu-Mat erstellen wollte, was soo erstmal partout nicht funktionieren wollte. (Shader-Nodes: Wohin mit der Translucency?) Mittlerweile weiß ich natürlich auch, wieso: der Basis-Shader hat(te) keinen Kanal, der Transluzenz 'verstehen' oder 'verarbeiten' konnte. Völlig egal, was ich nun bspw. in einen diffusen Kanal einstöpsle (SSS, TraLu oder was-auch-immer) wird letztendlich durch die eigentliche 'diffuse' Kanaleigenschaft reinterpretiert, was also heißt, am Ende ist es eben doch bestenfalls wieder ein diffuses Material. Hat mich seinerzeit ziemlich Nerven gekostet, erstmal herauszufinden, dass das soo nicht funzen kann:gaehn..)


    Soll also die Funktionalität eines Shaders über dessen bereits vorhandene Schattierungsmöglichkeiten hinaus erweitert werden, wird es ohnehin nötig, die Grundstruktur von Vorne herein anders zu gestalten.


    Bsp. oben erwähnter TraLu-Shader ohne D|S-Basis-Shader-Brick:


  • Hier mal ein Gegenbeispiel:


    Gefordert: ein alter Spiegel, der an den Rändern schon erblindet ist.

    In Octane braucht's dafür keinen Node-Albtraum...

    Das versteh ich unter Einfachheit und Übersichtlichkeit :)



  • Aber für Zwecke, wie bspw. esha's Gemshader, würde üüch wohl ohnehin eher einen neuen Shader erstellen, der tatsächlich nur das beinhaltet, was gerade gebraucht wird. (Ich leiere an dieser Stelle mal wieder einen immer und immer wieder von mir gern genutzten Spruch 'runter: "So viel wie nötig - so wenig wie möglich!")

    Wenn es nur darum geht, ein bestimmtes Material zu reproduzieren, hast du eindeutig recht. Aber bei DS-Shadern wollen die Kunden immer gern alle Kanäle zur Verfügung haben, also muss auch alles drin sein. Da muss es eben die Möglichkeit geben, Glas mit Emission und Metallic Flakes zu kombinieren usw.


    Soweit ich gehört habe, ist es in DS auch ressourcenschonender, denselben Grundshader (natürlich mit verschiedenen Einstellungen) bzw. nur einige wenige Shader in der gesamten Szene zu verwenden als für jedes Material einen eigenen, spezifischen Shader zu verwenden. Aber wie genau da die technische Erklärung ist, weiß ich nicht, da müsste ich nochmal nachfragen.

  • Den Spiegel krieg ich bestimmt als IRAY T'n'E-User hin, ganz ohne Node Editor... solange man nicht zu faul ist, sich die Map zu malen, was mit Gimp keine fünf Minuten dauert.


    Grundsätzlich wird hier jeder verteidigen, womit er selbst am besten parat kommt. Ich hab kein Problem mit Kanal-Listen, insbesondere, da man sie in DS ja direkt anwählen kann, ohne ewig scrollen zu müssen. Wenn ich natürlich einen angepassten Shader brauche, hab ich ein Problem, ja. Aber dann a) probier ich solang rum, bis ich es hinkriege, b) frage jemanden, der sich mit dem Shader Mixer auskennt oder c) lasse ich schlimmstenfalls das Bild oder schwenke auf eine mir bekannte, wenn auch nicht hundertprozentig passende Lösung (wie Postwork) um.


    Daher wäre es mir lieb, wenn wir dieses "X ist besser als Y" lassen und uns auf die Funktionalitäten konzentrieren könnten. "Kann mir nun jemand den Node Editor der jeweiligen Engine erklären oder nicht?" sollte die Frage des Threads sein, nicht "welche Engine hat die dickeren Shader-Eier?"

  • Es geht nicht darum wer die "dickeren Shader-Eier" hat, was immer das bedeuten mag, es geht ums Bedienkonzept. Man kann's einfach und benutzerfreundlich halten wie in Cycles, Octane oder Vue, oder man präsentiert sowas wie im DS-Beispiel oben - oder auch Posers unsäglichem Firerfly Materialraum. Für mich jedenfalls ist klar, wo das Herumwerkeln mit Shadern mehr Spass macht. ;)

  • Es ist für dich einfacher, weil du es gewohnt bist, damit zu arbeiten. Wenn man einen so komplexen Shader wie den IRAY Basis-Shader aufbaut, dann wird das wohl so ziemlich überall ein ziemliches Wirrwarr geben, wenn man sich alles auf einmal anschaut.

    Jemand, der sich mit dem DS-Shader-Mixer gut auskennt, kennt vielleicht auch die nicht auf Anhieb ersichtlichen Möglichkeiten der UI - wir haben hier nur niemanden, der das kann, und da es eigentlich kein Feature gedacht für die breite Nutzermasse ist, fehlen entsprechend auch die Tutorials im Netz.


    Worum es mir ging, ist eben die persönliche Präferenz beiseite zu lassen und sich statt dessen auf die Funktionalität des jeweiligen Features zu konzentrieren. Ich hab aus diesem Thread jetzt bisher nur mitgenommen, dass jemand, der mit einer anderen Engine arbeitet, mit dem Shader Mixer nicht so gut zurecht kommt. Tut mir leid, aber DAS hatte ich irgendwie erwartet... Irgendeinen Fakt, wie man das Ding nun bedient, hab ich noch nicht gefunden. Und das wäre eigentlich die viel wertvollere Information für mich, als mich zum X-ten Mal darüber informieren zu lassen, dass ich, wenn ich weitere 300-600$ ausgebe, mich noch mal in ein neues Programm mit neuen Shadermöglichkeiten einarbeite und summa summarum beiseite schiebe, womit ich seit 10 Jahren gewohnt bin, zu arbeiten, vielleicht mehr machen kann - wobei ich bei dene, die gut mit Iray umgehen können, und denen, die gut mit Octane umgehen können, in der Qualität der Bilder jetzt nicht so den Unterschied erkennen kann.


    Erklär mir, wie es funktioniert. Dass du Octane lieber magst, weiß ich jetzt schon.

  • wir haben hier nur niemanden, der das kann, und da es eigentlich kein Feature gedacht für die breite Nutzermasse ist

    Warum eigentlich nicht, hm?

    Irgendeinen Fakt, wie man das Ding nun bedient, hab ich noch nicht gefunden.

    Darum geht's in diesem Thread ja auch nicht. Thema ist doch der Vergleich der Node-Editoren und nicht ein Tutorial.

  • Aber für Zwecke, wie bspw. esha's Gemshader, würde üüch wohl ohnehin eher einen neuen Shader erstellen, der tatsächlich nur das beinhaltet, was gerade gebraucht wird. ... 


    ...vielleicht sogar zwei separate Shader sinnvoll: einen basierend auf Glas-mit-Absorbtion für kristalline Geschichten und einen Diffuse/SSS-mit-Coating für eher diffus wirkende Materialien. ...

    Yop, würde ich genauso machen. Die Kombi mit Diffuse Shader liefert dann auch gleich die Option das Teil leuchten zu lassen,

    also Neonröhre und ähnlichen "Glow" Gedönskram. Wobei in Octane darauf zu achten ist für die Emission nicht das RGB- sondern das Gaussian Spektrum

    zu verwenden, da bei höheren Watt Zahlen ansonsten nur grelles Weiß emittiert wird. Muss nicht für Iray gelten.


    Dein DS Shader Beispiel im ersten Bild sieht übrigens sehr übersichtlich aus. Damit kann man arbeiten. :thumbsup:

  • Hier werden auch zum Teil Äpfel mit Birnen verglichen.

    Der Screenshot von meinem Shader ist sowas wie die eierlegende Wollmilchsau in prozedural. Der enthält alle Channels des Uber-Shaders plus zahlreiche Kontrollen für die prozeduralen Funktionen. Daher ist er auch so komplex. Niemand wird je alle Channels auf einmal verwenden, aber falls das doch mal jemand wollen sollte, geht es.

    Für ein einfaches Material wie z.B. einen Spiegel ginge auch ein einfacheres Setup. Nur tut sich für sowas niemand die Arbeit an, einen extra Shader dafür zu erstellen, weil es mit dem Standard-Uber-Shader viel schneller geht.

    Das mag auch einer der Gründe sein, warum es kaum Tuts für den Shader Mixer gibt - weil es in 95% der Fälle gar nicht notwendig ist, einen eigenen Shader aufzusetzen.


    Einen wirklich fairen Vergleich könnte nur jemand anstellen, der sich mit beiden Shadersystemen gleich gut auskennt. Aber wer Octane bevorzugt, hat meist kaum mit den DS-Shadern gearbeitet und umgekehrt. Ich verwende Octane nicht, weil ich für den Daz-Shop Iray Shader liefern muss.

    Wie ist das eigentlich in Octane, wie ist da der Workflow beim Aufsetzen eines Materials? Kommt das mit einem Standard-Shader-Setup, das in den meisten Fällen ohne Änderung funktioniert? Oder muss man immer bei Null anfangen so wie damals im Poser-Materialraum?


    Da wären wir auch schon wieder beim Bedienkonzept:

    Für Iray in DS braucht man eigentlich überhaupt keine Ahnung von Shader Nodes, Bricks usw. zu haben. Als "Normaluser" muss man den Shader Mixer gar nie öffnen. Man lädt per drag & drop die gewünschten Texturen in die Slots im Surface Tab und fertig. Ich finde das sehr praktisch, dass ich nicht für jedes Material einen Shader zusammenstellen muss. =) Das hat mich nämlich in Poserzeiten immer so genervt.
    Der Shader Mixer ist eher sowas wie das Skript IDE Tab: ein nettes Extra für Leute, die gern basteln, aber für den Normal-User gar nicht notwendig.

  • Der Shader Mixer ist eher sowas wie das Skript IDE Tab: ein nettes Extra für Leute, die gern basteln, aber für den Normal-User gar nicht notwendig.

    Womit wir beim Thema "Warum eigentlich [kein Feature für die breite Nutzermasse]" wären: DS ist so aufgesetzt, dass selbst das Mausschubser-Männchen/-fräuchen à la "ICH HABE DAS INTERNET GELÖSCHT!!" es einigermaßen bedienen kann, um damit halbwegs brauchbare Bilder zusammenzukriegen. Wenn man den leicht hinkenden Vergleich heranziehen will: es ist wie Windoof, DAU-sicher. Die Shader-self-Setups wären aber schon eher was für den versierten Unix-User.


    In DS reicht "ich klick meine Textur rein" für die Hausmütterchen/-väterchen-Nachmittags-Kreativität nach dem Motto "Papierblumen an Faden kleben" aus. Wer die Papierblumen noch selber ausschneiden will, beschäftigt sich mit den Shader-Channels und macht seine Posen und Licht-Setups selber. Und wer das Papier noch selbst erfinden will, bastelt sich seine eigenen Klamotten, Charaktere und Shader. Für ein anständiges Bild reicht alles davon. Aber der Sprung, gerade im 3D-Bereich, zum "Papier selbst machen" ist, gerade für DS-User, meiner Meinung nach nur selten den Aufwand wert. Es gibt massig guten Content, der sich mit ein bisschen Phantasie, Shadern (oder dem Wissen um die Channels und dem Willen, ne kleine Map selbst zu pinseln) und den mit DS mitgelieferten Möglichkeiten wie Dformern, Dforce, Geometry Editor und Geometry Shells in den allermeisten Fällen irgendwie zu dem verbasteln lässt, was man will, oder doch wenigstens auf 90% rankommt. Und für die 10% mach ich mir die Arbeit nicht, einen ganz eigenen Shader zu erstellen. Vor allem dann nicht, wenn ich wiederum 80% der fehlenden 10% per Postwork erledigen kann.


    DS richtet sich vor allem an Hobbyisten. Ich finds gut, dass auch Profis es benutzen können, und DAZ die User eben nicht nur mit dem vorgefertigten Kram abspeist, sondern ihnen die Möglichkeiten gibt, zu fummeln und zu probieren. Aber die ganz-ganz-ganz Selbstmacher sind nun mal nicht der Fokus der Software.

  • :D Danke. Es heißt allerdings nicht, dass ich nicht gern wüsste, wie der Shader Mixer funktioniert. Wenn ich nicht tiefer in die Materie einsteigen wollen würde, wäre ich hier im Thread nicht unterwegs. Dann hätte ich mich auch nie mit Dform-Weightmaps und Dforce beschäftigt. Dass ich es (wahrscheinlich) extrem selten nutzen würde, heißt nicht, dass ich es nie nutzte - wenn ich es könnte.


    Wenn nie Grammatiken und Wörterbücher entwickelt worden wären, hätten eine Menge Leute nie eine andere Sprache gelernt, und erst recht viele nie die Schönheit der Shakespearischen Sonette in ihrer Originalsprache bewundert. Man braucht einmal eine Bedienungsanleitung, um feststellen zu können, ob man ein Feature nie, selten, einigermaßen oder gern benutzen würde.


    Und diese Tutorials, die fehlen für den Shader Mixer leider ziemlich. Für fast alles andere findet man ja was, selbst für so komische Sachen wie den Iray Decal Node oder so. Da ist das Prinzip auch einfach zu verstehen.

    Was ich eigentlich bräuchte, wäre

    a) Wie baut man einen normalen Shader auf? (Also die Logik / der Workflow hinter einem Node Editor - hab noch nie gelernt, mit sowas umzugehen.)

    b) eine Liste der Bricks mit "Was kann ich damit ändern?", "Was kann ich einstöpseln?", "Wo stöpsel ich das ein?"
    Das würde mir schon reichen. Rumprobieren kann ich dann selber, mach ich auch gern. Aber mir fehlt völlig ein Anfang.

  • Ich meine mal gelesen zu haben, dass man zumindest das, was angestöpselt wird, angeblich am Buchstaben des Stöpsels erkennt - B = Boolean (wahr/falsch), F = Function (afaik ein Zahlenwert), C = Color (ein Bildwert? oder nur die Farben?) Aber mich dann damit zurechtzufinden - großes Nope.

  • Der Shader Mixer ist eher sowas wie das Skript IDE Tab: ein nettes Extra für Leute, die gern basteln, aber für den Normal-User gar nicht notwendig.

    Jap, sehe ich auch so. =)


    Und ich kann auch sehr gut nachvollziehen, warum du den Uber-Shader als Basis genommen hast. Immerhin geht es dir ja tatsächlich in erster Linie auch darum, als Vendor ein möglichst 'kundenfreundliches Bedienkonzept' zu liefern und wir sind doch alle auch froh, wenn wir auf's Surface-Tab klicken und ein vertrautes Bild vor Augen haben. War also meinerseits auch nicht als 'Nörgelei' gedacht. =) .. im Gegentum: ich mag es sehr, wie du die Sachen so handhabst und wünschte, andere Vendors würden es genauso handhaben ..


    Aber ich denke ja auch, dass du hier durch deinen Job bedingt, auch eher eine der Ausnahmen bist. Ich sehe die Shader-Mixer-Themen hier z.B. eher aus der Perspektive eines 'Endanwenders', also derjenigenwelchen Leute, die - gäbe es deutlich mehr davon - hart arbeitende Menschen wie dich um ihr täglich Brot bringen würden, weil eben schlichtweg kein Bedarf an derlei Produkten besteht.

  • Wobei in Octane darauf zu achten ist für die Emission nicht das RGB- sondern das Gaussian Spektrum zu verwenden, da bei höheren Watt Zahlen ansonsten nur grelles Weiß emittiert wird.

    Hm .. ja .. RGB-Farben sollten für Lichtemissionen in PBREs ohnehin nicht wirklich das Mittel der Wahl sein .. sind für Rendering im HDR-Bereich 'nach oben hin' schlichtweg viiiel zu beschränkt. Das kann man zwar schon für LEDs oder andere farbige Emitter ähnlichen Typs machen, möchte man aber natürliche Lichtquellen simulieren, sind sie eher suboptimal und es sollte möglichst auch auf 'natürlichere' Farbspektren zurückgegriffen werden.


    'Gaussian Spektrum' klingt für mich auch schonmal nicht schlecht. =)


    b/Cycles hat für sowas ja bspw. eine 'Blackbody'-Node, also Lichtfarbe basierend auf die Farbtemperatur (Kelvin-Gradangaben). (Glaube in iRAY ist das für Lichtquellen ganz ähnlich, oder?) Darüber hinaus könnte man in b/Cycles bspw. auch ein Lichtemissions-Spektrum basierend auf Wellenlängen der Lichtstrahlen zusammensetzen .. ist aber eher etwas für gaaanz Schmerzbefreite. :gap

  • Jo, Iray hat auch K-Werte. Ist halt ein physikalischer Renderer, und man kann auch bei emissive Shadern die "Maßeinheit" festlegen (cd pro m²/ft²/cm²... und Lumen).

    Das Problem bei K-Angaben sind dann ungewöhnliche Lichtfarben, z.B. für magische Effekte, wie Grün, Lila, Pink etc. Dafür benötigt (und hat in Iray) man eben die Lichtfarben über RGB.

  • Ich meine mal gelesen zu haben, dass man zumindest das, was angestöpselt wird, angeblich am Buchstaben des Stöpsels erkennt - B = Boolean (wahr/falsch), F = Function (afaik ein Zahlenwert), C = Color (ein Bildwert? oder nur die Farben?) Aber mich dann damit zurechtzufinden - großes Nope.

    Stimmt. Nur bei F gibt es zwei verschiedene, also muss ein F-Ausgang nicht unbedingt immer in jeden beliebigen F-Eingang passen :rolleyes2:

  • ....Als "Normaluser" muss man den Shader Mixer gar nie öffnen. Man lädt per drag & drop die gewünschten Texturen in die Slots im Surface Tab und fertig. Ich finde das sehr praktisch, dass ich nicht für jedes Material einen Shader zusammenstellen muss. ...

    Es geht hier nicht um "Normaluser" die müssen, sondern um Material Interessierte die wollen ;) Shader Wechsel via drag and drop ist (genau wie Textur Tesselation) eine Basisfunktion materialfähiger Programme wie Modo, C4D und anderen. Auch Octane Shader (derzeit rund 2.000 in der DB verfügbar) lassen sich mit der Maus auf den Surface Kanal oder auch direkt in den Render View auf das Objekt ziehen, wie hier gemacht.






    Jetzt will ich diese Strubbelkugel aber aus Glas haben und rot leuchten soll sie auch noch.

    Womit wir dann wieder on Topic, und im Node Editor wären.



    Hier meine, weniger blumige, User Kategorisierung ;)


    Anwender Kategorie 1

    kauft fertiges Produkt, drückt „Rendern“ und freut sich über das Ergebnis. Er weiß wie man 3D Objekte lädt und wo der Render Button zu finden ist. Der Begriff „Shader“ ist ein Fremdwort und 3D Licht versteht er auch nicht wirklich. Der Qualitätsanspruch ist gering.


    Anwender Kategorie 2

    möchte statt Alumiunium lieber Gold auf einem Objekt haben, tauscht hin und wieder Shader aus und ist ebenfalls zufrieden. Er weiß wo und wie man Shader wechselt, Licht heller oder dunkler stellt und Bilder ins Texture Environment lädt. Von wichtigen Zusammenhängen zwischen Rendermaschine, Licht und Material hat er schon mal gehört. Der Qualitätsanspruch ist Mittel.


    Anwender Kategorie 3

    manipuliert fertige Shader sowie Licht nach seinen eigenen Vorstellungen um ein (subjektiv) optimales Ergebnis herauszuholen. Er weiß wie Shader, Rendermaschinen und ihr Licht grundsätzlich „funktionieren“, kennt die wichtigsten Bestandteile und nutzt die daraus resultierenden Möglichkeiten.

    Ein Spielkind das mehr wissen will ...oder einer der es können muss, der CGI Profi. Und weil der gewünschte, grün kristalline, mystisch leuchtende, Gold Shader mit eingestanzten osthebräischen Hieroglyphen in keiner verfluchten Datenbank zu finden ist, baut er den blöden Shader eben selber, oder erweitert einen Vorhandenen entspredhend. Der Qualitätsanspruch ist hoch bis nicht erfüllbar, denn nach jedem Render Durchlauf findet er noch etwas, dass zu verbessern wäre.


    Dieser Beitrag ist für User der Kategorie 3 und aufstrebende Kategorie 2 gedacht.

    Wem es genügt fertige Shader gegen andere fertige Shader auszutauschen, braucht keinen Node Editor.


    Die Kategorisierung bitte nicht zu ernst nehmen :)

  • Ich stimme dir zu, will Kategorie 3 aber vielleicht noch unterkategorisieren:

    3a) versucht, im bestehenden Basis-Shader das zu erledigen, was er braucht;

    3b) versucht sich auch an eigenen Basis-Shadern.


    Denn ich bin über 2 schon raus. Ich bastel in meinen Channels regelmäßig rum und bekomme das mythisch leuchtende, runenverzierte Gold auch hin (wie es gleichzeitig grün kristallin sein soll, entzieht sich allerdings im Moment meiner Vorstellungskraft... mein Hirn ist nach 3 Wochen dauernd irgendwer krank im Haus nicht mehr so leistungsfähig). In 3 bin ich aber - unter anderem wegen der fehlenden Einführung in Node Editoren und die entsprechenden Bricks - nocht nicht angekommen. Nicht, dass ich nicht hin wollte, wie geschrieben.