Ein Gedanke …
Nur interessehalber. Ich bin mit den bisherigen Features des OGL Renderers gut klargekommen. Normalerweise habe ich damit reine Animationsstudien gemacht, um Tempo, Timing und die Bewegungen an sich zu kontrollieren. Ob da AA bei war, Transparenz in Klötzchen oder Peng, hat nicht interessiert.
Das hier ist eine andere Hausnummer und sieht schon sehr “fertig” aus. Für manche Kunden mag das als Renderergebnis reichen 
@Kurt, sehe ich genauso, deshalb ist das wirklich hochinteressant - da könnte ich tatsächlich Octane ab und zu mal ruhen lassen.
Gruß, Udo
Wenn letztlich nicht mit dem AR/PR gerendert werden soll, nutzt es für den Look wenig, da die GL View auf C4D Materialien abgestimmt ist. Man müsste also alle Materialen doppelt anlegen. Einmal für die OGL Preview und einmal für den Renderer der genutzt wird. Dann ist das nicht sehr effektiv. Jedenfalls wenn viele Materialien in der Szene vorkommen.
Was zum Thema, wann kommt R18, nun steht doch auf Maxon.de selber, da wird doch R17 und R18 beworben, bis 31. August, also wird es wohl zu dem oder kurz nach dem Datum wohl erscheinen.
Bis man irgendwann alle meist nötigen Mats für jeden Renderer sauber in Bibliotheken hat. Dann ist das halb so wild..
Ich versteh den ganzen Hype um diese Editordarstellung nicht…Für was soll das gut Sein?
Fürs Timing reicht auch die Claydarstellung?
Und sorry RenderBaron, wenn ich an deinem noch so geliebten Maxon/AR Kritik äußere…
Oder die 3rd-Party Entwickler passen ihre Materialpreviews an. Aber das kostet ja Geld und hat keinen Nutzen…
Volle Zustimmung. Dieser Scheißeditor nimmt einem die ganze Vorfreude beim Rendern!
1 „Gefällt mir“
Jo,da hast sicherlich recht, vorallem bieten die neusten Engines eine gute / schnelle Preview.
Und bei komplexen Materialien wird man eh rendern müssen…
Ich finde es schade, dass an BP nichts gemacht wurde…Thema Abwickeln etc.
Meistens muss man hier über Zbrush oder 3D Coat fahren.
Cloth wird auch schon seit Jahren auch nicht aktualisiert, was ich auch schade finde…
Gerade wenn verschiedene Sachen interagieren müssen, war MD 2 umständlich.
Charackteranimation: wenn man mehr als zwei Mocaps in einer Szene hat, kann man nicht mehr arbeiten…Gerade hier hätte ich mir eine Verbesserung gewünscht.
Und zum Thema Editor:
Wie wäre es denn, wenn man mal eine richtige 25 Fps Scene im Editor abspielen könnte?
Das wäre doch viel Sinnvoller?
Es wäre wünschenswert, wenn die in meinen Augen überfällige Überarbeitung der OGL Preview Hand in Hand gehen würde mit der editorbeschleunigung von Prozessen und Objektmengen. Lassen wir uns überraschen!
bei den Themen stimme ich dir voll zu, aber das sind halt nicht alle Baustellen, die Cinema aufweist. Ich bin froh, dass Maxon überhaupt dabei ist, welche anzugehen, wie z.b. endlich mal überarbeitete Werkzeuge wie das Messer.
Was die sinnvolle Reihenfolge betrifft, so sehen das verschiedene Kollegen vermutlich wieder anders. Für mich ist z.b. das Thema Editorbremse bzw. zu wenige Objekte verwaltbar ganz vorne.
Auch hier stimme ich Kurt zu.
was z.B. Cloth angeht so ist diese Funktion sicher sehr überarbeitungswürdig. Ich arbeite derzeit mit MD, ein Programm was kaum Wünsche offen läßt (außer die Mehrprozessorfähigkeiten, die noch eher mangelhaft sind).
Es ist nicht zu erwarten das C4D jemals ein ähnlich umfangreiches Cloth-Tool zur Verfügung stellen wird und wer einmal mit MD gearbeitet hat, will auch nichts schlechteres mehr haben, insofern ist C4D-Cloth für mich sehr entbehrlich.
Genauso verhält es sich mit Realflow und anderen Tools.
Das sind alles Spezialtools deren Leistungsfähigkeit nie von C4D erreicht werden, also sollte man nicht unnötig Ressourcen darauf setzen. Hier gibt es ander C4D-native Themen, die noch weiter vderbessert werden können, s.o.
Gruß, Udo
BP, Cloth, Physics, Sculpting, Rendering - dürfen wegen mir alle gerne ausgelagert werden. Aber zumindest die Basics - Modeling & Animation - sollten in der “Host” Applikation (und als mehr nutze ich C4D nicht) brauchbar sein. Und ich bin ja wirklich ein Fan von C4Ds Animationsmöglichen (sei es Character, MoGraph, TP oder die einfachsten Sachen). Man kann quasi alles animieren und die Macken halten sich in Grenzen. Nur die Performance dabei, die ist teils verbesserungswürdig. Aber vielleicht wird das ja jetzt mal. Würde mich freuen
1 „Gefällt mir“
Naja, ein nativer Renderer sollte schon irgendwie dabei sein. Dass der nicht an Octane rankommen muss, ist aber auch klar…
Das Problem beim Auslagern ist, daß viele Funktionen mit anderen interagieren. Schon beim Rendering haben wir das Problem, die Viewport-Darstellung mit dem fertigen Rendering-Look abzugleichen (wie hier bzgl. des neuen Viewports schon angemerkt). Die Art und Weise, wie Subframes vom System behandelt werden, muß für MotionBlur dem Renderer bekannt gemacht werden. Die Struktur der Materialien muß ebenfalls vom Renderer korrekt erkannt werden. Dazu kommt, daß Plugins, die das Rendering direkt beeinflussen, jetzt extern ausgeführt werden müssen bzw. einfach nicht mehr gehen / auf Renderer-Seite spezifisch implementiert werden müssen.
Physics ist noch eine Ecke schlimmer: Hair, Cloth, Partikel, Fluids, Soft/Hardbody müssen über einen gemeinsamen Kern interagieren, damit wir nicht am Ende wieder das aktuelle Problem haben, daß jedes Plugin und jede Funktion mit ihrer eigenen Physics-Engine daherkommt.
Die einfachsten Funktionen, die man externalisieren kann, sind wohl Sculpting (Interface über ein Mesh oder eine Hierarchie von Meshes) und UV-Abwicklung (Interface über Mesh in, UV-Definition out). Painting ist einfach, wenn man es auf eine reine gemalte Textur (Bild) beschränkt; sobald ich ein komplettes Material beim Painten sehen möchte, erzeuge ich Abhängigkeiten zu (engine-spezifischen) Shadern und dem strukturellen Aufbau der Materialhierarchie.
Ein reiner Host / Hub steht daneben auch immer vor dem Problem, daß eine Änderung am Kern potentiell alle davon abhängigen Plugins zur Änderung zwingt. Nicht jede Funktionalität läßt sich über ein Legacy-API abfedern. Das sehen wir ja schon aktuell, wenn nach einem Release einige Plugins nicht mehr wollen. Wird sicher nicht besser, wenn noch mehr entscheidende Funktionalitäten zu externen Herstellern abwandern.
1 „Gefällt mir“
@Cairyn
Da gebe ich Dir in allen Punkten mehr oder weniger recht. Ist ja auch immer eine Frage was einen in der täglichen Arbeit eher tangiert.
Aber würdest Du ernsthaft irgendein Projekt, welches stark auf die Verzahnung verchiedenster Physics aufbaut, in Cinema 4D umsetzen? 
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. Einzig Houdini scheint hier wohl anders zu ticken, hier läuft alles über die Houdini Engine - also wer nahtlos pluginfrei alle Effekte nutzen möchte wird wohl nicht an Houdini vorbeikommen.
Allerdings arbeite ich gut und gerne mit PlugIns, man kann sich dadurch aussuchen welche Themen vertieft werden sollen.
Mein persönlich größter Wunsch für C4D ist allerdings die Verbesserung der Mehrprozessorfähigkeiten aller rechenintensiven nativen Funktionen (dazu gehören sicher u.a. alle Dynamic- sowie Soft/Hardbodyfunktionen) - damit das endlich noch schneller geht.
Gruß, Udo
Leider bringt die R18 schon wieder kein NODE-basierendes-MATERIALSYSTEM mit:|
Darauf warte ich schon soooo lange. Ich frage mich langsam, ob Maxon was das angeht den Knall nicht gehört hat !!!
Obwohl dieses Thema seit Jahren auf allen möglichen Plattformen oder Maxon Events angesprochen wird und man auch bei anderen Produkten eine starke Entwicklung in diese Richtung feststellen kann, reagiert Maxon überhaupt nicht ! Wollt Ihr nicht oder könnt Ihr nicht ???
Selbst über einen simplen Instanzen-Shader hätte ich mich ja schon gefreut, weil ich nämlich überhaupt keine Lust mehr darauf habe mich durch etliche Materialkanäle oder Shaderhirarchien zu quälen nur um z.B. die Größe eines Noise zu ändern !
( …ich weiß es gibt das plugin cm-nodes, aber ich finde das ist nicht das gleiche, wenn auch schon ganz nett. Sowas gehört für mich einfach in die Main-app mit rein ! )
Maxon: Ihr schimpft Euch doch immer so workflow orientiert !?
Mit R18 habt Ihr aber an diesem Punkt in meinen Augen schon wieder eine wichtige Optimierung verpasst !
Irgendwie glaube ich, dass die erst den neuen Code fertig machen müssen bevor die ganzen Material und Simulationsgeschichten sinnvoll umgebaut werden. Vielleicht hat das aber auch schlicht keine Prio bei denen.
Irgendwie glaube ich genau das überhaupt nicht. Die CM-Nodes zeigen, dass es auch ohne Umbau gegangen ist. Jedenfalls bis der Reflectance Channel raus kam. Der ist ja ganz nett, aber das Handling … da wünscht man sich sofort ein Node basiertes System. Ich verstehe StereoV durchaus
Denkbar ist, dass sich Maxon keine doppelte Arbeit machen möchte. Keine Ahnung wie stark das ganze mit dem neuen Core verdrahtet ist, aber auch der wird ja anscheinend schrittweise entwickelt und eingebaut, nicht in einem Hauruck. Eine bald kommende Node basierte Lösung ist also schon denkbar, jedenfalls von außen gesehen.
Und last but not least darf man nicht vergessen, dass Cinema als einfach zu erlernen gilt. Das würde für mich zumindest bedeuten, dass es wie bei Blender und Max (?) zwei Zugänge zum Material parallel geben müsste. Nämlich darunter einen einfachen wie bisher für die Einsteiger.