Testing Wanted for Joining Nodes Into Frames

I do really like the idea of removing the parenting concept from the node editor. It always seemed a bit shoehorned in from objects. The consistency is a bit cool but it’s not very useful in practice.

Maybe one way to make adding frames more pleasant is to have an “Add Frame” active tool. The toolbar is under-used in the node editor I think, and this might be a nice opportunity.

You could drag a rectangle to create the frame, and the text editing for the frame label could be focused immediately. Then you press enter and create the next frame.


That is a really good idea. Plus you wouldn’t even have to move nodes into the frame area, since you can draw the frame around the nodes instead. I like this even more !

I’ll try to get a usable prototype build ready over the weekend so we can really tests this.

+1 on the toolbar being criminally underused in the node editor.
A lot of the tools probably wouldn’t really see much use by hardcore noders, since the shortcuts are pretty good, but it would do a lot for for discoverability. How many people even know that you can mute node links?


There’s already a Join in a new frame operator:
It takes all selected nodes and draws the frame exactly fitting it around them. If the parenting concept in node editor was removed, I think this operator (or its hotkey at least) could be repurposed to automatically frame the selected nodes and activate the editing of the frame label? And in case all nodes would be deselected, it would activate the click-drag frame creation? :slight_smile:


I actually use J almost always instead of ctrl-P for that. It’s much more convenient to use just one key than a combination that requires to move the left hand to the right side of the keyboard

Hi everyone,

there is now a build available with the link below. It is a bit more WIP than I had hoped, but I think it let’s you get a good feel for the changes.

NOTE: Additionally to to the usual caveats when using experimental builds, I want to remind you to better not save over existing files.
Since the patch removes the parenting hierarchies, the frames and nodes won’t be attached anymore when opening files saved with this build in other versions of blender - so this is a forward-compatability breaking change.

State of The Patch

Here’s how things work now:

  • Frames move all nodes that are completely contained within them
  • By default frames are static and have to be resized manually (the “Shrink” option is still available - more on that below.)

Resizing Frames

I also made a few adjustments to the resizing of frames, that I thought might be nice now that we might spent more time with that:

  • The hitzone on the edge of the frame doesn’t get too small anymore when zooming out. This might still need some tweaking.
  • Pressing Spacebar while resizing nodes will move the frame. This is consistent with the behavior of box select and I thought it might be handy to be able to easily move frames around underneath the nodes.
  • Pressing Alt when resizing a frame will symmetrically resize the frame around it’s center. Not sure about this one, but I thought it might feel familiar to everyone using 2D graphics software

Having the node borders snap to the grid, when snapping is enabled, would be nice, too, but I didn’t get around to that.

Known issues:

  • Duplicating frames is a bit iffy right now. I have a hack in the default keymap, to mitigate this, but if you use a custom keymap or the “Duplicate” operators from the menu, you’ll notice that currently nodes are moved together with the frame that is duplicated underneath.

Shrinking frames

Since I’m still a bit attached to shrinking frames, I kept them around to see if they can still fit in without parenting. So for now you can still manually activate the “Shrink” checkbox for frames in the sidebar, which will make a frame adjust to the nodes it currently contains.

Things of note:

  • Even with shrinking enabled, you’re now able to still resize the frame to quickly adjust which nodes are contained inside the frame.
  • You can also still remove nodes from shrinking frames by pressing Alt when moving them, same as it was in the original patch. (I haven’t yet untangled that from the node link insertion, so they still share the same hotkey.)

If you want to stress test the shrinking frames, I also added a toggle in the experimental user preferences called “Shrinking Frames” that makes frames have shrinking be enabled by default.
If we wanna keep shrinking frames around having a preference, if it should be enabled by default when framing nodes might be reasonable.

Shrinking frames do add some additional complexity and there are still some issues to be ironed out, but before sinking more time into that, I’m interested to hear if you think that’s a direction worth of more investigation.

Overall this is a bigger change than I’d usually try my hand on and there’s a lot for me to figure out, so bear with me. :slight_smile:


OK, so I’m loving it so far. To me the basics of the behaviour feel much more intuitive (although it is still wip, so there is some issues as you point out). I’ll try to give my view to the points you make:

