Proposal: Addressing Geometry Nodes UX Issues

With the recent, very active development pace of Geometry Nodes (GN) in Blender, lack of features is slowly ceasing to be the limiting factor of GN potential and user productivity. However, this potential is still being inhibited by the accumulation of various, relatively minor UX issues. These issues together significantly impact user productivity when using this new, promising system so many development resources are spent on. This document is intended to be a compilation of these issues, with explanations, examples as well as proposed solutions.

Connecting a wire to already occupied single-input node socket will automatically reconnect the existing wire into a next node input, if there is one present (and is of same data type).

Blender currently always assumes that when the user wants to connect a wire to single-input node socket which is already occupied by a wire, the user intends to reconnect the existing wire to another node socket on the given node.

To an average user with no knowledge of Blender’s source code, it will seem that the automatic reconnection is based on a opaque, difficult to predict combination of some (or all?) of the following rules:

  • The node socket is right next to the socket that is being replaced.
  • The node socket is not occupied.
  • The node socket is of the same data type.
  • There is another, unoccupied node socket actually present on the given node.

Upon closer investigation however, it is clear this is not the case. Rather, each node socket has some hardcoded “alternative candidates” for a wire reconnection. For example, connecting a wire to an occupied “Specular Tint” node socked of Principled BSDF shader will reconnect the existing wire into a “Specular” input, even though both are quite distinct, different features of the shader which require different types of input.

This also demonstrates it is quite difficult for the user to anticipate the behavior of this feature in advance, as there is no simple rule of the thumb list, like on the example above, which would allow the user to reliably expect the outcome, instead of being forced to employ trial and error approach.

Lastly, this is inconsistent with the behavior found in majority of other Computer Graphics (CG) industry software. With the significant increase of Blender’s popularity in past few years, the idea of Blender being used as a part of pipeline, instead of standalone, full CG production suite is a lot more common. Inconsistencies like these make the use of Blender alongside other CG pipeline software a bit frustrating experience.

Of course, the point here is not to hammer Blender’s UI interaction model into a shape of other mainstream software just for the sake of it. In this particular case, it is just mentioned as another benefit of changing this behavior, complementing the other benefits mentioned above.

Proposed solutions:

  1. Preferred: Make the use of this feature explicit by requiring a modifier key press
  • Pros:
    • No more frustration from unintended, unmodifiable behavior, resulting in both expected and unexpected user errors.
    • Relatively easy to avoid keymap conflict as dragging a wire is a modal process, allowing restriction of the modifier key use to its scope, avoiding potential conflict with both default keymap as well as node wrangler.
    • Behavioral consistency with other CG software utilizing node based systems.
    • The feature remains existing, and may even become more useful when the user can more explicitly communicate the intent in advance using the modifier key
  • Cons:
    • Slight increase in complexity of the keymap, and therefore leaning curve.
    • Small learning curve step for existing Blender users.
  1. Remove the feature altogether:
  • Pros:
    • Same as 1.
  • Cons:
    • The minority of users with the skill of anticipating the complex behavior and utilizing this controversial feature to their advantage will miss it.

Solved by: âš™ D14457 UI: Address cosmetic papercuts of the reroute node

Reroute nodes switch between horizontal and vertical bezier curve tangents based on their location in relation to their input and output wires source location.

With the advent of node based workflow focus in Blender, it is inevitable that dealing with relatively complex node based graphs will be quite common for Blender users. Reroute nodes are important tool, allowing users to manage and improve readability of complex node based graphs by allowing them to be more specific and precise when it comes to routing the connections between the nodes in complex graphs. The means of aiding the readability of complex node networks is achieved through improvement of visual aesthetic, therefore this should be the priority.

Text formatting rules have evolved over time to aid readability of the text based interfaces, through the various means, such as spacing, character size, character colors, styles and so on. Visual interfaces, such as the one utilized by GN, should also facilitate easy readability of the node graphs, through similar means formatting. Bezier based node wire curving, already implemented in Blender, puts emphasis on the left to right horizontal flow of the node network data.

It’s working very well with the exception of the reroute node, which breaks one important rule; That Blender’s node based system are designed to be laid out horizontally. There are currently no node systems present in Blender, which utilize vertical node based layout, with node inputs and outputs placed on top or the bottom of the rectangular shapes representing the nodes.

As a consequence, every time a reroute node decides to switch its tangent direction to vertical, it becomes jarring experience for majority of users. It feels like finding a right aligned paragraph of text in a book populated by otherwise right aligned paragraphs, or stumbling upon a piece of source code, which blatantly disregards established formatting guidelines in a middle of otherwise pristinely formatted codebase.

While there may be some corner cases, where switching to vertical tangents could actually improve the visual aesthetic of the node graphs, even in those cases, the consistent approach of always horizontal tangents does not come off much worse:

