R18

Zitat von udo.lehmann

Das ist doch unrealistisch. C4D wird und kann niemals alle diese Funktionen in gewünschter Perfektion zu Verfügung stellen, dafür muss man immer Spezialtools integrieren, ob als PlugIn oder anders sei dahingestellt. Diese Spezialtools werden auch immer ihre eigene Engine mitbringen müssen, und da ist es egal ob man C4D, Modo, Maya o.ä. Programme verwendet.

Sagen wir mal, es ist zur Zeit einfach nicht gegeben. Ob es unrealistisch ist, die Physikengines über einen gemeinsamen Kern zu verknüpfen, ist eine andere Frage; und ob die Pluginhersteller dann mitmachen und diesen Kern nutzen, wenn es ihn denn gäbe, ist eine dritte.

Es ist in diesem Fall auch nur ein Beispiel. Integrationsprobleme und konzeptuelle Widersprüche kann man überall finden, wenn man zwei Produkte verschiedener Firmen verknüpfen will. Es ist sicher interessant, ob und wie Maxon diese Dinge in Zukunft lösen wird, denn ein neuer (mühsam eingeführter) Kern wird ja sicher nicht schon in drei, vier Jahren wieder abgelöst werden, und stellt damit die Grundlage für das nächste Jahrzehnt (oder auch zwei).

Persönlich bin ich sehr dafür, viele Funktionen in C4D selbst zu halten. Klar, das ist dann nicht immer der Bringer für hohe Ansprüche, aber wenn man diese Funktion dann nicht als zentrales Arbeitselement ständig benötigt, kann es absolut ausreichen. Wenn man's braucht, kann man durchaus auf hochwertige (und teure) Plugins oder Alternativprogramme ausweichen. Aber die reine "Hub"-Idee kann ich nicht begrüßen; Maxon vermarktet C4D als Allround-3D-Applikation, und dementsprechend erwarte ich auch eine vielfältige Funktionalität. Für einen Barebones-Hub bezahle ich nicht diese Preise.

Also es gibt ja gerade im Bereich der Physics durchaus unified solvers, also dass eine Technologie für verschiedenste Arten von Simulationen missbraucht werden kann und somit alles miteinander interagiert, ganz natürlich. Aber dabei sollte man wissen, dass es auch da eigentlich immer Qualitätseinbußen gibt. Und das Folgeproblem bleibt oft bestehen wie bei Cloth: ist schnell und einfach, aber MD knallt einfach mal die Quali aufn Tisch. Obwohl die Algorithmen natürlich auch da stetig besser werden, aber Zaubern geht noch nicht.

Das soll kein Pro und Kontra für das eine oder andere sein, aber es ist nicht so einfach alles perfekt miteinander agieren zu lassen und dabei durchweg eine hohe Qualität zu ermöglichen. Cinema ist von der Architektur ja zumindest schonmal fähig eine tiefe Integration zuzulassen, aber gerade bei z.B. den dynamics ist für Pluginentwickler einfach viel zu wenig Kontrolle und Interaktion möglich (über die Programmierschnittstelle aka API). Für Effex musste ich die Bullet dynamics komplett selbst neu integrieren, nur um die Fluidsimulationen mit C4D Objekten beidseitig korrekt interagieren zu lassen und um subframes korrekt zu synchronisieren.

Für Entwickler und Nutzer bei weitem nicht optimal (und zeitaufwendig).

Zitat von Cairyn

Sagen wir mal, es ist zur Zeit einfach nicht gegeben. Ob es unrealistisch ist, die Physikengines über einen gemeinsamen Kern zu verknüpfen, ist eine andere Frage; und ob die Pluginhersteller dann mitmachen und diesen Kern nutzen, wenn es ihn denn gäbe, ist eine dritte.

Die Frage ist ja auch inwiefern der neue Kern = besseren Zugriff bedeutet. Ich habe nicht das Gefühl, dass dadurch diese Situation verbessert wird, aber ich würds natürlich begrüßen.

Zitat von stereoV

Leider bringt die R18 schon wieder kein NODE-basierendes-MATERIALSYSTEM mit

Mit R18 habt Ihr aber an diesem Punkt in meinen Augen schon wieder eine wichtige Optimierung verpasst !

Es wird wie immer gemeckert. Die einen wollen einen Node-based-editor, die anderen finden alles was mit dem Physical Render zu tun hat verschwendete Zeit, weil es eh keiner braucht, da alle nur noch mit Octane rendern.

Tja so ist es halt

Zitat von Moosi

Es wird wie immer gemeckert. Die einen wollen einen Node-based-editor, die anderen finden alles was mit dem Physical Render zu tun hat verschwendete Zeit, weil es eh keiner braucht, da alle nur noch mit Octane rendern.

