Feedback wanted on node layout changes to match the node grid

[lone_noel]

Because of our layout system and the multitude of layouts and widgets shown on nodes, the spacing of those widgets as well as the node’s sockets can vary a lot.
As a result aligning nodes and/or their sockets with each other to create tidier and/or better readable node trees can be frustrating and time consuming.

In D14466 I started working on this, and while I’m already happy with the improvements in the patch over what we have right now, the feedback on the patch prompted me to develop this a bit further.

I start by laying out the idea behind D14466, the advantages and disadvantages I found.
After that I’ll present some further things that came to my mind to address some of the things D14466 doesn’t handle, yet.

D14466

The changes in D14466 include:

• Increasing the node grid spacing to be 1.1 times U.widget_unit instead of 1.0 to match the socket spacing
• Use a column layout for the node option widgets so they align with the socket spacing of 1.1 U.widget_unit
• Offset the sockets of reroute node by half a node grid unit to align with the node sockets

Before:

With D14466:

Things that are not so nice:

• It doesn’t really handle hidden node sockets other than center aligning them a bit better. Not worse than before, but not much of an improvement either.
• The multi socket has to grow either…
  • (a) in large increments of one grid unit to keep the other sockets on the node aligned or
  • (b) as it does now, often messing up the alignment of the sockets below it

---

From the feedback I got on D14466 (a) seems to be preferred but I’m not sure about that, yet.

Videos of the multi socket expanding

Scenario (a)

https://dev-files.blender.org/file/data/3eecjzxet3xcqlbssry2/PHID-FILE-2325vb4rvrlpuiluuoyg/multi_input_socket.mp4

Scenario (b)

https://dev-files.blender.org/file/data/qm5kf3rdz46w6qxiwhd6/PHID-FILE-s4j2lq4zzm572crvjutt/better-multi-input-handling.mp4

These points motivated me to think about an alternative way of approaching this. I’m not yet sure how much I like this, which is part of the reason I’d like to get some feedback.

Alternative: More dense snapping grid and grid based hidden nodes

Rather than using 1.1 U.widget_unit as in D14466 we could go one level smaller and make the snap grid exactly half of that.
This would give us all the proper alignment of D14466 but would allow generally tighter layouts and link routing. On top of that with the smaller grid spacing multi sockets could also expand in smaller increments which would look a bit nicer.
The one downside I could see is that 0.55 U.widget_unit might feel a bit small at certain zoom levels making snapping more finicky.

That being said, the big motivation for this would be that this would allow making hidden nodes grid based.

The current design for hidden nodes is very compact, but the circular arrangement of sockets doesn’t lend itself very well to any type of grid based alignment, which is why there isn’t much done to them in D14466.

With a grid spacing of 0.55 U.widget_units, it would be possible to very compactly align the sockets vertically along the node. As a result hidden nodes would be more rectangular, which makes them less compact than the current solution but the tighter snap spacing would still allow for overall more compact layouts. Here’s a prototype showing what this could look like. It doesn’t win beauty contests, but I also don’t feel like it’s worse than what we got

Current

Prototype

More Screenshots

---

Collapsing

Current

Prototype

---

Socket Alignment

Current

Prototype

---

Tidied node tree

Current

Prototype

Questions

I made this topic to move the discussion from the patch itself and get feedback from users and maybe other developers before putting further work into D14466.
Feel free to share your thoughts, but please refrain from feature requests outside the scope of this proposal.

Some questions to get you started:

1. Do we want any of this?
2. If “yes” is the improvement in D14466 enough or do we want something more wide reaching as proposed in the alternative?
3. If you prefer what’s already in D14466, which handling of the multi socket would you prefer?

[kuboa]

Thanks again for this greatly needed patch, and for opening a discussion thread for it.

1. Yes, we absolutely want this, or something like this. There is exponentially more node-tree setups now that Geometry Nodes is a sizeable part of the Blender world, and the inconsistent, finicky state of the grid snapping is hurting the experience.

2. I’d vote for Scenario a, where the multi-input sockets get bigger incrementally with the grid to make sure all sockets align all the time. It does look more awkward for the individual nodes that have multi-input, but the overall consistency of the node tree is much more important, imho. Otherwise, we end up with wildly varying gaps between vertically stacked nodes. Could the awkwardness be somewhat remedied by re-aligning the noodles so they’re spaced equally when the socket widens? I guess they would “jump” when they snap in that case, but I don’t know how bad that’d feel.

3. Sockets always aligning with the grid is important. That said, I find the “Alternative” hidden node design a bit too much. As long as the middle input and output sockets in a hidden node is aligned with the grid, current design should suffice, I feel. Hard to tell from the screenshots though, they’re mostly shown in isolation, I’d love to look at them with different node setups along non-hidden nodes and straight noodles etc. Will you be creating a second patch for the alternative?

[lone_noel]

Thanks for the feedback.

