On the topic of little OCD triggering UI pet peeves.
Some nodes vary from one of the three “standard widths” of all the other nodes. The three standards being the widths of e.g.: Curve Length, Points to Volume, ColorRamp, and the nodes deviating from these standards being: Curve Handle Position, Geometry to Instance, Raycast, Subdivision Surface, Face Neighbors, String to Curves, Brick Texture, Musgrave Texture and the Wave Texture
4 Likes
Just find an unreal plugin that change the line style
[ image removed by @sybren ]
-
The default is very like the blender one, but I prefer the second one the most.
I think it is easy to set (not reroute node) and read. (auto label show for reroute will be fine to add to this design, for long wires) -
Adding a reroute node is more like the third way(However, we have to make the reroute place very carefully)
Cool, to my brain the 3rd option 45° angles are the most clear to interpret at a glance
2 Likes
I have removed the image attached by @Atticus . Please refer to Copyright guidelines for devtalk for more info.
If you want to discuss this decision, please DM me.
I think the existing node adsorption capacity can be slightly enhanced, the larger scenarios, or remote node link ui shrink more easily when the phenomenon of not connected, although these do not affect the functionality, but the details also determine the good or bad user experience.
One more down, 2 to go 
3 Likes
I think this point in the opening post is adressed by https://developer.blender.org/D16230. It’s the other way around from the proposed solution, but you can disable the connection to underlying links now.
In a similar vein I guess a next step could be to also improve how attaching nodes to frames after transforming is handled:
- It should be based on the node’s position rather than the cursor’s.
- It should also be disabled by
Alt. - A slight highlight for frames during transform similar to the one for links would be nice to make the user more aware of the frame insertion (and allow them to disable it, if it’s not desired)
5 Likes
I don’t consider this a solution as it goes against general UX standards. If you take a look at the average of all CG related software which has some node editor, merely moving and releasing a node over a node link never results in node attachment. This means node attachment in this way should be considered a sort of special action. Special in that it’s not usual and/or expected. The flaw of this solution is that it does the special action by default and requires modifier key to force the expected regular behavior.
It’s important to realize that Blender is often used just as a part of pipeline, alongside other software which has node based editors. So the less muscle memory conflicts are, the better.
It should work the same way as the new node socket swapping. In almost all other software, when you plug a new link into already occupied socket, the link gets replaced. Luckily, now it’s the case in Blender as well. The unusual, special action only happens at the request of a modifier key (node links get swapped).
As long as the modifier key-less behavior defaults to the unusual behavior and the expected behavior has to be forced by obscure modifier key, I still consider this to be a UX issue.
1 Like
I completely agree that nodes should not auto-insert by default. Hopefully this can be changed in the keymap.
Yes and yes !
In this case however, moving a node into a frame is less consequential, as it doesn’t change the graph topology -whereas inserting nodes into a tree does. So, should it require holding a modifier key to insert nodes into a frame by dragging ? personally I don’t think so
I’m not sure about this one… either I start with no frame, or I start with an existing frame :
If there’s already a frame around, and I want to add nodes to it, selecting them and dragging them over the frame is easy because I don’t have to make sure all nodes overlap the frame area : as long as my pointer does, it’ll work. It shouldn’t depend on whether or not the frame is already big enough to accomodate the nodes that you’re dragging into it. I can see it becoming tedious in certain situations. I think highlighting should help there.
If there is no frame to start with, selecting them and hitting ctrl+j is always easier than going shift+a ->click “add” ->type “frame” ->click “frame” ->select nodes ->move them inside the frame.
It can. But as long as the wrong default behavior is there, I can’t mark it as solved UX issue, if it doesn’t work out of the box. Adjusting it in the keymap for me is trivial, since I use custom keymap anyway, but I want every user, new or experienced, to be able to experience good UX, and experience it out of the box.
Ah, that’s not quite what I had in mind. I still want to add all selected nodes to the chosen frame. The question is more about how to choose the specific frame for insertion.
Join all selected nodes into a frame…
- …when any selected node touches it.
- …when the center point of all selected nodes (or another reasonable proxy area) touches it.
- …when the mouse touches it.
Here’s what my experiment with option (2.) looks like (when it doesn’t join the nodes the second time, I’m disabling it by pressing alt )
I had started my experiments with option (1.) because it’s very clear, but it becomes increasingly imprecise as the number of selected nodes grows simply because the selected nodes are covering a large area, which I found annoying in practice.
Option (2.) is precise but it can be unclear where the activation area is - a bit of tolerance does help a lot though.
Option (3.) doesn’t have those issues since the cursor is already drawn during transform, but here we have a disconnect between where the nodes are and where the elements they affect are, which can be annoying and is odd, since dropping nodes into links behaves just as intuitive as you’d expect.
Video of what I mean
It’s weird how the node inserts into the link based on where it is and the frame joins based on the cursor.
This is why right now I’m partial to option (2.). There are some edge cases, but to me it felt alright and reasonably “drag’n’drop-like”.
In the long run I hope, that attaching to links and inserting in frames can behave similarly in terms of how they select their target. Otherwise it wouldn’t really makes sense to toggle them with the same modifier key.
To really do that we also should have the ability to attach multiple nodes at once onto links like with https://developer.blender.org/D12022 or https://developer.blender.org/D14185.
4 Likes
I like very much this solution, actually.
I don’t know about all or average CG packages, but I use nuke quite frequently and it autoconnects in the same way (as in, by default). And blender’s way is better in some respects, because disconnecting is really easy, and makes use of the modifier key in a really consistent manner (alt key if you want to either disconnect or not connect at all). Much better than the 3-key combo you have to use in nuke.
Could be improved? sure, (i.e. travelling from one point to other of the editor’s canvas while grabbing a node is awfully slow, in that respect nuke’s way of using a key to move the canvas around instead of travelling through it is really useful), but considering nuke is one of the big CG software packages out there, I wouldn’t say that Blender is the odd one out.
Just my two cents.
4 Likes
One thing I find annoying is that you can’t be sure if a node is attached to the frame until you move either of them, because the node can end up over a frame unintendedly, and then blender understands that it shouldn’t be parented to the frame.
In principle I get the idea, but the way to check if is parented or not is really unconvenient. So I usually resort to just move the frame, and check if everything inside moves with it (ctrl-z if it does because I didn’t really intend to move the frame, and if there’s one that does not follow, move it inside).
In any case, i think the user should be able to tell at a glance if a node is part of a frame or not, but maybe there could be an option in settings: that any node inside a frame is considered parented to it by default or not. I know I would activate it just to get rid of the uncertainty.
I do, that’s the thing
I am aware, but nuke is a bit different. The trees are never as crowded because nuke uses nodes only as “icons”, and doesn’t actually put interactable UI elements inside them. The primary way you interact with nodes in Nuke is not directly in the node editor, but in a separate panel on the right. In Blender, it’s the other way around. You primarily interact with nodes right in the node tree space, and only rarely use the panel on the right. In Nuke, this results in less tightly packed node trees with lots more empty space to place the node in, at any given time, if you want to place a node without connecting it.
I just propose to make it more consistent. Alt key if you want to connect disconnected node, and the very same Alt key if you want to disconnect a connected node
1 Like
I don’t think the difference is that relevant to the connection issue TBH. True, they use different systems and blender nodes are “beefier” and interactive, but it also has the auto-offset for when you place a node over a link, and it works generally fine, IMO.
I am not against it, honestly 
. It would be less convenient, I think…but just a matter of bit of getting use to it to create new muscle memory. Just wanted to point out that blender is not the only one out there that uses that default system.
In the original post, there’s literally a section showing the typical cases where it doesn’t
Auto offsetting usually only works for people who don’t intend to manage / cleanup the node placement themselves, and don’t have the problem with nodes being all over the place. But then, there are also autistic people like me, who like things to be clean, so having something that moves whole chunks of nodes around is actually destructive
Most of my node networks usually look like this:
So auto offset becomes just a tool of destruction.
3 Likes
Yes that can be an issue. I don’t really encounter it often now but it could very well be that I’m used to work around it : when inserting a bunch of nodes into a frame (which in my workflow happens once I’m satisfied with the behaviour and I want to tidy up the area), I do it all at once so there’s hardly ever anything left.
However I think the issue you’re describing mostly comes from the fact that frames are rectangles. Sometimes nodes don’t conform very well to that rectangle and some other nodes (not meant for the frame) happen to spill into the frame area, and that’s where it gets ambiguous. My take on this is that frames should become convex hulls (as in Jacques’ simulation branch). But this wouldn’t alleviate all problems because a node can still be in the general frame area and not be included in it. I’m thinking, maybe there should be a more obvious indicator that a node is part of a frame. Right now it loses its drop shadow, maybe it could gain an outline that’s the same as the frame color ?
It does so in Houdini as well, but Houdini is the same as Nuke, nodes don’t get in the way because they’re tiny, and they’re tiny because their contents are offloaded to another part of the interface (as Ludvik said).
Completely on point. You don’t even have to be on the spectrum (unless you used the word figuratively), I micro-manage my nodes too… otherwise I get lost. I just need to have that level of control and I just can’t use auto-offset because it doesn’t care about snapping to grid and it doesn’t know about forks either, so it just moves everything that’s upstream/downstream from the insertion point.
I am no stranger to accidentally moving nodes into a frame or forgetting to include some. This is how my node trees look like :
I use colored frames to separate the process into parts, and having them in the form of rectangles create “blind spots” so to say. Auto-offset usually ruins the entire thing
Sort of a sidenode but using Alt for inserting or detatching nodes is always overriden by “Emulate Three Button Mouse” navigation and as such completeley eliminated in the node editor due to navigation.
I wonder if it would be possible or a good idea to draw focus on node interaction while hovering over a node and pressing the option keys instead of grating the first priority to panning and zooming always.
When you are moving the node, you are in a mode. It’s modal operation, so it should not be an issue to resolve that conflict. The only difference is that first pressing alt and then doing the operation vs first doing the operation and then pressing the alt would be two different operations. But that already happens in so many places in Blender, so that shouldn’t be an issue either.
You mean sort of like activating the option buttons while already interacting with the node.
Like - klick-drag and while holding interaction with the node already using combinations of Shift-, Ctrl- and Alt- buttons as options?