Aber tatsächlich hat das eine nichts mit dem anderen zu tun. Octane liefert einfach seinen eigenen Node-Editor für Cinema mit – das muss aber nicht so sein und ist auch nirgendswo sonst so. Andere Programme besitzen halt seit jeher node-basierte Workflows, und jede externe Renderengine besitzt halt Nodes die genau in eben jenem Node-Graph angezeigt und benutzt werden. Octane for Maya Nodes existieren genauso im Node-Editor/Hypershade wie alle Maya internen shading-nodes (und alle anderen Nodes…), Arnold Shading Nodes, Mental Ray Shading Nodes, Vray-Nodes… etc pp. Genauso wie in Houdini halt Octane Nodes im SHOP-Kontext existieren, wo sie hingehören. Ein Node-Editor in dem sich jeder Plug-in Renderer (und auch jedes noch so beliebige andere Plugin) einhängen kann sind jetzt wirklich kein Ding der Unmöglichkeit und weitläufig eher Standard, und nicht unsinnig. Genauso wie es halt Vorteile hat wenn Shading-Nodes im selben Kontext wie andere Szenen-Nodes exestieren anstatt für jeden Fluff 5 unterschiedliche Editoren zu besitzen. Genauso wie es auch andernorts völlig normal ist, dass auch Materialien anderer Renderengines mit ihren eigenen Viewport-Previews kommen anstatt das alles grün/schwarz oder grau wird oder explodiert (allerdings in vielen Fällen trotzdem mehr schlecht als recht oder limitiert) Ob man das alles persönlich nun braucht oder nicht – mich wundert es eigentlich schon sehr, dass von allen Features die Maxon gerne nach 1-2 Versionen von anderen Softwarepaketen klaut (und teilweise auch userfreundlicher umsetzt), es noch kein node-basierte Scene oder zumindest Shading-Graph ins Programm geschafft hat. Da Cinema sich langsam tatsächlich eher als Hub aufbaut, muss das über kurz oder lang kommen.

Ich bin ganz bei Dir.
Mein Kern der Aussage war aber das Maxon es den usern irgendwie nicht recht machen kann. Einer schreit immer.
Klar, optimal wäre es wenn der neue Viewport von allen Plugins genutzt werden könnte und ein Node Editor eben genau so universell daher kommt. Die anderen Hersteller zeigen ja wie es geht und vor allem das es geht.

Ahh, jetzt weiß ich woran es liegt. Das Benutzerbeteiligungs-Programm, hat eindeutig festgestellt das keiner den nicht vorhandenen Node Editor verwendet.

Will nicht stänkern, mir gefällt dieses Release auch wirklich gut.

Aber mit ein Grund, warum mir Octane und Arnold so gut gefallen, ist der Nodeditor. Benutze zwar noch immer für Jobs meistens Vray, aber nur leicht komplexere Materialien werden hier immer zum Workflow-Graus. Auch mit ReferenceShader...
Nodeeditor, mehrere UV Kanäle pro Material und neues Unwprapping steht bei mir als weiterhin ganz oben, direkt neben der Performance bei vielen Objekten.

Meine hoffnungsvolle Spekulation ist, Maxon arbeitet hinter den Türen schon länger an einem general-überholten xpresso, das wesentlich tiefer geht, Multicore unterstützt, Objekterstellung erlaubt wie auch Shading.
Dann gibt es spezielle Xpresso Generatoren, Deformer, Materials, Partikel und weiterhin den Tag

In Sachen nodeorientiertes Arbeiten:
Nodes haben natürlich viele Vorteile u.a. komplexe Sachverhalte höchst flexibel gestalten. Aber Nodes haben auch Nachteile – um diese Arbeitsweise effektiv nutzen zu können, muss man deren Sprache sprechen, also quasi „Vokabeln“ lernen und die Verknüpfungslogik erfassen um damit kreativ arbeiten zu können.

Das erfordert Übung und Zeit. Für jemanden der täglich damit arbeitet ist das recht schnell erlernt und man bleibt auch drin. Für andere, und damit schließe ich mich ein, ist das mühsam besonders wenn zwischen mehreren Arbeiten teilweise Wochen liegen, schließlich arbeite ich nicht täglich an Materialien. Ich habe meine Materialbibliothek die ich gut und effektiv nutze, da muss ich keine Nodes für haben und ich kann gut und gerne mich auf andere Dinge konzentrieren als ständig mich in die Nodebearbeitung üben zu müssen.

Einmal ein längere Pause in komplexen Zusammenhängen, egal ob Nodes oder andere umfangreiche Tools, und man fängt fast wieder von vorne an.

Dennoch arbeite ich mich gerade in die Substancesoftware ein, hier geht ohne Nodes nichts, aber es macht spaß. Ich hoffe nur das ich es auch noch nach Wochen weiß wie es geht …

