Thread about Scene Nodes anyone?


Since Scene Nodes are an experimental feature and developers want to have feedback, how about having this thread for feedback ?

Anyone having to point out something can do so replying here.


I’ve just seen this amazing video :

It whould be a game changer if the next C4D release had nodes to manipulate geometries to apply certain styles like the above.

It might seem far-feched because it flerts with similar AI/DeepDream effects in Photoshop and other experimental applications. But i think it can be achieved by making the nodal pipeline more conditional-oriented. Like in programming having an IF node could make that kitbash collection very easy to automatically generate many different-looking skyscrapers.

Imagine the following pseudo-coding style concept in a nodal system :

For given polygon on an object (1) place a model (2) in a specific location (3) on it and put a flag (4)
IF NEXT polygon IN selection (5) has no flag THEN place a model (2) in a specific location (3) on it and put a flag (4)

(1) wall_model#4
(2) window_model#2 or random from a collection
(3) can be a reference position like polygon_center, vertex_center, point, or an absolute x,y possition, or x,y position away_from given polygon/vertex/point selection center
(4) a scripting temporary control token with a generic string name for reference
(5) polygon selection

Those 2 lines can polulate a perimeter with windows but even if it looks like a more complicated way to do something without a cloner it certainly can do more, for example:

  1. place a specific type of window or other object if the next polygon has window of type X or has a flag of string Y.
  2. place a specific type of window or other object if the polygon area is bigger than X.
  3. ommit placing anything in random intervals or every X iterations (MOD)
  4. do something else when the chain event has stoped or certain criteria has been satisfied (like when there is no valid action to do after all polygons have been occupied with a window or all types of windows have been placed)

Doing that in a floor-by-floor iteration in a similar way using other helper nodes like a FOR and WHILE, can produce unlimited types of different buildings with an intuitive, easy to follow and understandable tree of limited number of nodes using only the nodes for a single floor.

And the style mentioned above ?
It’s obvious that different types of bark and wood chunks where placed to overlap with the buildings.
Current deformers and generators can smooth the overall look and make it look coherent.

Imagine the possibilities …
Make unique trees, cars, buildings…
Generate labyrinths, mazes, polygonal patterns, city grids

Automate details based on rules like placing bins on road corners and trafic lights on cross-sections.
Add some animation nodes and you have a vehicle traffic system.

All these I believe can be achieved with the current node editor … but it whould require a node tree of unimaginable complexity and a genious to concieve it.


Nice thread. I wish I could contribute but am an R20/Blender guy.

Cool video too. Unfortunately as years have passed it’s harder to get open discussions going on this forum.


I made the thread as a place for mindstorming rather than discussing. It’s hard to discuss with more than 4 persons in this kind of forum.


I wonder if there is some practical benefit for intergrating a different navigation system in Node Editor from that the Xpresso has.


In both you have to reach with your cursor the edge of the window, click and drag to a pan around.
Probably having a map is more computationaly intensive.

When I first tryied the Node Editor I did not notice the map and tried to pan around by draging a node to the edge of the panel in hope for an auto-pan. Auto-pan when near window edge is a smart UI design but on the other hand you whould never reach the Scene Output :laughing: I guess since its the only possible output you just might as well set a node as End_Node for final output.

A UI element that I love and only the Node Editors have but not the Xpresso is beeing able to see a nodes’ atribute in the Editors’ window : Screenshot_3. In Xpresso I have to make space to see the Attributes Tab in my layout. Which can be a setback when I wan to have a look at an object’s attributes at the same time…

One last thing about UI … I’ve noticed I can’t have both Material and Scene Node Editors open… It’s a refresh on the same window and is laggy.


The color indicator is a very helpful UI element.
I don’t have OCD but some Nodes really have to get in a category with the same color indication.

Why have a Bent deformer with a grey color when all others are purple ?
Why is a Primitive an operator ?
Why is landscape Gray and not Blue like all other primitives, and when inserted is Green?
The first 6 categories all contain nodes with the same color indication and then you have Geometry and Generator with 3 and 4 color nodes !

