Testing Wanted for Joining Nodes Into Frames

Feature & Design Feedback
15

Yeah your case also makes sense. I don’t have a strong opinion here. But it is also difficult when dragging several nodes into a small frame it becomes a bit difficult to find highlighted position. And also it slows noddling process a bit. First you have to drag and drop node/nodes into frame where it highlights then you adjust their final position.

I have now gotten used to it but yeah, it created extra burden on my brain: shall I press alt first then drag or the opposite? :slight_smile:

Great work anyway, it will definately speed things up. Thanks.

1 Like
16

This is a good enough reason for me to try some more with having all selected nodes (or at least a close approximation) activate the frame to join.
Fiddling around to find just the spot to join with the frame isn’t great and you noticing it as an issue quite quickly means that it should be handled better. Hopefully we can get it to a point where you never have to actively think about it - where is just works.

It will have the issue with precicely picking a frame when overlapping a large area in some form, but maybe that limitation isn’t as big an issue in practice and turns out to be the better compromise.

I’ve been there!

1 Like
17

Could that be solved by making both options part of the transform operator modal keymap ? (=attach/detach node & frame/unframe node)

This way alt+click stays free for something else

18

Upon further playing around, I have quite gotten used to it. I think it is good as it is.

2 Likes
19

That is good to know!

That could make sense. I’d have to look into that but the way it’s implemented right now when pressing Alt and then dragging it just runs “Detatch Links” and then activates the modal “Move” operator.

20

I’ve used quite a few different software packages with node based systems over the years, and when it comes to frame management, nothing comes even close to Unreal Engine due to the simplicity.

You guys seem to be solving lots of issues related to hotkeys and muscle memory, yet UE is a living proof that these problems don’t have to even exist in the first place.

In UE it works extremely simply. As long as any node is fully enclosed inside of the frame, it’s part of the frame and moves with it. As soon as the node is moved outside of the frame, or only partially overlaps the frame, it’s not part of it and doesn’t move with it.

We are trying to solve the issues of explicit parenting, such as order of the operations to properly parent/unparent node to the frame or what the hotkey should be. But why not just step out of the box, and think about whether you even would want to have explicit parenting.

If you think what the node frames are, they are a visual and management aid to organize the clusters of nodes in situation where you still want to have direct access to them instead of abstracting them into a node group. So ultimately you want two things:

  1. To have visual aid that encapsulates and describes purpose of a given cluster of nodes.
  2. To have layout management aid of being able to move clusters of nodes as a single item around, without having to select them all first.

Given these requirements, if you ask yourself if you would ever want to have a node which is inside of a frame, but not parented to the frame, the answer will most likely be no. In fact when the node is inside of a frame but not its child, it’s in most cases just an error, because you forgot to parent the node to the frame.

So why even have this option? It’s just so elegant in the Unreal Engine. You:

  1. Never have to spend mental energy thinking about any hotkeys
  2. Never have to worry if you parented the node to the frame or not

Only small drawback is that you have to manage the size of the frame manually, so there’s no feature where dragging a node over frame expands the frame to encapsulate the node. But to me that’s very small price to pay for the simplicity and ease of use of node frames that require no hotkeys and no manual parenting.

7 Likes
21

In the sister thread over on blenderartists we were having a similar discussion and ultimately came to the same conclusion.
It’s just much nicer if frames would be “what you see is what you get”.

This one I’m not sure about. The solution proposed over on BA has been that moving nodes on top of frames always adds them, but removing them requires the ‘Alt’ key and to me that seems like a great way to handle it.

4 Likes
22

This still doubles the complication I am afraid. You create different rules for adding them and different ones for removing them. It ceases to be simple and elegant.

The point here being that if there was no alt key removal, you can simply remove the node from the frame by moving it outside. If you are working inside of the frame, I don’t think it’s that annoying to have to resize the frame from time to time to make more space. I mean it’s not like you have to do it immediately. You can just work as you wish and only when you are done, drag one of the corners of the frame and cover the entire new thing you just did.

And once that is the case, internally, the whole concept of frames having any children, and whole concept of parenting in node editor can just be deleted. Frames would no longer store their children and nodes would no longer have any concept of having parents. Instead, every time user would move the frame, a simple function would check which nodes are fully enclosed in the frame and move them as well.