I’m not liking the look of the alternative hidden node very much either. Using it in my tests and having everything just line felt kinda nice though.
But maybe that’s just the smaller snap increment.

I don’t think I’ll open an extra patch on d.b.o for the alternative, but here is an up to date .diff-file, in case you can build it yourself and are interested in testing:
pasteall.org: node-grid-alignment-alternative.diff

[USB10]

With this new patch, suppose if I connect a lot of noodles (say around 10 or more) to a multi-input socket (like that of Join Geometry node), the node will get longer and longer. Won’t it look distracting?

@lone_noel

What if you make the noodles connect perpendicularly to all the sockets instead of just making the collapsed node longer? Because now the collapsed nodes will no longer look collaped as there’s not much difference in height between the 2 modes (normal and collapsed).

You probably don’t want this to happen:

erindale.xyz 🍥 (erindale_xyz)

[Stimes]

One thing you can add is a personalisation of the wire connexion like this : and let user choice what he pref between both

[Hadriscus]

Generally this is a much needed improvement and I’m happy you tackled it.

The multi-input socket growing every 3 or so connections looks a bit weird tbh. From looking at it without your explanation, I would wonder if something is off with my node tree. Not a big deal, but I’d try to avoid it. Maybe rethink the entire design? make it into a single (bigger) round socket? sure we’d lose the ability to re-wire an existing connection as we can now, but I don’t really consider it vital.

If we keep current design, why not “simply” make it as tall as there are connections? say there are three connections, make it three units tall. Would it be too much?

I’m not so fond of the new collapsed nodes, on one hand they look much better when they’re short nodes (math, etc.) but on the other hand the principled shader -and other naturally tall nodes- look strange when collapsed : not that much space is gained and we’re losing all the node contents in the process. It doesn’t seem like a worthy tradeoff to me. I don’t have something better to offer right now, but I think it’s worth thinking about it a little more.

[Strike_Digital]

Personally, I think that if the noodles can be spaced out evenly as suggested by @kuboa :

@kuboa

Then the jumping every 3 or so noodles is absolutely fine for me. It will maybe only look a little weird for a moment when it jumps, and then after that I wouldn’t notice it again.

As for the rest of it, I think it’s a much-needed improvement, and you’ve obviously put a lot of thought into it already, so I can’t wait to see it finally implemented!

As with others, I’m not a massive fan of the new hidden nodes, but I think that with a bit of time I could definitely get used to them.

[Lloyd_Almeida]

Superb job with alignment, the Nodes looks a whole lot neater and take a little less horizontal space. This is much needed finesse, thank you for effort.

Personally I don’t mind the the increments as long as the sockets align well. There are currently only 3 Nodes with expanding sockets and I feel it is a good UX hint that a lot more connections can be made ( If the increments could be reduced that would be perfect )

Regarding the Hidden state, kindda on the fence on that one. It would make connecting to the Sockets a bit easier in the Hidden state ( If a user is familiar with the Socket order ). Also not too sure of the horizontal accents, I feel it adds noise .

On the other hand no more funky trees !!

I have a few observations, but I do not know how difficult they are to implement.

• The Default Width of the Nodes when they are created could be increased (as some Text truncates) and made uniform for that Category. Nodes affected are Texture and Color Nodes in the Geo and Shader Editor, Principled Nodes in the Shader Editor, Filter Nodes in the Compositor.

Below is an example of all the Texture Nodes in Geo Nodes with a similar width ( Image Texture has been reduced )

• The Color Swatches width is a bit off. It needs to be reduced to 50% of the Slider size to align. This will reduce the Default Width of many Nodes while still keeping the Text complete. eg Principled Nodes

• Fac could be changed to Factor in all the Nodes, there is space and its more explanatory.

If you want I could identify all the Nodes that need tweaking. Thank you again for you efforts.

[duarte.framos]

As already stated at the task this is very welcome change indeed.

Regarding the hidden node sockets, I think their main goal is being compact and saving space, even if unsightly or misaligned. Since you most often hide them when not directly working with them, forcing grid alignment would defeat their purpose and main strength.

Other than grid aligning the “central” socket when possible I would not force a grid layout in this situation, I think it goes against the main goal here of being compact.

Other than that for multi input sockets I’d still vote for making them grow organically as they do now but guarantee grid alignment for the top end of the multi input socket and for first socket below it, the following ones would naturally grid align again. I think it is the most future proof and “visually neat” solution even if the “jumping” sockets may look a bit off at first.

[lone_noel]

Thanks a lot everyone for the thorough feedback!

@duarte.framos

Regarding the hidden node sockets, I think their main goal is being compact and saving space, even if unsightly or misaligned. Since you most often hide them when not directly working with them, forcing grid alignment would defeat their purpose and main strength.

Other than grid aligning the “central” socket when possible I would not force a grid layout in this situation, I think it goes against the main goal here of being compact.