Gruß, Udo

Zitat von udo.lehmann

In Sachen nodeorientiertes Arbeiten

Damit hast Du teilweise sicher Recht.
Allerdings gilt zum Einen das Üben und lernen von "Vokabeln" und mehr noch, deren Syntax, Zusammenhänge zwischen Objekten etc., generell für eine solche hochkomplexe Software, wie sie ein so umfangreiches 3D Programm heute nun einmal ist, und nicht speziell für bestimmte Bereiche. Für manche vielleicht ein bisschen mehr, eingeräumt. Aber denk doch an Mograph oder Dynamics. Dagegen nimmt sich das erlernen von Materialnodes, die sicher nicht die Schwierigkeit von einem Xpresso mit sich bringen, wie ein Kinderspielplatz aus. Zumal man da sofort sieht was passiert. Oder dass nichts passiert, weil man versucht hat, Nodes zu verbinden, die nicht zusammen gehören. Anders gesagt: den nicht viel einfachereren Rest des Programmes musste man auch schon lernen. Da macht ein bisschen Nodes auch nichts mehr

Außerdem kann man mit Nodes nicht nur komplexe Sachverhalte flexibel gestalten. In vielen Fällen sind sie viel einfacher damit zu entwickeln. Mir geht es immer öfter so, dass ich in Octanes Nodeeditor das gesamte Material vor mir habe und sofort oder zumindest ziemlich schnell weiß, wo ich was tun möchte. Wenn ich das gleiche dann im Cinemas Materialeditor machen will, "verlaufe" ich mich mittlerweile auch ganz schnell mal, und das ständige rauf und runter nervt nicht nur: es dauert auch ordentlich. Mit anderen Worten: je komplexer das Material ist, desto größer ist eine tatsächlich messbare Zeitersparnis beim Bearbeiten.

Wie auch immer: es spricht ja nichts dagegen, das bisherige Material so zu lassen wie es ist. Wie man bei CM-Nodes sehen kann, ist es durchaus möglich, a) jetzt schon ein Node basiertes System zu integrieren, b) das bisherige dabei zu lassen wie es ist und würde c) endlich den in meinen Augen unglücklich aufgebauten Reflectance Channel dabei gleich mit überarbeiten ^^ Dazu wurden in diesem Thread schon Vorschläge gemacht, und auch das könnte man sich im Zweifel bei einigen anderen 3D Programmen abschauen. Ich glaube aber nicht, dass das nötig ist.
Im Grunde ist der Channel auch nicht viel anderes als ein Layer-Node. Wie das ganze unter der Haube nachher aussieht, mag auf einem anderen Blatt stehen, aber so unmöglich ist das sicher nicht. Hey, externe Entwickler haben für ihre Node-basierten Systeme die Xpresso-Oberfläche genutzt Wo ein Willi ist ...

Und nicht zuletzt: dass Du mit einer Materialbiliothek gut fährst, freut mich sehr für Dich. Ich habe idR. so unterschiedliche Projekte, dass ich immer neue Materialien anlegen, oder zumindest alte kopieren und verändern muss, nicht nur in Texturen. Ich habe das früher auch mal versucht mit Bibliotheken, dann aber schnell aufgeben. Was ich sagen will: auch hier kommt es auf das jeweilige Büro an, was denn gefordert und gebraucht wird. Ich könnte das auch rumdrehen und sagen: wenn Du nur selten Materialien anfasst und mit einer Bibliothek auskommst, machst Du vermutlich sehr stark auf einen Bereich fokussierte Arbeiten, für die eine Prime oder sogar eine Lite plus Renderer ausreichen mögen ^^ Klingt nicht so nett, oder? Aber vor allem: einseitig. Wir sind aber ein sehr vielseitiges Volk

Hallo Kurt,
ich denke der Königsweg ist in er Tat der das man zwei Arbeitsweisen zuläßt. Da ich in Sachen Material ohnehin fast ausschließlich mit Octane unterwegs bin, habe ich ja auch den Luxus beides zu wählen - klassisch oder nodebasierend.

Das ich mit Octane und seinen Standardmaterialien sehr gut zurecht und auch auskomme liegt einfach daran das ich meistens Technik visualisiere, hier sind Oberflächen ohnehin eher einfach gestaltet, und es kommt mehr auf Animation an.

Das Modeln besteht in meinem Fall mehr aus der Konvertierung von CAD-Daten in C4D. Dennoch schaue ich gerne in andere Bereich hinein, derzeit aber noch lieber ohne Nodes

Gruß, Udo