There has to be an organizational overhaul over there ‘cause it’s a mess… For 10 minutes I was trying to find the green Solidify Node and couldn’t see it in that pool of brown and green … And ofcourse the fist place to look was the Generator category that contains only green nodes. I did not remember the nodes’ name 'cause it was my first try in the Editor but it really stack with me that it was green and I knew what it was suppose to do and in my train of thought I had to find something that “generates” a cage or thickness.

Maybe there is some reason I not see for nodes beeing colored as they are… I tried making sub-categories to sort some nodes but it’s not possible yet…


So we can have material nodes in Scene Nodes Editor but no scene nodes in Material Nodes Editor…

I hope they merge all Node Editors in one so we can have Materials and Geometry that change depending the Motion or relative to other attributes of an object.


Some nodes work only in materials and some only in scene graphs. Most however work in both. Some of the uses are a bit exotic though.


I think those “exotic” uses could enable VFX concerning ThinkingParticles to achieve the following proceduraly:



Just for clarification, this is already possible using the Material Parametrization node. It allows you to transfer basically any information from the scene node context to the material context, you just need to create a material that offers the para,meter you want.
Having all nodes executet in the same context is simply not possible, it would mean that the scene graph could possible be evaluated on a per subpixel base, something that would bring any system to a standstill and would rule out any kind of GPU rendering.


When I hear about nodes somehow I subcontiously feel like I will have the ability to code visually. Maybe because I used to teach children to code LEGO Mindstorms or maybe because Xpresso lets me tinker with values. Material Nodes didn’t really offer such an experience but Scene Nodes as experimental feature did make me feel there is such kind of potential.

C4D looks like a promising platform for bridging the gap between Artists and Programmers, where artists can learn to program and programmers can tinker with a higher level of coding concepts for faster outcome on more complex matters.

Maxons’ target at Motion Graphics whould benefit from having a node system capable of visualizing Generative algorithms as seen here:

Something that currently I’m struggling to achieve.


Is there currently an evaluational optimization in Scene Nodes ?
I mean does the Node tree get evaluated from root to Scene every time I make a change in an arbitrary node, or is there an inteligent algorithm that retreives a middle-state object before the node to be changed and evaluates it from there on ?


In Xpresso there is an amazing node called Result. I’ve been using that to “debug” my node trees when things didn’t go as they should. I would put that node in every output and check how a value got changed from node-to-node. So if a node made a misuse of my value due to type (int, float, vector, matrix etc.) I whould notice and if a node output a type other than what it got in I would also see that and learn about what the node spits out and in what format in case I had to manually input some values elsewhere.

I’m trying to do the same thing here but can’t… I’ve tried the Value, Print and ConsoleOut nodes and got nothing …


If you want to know what is going with nodes visit Nodevember stuff


Console Out needs to be connected on the output side, usually you simply drop it onto an existing wire.
Scene Nodes are heavily optimized, they are only evaluated when dependent values change, also they auto optimize for multithreading.
Even if Nodes are easier to understand and use for some people, it is still coding and requires knowledge of algorithms and structures to implement complex things.


I know it’s Nodevember that’s why i’m experimenting with 'em.
Seeing Default Cube (youtuber) making all kind of things with just vector desplacement (which Maxon discontinued) makes me anxious to learn them quick.


This is probably my last entry. I’ve tried to put as much feedback as I could. I’m not the type of person that just points at wrong things. I also like to point at (possible) solutions.

Philosophy is what makes C4D what it is and distinguishes it from other apps. It is its’ signature. New users prefer C4D for these qualities:

Intuitive User interface, Good User Experience, Fast results, Stability

Old users prefer C4D for a lot more.

OK, so the new Scene Nodes (from my point of view) look alien to the rest of C4D for the lack of Intuitive User interface and User Experience and Fast results. When I say fast results I don’t mean that C4D is not fast. I mean the (node) tools provided don’t offer fast results as a constructed method; I’ll come back to that after UI/UX.

  1. Intuitive User Interface and UX Philosophy
    Until now users were used to these steps: Hear about a new tool from MAXON (hype), click on the new tool, experiment with parameters, instant visual outcome (wow).
    Now here you could argue that