Synthetic examples aside, below is a video showcasing the current state (on the left) compared to proposed state (on the right) on a non trivial node graph of average production scenario complexity:
Blender Reroute Node fixed bezier node links - YouTube

Lastly, current behavior, where user can not affect the direction of the reroute node tangents in a deliberate way creates often very difficult, frustrating choice of either compromising on visual aesthetic (and therefore readability) of the node graphs by having node wires overlap the nodes, or having vertical node tangent direction in exclusively horizontal node graph:
A tough choice between reroutes being vertically aligned with the node pins but having unappealing tangents versus visually pleasing tangents but vertical misalignment. There is no win here, just two different types of loss.

Proposed solutions:

  1. Preferred: Remove the feature altogether
  • Pros:
    • More pleasant visual aesthetic of the node graphs
    • Improved readability
  • Cons:
    • Some existing node graphs may need some readjustments
  1. Add user preference to toggle the “dynamic” aspect of reroute node tangents
  • Pros:
    • Preserving the functionality for the users who prefer the inconsistent vertical tangent aesthetic (is there substantial amount of them?)
  • Cons:
    • Overpopulating already overloaded user preferences by most likely underused option.

It is not always possible to place new nodes onto node editor area occupied by connection wires without connecting them to the overlapped wire.

As per the point already made above - With the advent of node based workflow focus in Blender, it is inevitable that dealing with relatively complex node based graphs will be quite common for Blender users. This also means it’s a lot more common for the users to run into a situation where they are working with a node graph, where the entire visible area of the node editor is occupied by nodes and wires.

In such case, it often becomes very difficult to add a new node to the graph without accidentally connecting it to a random, existing node wire, due to a feature which automatically connects nodes when placed on top of existing wires. This is, once again, an example of faulty user intention prediction, where Blender can not reliably assume this is really what the user wants to do.

The workaround for this becomes a frustrating chore of adding a node, scrolling away to find an empty space for node to place, hooking the remotely placed node to distant inputs/outputs, and the moving the connected node back to the place it was originally supposed to be.

One could make an argument, that in a modern software, which properly supports undo feature, this should not be much of an issue. In reality, unfortunately, unintentional connection of a new node to already existing graph can often trigger recomputation of heavy, expensive to compute operations, resulting in noticeable, frustrating delay, until the operation is complete, and then another, comparable delay until the operation is undone.

Proposed solution:

  • Make the use of this feature explicit by requiring a modifier key press
    • Pros:
      • No more unintentional connection of newly added nodes or when moving existing nodes.
      • Behavioral consistency with other CG software utilizing node based systems.
      • Relatively easy to avoid keymap conflict as moving a node is a modal process, allowing restriction of the modifier key use to its scope, avoiding potential conflict with both default keymap as well as node wrangler. While Ctrl key currently snaps the node movement, and Shift key improves the transform precision, the Alt key seems an ideal candidate, as it is unoccupied.
      • Functionality is preserved
    • Cons:
      • Slight increase in complexity of the keymap, and therefore leaning curve.
      • Small learning curve step for existing Blender users.

The “Auto-offset” feature state is stored per editor area, not user preferences.

Once again, with the high complexity node graph creation and integration becoming increasingly common occurrence in Blender, users who want to maintain their productivity high, even when dealing with significant node graph complexity, are often required to put some effort into arrangement of their graphs.

While Auto-offset feature may be useful during rapid initial prototyping of the node based system, it often becomes a hindrance in the stage where the backbone of the node system is finished, and parts of the graph are now manually cleaned up and arranged to facilitate good readability. In such case, it is preferred to turn of the Auto-offset to prevent breaking the meticulous existing node arrangements, like on the example below:

The addition of “Set Position” node with the Auto-offset feature has created more problems than it solved.

Unlike the issues mentioned above, this one can be solved as Auto-offset feature can be disabled. The problem here stems from the fact that the Auto-offset feature has been incorrectly categorized as a scene setting, rather than user preference. Usage of this feature is mostly a preference of how user wants to work.

Anticipation of the effects of this feature will sooner or later be embedded into the user’s muscle memory, so it does not make much sense for the on/off state of this feature to be unique across multiple different editors in single Blender file, or across multiple blender files opened by the same Blender installation.

One could make an argument, that the great flexibility of Blender allows you to change the state of this feature, and save the state in the startup file. The problem here is that the state is really stored per editor area, not just per file. Even in the case of changing the Auto-offset state in all of the open node editors present in the startup file, the change will be reset to the default ON state for any newly opened node editor, or even for the node editors closed and reopened in the same editor area.

