How can I better structure my node tree and make it easier for others to understand?

Question

I built a Node with a Geometry Nodes node tree, but now I only see knots instead of nodes, which drives me nuts, and don't know how to make it look great again.

As you can see, I have what I think is a beautiful node tree here, which creates a node:

---

At first glance, this looks completely like an opinion-based question, but after some research, it turns out that there are obviously basic mechanisms here that have often been misinterpreted at the grassroots level.

Hence the question:

How should nodes be structured and represented so that the general public (and I) can better understand them?

WARNING

"Stack Exchange is not suitable for such a broad topic precisely because it is not designed to handle threaded nuanced dialogue covering many points." – (Marty Fouts)

So please note that the answers below are an extensive "collection" of tips & tricks, as well as individual interpretations of the underlying facts that Blender gives us. Some of the positions presented are also partially contrary, and somewhere in the middle might be the right path for you.

So this contribution here is an unusual exception, which deviates from the actual concept of this platform, both in content and structure!

-- The only reason why I do not delete this question is because it is the only one here, which deals with this difficult topic rudimentarily, and here especially beginners can learn many useful tips at one place.

Answer 1

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.

1. Structuring

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.

2. Inputs

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.

Tips:

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:

1. Open the Blender Preferences and the Keymap tab.
2. Navigate to Node Editor -> Node Editor (global) and scroll to the end of the list
3. Click on Add New and enter as identifier node.options_toggle.
4. 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.

5. Noodles

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.

Therefore:

• 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.

7. Reroutes

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.

Tips:

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 Groups!

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 Frames
• If it turns out that node structures are repeated, and the clarity does not suffer from it, use Groups

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.

10. Screenshots

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.

Answer 2

This call for organizational awareness echoes the sentiment of a site called Photoshop Etiquette. Yes, there is an entire website devoted to organizing PSDs. Turns out it's a pretty good read, and many of the concepts also apply to Blender.

Data organization is a broad topic, but even if we restrict the topic to nodes there's plenty to talk about.

Flow

Nodes should flow from left to right, and this should be visually obvious.

^{Markus von Broady pointed out a good exception: "make the flow horizontal from left to right within a frame, but free in any direction between frames".}

So, large chunks of Framed content can often be stacked vertically and still visually make sense. But in general, somebody who has never looked at the node setup before should be able to identify the flow, and it should go this way →

Frames, Reroutes, and annotation

Join CtrlJ nodes into Frames. Categorize clusters of nodes according to what they are actually doing. I think most of us do this already, but I will add a few further suggestions:

You can actually use a text file to add "documentation" to a Frame. But if there's a way to make the setup self-explanatory and intuitive, that's even better than adding documentation.

You can peg a Frame with Reroute nodes as studs to widen it enough to fit a lengthy title.

...where the magic happens. There's a 63 character limit on Frame labels.

Label size can be adjusted too, but I'm not sure how I feel about requiring the user to zoom in even further than they already have to. Use sparingly.

Reroute nodes inside a Frame, if you give them labels, can make for nice bullet lists.

Value

Use Value nodes as controllers, then move all those adjustable parameters to the left. This will spare you a scavenger hunt when you're trying to locate which parameters you actually intended to tweak or automate.

When animating, keyframe your Value nodes instead of the main node itself, because you can always plug a value into something else and route that signal to multiple places, but the reverse is not true.

The types of nodes you find in the "Input" section of the Add Menu are the types that should probably be on the left side of your node tree, keeping with the left-to-right flow, and also considering how grouping works.

Keeping all your parameters to the left makes it easy to find them when you need them. As an added bonus, it also makes it much easier to group them! The nodes you want to select and group will all be to the right of the input values.

Snapping

Snap to the grid. Even though the grid when inside a Group node is offset a bit from the regular non-grouped grid (still irks me), aligned is better than unaligned.

You can leave Snapping off and call upon it by holding Ctrl while moving your nodes.

Reducing visual clutter

It is possible to adjust the straightness of your wires or "noodles" to suit your preference. The shortest distance between two points being a straight line, straight feels like less cognitive load for me personally. And if while you're working, a wire gets occluded behind other nodes, it's easier to follow it if the path is straight. Opinions on this will vary, so luckily we can customize it. Just remember that the look can be changed in Preferences → Themes → Node Editor.

Hide (toggle): H

To Hide or not to Hide?

I generally don't completely Hide nodes, because if I'm sharing a screenshot on SE I'll just need to unhide them anyway to show what they're doing. Plus, I like to be able to see what's happening at a glance.

An exception to this is when the node's purpose can be summarized in a label:

^{Here we are just making the value negative by multiplying by -1. Let's Hide the node and give it an intuitive label instead.}

Hide Sockets (toggle): CtrlH

It is generally a good idea to hide unused sockets. But bear in mind that seeing the values of sliders can be valuable too. If a slider's value has been changed from its default, it should probably not be hidden.

Group nodes

Your Group inputs will be hard to read unless you give them short input names or tick the "Hide Value" checkbox. Sure, you can click-drag to widen that individual Group node, but when new ones are added they appear at the default size.

If a socket's slider is unlikely to be used, "Hide Value" to get rid of the slider.

Certain input sockets should only receive Integer or Boolean data. But Material Nodes currently do not support the ability to specify these data types. Therefore, we should label them in a way that the user can tell what type of number to dial in.

Channel No.(Int)

Use Alt.(Bool)

Probably turn off Auto-offset. This feature causes your nodes to move for you as you place them. While it's nice to have the option, I've found that when it's enabled arrangements tend to creep far out of position as more nodes are added. People will probably have varying opinions on this, but leaving it off works for me.

Try to leave your Output node more or less in its original place. Then when you switch from one material to another your "home base" will always be in focus. This might be a bit obsessive, but it's at least something to be aware of.

Keeping Group or Geometry Nodes' Input and Output nodes on the same spot on the Y axis can help your node tree stay basically horizontal as it grows.

If an Image Texture node is modified/mapped in multiple ways, just Group it as a reused asset instead of creating multiple copies of Image Texture nodes containing the same image.

Then we can place an instance of the grouped Image Texture on the left, at the "beginning" of our node tree. This provides easy access when we want to change the source image, and we only need to tab into the group and change it once. Maybe one day Material Nodes will be blessed with a Texture Input the way Geometry Nodes have, but until then, this method can help.

Polish your reusable assets before reusing them over and over. Wouldn't you rather check your Group settings and set the default input values to something logical now... instead of appending your Group into another .blend and in the future only to find that for no apparent reason the texture alpha defaults to 0.8663? (For example.)

If you think you or someone else might want to get at these nodes using Python, give logical names to their data blocks. Math.006 is not a very descriptive name. How about Math.ScaleX instead? Some kind of naming convention is better than meaningless trailing digits.

Scale

Try to unify the scale of your materials as much as possible while building your node tree to avoid headaches later. If you use a single Value node to control your material's global scale, then when resizing your material, all the texture components (images, procedurals, etc) should ideally scale together uniformly. So instead of:

• Mapping - scale: 0.5
• Noise Texture - scale: 4
• Wave Texture - scale: 20

try setting up a Value node with Math:Multiply nodes to control the master scale:

• Mapping - scale: Value * 0.5
• Noise Texture - scale: Value * 4
• Wave Texture - scale: Value * 20

Since properties such as Bump:Height and Subsurface Radius are also relative to the object scale, consider linking these values to your global scale as well. Although it may not be realistic to always expect materials to be scalable without the appearance changing in other regards (especially with more complex materials having multiple types of Texture Coordinates), certainly the more unified your material's scale is, the fewer issues you will need to troubleshoot if you need to resize it at some point.

Make sure the object(s) you're designing your material for are at a scale of 1.0, and that meshes are at a "real world" size (if texturing real world type objects). Take 1 Blender Unit to equal 1 meter.

On the other hand, when designing a tiling pattern for general use it probably makes most sense to design it so that a scale of 1 equates to 1 UV tile.

Purge unused dependencies

If you drag an object from the Outliner into your Geometry Nodes setup, that value gets remembered, even if it isn't used in the end. So you might Append a GN Group and it will bring with it some random image texture you used when you were first creating it, but it is no longer needed. To solve this, unplug the wire from the input socket, clear the data block, and then plug it back in.

Final thoughts

There you have it. A bunch of "best practice" sort of guidelines. Admittedly opinionated, just like the other answers here - but hopefully offering some usefulness as well. I don't insist there is one "right way" to optimize, but being aware of different strategies puts more organizational tools in our toolboxes.

Answer 3

You could find your answer in Psychology, in fact it's quite a well studied field. It's known as Gestalt Psychology or Gestalt Principles of Visual Design. It's the study of how we humans perceive a group of individual parts as a whole, how we recognize structure into that. So, in my opinion, this is an excellent question!

Gestalt Principles of Visual Design

Some claim there are 5, other say there are 7 or even 10. Here is a shortlist.

Principle of Proximity

Grouped objects are being perceived as one. So keep your nodes which belong together close together.

Principle of Similarity

When objects look alike, we see them as the belong together. Have you noticed the colors of the nodes and lines? The shape and colors of the inputs and outputs? You could change the colors of nodes and frames.

Principle of Continuance

Your eye wants to move from one part to another, following a path. Try to organize your nodes in such a way where the eye doesn't have to jump from point to point. Make it flow in one direction as much as possible.

Principle of Simplicity

We human optimize and simplify everything we see. You should make this easy. Try avoid crossing lines, for example.

Principle of Common Region

When we see a group of things enclosed in the same container, we tend to see them as one. It helps to use Frames or Node groups for mathematical calculations which we see as one already.

Principle of Focal Point

Some things draw our attention more than others. It's kind of funny that the Input and Output group nodes are gray/black contrasted against the blue/purple of the math nodes, the red of the input nodes. However, the green of the geometry operations and geometry lines is fitting. They are the most important and tends to draw our attention. Consider changing the size and color of the Input/Output groups.

Principle of Closure

We tend to fill holes in the shapes and structures we see. Probably not as much as applicable in a node tree as the other Principles.

Surely I missed a few, but keeping these few in mind should already make your Nodesoup much more readable, according to the literature.

Answer 4

After reading quellenform's answer, I think this is pretty much an opinion-based Q&A, as we're both experienced with geonodes and yet we have wildly differing opinions...

From General to Specific

Read all the headers of this answer, then return here to read the rest.

We live in a crazy world, and yet we're only monkeys [poetic license] who can remember only 5-9 things at once. So you can make a very tidy-curvy-horizontal setup, but that alone isn't enough, and as quellenform mentions, you need frames:

(taken from How can I make a cube with mountain surface only on top of the face in geometry node?)

In this setup you can clearly see 7 distinct frames. The colors are not random: one is the color of the Noise Texture node...

💡 Tip: when setting a frame color, you can use a color picker and pick it from the node that is the heart of the frame.

... Y is green, X is red, negative X&Y are darker. You can, albeit barely, read the titles of the frames. You can also see a mess on the right side, I ran out of time budget. 💩

So you have a general overview of what happens. You can now ✲ Ctrl$\color{green}{█}\color{#888}{0█}$ click on the image, to open it in a new tab and zoom in (I think ideally it should have 2x the resolution it actually has).

Now let's see what happens if we resign from vertical links:

The width increased, though only a little, because in this setup the left/right/top/bottom frames were parallel (in many of my setups it would be much worse, e.g. Is it possible to dynamically collapse all edge rings or scale a tube thickness to zero using Geometry Nodes? [duplicate]). After scaling the text shrank. Still visible to me, but worse. Readability of connections got considerably worse. Could I do a better job? Maybe, but now I would need to reason about what is the perfect spline width/height ratio, or at what angles are splines allowed to cross, or how close can a reroute be to an intersection etc. The thing is, geonodes already trend to be the most time-expensive answers. Using vertical links is trivial: they always cross at maximum angle with horizontal links. Scanning where the link goes is easy, because you easily remember its x or y position (like reading a table). So the comparison reminds me of the labyrinth sketching scene from Inception...

My advice: make the flow horizontal from left to right within a frame, but free in any direction between frames.

BSE or Production?

Use a lot of Custom Groups (Don't use Custom Groups)

I'm a big fan of being goal-oriented. When developing a personal or professional project, encapsulate with Custom Groups (yes, also for single usage!). Someone who modifies your setup (including you) on a higher level of abstraction, doesn't need to know (remember), how "find 2nd nearest" group works.

On the other hand, someone on BSE, recreating your node tree (especially in Blend-Exchange-less future) will need to read it all, go back and forth between multiple images, often on a single computer screen, maybe smaller than yours, maybe on a phone... And some readers test answers for correctness so they absolutely need to understand everything.

BTW, Custom Groups create Input/Output mess, and can't evaluate self, even though internally it's not a circular reference:

(from Red shader node noodle (line) from node group vector output to image texture vector input)

Renaming Nodes

quellenform's 2.4. Save Space describe me pretty well. Robin Betts goes a step further to minify so much that some data becomes hidden and requires the node title to be renamed to inform what it does.

My recommendation is to DO that. My beginnings in geo. were hard (Capture Attribute and Transfer Attribute nodes still haunt me in nightmares), and this technique by R.B. helped to manage all that mess. I no longer do that, however, because it does (slightly) degrade readability, and usually I happen to have enough free space anyway.

Remember, while it's obvious what x + 1 means, some people might have problems to reproduce log2(x) - is x the base, and 2 the value? What about renaming Combine XYZ to x;0;0? Even leaving the default names causes issues.

I still rename εpsillon type of nodes, for a different reason: sometimes the tolerance value is too precise to be fully visible - then I rename e.g. Compare to Compare ep.=1e-6 (to show the value is not 0, even though that's what the field displays), or Compare ep.=0 (to confirm it's 0).

Miniaturization

I space connected nodes by 2 snapping steps. 1 snapping step makes it hard to link nodes before v3.2.0. However, if two nodes aren't connected, I allow them to be 1 step apart, which (ironically) communicates they don't interact:

I also resize the nodes horizontally to make them as narrow as possible without decreasing readability. Above Radius became R, but it's pretty obvious what it is. Subdivisions become Subdivi which is long enough to figure out what it is - not pretty but readable. Recently I learned to narrow the Attribute Statistic node all the way in, as then it becomes Attribute Stat, which is pretty nice and readable. Just keep in mind, when taking a screenshot, it may become Attribute Sta or Attribute Stati due to how font hinting works:

In order to snap the right sides to grid, you can press ⬆ ShiftF4, then paste the following script:

C.area.type = 'NODE_EDITOR'; exec('for n in C.selected_nodes: n.width = round(n.width/20)*20')

I hide all sockets irrelevant to the setup, e.g. if I don't connect anything to $\color{#cca6d6}{◈}$ Selection in Delete Geometry, as it can't be set manually inside the node (with a reasonable assumption no Python hacking was done):

Or hiding Z component for a 2D vector used for a 2D texture. Or Fac/Color, if I don't use both:

(If Detail=0, Roughness would be irrelevant as well)

Symbolic Regression

There's many tools that make you seem smarter than you actually are, for example if you have some maths:

write down the formula equivalent of your node setup:

$a² - 2ab + b²$   or   a^2 - 2ab + b^2

Type it into Wolfram Alpha, look for the alternate form that produces the least nodes, and enjoy saved space:

Vanilla - use default settings

You may change settings to improve readability, however, if you use a theme to your own pleasure, consider taking screenshots in factory defaulted instance of Blender. Consider how a newbie user may understand a $\bbox[#3c3c83, 7px]{\color{white}{\text{dark slate blue Add}}}$ node is Vector Math, but $\bbox[#246283, 7px]{\color{white}{\text{teal Add}}}$ node is scalar Math. Non-standard colors can be confusing...

☯ Find Balance

I argued for a standard theme, but maybe different colors put some life into your work and make it fresh and cool and therefore interesting and motivating to read it and learn...

Try to save space and make your setup concise, but not so much that individual nodes become cryptic.

And finally:

Try to improve the readability, but remember you could spend your time answering more questions instead - estimate what is the optimum for the community's benefit; don't be religious about it! In the patch 3.2.0. Blender devs decided to demotivate from the links flowing to the left, which interfered with the conventions I finally worked out. So I could change my habits, or stay at 3.1 for a while, or... I could also choose not to care about this:

Answer 5

IMO, if they were in another category such as modelling, many [Geometry Nodes] questions would be considered too broad.

Node-coding is verbose. Comprehensive answers to those questions require trees which are simply too big to illustrate in a BSE answer, however you arrange them.

In a domestic recipe book, the instructions for Sauce Mousseline might start with an ingredients list:

• 1 tbsp water
• 2 tsp lemon juice
• 1 egg
• ...
• 1/4 pt whipping cream

and follow up with a method:

• Separate the egg
• Chill and dice the butter into 1/2" cubes
• ...
• In a heat-safe bowl, combine water and lemon juice with a pinch of salt
• ...

.. and fill many pages of paper, or ad-filled web pages, with repetitions of the above. In a professional kitchen manual, the recipe would be:

• Lighten a Sauce Hollandaise (p. 14) with whipped cream.

If we can't reasonably constrain GN questions, at least we could try to make the answers more modular? The ambition of a good GN answer could be to include re-usable node-groups, (that do one thing and do it well,) and cross-reference groups from other answers, wherever possible.

Answer 6

A very important thing that for some reason no one mentioned yet is:

Do not have any connections go over or under other nodes!

This is the first thing you need care about. If you look at all answers proposed prior to this you will see that they all did this without mentioning it.

Noodle curving:

I have always been a staunch defender of straight noodles that is until Blender 3.2 fixed the single greatest issue concerning curved noodles, which were reroutes.

So if you are using Blender 3.2 or newer her are 3 reasons why you should use curved noodles:

1. Thanks to the noodle curving you will have significantly less overlap of your connections.

2. If you have long connections with straight noodles the inadvertently will pass over other nodes. with curved noodles you can be more loose about the rule of not having connections go over or under other nodes. Why is that? Because with curved nodes wherever the noodle is horizontal is where it is connected to. With straight noodles it may go over an input/output without actually being connected to it, while looking like it is.

3. If for some reason you do have retrograde connections you will run into the issue that you oftentimes can't see if an output is actually connected to something or not, as the connection directly passes under the node. Curved noodles however always have a little buffer after the the output thereby eliminating this issue.