A Bold Interpretation of the Guidelines
How nice it would be if the node tree is structured in such a way that it is largely self-explanatory and makes it possible to see what it is all about with as little time as possible.
A well-built node tree is the one that you can look at even after a few years, and where, thanks to its readability and structure, you can understand what you were actually thinking at the time.
A few guidelines or rules can help to present what has been learned in the best possible way and make it more accessible to others (especially for beginners).
Of course, some components of the presentation are also a matter of taste, and some node gurus have developed their own style over time (and are sometimes incredibly proud of it).
However, and this must be said honestly, mostly exactly these personal styles represent a personal opinion, and often it is exactly this that makes it difficult for others to quickly understand the original idea.
Structuring nodes is always an exciting undertaking once the node tree has reached a certain size.
The more branches and groups there are, the more unmanageable the structure becomes, and the more likely it is that one will lose the overview. Especially for others it is often difficult to understand what is actually happening here.
The human brain is always trying to recognize patterns, and if certain things are of particular interest, the focus is directed to these areas.
The trick is to arrange and place the nodes in such a way that an impenetrable thicket of noodles does not disturb the readability and the recognition of connections.
In the best case, nodes are distributed in such a way that they are grouped by topic or task, and the flow of information is easily recognizable at first (or second) glance.
In the case of nodes, however, it is essentially about their connections.
Therefore, it is best to group your nodes in such a way that the topics are delimited as much as possible and the connecting paths can remain clear and as short as possible.
By the way, you can practice this in a playful way, for example with this wonderful mini-game: Untangle
Tip: Use the Snap option when structuring/moving (you can find this option in the upper right corner of the editor window).
This allows you to align the nodes to the grid, which in principle allows you to achieve a more structured placement of the nodes.
Note, however, that this option is not only activated for the one window, but for all windows, which can sometimes be unexpectedly unpleasant in the 3D view.
If you use a
Group Input in several places of your node tree, avoid long connections.
You can place several nodes of type
Group Input with a clear conscience, because it simplifies things enormously and has no serious disadvantage.
This question has been asked here before: Do duplicates of the "Group input" on Geometry Nodes waste memory?
Try to provide repetitive inputs as
Group Input, so that you can easily use the same value at different places in the node tree without having to rely on long connection paths.
3. Horizontal or Vertical?
One of the biggest misconceptions about Nodes is that they are designed for a specific orientation: Horizontal!
Often you see node trees where the nodes are arranged one below the other, but this is actually not the concept behind it.
A node has its inputs and outputs on the left and on the right, and also the connections are oriented to a horizontal chaining!
In the release notes of Blender 3.2 you can read for example:
"Curved node links always attach horizontally to the reroute node to avoid breaking the visual flow."
So at the latest when you use reroutes, very idiosyncratic links are created, which can disrupt the visual flow enormously.
If nodes are not positioned horizontally, this can lead to the following problems:
- The flow of connections is visually interrupted, interfering with the ease of grasping the structure.
- Nodes can be collapsed vertically, and therefore it is easy for nodes to overlap once they are unfolded.
- Screens tend to be wide rather than tall, often making vertically distributed nodes difficult to grasp at a glance (Yes, here on BSE it's the other way around, but most users edit blend files in Blender, or enlarge the image anyway).
- The flow of nodes should never be retrograde if it can be avoided. This often makes it difficult to grasp the entire structure.
Note: The strength of the curvature of a link is also controlled by individual themes. It's possible that your shape forced into a vertical structure will look fine, as long as someone with a different theme doesn't have to work with it.
4. Save Space!
If the task of a node is clear and only the default settings are used, it is recommended to hide some parts.
Especially with large nodes this saves a lot of space and helps to keep track of the really relevant settings of a node.
So if it is possible, and this does not disturb the expressiveness of a node, consider the following tips:
- Hide the (default) options
- Hide the unused sockets
Additionally, you have the option to collapse a node completely.
This is handy if the node and its inputs/outputs are actually self-explanatory.
However, it is extremely clumsy and confusing for others when they try to read your node tree, because it also hides the names of the inputs/outputs and it is often not clear what is connected to what, because everything is extremely close together.
In such cases, you then have to manually expand the node, but this can lead to an overlap of the nodes again, for example, in a vertical arrangement, and the connections become even more unclear.
As a rule therefore applies:
- Minimize the nodes unless you are hiding relevant identifiers with them.
- Avoid consequent and ill-considered collapsing of the nodes just to save space. The readability of the whole construct should always be more important than the need to fit as many nodes as possible into a small space.
To work faster, use CTRL+H to hide the unconnected sockets.
If you want to be even faster, create an additional shortcut for hiding the node options:
- Open the Blender Preferences and the Keymap tab.
- Navigate to Node Editor -> Node Editor (global) and scroll to the end of the list
- Click on Add New and enter as identifier
- Add the shortcut CTRL+B
This way you have the hiding of the sockets and the hiding of the options right next to each other, and you can edit your nodes even faster.
A sensible approach is to always work out the prominent strands and to lead them as straight and short as possible from left to right through the node tree.
All side branches and offshoots are always built around the mainstream or branched off in such a way that it is clear that it is a side branch.
Tip: Take the space you need, because there is plenty of it! Only move the nodes together once it is clear to you how the flow runs or should run.
By the way, the curvature of the noodles is set individually via the theme.
Some people like to use straight lines instead of curved ones.
That's fine as long as only you use your node tree and as long as you do NOT share it with others!
If you do share your node tree, make sure the noodles flow well and stay clear even with curved lines.
It's that human brain thing again: this one can follow curved lines better, according to studies.
That's exactly why the noddles are designed that way by default!
6. Individual Names
If you follow the points mentioned so far, it shouldn't really be necessary to name any nodes individually!
If it still seems necessary, then you have not applied the above points correctly.
- Avoid renaming the nodes, they rather obscure the meaning or task of the node for others instead of increasing the readability.
- Use individual names of nodes only there, where despite another name a distinguishability to other similar nodes can be ensured.
Tip: To rename a node use the F2 key.
However, where individual designations are extremely important and correct, that is Reroutes!
It is actually not primarily important to know which task a Node does and to signal this with the renaming (the Node should be self-explanatory), but much more importantly is to know, which inputs are supplied, and above all: What output does a node provide?.
If you only show sections of your node tree and explain them with a picture, it is always important to know what information you are actually working with here.
Therefore use individual labels, but focus on the noodles and their Reroutes instead of the nodes.
Did you read the point about the noodles?
Yes? Then wherever possible, avoid creating angular structures with your Reroutes as soon as you share your screenshot or file. The visual "flow" should always be curved, because our brain can follow these shapes more easily (even if you might already be so used to angular shapes that you don't really notice it anymore, but then you're probably already a "Geometry Nodes pro" anyway).
Therefore the rule is:
- Use Reroutes!
- Use Reroutes especially at places in the node tree where there are transitions from one topic to another.
- Use Reroutes in large node trees there, where due to the space requirement always only a part of the tree can be regarded, and thus is not clearly evident, which data are processed.
- Name the Reroutes as good as possible!
This is especially true if you use only a part of your nodes as a screenshot, for example!
- Avoid angular and retrograde connections that can result from Reroutes.
Reroutes can easily be created by pressing the SHIFT key at the same time and crossing a noodle with the right mouse button pressed.
To move a Reroute, select it and press G
8. Frames & Groups
If it is still necessary to use individual identifiers, use frames as a priority and name them.
Frames are in many cases even better than
On the one hand you always create a new node tree with groups, and on the other hand it is technically mostly not necessary to create a group.
From a technical point of view, a group really only makes sense where a part of the node tree is to be used multiple times for a very specific reason.
If you compare it with programming, a group would be something like an own class.
Because this is often misunderstood as a space-saving thing, therefore also often the clarity of node trees suffers. Nesting always requires more clicks and the brain and hand ultimately have to do more work to get the overview.
Therefore, to save space, rather apply the above points instead of packing everything thoughtlessly into a group, because that's not what it was designed for!
Often it is enough to simply put a frame around a certain part of your nodes and give it a meaningful name.
The rule is therefore:
- Use priority
- If it turns out that node structures are repeated, and the clarity does not suffer from it, use
In both cases: Give them correct identifiers that allow others to understand what the part actually does!
9. Colors & Themes
Often the Picassos among us forget that other users may be using their own color schemes, and the unfortunate thing about individually set node colors is: Individually set colors are absolute and do not adjust to the individually chosen color scheme!
A much more drastic example: A white or black colored node would possibly make the text completely unreadable in another color scheme, because the node keeps its color, but the text color is defined by the color scheme chosen by the user, which can be white/light or black/dark.
Here you can see a node with the individually defined color #333333:
And here is the same node shown with a different color scheme:
So it's basically good to highlight something particularly important with color, but use it sparingly, choose the color wisely, and keep in mind that in a different color scheme your individually defined colors would be used exactly the same way.
Note: The same applies to the size of the node, as you can see in these screenshots. For example, if you resize the node so that the text remains readable, also note that the font size may be defined differently in another theme.
Food for thought: By the way, there are also people who use certain color profiles due to a visual impairment (e.g. color blindness), or who do not see things the way you do for other reasons.
Remember next time, don't make the significance of your nodes dependent on colors.
Tip: If you like to show your nodes in a color scheme that fits better into this Q&A platform, you can download this theme here. I created this to be able to show node screenshots a little more clearly. However, it is less suitable for day to day work with Blender in my opinion.
Out of respect for the readers, the picture should actually always show exactly what is directly related to the question or answer.
Not more or less!
Nobody has to care about what else you have on your desktop, and you should not bother others with it!
In the worst case, such a screenshot can even be a problem in terms of privacy and data security, which is why screenshots created in external programs should generally be avoided.
In general, the function integrated in Blender should always be used to photograph the nodes.
In Blender you have two options to choose from:
- Save Screenshot
Creates a screenshot of the entire Blender window, but without the operating system specific window bar.
- Save Screenshot (Editor)
Creates a screenshot of a specific editor window within Blender.
Unfortunately there is currently no usable way to create screenshots of really large node trees. The size of the screenshot is always limited to the size of the window/editor.
However, there is a little trick (if you have multiple monitors) that can help at least partially: Just stretch the Blender window over the whole size and then take a screenshot of it.