Proposed Solutions:

  1. Preferred: Move the Auto-offset setting from the Node Editor(s) into User Preferences
  • Pros:
    • What is clearly a workflow preference will now remain in the same state across different editors and different Blender files, reducing the amount of unpredicted, unintended errors requiring undo.
    • Removal of one UI element from the Node Editor UI (which is also in an inappropriate place called View. Toggling this feature does not affect how the contents of the node editor are viewed)
    • Currently, the Editing section of User preferences contains multiple panels for individual editors, such as Text Editor. It also contains a setting directly related to the Auto-Offset feature - the Auto-Offset margin, but it’s currently present in the ambiguous “Miscellaneous” pane. This change could be executed aesthetically well by creating a new “Node Editor” panel, and putting both Auto-Offset toggle and Auto-Offset margin value there. This would improve user experience by grouping both of these related UI elements next to each other.
  • Cons:
    • Users relying on the per editor state of this feature will be disappointed (are there any?)
    • Existing users will have a bit of learning curve, having to find the new location of the feature.
  1. Synchronize the Auto-offset setting between all the node editors of the same type in the given Blender file (including editors created in the future).
  • Pros:
    • What is clearly a workflow preference will now remain in the same state across different editors, reducing the amount of unpredicted, unintended errors requiring undo.
    • The option stays in the same place, not adding to the learning curve for existing users.
  • Cons:
    • What is clearly a workflow preference will be stored within a file, not user preferences.
    • Related “Auto-Offset margin” setting will still be present in an unrelated place.

Solved by: âš™ D14458 Geometry Nodes: Don't create new node tree when adding a nodes modifier

It is not possible to apply existing GN data block to an object which does not contain existing GN modifier without unintentionally creating a new data block.

This is yet another example of unreliable user intention prediction. Currently, once the user has authored a GN asset in form of reusable data block, which they want to use on another mesh, the only way to do so is to create a new GN modifier on the target mesh. The GN modifier, unfortunately, always creates a new data block, incorrectly assuming that every time user creates a GN modifier, they are doing it for the purpose of authoring a new GN node network. In such case, a simple task of adding a GN modifier to 8 scene objects can up polluting the data block list like on the example below:
This can result in a state where the maximum width of the data block selector UI popover gets overpopulated by the generated garbage data blocks, and user has to resort to text search or scrolling to actually find the one they want to use.

This creates uncomfortable duty of either manually cleaning up the unused data blocks using the Blend File mode of the Outliner editor, or by saving the Blender file and reopening it. Neither is optimal, and distracts the user from the desired workflow attention.

One could make an argument that GN modifier coming with a GN data block by default simplifies the learning curve and user experience. However, GN is relatively advanced, technical feature of the software, requiring at least moderate technical experience to utilize properly. So if a model user is unable to figure out it is required to click a big “New” button after the GN modifier is created, it’s hardly imaginable they will be able to do anything productive with GN:

Furthermore, this behavior is also inconsistent with other modifiers. For example the Displace modifier does not come with a new Texture data block by default. So the argument for easier out of the box experience does not hold up here either:

Proposed solution:

  • Do not automatically create a new GN data block when creating a GN modifier
    • Pros:
      • The blend file is not populated with unintended data blocks
      • Users are not required to go through the chore of manually cleaning up these data blocks.
    • Cons:
      • In the case where user specifically intends to create a new GN data block through the Properties editor, one additional mouse click is required.

Just for the records, I asked @LudvikKoutny to post this here since we had been discussing this based on a google doc and it’s better to have it more open.

I think there’s some good news here, that many of these are addressed by WIP patches:

Other things aren’t handled yet though:

  • Automatic link socket switching with matching socket prefixes
    • I agree this behavior is very weak. I’d be interested if someone had a more solid design. Otherwise, I agree that removing it might be best.
  • Auto offset
  • Creating new node trees when creating a modifier
    • Your solutions sounds reasonable to me. Would need to get the opinion from other developers first though.

You read my mind, thanks for taking the time to clearly explain this. The only one I don’t care much about is the reroute node link direction, though it’s good to see that it’s being taken care of; other than that 100% agree with you.

This one specially gets very annoying very fast. I’ve been testing with a few node groups I intend to save as presets for motion graphics stuff and the amount of “empty” GN data blocks I end up with after 30min of work is just too high.


While it’s good, I am afraid many of these patches will end up in the forever-WIP state. For example here’s one from 4 months ago:
It’s not in the list above but it’s still another annoying UX issue. Lots of patches get made, but many of them end up forgotten.

In fact, the reroute improvement one will have its one year anniversary in couple of months :frowning:


That’s mostly on me being an amateur coder and doing this in my free time. The first implementations were more of a hacky proof of concept and it has only gotten into state I would consider potentially ok for review last month - at least partially.
Before that, there would need to be an agreement on the design, though.

The visual paper cuts like the kinks in node links or the off-center label can be easily split off into their own small patch, so they are not held back by issues with the rest of the features.
I’ll happily do that as soon as there is a general “go” that we want those things. :slight_smile:

With UI/UX stuff the design can be as much of a bottle neck as code review.
I appreciate you taking the time to phrase the issues so clearly and I’ll see if I can help implementing some of your ideas, if time permits.

Feedback to your proposal:

  • I like the idea of a “swap” operation for node links activated with a modifier key. Especially with Math/MixRGB nodes I find it handy to swap inputs from time to time.

  • I’d prefer “Auto-offset” to be a global editor setting rather than a preference. I do enjoy it in the sketching phase of node tree creation, as it helps to just get stuff out of the way but I turn it off once I start to clean up. So a preference would be a bit inconvenient for me.
    A preference is still better than having to disable it in every editor though.

  • I agree that creating an empty node tree with every new Geometry Nodes modifier gets old very quickly. Just creating it without a data block like every other modifier sounds good to me.


I am thinking about replacing the current functionality with one where holding a modifier key would plug the dragged wire into the selected slot and replace the dragged wire with the original contents of that slot if there were any.

So let’s say you have Node A plugged into Socket A of the Node B. If you drag out output of the Node C and plug it into Socket A of the Node B, the connection gets replaced by the output of Node C, but the output of Node A does not get reconnected to another slot.

If you do the same operation, but hold down a modifier key, input of Socket A on the Node B gets replaced by the output of Node C, and output of Node A becomes the new dragged node link, so you can reconnect it quickly. This way, you don’t need to travel back to output socket of Node A to reconnect it, if reconnection was your intention.

That sounds pretty much like what I had in mind.
The feature working across different nodes would be a cool benefit of the explicit operation compared to the auto-magic behavior we have now.

I have always felt that the alt modifier is underused. I often think that, if the alt modifier serves to disconnect a node, keeping it pressed works should serve to move around with the node, even panning, without it automatically connecting itself to another wire.

The same could serve when creating a node, since it is a modal operation. The user could create a node, and then hold the alt key or not (depending on the desired behaviour), before moving the mouse.

I would prefer to have to make explicit the not-connecting behaviour than the other way around, to be honest. Or there could be a toggle in the preferences.

1 Like

I was thinking, regarding the last issue, maybe it would make sense to have two different add menus in the modifier panel, one for shipped modifiers and one for custom nodetrees, and the one for nodetrees would show the list of nodegroups you’ve created in current file plus the ones you have as assets plus a +new option. Or maybe four different buttons, one for adding shipped modifiers, one for assets (though eventually some assets will be shipped), one for nodegroups created in present file, and one to create a new one. (Not too convinced about either option but maybe worth thinking about it?)

I completely missed this thread. Nice compilation, thanks for taking the time.

Regarding Auto-offset : it could be improved to account for “sibling” branches and move them along with the main branch. Fully agree with the rest of the points presented.

1 Like

I think the default theme should also have straight noodles and no grid levels. Noodle curving makes the node trees harder to read and organise with reroutes.

Grids serve no practicle purpose other than to accentuate that the UI of the nodes doesn’t line up with the grid squares

For video content, the old grid and the new dots just cause compression artefacts.

This would definitely improve matters! Also if the offset distance was some whole number of grid squares.

Also frames and nodes in frames mess up snapping to the grid too.

Actually one more suggestion, comment nodes. We need a way to comment node trees better. Text blocks in a frame just isn’t an adequade solution. I’m sure something could be peiced together quickly by a community member to this end.


I think the snap thing was solved recently:


Oh sweet - updated. I’ve been stuck in 3.1 the last week so I didn’t notice yet.

1 Like

I personally find rounded noodles much easier to follow and it seems like there is literature supporting that: Why Rounded Corners Are Easier on the Eyes. (I only did a quick google search though…)
So I think curved links are fine as a default - but it’s not like changing it is a big deal.

So true. One of my biggest pet peeves.

Yes! As node networks become more complex we really need for better tools to document them.


My take : the background grid of points provides a visual anchor when moving around. I tried disabling it as some of you do and it was disorienting… it felt like moving about in this white environment in the Matrix. A bit like disabling the grid when working on a single 3D object without context -I lose grip with where’s up, where’s down. Now we’re talking about the defaults, so it’s not exceptionally important, I know I can always keep it.


If this was fixed, I think I might just find inner peace :sweat_smile:


I think the major part of this issue is how the reroute tangents are handled. If that’s fixed, and the curving is a little reduced, it will probably look better than completely straight lines :slight_smile:

But right now, with the reroutes switching between horizontal and vertical tangents randomly, having completely straight lines is only way to make the node tree appearance palatable.



Oh, wow, that’s amazing news!
It’s really great to see that so much thought was put into the implementation to make it as seamless as possible!

This is great. Right now I OCD my node layouts to have straight lines without snapping, and I waste a lot of time. This is appreciated. Thanks for tackling this @lone_noel