In principle it is great. I have to say though, that it feels very weird that, when a node is overlapping two different frames, there is no Z-hierarchy. In my opinion, the node should only “be contained” by the frame immediately behind the nodes (so, the frame on top). In your video it is kind of ambiguous because of the transparency, but what I mean is this:

Shrink being activated in both frames, when the circled nodes are moved around:

  • frame 1(orange) should shrink to them
  • frame 2(blue) should NOT (since they should not be considered contained directly by it).

Thing is, I’m not sure if there is an actual exposed Z-hierarchy. I know there must be because the way they behave, but it’s something that, if it’s not exposed, it may be good to have it in the N panel (a way of arranging frames forward-backwards)

Love the spacebar thing, is one of those little things that is really nice to have.

In my view, not that useful, because you can easily include some unwanted nodes in the other side. I don’t think it hurts to have it, but I doubt I would use it all that much. Maybe others will, Idk

One thing I think would be more useful is to have a modified key that allows the user to select and move around only the frame without the nodes it contains. I have found it useful in other programs.

This is just great. You can move around the frame and the nodes follow it but still being able to transparently leaving them outside when resizing is awesome. :+1:

It makes me very nervous atm , the nodes feel trapped XD, there’s no way to move the actual nodes outside the frame when auto shrinking is enabled. (I know it’s a wip, it just felt hilariously ennerving)


I think having a preference is good. But I want to use this to point something that may be a little off topic, but I think it’s important:

The menu that pops up when right clicking over a frame is super wasted when it comes to frames. It has the same items as when you rc over a node. And some of them don’t make much sense when just right clicking over a frame (it does make sense if you have selected frames AND nodes), but for example, the option to make group son’t make much sense if you don’t have nothing selected and just RC over a frame.

What would make sense is to add a “shrink” or “color” options to the menu.
Or, even better, an “add a text” item that creates the text file and enters into text mode.


I know this last one is much more work and would need a design, but the option to quickly enable “shrink” without having to go to the N panel would be great. Specially since you cannot add it to the quick menu, which I don’t undestand exactly. I think it could be useful working something like this:

There’s a “Add Text” item in the menu when you RC over a frame.
When you click it, a text editor pops up with a text already created (with the nameOfTheFrame.text.001 or something similar), the frame dropdown for the text already filled, and focus in the input of text (so, when you click it you only have to think of writing the content of the note).

Two final things I think would add a lot ease of use would be two options added in the preferences:

  • option to determine the default label size. I know I always make it bigger.
  • an option to create each frame directly with a random color, and avoid having to tweak each one of them always.
1 Like

This is pretty great. How to say it - it doesn’t feel like I’m suggesting the editor what I want to do, and hoping it agreed. I’m just dragging things in/out of frames, dragging frames, and it’s just fluidly responding exactly as I want it to. Love the larger hit zone to resize, thank you.

I find the ALT and SPACE hotkeys to be a bit odd; naturally, I hold a modifier key and then click something. I don’t normally click, THEN add a mod key, to perform an operation. It does work, but I’m having to made multiple attempts each time to remember the way it’s done. Having said that -

  • Not sure I’d use those features that much anyway, so I’m not too stressed about it.
  • When I read the ALT key idea, it sounded sort of weird. But in practice, yes - I can see people would like it. I like that it is only X or Y resizing, not all directions.

You already know duplicate isn’t working as intended, so I’ll skip that for now (but yeah, it’s not working well.)

When I drag a node into a connection, I’m having to hold ALT to get it to move into the chain, instead of it linking automatically. Different than current behavior, but I’m not sure which I prefer. I can see both ways appealing (or not) to people. For myself, it seems like I often have nodes “joining” when I was literally just trying to move them around, so perhaps the ALT-to-join is a good idea.

One thing that is odd (perhaps a price to pay) - if I move a frame (empty, or with a ton of nodes) OVER another large group of nodes… suddenly, all those “second nodes” join the party of the first frame. It’s sort of funny, actually - you can drag a frame around, and eventually every single node winds up in that frame. Perhaps a frame shouldn’t be able to … “claim parenthood” of a node that’s already parented to another frame?