I think this puts it very well. And since the overall sentiment seems to be, that the prototype isn’t very appealing anyway - which I don’t disagree with - I’ll scrap that and concentrate on the alignment of the expanded node layouts, as I originally set out to.
That’s also a less intrusive change and therefore has a better chance of being accepted.

Also thanks for all the suggestions to improve the handling of the multi input. I’m sure one of them is bound to be good enough!
I’ll see if I have time to prototype them by the weekend and will post the results and patch files to test here.

[Claus]

I might be crazy, but could you test something like this? I wish I had the skills. It’s probably horrible for everything, but I’m curious at the potential.

[brecht]

I don’t think the changes in this prototype for collapsed nodes are really better. Perhaps for collapsed nodes it makes sense to only show sockets that something is linked to, maybe with an exception if a node has only 3 input or less. A long list of unnamed sockets doesn’t seem that useful regardless of their layout.

[Hadriscus]

I’m thinking, we may not be losing out on much by simply collapsing all sockets into one. That would make collapsed node trees very simple, visually speaking.

[lone_noel]

@brecht

Perhaps for collapsed nodes it makes sense to only show sockets that something is linked to, maybe with an exception if a node has only 3 input or less. A long list of unnamed sockets doesn’t seem that useful regardless of their layout.

That sounds like it would be a pretty good improvement!

@Hadriscus

I’m thinking, we may not be losing out on much by simply collapsing all sockets into one. That would make collapsed node trees very simple, visually speaking.

I think this is true in a lot of cases, but I often use collapsed nodes when doing a bunch of chained math operations. In those cases having separate sockets can be useful for operations that are not commutative like Substract or Cross Product. Those would become less readable.
So I’d prefer keeping small amounts of sockets visible by default.

[Claus]

@brecht

Perhaps for collapsed nodes it makes sense to only show sockets that something is linked to, maybe with an exception if a node has only 3 input or less. A long list of unnamed sockets doesn’t seem that useful regardless of their layout.

Doesn’t ctrl-h already do that?

@lone_noel

chained math operations

I feel like there should be a node just for this.

[LudvikKoutny]

@brecht

A long list of unnamed sockets doesn’t seem that useful regardless of their layout.

Vertically aligned long list of unnamed sockets is still an improvement over vertically misaligned circular blob of unnamed sockets. Especially in an editor which uses rectangles with rounded corners as a visual language. Capsule shapes then end up looking really odd.

I agree that it’s not an improvement that reaches its full potential, but it’s still a significant improvement worth having.

Overall, I think it’d be a good idea to think about whether we even need node collapsing and hide unused node sockets operator living alongside each other. It could be better to combine both into superior feature which covers both use cases.

[Hadriscus]

@LudvikKoutny

Overall, I think it’d be a good idea to think about whether we even need node collapsing and hide unused node sockets operator living alongside each other. It could be better to combine both into superior feature which covers both use cases.

Yes ! entirely agree. There should just be a single mechanic governing node & socket display, I believe that would simplify usage. Right now I’m never too sure whether I should collapse nodes or hide unused sockets.

[LudvikKoutny]

I just always hide sockets and forgot that the collapse even exists, because of how ugly shapes it produces. And lack of node socket titles is a dealbreaker too. Without them, it’s hard to tell what you’re looking at. Clearing the node tree clutter is a means of improving readability at glance, while removing the socket labels reduces readability at glance. So the collapse node feature essentially defeats itself

Hide unused sockets is just superior It’s a single button press instant node tree declutter

↓ ↓ ↓

So it’s really difficult to justify the existence of collapse.

[HooglyBoogly]

I find your idea of merging hiding sockets and collapsing nodes intriguing.

One problem I have with hiding sockets is that sometimes it removes important information on socket buttons. In your example above, imagine the length 0.15m in the curve to points node was a value that you set explicitly, something meaningful to the understanding of the node tree. Hiding it isn’t always a good thing. Obviously you can work around this, but it makes the workflow slower.

Then on the other hand, it’s obvious to hide “Seed” on random value nodes if the value is still zero.

I wonder if it would be helpful to make the “Hide” operation smarter so that it ignores sockets you changed explicitly?

[kuboa]

@LudvikKoutny

it’s really difficult to justify the existence of collapse.

Everyone has their own workflows and visual preferences—I personally find collapsing enormously helpful for singular inputs like Index, or math nodes, or nodes with few or no settings like Join Geometry and Merge by Distance. The small pill form makes it much easier to notice, differentiate, and read stacked node sequences, not to mention all the space saving.

I’d support opting for a superior singular solution vs two OK ones, but that can only come with a new design that would (somehow) combine best of both worlds imho, I would hate having to give up either features atm. A compromise like “collapsing also automatically hides unused sockets” like @brecht suggested could be alright, but even that raises several new design questions so I fear we could quickly derail and step out of the scope of this particular patch.