I can’t speak for everyone, but the way I work, and I’ve seen other work is that you don’t really need to care about the frame in realtime in the same way you don’t care about neat arrangement of the nodes if you are prototyping rapidly. You usually make something, and then only after it works, you take a moment to clean up the node arrangement so the flow is more obvious. In UE, during this step I’d also just drag the frame to encompass the new part of the work I’ve done.
In fact, in unreal, the frames are called “Comments”, as in they literally mean that you are commenting your node based scripts. This implies that the frames are there mainly for you to remember what you did next time you open the file, or for the others to help them figure out the mechanics of your node graph.
But when you are creating part of the node graph, you are in the current mental context so you are obviously aware what part of the node graph you are working on. So for example if you are creating the part of the node graph which scatters the moss, you are aware you are working on the moss part, even if they frame you’ve labeled “Moss” doesn’t fully contain a couple of new nodes you’ve created.
So once you are done and the part of the node graph works, when you go ahead and clean up and align the nodes, you also take couple of seconds to extend the frame over them. You don’t need to wrangle the frame every single time you add a new node or move existing one.
Actually in Houdini both chidren defining the size and manual adjustment incorporated. Also you don’t need any keys for parenting. Dragging nodes to frame parents it, if you want to unparent faster dragging unparents it.
I am open to anything, all I am saying is children defining the size automatically is very handy, I don’t want to lose that.
1- Dragging a node to a wire to parent and alt+dragging to unparent is already established, people are used to it. So same behaviour for frames? Dragging to a frame parents it. alt+dragging unparents it. No confusion.
2- Children defines the frame bounding box automatically but you can also adjust it manually.
The issue is that those hotkeys are running out really fast. And there are way more useful things to do with modifier keys during node transform than wrangling the frames.
For example see the discussion in the other thread:
Alt key during node transform already toggles whether the node is connected or disconnected onto underlying node links. So you can’t have the same key also do unparenting from the frame. The shift key is free (or rather isn’t but does quite useless operation right now), but even that one could be better used for toggling auto-offset on the fly.
Other software have smaller nodes (no exposed list of parameters), Blender nodes are almost always bigger (taller really) so they naturally require a bigger frame to be fully contained. Perhaps then we could change the rule slightly to make it so as long as the node header is contained, the node moves with the frame. Not sure whether that would be better, just a suggestion. It probably makes the thing less obvious visually.
It would just take more mental effort to determine which nodes will be moved with the frame and which won’t. Human brain can easily evaluate whether some objects are fully enclosed in some frame, but if the rule is also partial overlap, then you need to evaluate each individual node mentally to see if appropriate part of it is contained within the frame. It just wouldn’t be worth it.
I still think it’s important to think of frames as visual comments. In a sense that they don’t have any actual functionality which affects how the node (code) tree behaves. This means it’s really not necessary to have the frame always right size in realtime, so resizing the frames won’t be that frequent of an operation. You would usually do it after you are done building the node tree section.
100% in agreement. For me, frames are something that I do very late in the game, to clean up the layout so that when I re-open the system in a few weeks, I’m not completely lost. (Certainly they help with dragging groups around, absolutely. But I don’t need the layout to look like perfectly aligned artwork with exact margins.) If I need to drag the parent frame larger to make space, so be it - it’s not like I’ll be spending much time doing it anyway.
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?
+1
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
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.
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.
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)
ADITIONAL THOUGTS ABOUT FRAME FUNCTIONALITY
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.
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?
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.