Overall, very pleased. Great work on this.


Maybe delay the parenting operation until after releasing the mouse button? So it only adds the frames/nodes that you have left inside the moved frame explicitly at the end of the operation.

I think that’s a great solution.

Maybe I’m misunderstanding, but this should be how it works. (And at least on my end it does - see below.)
If it doesn’t work like that a file to reproduce the issue would be great!

I will double-check this in the morning, for sure. Don’t want to lead you in a bad direction.

1 Like

Oh, you’re right, sorry. I was on the phone when I answered the last time, so I took the comment at face value, but didn’t check for myself. My bad

1 Like

Yes, I think there should be some depth based hierarchy. Essentially, in your example, moving the blue frame should move the nodes in the orange frame only if the entire orange frame is enclosed in the blue frame.

But to be honest, I think there will be more of these issues as a consequence we are still keeping the shrink option. If the shrink option didn’t exist, this can be much much simpler. The one simple rule would apply, that any frame containing nodes moves them. So both blue and orange in this case. Only the retention of the shrink features complicates things once again.

Yes, exactly.

I disagree. I think that would be extremely annoying. It would be very easy to unparent nodes from its top-containing frame by accident, if any frame that is visually containing the nodes can move them with no hierarchy considerations. Take the orange/blue frame example:

previous image

  1. You have arranged the nodes to be children of the orange frame.

  2. But since it’s an operation that still relates to those in the blue frame, you overlap them a bit (so it ends up like in the image above)

  3. Then, for some reason, you have to make room and move the blue frame to the left. Here there would be a couple of options possible:

    • A) you drag those nodes with the blue frame, removing them from their “main” frame (orange)
    • B) you drag the whole orange frame with it
    • C) you leave the nodes and orange frame where they are, losing the overlap between orange frame/nodes/blue frame, so it forces you to select blue and orange to move them together.

A would be just wrong, since then it would be a mess to manage what nodes are contained in what frame, they could be changing parents unadvertently all the time (and sometimes you wouldn’t even notice).

B goes against the main behaviour it’s being implemented by @lone_noel (which is, only when completely contained is considered a child).I think would bring a big inconsistency.

To me, C is the only one acceptable. Even when it could bring some (minor) inconveniences, it would be much more consistent and easy to manage.

It may be the case that the shrink option bring more issues, probably since it adds more complication. But the main issue in my view is the Z-hierarchy, regardless of auto-shrinking.

In any case, if the option for shrinking is brought to a pop up menu, I imagine my own workflow would be: not having frames auto shrink by default, and use the menu to toggle it explicitly, or even better, give it a shortcut to toggle it at will.

Then again, I may be wrong. It’s just my take on it.


You have gotten yourself into a messy situation due to not treating the frames as visual comments of the node based code.

You are saying “But since it’s an operation that still relates to those in the blue frame” but I am a bit curious what kind of mental gymnastics would you use to justify that. You have two nodes, spline parameter and group Input being in the blue frame, and also the orange one, but their output links clearly lead directly outside the blue frame and are very unlikely to lead into anything that is inside of blue frame.

So it would be really hard to say that they are somehow related to the blue frame. If they were, than whatever they output to would be part of the blue frame as well.

The behavior I described is how it works in UE which I have been using for about 4 years now, and I never had an issue with it. Every single time there were two frames which were partially overlapping each other, instead of one fully containing other, it was an error.

If you think of the frames as visual comments, they are kind of similar to text based code comments. You can have a class which has a comment, and then inside of it you can have a function which is also commented. The class fully contains the function and its comment, but you can’t have a comment that comments the entire class and only part of the function at the same time.

Having the comments as 2D shapes inside of 2D space does allow for some flexibility, but that flexibility is hardly necessary there. What you have here is a bit of synthetic scenario, so you are now trying to invent some monstrous overcomplicated behaviors (rules of which will once again be offloaded to users mind, reducing the usability of the frames) to fix something that’s unnecessary in the first place.

The clear solution to your image is to simply hover over the right edge of the blue frame, and resize it outside of intersection with the orange frame. Or if the nodes in the orange frame really have something to do with the blue frame, as in that their output somewhere terminates inside the blue frame, then whatever rest of the orange frame is should be fully enclosed in the blue frame.