Nochmal zu Nodes, da muss ich Kurt zustimmen. Eigentlich ändert sich durch ein node-basiertes System für den User der es nicht will erstmal nix. Ich kann ja in beispielsweise Maya auch ein Material im Attribute Editor mehr oder minder exakt so gestalten wie ich es in Cinema im Material Editor tue, und muss den Node-Editor niemals zwangsläufig aufmachen. Wenn ich aber nicht tausend Dublikate von kleinen Utility-Shadern benutzen will, ständig immer wieder das selbe einstellen oder rumkopieren oder ähnlichen Quatsch, mach ich ganz schnell den Node-Editor auf und bin 10x schneller durch. Das eine schliesst halt das andere nicht aus, und davon abgesehen ist die Verbindungslogik in Shader-Setups absolut die selbe wie sie es jetzt gerade schon layer-basiert ist. Nur übersichtlicher dargestellt und Shading-Nodes haben in aller Regel meistens nur ganz einfache Ports. Nämlich meistens nur einen oder mehrere RGBA In und nen RGBA Out. Und deren User-Interfaces entsprechen i.d.R absolut dann genau dem, was dir auch ein jetziger Shader ins Cinemas Materialeditor an Funktionen exponieren würde.

Ja, ich denke wenn man beides anbietet "Nodes" und "Klassisch" dann ist jedem geholfen - Octane macht es ja gerade vor und ich werde mir jetzt auch mal die Materialnodes von Octane mehr anschauen.

Vielleicht ist zunächst der Substance-Weg den C4D einschlägt ein vertretbarer Kompromiss, hängt eben von der Renderqualität ab.

Gruß, Udo

Was ist denn mit cmNode? http://www.cmstuff.com/article/1004/cmnodes+v1
Läuft ja mit der R17. Hat das jemand so richtig in Gebrauch? Also ich nicht, und ich gehörte auch mal zu denen die nach Nodes geschrieen haben.
Und wenn Maxon dann Nodes einbaut, sind sie sicher auch nicht ausgegart... *Teamrenderer-angst-hab* :-)

"in", nicht "mit". Irgendwas war ... nicht alle Shader, kein Zugriff auf Reflectance (und der macht 90% aus), kein Zugriff auf Layer ... irgendsowas völlig Unwesentliches *** Aber das Teil an sich ist schon ziemlich kühl, denn er hat dem Editor eine Menge Shader und damit Möglichkeiten spendiert, die Cinema selbst noch garnicht bietet. Respekt dafür!

*** alles drei.
Oder ich kapiers nicht ^^
Ich bekomme jedenfalls keinen Zugriff auf bestimmte Parameter des Materials aus dem Nodeeditor heraus: Layer, Reflectance-Layer, Eigenschaften wie Lambert im Farbkanal etc. weil der Editor innerhalb der Shader in den Texturslots sitzt.

Zitat von udo.lehmann

Vielleicht ist zunächst der Substance-Weg den C4D einschlägt ein vertretbarer Kompromiss

Dann musst Du im Desinger noden ^^

Zitat von Kurt

...

Dann musst Du im Desinger noden ^^

Ja eben, "noden" im Substance Designer mit Interface zu C4D und "nichtnoden" im normalen AR oder PR - ob das ein möglicher Kompromiss ist muss sich natürlich erst zeigen.

Jedenfalls arbeite ich mich gerade in den Designer ein, um auch das Noden mal zu üben und zu lernen, da man ja kaum noch darum herum kommt

Gruß, Udo

Zitat von udo.lehmann

Ja eben, "noden" im Substance Designer mit Interface zu C4D und "nichtnoden" im normalen AR oder PR

Ah, verstehe ^^ Guter Ansatz, viel Erfolg!

Zitat von udo.lehmann

Ja eben, "noden" im Substance Designer mit Interface zu C4D und "nichtnoden" im normalen AR oder PR - ob das ein möglicher Kompromiss ist muss sich natürlich erst zeigen.

Jedenfalls arbeite ich mich gerade in den Designer ein, um auch das Noden mal zu üben und zu lernen, da man ja kaum noch darum herum kommt

Gruß, Udo

Ich hoffe, Du hast genug Zeit.

Warum? Ist der SD schwer zu erlernen?

Gruß, Udo

Lass Dich nicht vom Robi verunsichern, Du machst das schon

Zitat von udo.lehmann

Warum? Ist der SD schwer zu erlernen?

Gruß, Udo

Nein, es ist verflucht simpel. Das ist ja das Problem. Man will immer mehr und noch mehr und dann hier noch und dann da noch. Und schwupps, haste für ein Stein-Mosaik nen Monat rum. Es macht unglaublich viel Spaß.

Kleiner Tipp für den Anfang: Wenn Du Node-Gruppen (Graphs) hast, die Du auch in Zukunft verwenden kannst, speichere sie Dir direkt zur Wiederverwendung ab. So sparst Du Dir unglaublich viel Zeit. Und es ist eines der Kernkonzepte.

Super, danke dir.

Guss, Udo