“Of course you can’t have instant visual outcome with nodes, they are a complicated system!, our users have been introduced to new systems in the past and it was a success.”

Let’s analyze those that had the biggest impact in UX/UI.

  • New Reflectance material channel. A lot of people got confused by it wondering what’s the purpose of it when other channels do just the same. But there was a one line Philosophy that made it all clear:

“All material information is light being reflected from the surface of the object.”

And of course all parameters were readily available to be experimented with a preview always updating. Even by clicking randomly you could have an outcome and soon enough you would make out those relations between parameters even if you understood half the interface English words.

  • Xpresso. That was a big wall. But there was a Philosophy:

”Every parameter can be relatable to some other parameter”

Boom, that’s it. The only thing someone had to do is have a look of what nodes were available to modify parameters, that he was already familiar with, the way he was expecting.

  • Material Nodes. Overwhelming? Yes. Hard to get through it? No. The Philosophy was no different from Photoshop layers. The only thing that changed was the way they were represented.

So what makes Scene Nodes “alien” to the rest of C4D ?

  1. Bad naming. Naming procedures and functions with missleading names or names that don’t make much sense to their action leads to bad UX. Especially when those tools are the same tools everyone uses daily!
    • Distribution Nodes – Cloner Mode
    • Effector Nodes – Deformers
    • Expand Selection – Grow Selection
    • Geometry Clone – Clone
    • Insert – Extrude Inner
    • Lathe Line – Lathe
    • Range – FOR programming command
    Why refer to splines as lines ?

  2. Overwhelming complexity. Too many nodes. Having many tools to your disposal is desirable but after a point it gets just tiring. Sometimes you just need a complex tool without having to build it yourself from scratch. That tool is already part of C4Ds functions, so why isn’t it here? It is, it’s just in peaces… Scene Nodes is like opening an IKEA purchase. Actually it’s not the great number of nodes that can be problematic but their scattered functionality in to absolute smallest possible pieces (not talking about math nodes), keep reading it will be made clearer. Just open one of the green nodes like the Directional Cloner and see how complex things we got for granted are.

  3. Lack of compactness. C4Ds interface (looks like it) was built in the Philosophy of “Get as much as possible in as little space as possible in logical and coherent ways”. I’ve talked about lack of optimal organization on a previous post, so I’m not going to repeat myself. I will talk about compactness. C4Ds UI has provided tabs, drop-down menus and section folds to make complex tools with extensive parameters more compact and consequently easier to access said parameters. Scene Nodes don’t have such UI helpers. They don’t need them. They are not that complicated. But they are a lot of them. There is only one good example of good compact use and that is the Primitive Operator. For some reason I don’t understand though, developers have also provided nodes for every single Primitive Type included in the Primitive Operator. All 14 of them! I think there should be more Nodes like Primitive Operator. Grouping nodes like this is good for two reasons:

    • Makes easier for users to find the type of node they need.
    • Even knowing well the name or place of a node in the NodePool the work is faster. Need three different Deformers ? Just grub one, copy it and paste it three times. Change its mode from its parameters from the drop-down menu. Need another Field Node ? Why delete it and search for the new one? Just change its functionality from the drop-down menu, you know… just like how fields are already in C4D.

Like I said nodes look like an IKEA package. Some nodes should be grouped not only by common ancestry but also by relevance. Every Field Node should have a Remap Node integrated. Just like Fields are in C4D. Users have to have access to common attributes readily available inside the node and not have to forage from the pool every once and while. Just like in Expresso Nodes when throwing an object in. Not all those inputs and outputs have to be visible in the representation if not needed. If a user needs to pass an attribute to the next node he just has to greenlight it.
There’s also another way of compacting suitable for simple function nodes, check this out:

(up, before) (down, after)

  1. No interactivity with the rest of the interface. Probably users will be relieved if there is going to be a way to drag and drop things from the Object Manager into the Scene Nodes Editor. It speeds-up the workflow. Make a setup quickly in the traditional way and then toss it in Scene Node Editor to expand your options.
    Not a 1-to-1 relation with the rest of C4D. I think that every single option from the Create, Select, Tools, Mesh, Spline, Volume, Mograph, Simulate drop-down menus, should be part of the Node Pool. I know it’s still an experimental and incomplete system but I don’t know what developers have in their plans so I had to mention it. Right now the Scene Node Editor looks like just another way to work in C4D (the hard way). The impression I get from the promising benefits of such a workflow is the non-linearity. Some functions in C4D are one-way, you cannot make them do things dynamically. In the node environment you can apply them in different places and undo their effect non-destructively to the rest of your setup.

  2. Information Flow. The Philosophy of Information Flow in this new Editor is absent. Some Nodes (like Matrix Op.) work connected on either side of other nodes with the same effect, some do not. Some need to have an Input some can be independent. Information Flow is important for comprehending iterative structures. Even in programming languages loops like FOR, WHILE, DO-WHILE have their code indented or enclosed to isolate their recursive content. This is not apparent with the current system. It’s less intuitive to understand in what part of the node tree the generation of copies happens and from there on how to manipulate each copy individually or all at once.

Other Small Points

  • The preset layout “Nodes” should be renamed to “Scene Nodes”. Otherwise add access to the Material Node Editor and Xpresso.
  • Double-clicking on the Group Menu Separator should shrink the width according to the maximum title length.
  • When Node Scenes are opened in float window, the background interface although responsive to cursor hovers does not respond to the first click.
  • In Nodes layout Editing an Asset pops an additional Node Editor window. Subsequent Asset Editing happens in the same window. All Asset Editings should happen in the same window.

Blender introduced Geo-nodes a week before. C4D looked like it had gained ground in the race for 2 months and then lost it.

My advice is to make a system of nodes not too similar to others already out there. There is still room and time for innovation to make it more “native” to the rest of the C4D environment and also a better alternative to others. Nodes looks like it could be a higher lever of programming but due to its current complexity nessesary to achieve some simple things it currently is not. Right now ,to me, looks like low-level code lines turned to squeres and thrown on a grid.

Scene Nodes introduced some helpful functions but never gave the satisfaction to users to get them working outside the new system. I’m talking about Solidify and Greeble and the Mandelbrot, Mandelbulb, Spiral and Trefoil Distributors that could be optional modes in Cloner. The Brick Wall Generator looks interesting in the sense of having alternating offsets in a grid, looks like the Honeycomb Array but that Modulo node does add something more to it. All these could be implemented outside the experimental and incomplete Scene Nodes feature but for some reason they didn’t.

last but not leas, I insist that that IF node can be very powerfull if it gets a renovation with helper functions like Is_Neigbor, Is_Close, Is_Type, Has_Name, Has_Atribute etc… I think functions like these can bring some of my ideas from above posts to life easy.


I’m sorry that i can’t reply in depth here, so just a few things.

The Scene Nodes are the bare bones, lowest level of access a non developer user can get to the new object syste, of Cinema 4D. On the level currently exposed we do not expect most users of current Cinema 4D to be productive, this is one of the main reasons why scene nodes are officially and explicitly called a tech demo.

I agree that some names need revisiting, however in your examples you picked things that are not equal. While in many cases the results are similar, the method to achieve them is not and i am seriously reluctant to giving equivalent but definitly non identical things to similar names. This leads to the problem of the user having very specific expectations, that are not and can not be met.

This is coming back to scene nodes being a tech demo, they are not a production ready tool at this time but a glimps for the interested in how things work in general.

Especially the Primitive Op is actually a very good example here. The 14 primitive nodes you found are the source from which the Primitive Op gathers its options and the user is free to add to them by creating own primitves or adding third party ones. The main problem currently is exposure. Again a tech demo issue since the neccesary filtering of node is just not there yet.
All Fields and Effector nodes are currently just tech demo pieces.

This is by design, intention and necessity. In this first step the interaction with the old Cinema 4D scenegraph is minimal and due to the scene nodes being based on completely new technology there is no given compatibility with old elements. In this first iteration we accepted and embraced this, after all it is a demo of scene nodes, not an extension of existing CInema 4D functionality.

I think this will become clearer over time, again at this point this is still in development and we are learning as much as our users do :slight_smile:

Thank you very much for the feedback, it is much appreciated