Allow dragging nodes into and out of frames by pressing Alt during transform
Highlight the frame that you are about to drop nodes into
It sounds simple but it requires some changes to current behaviour and the keymap, so I had hoped to get some feedback on the idea from experienced node users before bringing this topic up with the main devs.
If you feel like giving this a go, you can find a test build over at Blender Builds - blender.org by looking for “PR105457”.
This is an experimental build so be careful with your files to not lose any work.
I’m really curious to get some opinions on this, so if you have any thoughts regarding this proposal, feel free to leave them here or in the feedback thread on devtalk. Thanks!
It’s encouraging to know that I’m not alone with this!
One of my biggest pet peeves for a while has been how nodes can only be removed once you’ve set them down. It’s nothing big but it can feel a little like they are “stuck”.
With this proposal we can basically drag’n’drop nodes between frames, which feels much nicer.
The reason I’m so bent on getting someone to test this and get some specific feedback is that I’d really like to nail the feel of this, since that can make all the difference.
I remember watching it on the forum…i would love to have this functionality it’s infuriating…also maybe you could have Houdini like disconnect where you just wiggle the node and it disconnects the node without breaking the connection between previous and next node.
One thing that I’m not 100% sure is I think the Alt key on linux by default resize/move windows…
But I think you need to disable that to work with blender anyway !
I’ll give it a second look but I already saw that feature on the patch tracker and it looks much much better !
I have one suggestion about frames in general, it’s that the max text size could be bigger.
I can give example of big nodetree where this can be used to define some zones, but when it’s zoomed out completely we can’t read… Sorry I know it’s of topic …
I’m pretty sure your patch isn’t getting feedback because it’s amazing, that little video is already a mic drop, we can’t talk anymore in awe with the jaw dropped !
There are several places where Alt as a modifier before/during click is used (e.g. disabling link attachment or link swapping to name a few just in the node editor), so that sounds about right.
Would still be interesting to know about such conflicts.
No worries! I see what you mean. A bit unfortunate, since the original version of this patch included an increase to the maximum label size, but we decided against that on grounds of it probably never being needed…
In general I’m very interested in how to improve tools for node tree annotation and documentation. One thing that’s missing here from a design perspective is an agreed upon big picture of what a great annotated node tree even looks like - some best practices.
That could then work as a spec, when designing ways to improve workflows.
As a blender user I’m just a hobbyist so it would be amazing to get professional perspectives! Maybe I’ll start a thread for that once I’ve got a bit more time.
That’s the next step!
The core team has a lot on their plate with simulation nodes and all so I thought this time I’d try out this approach of fleshing out the design with the help of user feedback.
My hope is that this way the patch review can then focus on implementation and we won’t have to go through too much back and forth tweaking the behavior. We’ll see if this works out!
You should really do that. Have switched that long time ago to the meta/windows key.
IMHO alt is the right choice due to the similar behaviours Leon mentioned. Most people would expect such a function on that key. Also quite sure that changing the default keymap and get rid of the alt modifier could not be an option. That causes way to much trouble. The windows community would not be very pleased. And the accustomed linux ones also.
This is something that I have unconsciously done many times (ALT + drag a node out of a frame) since it resembles the ALT + unlink a node and keep the connection between its child and parent. Met with the frustrating realization that I have to ALT + P beforehand (P being so far into the leyboard that you have to either break your left hand to achieve the shortcut or move the mouse-holding hand which is also annoying)
If it was integrated into vanilla I would really like it. I would definitely use Frames more, too.
You’re right @moshus !
I transferred all my Mate desktop shortcuts to the meta key and I now discover really cool features
@lone_noel I also tested the patch, is this now the only way to add an element to a frame ?
I’m wondering if we really need to have the alt-key activated to add something to the frame.
Also when putting a node across a noodle it doesn’t connect it anymore, we need to have ALT pressed as well.
I think, the way it can work is that when dragging a node over a noodle ( connection) the connection highlights and release plug the node.
Alt and move allows to unplug without breaking the link.
In the same fashion, moving a node or a set of node over a frame highlight the frame and release add that to the frame.
Alt and move allows to remove from the frame.
I’m not sure if this is confusing or not, but I think Alt-key pressed should still allows to connect and unconnect. That way it’s still possible to move an element to one frame to the other.
Alt allows to connect and disconnect. without alt it allows only to connect.
That way, it’s still very close to what we have before, but we just have a visual clue that something append. And on top of that removing from a frame is much simpler…
Anyway, it’s really a great QOL improvement since ATM I’m never sure if I added or not something to the frame.
Yeah, maybe the old behaviour is better, as i think it would be more common that someone wants to connect if he places the node over noodle …
… but there should still be a way avoid a link connection, if you want to place a node into mess of noodles without making a connection.
When you just mean frames, i would agree. In case of links not, because it would then erase the possibility to not connect at all. As it is actually done by pressing alt when placing a node over a noodle (in the old bevaviour).
That’s really cool to hear. I have some ideas, but they would need tidying up. Here is an adhoc brain dump on the general topic of nodetree documentation. Some of these seem rather low-hanging fruit, some others are more involved but they’re mostly just food for thought.
Frame node labels can be scaled up to stay readable at a distance, however they will quickly overflow into the proper “container” area below and, more often than not, be occluded by the parented nodes and become illegible.
The draggable area has improved a lot recently by including all sides of the frame, but this is not communicated apart from a change in pointer icon, which can lead to, for instance, accidental transforming when trying to box-select the contents.
Frame nodes were hacked into displaying text, which makes them serves two entirely different purposes that cannot be combined for this simple reason : parented nodes hide the underlying text. That means the user who wants to document a piece of tree often needs to use two frame nodes. Trying to make these two concepts (grouping of nodes and display of text) live together is already weird on paper, in practice it’s also room for error because the user can accidentally parent something to a frame that’s intended to just be documentation. I don’t think this should be allowed at all.
The user can’t type the text directly into a frame node, instead having to link to a text datablock. The user has to rely on Blender’s text editor anytime they want to bring edits to a particular docstring -so to say.
Another way to document node tree is by scribbling with the annotation tool. Although it may not be always legible (some of us are medical doctors at heart) it can be valuable because some things are easier drawn than explained through text.
As far as I understand it uses the grease pencil code path, only heavily crippled : it doesn’t allow transforming strokes at all, so whenever the node tree layout changes the user is bound to erase and re-draw.
I have some ideas to solve these.
Make the frame node header equal to the tallest area a scaled-up label can occupy, so that the label always stays visible, regardless of its size.
Draw discreet lines all around the frame “container” area, including below the label area, for visual distinction.
Introduce note nodes actually aimed at containing text and nothing else. Keep them as simple as possible : a header with label, and a text content. They can’t contain other nodes, but they can be resized just like the frame nodes. Since Blender allows any font to be used for the interface, there should be some sort of indicator/warning for text overflow as well, in case the note’s contents can’t be displayed in full with the chosen font. They can use a different font from the rest of the interface as well.
Have the note text editable either in-place or from the sidebar. My understanding is that the latter requires creating the concept of a multi-line text widget… doesn’t sound exactly straightforward.
Introduce minimal functionality to transform strokes. Since I’m not sure how this can be done without introducing selection as well (I don’t think we would want that?), maybe have a new active tool that transforms the entire annotation layer as a whole. This way, as long as the “documentation” (aka scribbling) is logically arranged in layers, it can be refit to a different nodetree layout, and still make sense.
Nice, we’re getting into details! Thanks for testing, everyone!
On devtalk there have been a few users (including @Hadriscus ) advocating for explicitly enabling connecting nodes to links rather than how its now. I found the arguments quite convincing, though I’m not feeling strongly about it either way.
I think not breaking peoples muscle memory unnecessarily, is good though.
That is a good question actually.
On one hand I like that you don’t have to add nodes to frames and that the frames aren’t highlighted unless you actually wanna put a node into them, but right now I sometimes end up accidentally putting nodes on top of frames without adding them…
So maybe not being able to not add a node to a frame which makes it so that when a node is on top a frame you can also be fairly certain it belongs to the frame is an improvement?
Being able to just drag nodes out of frames to unparent them at least makes accidentally adding them less of a hassle.
In general the behavior you outline makes sense to me and it’s nice that it’s closer to how it works currently.
I’ll look into, if things can be set up so that they can be configured either way without too much trouble, since I can emphasize with always wanting link/frame connection to be explicit.
Definitely some interesting points, @Hadriscus. I won’t go into detail here to keep things on topic, but if I really get to work on that at some point I’ll let you know for some more input
This is going faster than I can keep up with ! hah ! nice ! thanks for addressing this.
I haven’t tested it, but it looks like the header grows to accomodate the label size, moving the frame contents in the process ? Or does it grow upwards instead? I’d say that would be preferable to the alternative. Perhaps making the header size fixed means it would be too big in cases where the text is small.
Ok I see ! That can make sense ! Having an option maybe next to menu View / Auto-Offset, like Auto-Connect , would be great !
I can see how some people might prefer one over the other. I can advocate a bit for auto-connect if needed !
I was looking for a use case where you want a node over a frame but that doesn’t belong to it.
98% of the time that would be confusing. The frame allow to form a group , and also to move nodes altother , to me it’s assumed that if a node is on top of a frame it belongs to it. That’s the point !
But sometimes you might need a reroute to be over a group just to clean up the links. But I don’t think that would overweight the benefit of being able to automatically drop stuff there.
but in those case it would be cool to be able to Alt-P the reroute !
that would be amazing !
Cool ! Keep me informed as well if possible ! Node editor is by far where I spend my time the most in blender these last 8 mounth, I can showcase small issues I encounter, which are in general related to navigating / looking at very big trees !
Thanks a lot for taking the time to read and ask for feedback ! It’s super appreciated !
Over on devtalk the discussion got going, too, so here’s an update since I’m interested in your thoughts:
It was proposed that we basically do away with the concept of “parenting” in the node editor all together. Frames would work the following way:
When a node is completely inside a frames bounds it will be moved together with the frames
Frames don’t adjust their size together together with the nodes they contain. So you can always move nodes outside the frame.
Apparently this is how frames work in UE or Nuke, but I haven’t used either of those. I did made a quick prototype to test how that works (no modifier keys needed here):
What I like:
The relation between nodes and frames is always obvious.
No modifier keys or preselection highlight necessary!
What I’m not sure about:
You have to keep the nodes and frames in sync manually. I personally liked that frames would adjust their size based on the nodes they contain and that the relationship was a bit more explicit than “things happen to be inside right now”.
Over on devtalk people are very in favor of this, so I’m curious what you think (especially if you have experience with node systems that work like this).
I’m personally still very partial towards what @sozap’s described: always make a node part of a frame when it overlaps the frame but only allow to explicitly remove it when pressing a modifier key.
Both approaches seem like an improvement over what we have now, though, and eliminating cases where a node can overlap a frame but not belong to it is good in any case.
Likewise I appreciate all the feedback and considerations you guys contribute. It’s actually a lot of fun!