Losing the ability for frame to be auto resized when nodes are moved inside sounds like an issue on the paper, but after using many node systems for years, it’s just not an issue at all. What’s gained in exchange, deletion is substantial chunk of code (and UI elements/operators) aside, is also a very simple and clean unidirectional rule set:

  • Moving nodes can never affect (move or resize) the frame
  • Movement of the frame affects the fully contained nodes

Frames become just a thing in the node viewport you can create, name, color, move around and resize, and literally the only rule you need to remember about them is that if you move them, they will move any nodes they fully contain. But there are no other rules to remember.

3 Likes
23

I have to say I like the thought of not having to manage this parenting. I’ve never used unreal engine so this didn’t come to mind.

1 Like
24

I completely agree with this. We already have the ability to have the frame automatically shrink to fit the nodes. Personally, I really don’t think I need the frame to grow and shrink if it requires me to use a hotkey modifier to drag nodes out of it.

I would rather just click on the node and drag out of the frame. If I need the frame to be larger, I can just click on it and make more space before I drag it in there. Or, I can drag the node to where I want it, and then click on the frame and drag it and make it large enough to enclose the new node.

However, I do wish the “click area” was larger, to manually adjust the frame size. I really have to zoom in there to find the magic pixel on the border.

3 Likes
25

I agree. Is the same in nuke, although the concept of nodes are very different because of compactness and it makes the step of fully placing the node inside the frame easier.

And also, one of the very annoying things to me the way the frames behave atm is that you cannot distinguish if they are parented or not just by looking at them. So I guess one extra benefit of having it being auto parented is that it eliminates the need for explicitly communicating if the node is a child or not (and creating more visual noise along the way): if it is inside the frame, it is parented. Easy and unambiguous.

5 Likes
26

Yes… if this was implemented the way I suggested, important part of it would be making the frame border more visible, easier to find with mouse cursor, and replacing the corner cursor image, which is currently incorrectly set to cross cursor with diagonal resize arrows cursor. :slight_smile:

27

I hacked together a prototype to test this new proposal, since I haven’t encountered this in practice so far. No modifier keys required:

I have to admit that even after playing with this for a while I don’t find it obvious that having to manually keep the frame and its children in sync is necessarily better than having the frame adjust the size according to its children, but if that’s the way the wind blows that’s fine with me!

6 Likes
28

We’re definitely losing some of that flexibility, but it looks so straightforward not having to manage parenting, it looks worth it to me. Thanks for putting this up so quickly. It’s much better to see it in action than having to imagine it.

1 Like
29

I think the same. I tried to think of a way to maintain dynamic shrinking while also being able to simply move the nodes out, but these two just can’t live together without hotkeys or special rules.

Ultimately, I think simplicity wins. It also probably means more code can be nuked :slight_smile:

30

really cool! :+1:

Yeah, to me the biggest drawback in this kind of behavior is having to manage the frame size manually to make room to the nodes, because otherwise it will not be following the frame when you move it. It is the only thing that makes me unsure of it as a solution for Blender, because in Nuke’s case, nodes are so tiny that it’s very easy to make a little room to accomodate a couple new nodes (LudvikKoutny surely is more informed as to how much of an issue this can be, UE having also very big nodes)

Isn’t it tiresome having to make so much room to fit bigger nodes?

On the other hand, the biggest win (in my very much subjective opinion) is a draw between the auto parenting itself (the lack of shortcut) and how visually clearer is the hierarchy (it is really straightforward, as Hadriscus says).

The old way, you would have to either move the node to see if the frame resizes itself, or wiggle the frame a bit to see the parenting. And that can become infuriating when you forget and leave an orphan node behind.

2 Likes
31

Would that be such a compromise?

How about keeping this behaviour but adding the shift-drag that was talked about previously but for “move the selected nodes around, but keep them inside their respective frames (auto shrink)”?

2 Likes
32

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.

33

Hmm, I don’t like the manual adjustment , let the children decide the size. I prefer the one in your patch.

1 Like
34

Have you actually used it (I mean outside of the Blender bubble)? And are you sure you don’t like it more than you don’t like manual parenting chores?