So ultimately, you are inventing the same problem we are solving. We are in the process of solving the problem that manually parenting nodes to the frames is a solution to a problem that never existed. Users almost never wanted to have a node fully inside a frame but not be affected by the frame. So we are removing manual parenting now.

Overlapping frames are pretty similar. Most people will considering having two partially overlapping frames to be an error, or at the very least messy workflow. It makes sense to have smaller frames fully contained withing large frames, to describe some sort of hierarchy of node clusters. But having partially overlapping frames in terms of visual comments is like saying “Well, A is part of B but not really”, which has 0 informative value in terms of visually commenting your node based code.

Ok. I was taking that example because it was already in the thread and I thought it was easier to reference back to it. Those nodes are inside a hair asset group I was using to test it. I know that specific example doesn’t make sense. Sorry, I even thought somebody would make this very point, but I hoped it would be more understandable that I was just trying to use it as a generic example.

But I think my point still stands, because 1) I have seen people do just that for visual clarity. I personally don’t do it, but I’m aware of people that do. And 2) even if it can be just by accident, I think it simply shouldn’t be that easy to unarrange your node setup when there is a clear visual hierarchy between the frames.

So maybe this next example will make clear what I mean. Don’t focus on what the nodes are,please, they’re not the point:

This is what would happen in scenario A (bear in mind, shrinking is disabled in both frames). To me this is just wrong, mainly because there is a clear visual hierarchy that is not consistent with behaviour. Look at the frames, the orange is clearly on top, and to me it feels as if the blue frame is stealing a node from it.


Yes, I guess the point I was trying to make is that I’d find it very difficult, if not impossible to find a practical (non synthetic) scenario where having two partially overlapping frames is useful, in terms of communicating something about the behavior of the node network. If you want to communicate that two frames are somehow related, partially overlapping them would be quite a cryptic way of doing that. Much more clear way would be to simply fully enclose the two frames within another big frame.

So that you’d fully enclose let’s say “leaves”, “branches” and “trunk” frames inside the “tree” frame, instead of partially overlapping leaves, branches and trunk frames with each other, hoping that another user will understand that by the means of frames touching, they are related.

What you are doing in that video is intentional error. I do agree with you that in intuitively feels that the blue frame steals the orange frame’s node. But what’s important to realize here is that if we completely remove the concept of parenting, meaning that specific frames remembering their specific node children, then imagine the following scenario:

You move the blue frame to overlap the orange frame as you did in the video, but you don’t notice it, and keep working for another 5 minutes, forgetting what belongs to what.

After 5 minutes, you notice the issue but instead, you move the orange frame to the left. Should the orange frame steal the blue frame’s Geometry to Instance node? When you created the overlap, the Geometry to Instance node belonged to the blue frame, but keep in mind that since the parenting is removed, the nodes don’t remember what their children are, so by creating that overlap initially, you want the system to somehow magically understand that the join geometry node belongs to the orange frame while Geometry To Instance belongs to blue one, without the system being able to track the specific frame children.

Yeah, I see your point, the way I was rooting for would also mean stealing in that scenario, just the other way around. Well, I don’t know what to tell you, it sure looks difficult.
But if the final behaviour is as in the video, I think the visual hierarchy could be improved to indicate that it’s a co-parenting situation with no specific order. The semi-opaque colours indicate a behaviour that don’t follow what actually happens.

Anyway, I’ll sit back for now and shut up, I don’t want to muddle the thread with half-baked ideas.

Ok, new personal rule for myself - no replying at a very late hour, on my phone, on a critical point without sitting down at the computer instead of trying to rely on a failing memory.

Sincere apologies, it works as you’ve stated. I was remembering all of the “node stealing”, but not that I was letting go of the mouse.

So, having cleared that up - I’ll revert to my initial feedback on that. I don’t think one frame should be able to grab nodes from another frame in this manner. I actually realized it did this on accident when (yay for testing things) while resizing one frame (which crossed over another filled with nodes), and thought - wow, that will be a problem one day.