Nodes: new interactive operator to slide nodes #121981

Open
Jacques Lucke wants to merge 24 commits from JacquesLucke/blender:slide-nodes into main

When changing the target branch, be careful to rebase the branch in your fork to match. See documentation.
Member

This adds a new operator with the purpose of being able to make space in a node tree quickly and in a predictable way.

The exact behavior of the operator is still up to debate.

Right now it's triggered by holding down the V key and then clicking and dragging on some node or in empty space.

  • When clicked in empty space, all nodes to the left or right of the mouse will move.
  • When clicked on a node, all dependencies or dependent nodes will move.
  • When clicked on a node that was selected already and other nodes are selected already too, all dependencies or dependent nodes of all selected nodes will move.

TODO:

  • Validate and potentially improve behavior.
  • Maybe add some kind of visualization.
This adds a new operator with the purpose of being able to make space in a node tree quickly and in a predictable way. The exact behavior of the operator is still up to debate. Right now it's triggered by holding down the V key and then clicking and dragging on some node or in empty space. * When clicked in empty space, all nodes to the left or right of the mouse will move. * When clicked on a node, all dependencies or dependent nodes will move. * When clicked on a node that was selected already and other nodes are selected already too, all dependencies or dependent nodes of all selected nodes will move. TODO: * Validate and potentially improve behavior. * Maybe add some kind of visualization. <video controls autoplay src="https://projects.blender.org/attachments/8a9ba5c2-4db6-472e-979e-5a9d5badfb76" />
Jacques Lucke added 6 commits 2024-05-19 16:52:36 +02:00
Jacques Lucke added 1 commit 2024-05-19 17:04:01 +02:00
Jacques Lucke requested review from Simon Thommes 2024-05-19 17:06:38 +02:00
Jacques Lucke requested review from Hans Goudey 2024-05-19 17:06:39 +02:00
Jacques Lucke added 2 commits 2024-05-19 21:46:43 +02:00
Jacques Lucke added 1 commit 2024-05-20 20:14:08 +02:00
Merge branch 'main' into slide-nodes
Some checks failed
buildbot/vexp-code-patch-lint Build done.
buildbot/vexp-code-patch-darwin-x86_64 Build done.
buildbot/vexp-code-patch-darwin-arm64 Build done.
buildbot/vexp-code-patch-linux-x86_64 Build done.
buildbot/vexp-code-patch-windows-amd64 Build done.
buildbot/vexp-code-patch-coordinator Build done.
4d64f626ac
Author
Member

@blender-bot package

@blender-bot package
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR121981) when ready.
First-time contributor

Thanks for adding this feature. I did some quick tests, here are some of my findings:

  1. I am not too sure how validation bubble is constructed in this extreme case:
    image
    image
    I assume originally the boundary was only tiny, and grow larger and larger to the left because of linkage dependency.
    Right now I can't conclude whether this behavior should be expected without testing in actual work environment.
    but I do find some cases where nodes above and below aren't being actually moved for similar kind of reason.

  2. I also find the split isn't available in vertical direction.
    I think it will be very important, because if node tree branches out, we also need space vertically too.
    image

Thanks for adding this feature. I did some quick tests, here are some of my findings: 1. I am not too sure how validation bubble is constructed in this extreme case: ![image](/attachments/43eaca0f-fcc7-4b52-93c8-6982a155d97d) ![image](/attachments/b838555b-3f56-4af4-9021-019583d44292) I assume originally the boundary was only tiny, and grow larger and larger to the left because of linkage dependency. Right now I can't conclude whether this behavior should be expected without testing in actual work environment. but I do find some cases where nodes above and below aren't being actually moved for similar kind of reason. 2. I also find the split isn't available in vertical direction. I think it will be very important, because if node tree branches out, we also need space vertically too. ![image](/attachments/2207ba41-ea0c-449f-a326-fc2c0b9340d0)
First-time contributor

I tried using the operator on my tree generator nodetree, which is quite big, but the build crashes after about three seconds on opening the file, whatever I do. I'm not sure how to work around that. Edit : just like Brady mentions below, the files that cause a crash have quite a bit of nodegroup nesting. Maybe there is something to that

So I tried with some simpler nodetrees (with not a lot of branching) but couldn't make it work predictably.

Capture 1 : It seems to grab the nodes at rather arbitrary points? it appears to be related to the presence of frames.

Capture 2 : after removing some frames, it works more predictably, but some nodes (such as the index node around screen center) are always left behind.

I'm not sure how it works under the hood, so perhaps this suggestion is irrelevant, but could it be made more obvious by depending on the active node instead? or the selected nodes? similar to the transform operator, except grabbing everything up/downstream of the actively transformed node(s)? I wonder if perhaps it would even work as a transform operator flag, holding a hotkey while tweaking a node could trigger it. But there's the question of how to manage multiple selected nodes.

I tried using the operator on my tree generator nodetree, which is quite big, but the build crashes after about three seconds on opening the file, whatever I do. I'm not sure how to work around that. _Edit : just like Brady mentions below, the files that cause a crash have quite a bit of nodegroup nesting. Maybe there is something to that_ So I tried with some simpler nodetrees (with not a lot of branching) but couldn't make it work predictably. Capture 1 : It seems to grab the nodes at rather arbitrary points? it appears to be related to the presence of frames. Capture 2 : after removing some frames, it works more predictably, but some nodes (such as the index node around screen center) are always left behind. I'm not sure how it works under the hood, so perhaps this suggestion is irrelevant, but could it be made more obvious by depending on the active node instead? or the selected nodes? similar to the transform operator, except grabbing everything up/downstream of the actively transformed node(s)? I wonder if perhaps it would even work as a transform operator flag, holding a hotkey while tweaking a node could trigger it. But there's the question of how to manage multiple selected nodes.
Contributor

Just tested it out and it works quite well, I'm a big fan! I had instant crashes when loading some larger node trees (even just a node tree with 4 node groups, but inside the node groups themselves were quite large so maybe that was affecting it.

Certainly some kind of visual feedback for what is being affected would help a lot.

In the attached example I would consider this to be inconsistent behavior. Moving the random value node moves both it and the position node, whereas moving the position node only moves the position node.

Just tested it out and it works quite well, I'm a big fan! I had instant crashes when loading some larger node trees (even just a node tree with 4 node groups, but inside the node groups themselves were quite large so maybe that was affecting it. Certainly some kind of visual feedback for what is being affected would help a lot. In the attached example I would consider this to be inconsistent behavior. Moving the random value node moves both it and the position node, whereas moving the position node only moves the position node.
Jacques Lucke added 1 commit 2024-05-21 16:50:34 +02:00
Author
Member

Thanks for the feedback so far.

I assume originally the boundary was only tiny, and grow larger and larger to the left because of linkage dependency.

That's correct. The underlying goal here is to avoid moving nodes on top of each other. The situation could maybe be improved by starting to move unconnected nodes to the left only if they would start overlapping with other moved nodes. Not sure if that's helpful or more confusing.

I also find the split isn't available in vertical direction.

Would be nice, but it's also a very different problem I think. Should also be less common and doesn't have as high of a priority right now. How would you approach sliding in the vertical direction?

I tried using the operator on my tree generator nodetree, which is quite big, but the build crashes after about three seconds on opening the file, whatever I do.

Was probably the same as #122051. I fixed it in main and merged it into this branch. Will create a new package build.

In the attached example I would consider this to be inconsistent behavior. Moving the random value node moves both it and the position node, whereas moving the position node only moves the position node.

Looks wrong. Might be related to interface scaling, checking...

Thanks for the feedback so far. > I assume originally the boundary was only tiny, and grow larger and larger to the left because of linkage dependency. That's correct. The underlying goal here is to avoid moving nodes on top of each other. The situation could maybe be improved by starting to move unconnected nodes to the left only if they would start overlapping with other moved nodes. Not sure if that's helpful or more confusing. > I also find the split isn't available in vertical direction. Would be nice, but it's also a very different problem I think. Should also be less common and doesn't have as high of a priority right now. How would you approach sliding in the vertical direction? > I tried using the operator on my tree generator nodetree, which is quite big, but the build crashes after about three seconds on opening the file, whatever I do. Was probably the same as #122051. I fixed it in `main` and merged it into this branch. Will create a new package build. > In the attached example I would consider this to be inconsistent behavior. Moving the random value node moves both it and the position node, whereas moving the position node only moves the position node. Looks wrong. Might be related to interface scaling, checking...
Jacques Lucke added 2 commits 2024-05-21 17:17:00 +02:00
improve handling of frames
Some checks failed
buildbot/vexp-code-patch-lint Build done.
buildbot/vexp-code-patch-darwin-arm64 Build done.
buildbot/vexp-code-patch-darwin-x86_64 Build done.
buildbot/vexp-code-patch-linux-x86_64 Build done.
buildbot/vexp-code-patch-windows-amd64 Build done.
buildbot/vexp-code-patch-coordinator Build done.
4e8beaa47b
Author
Member

@blender-bot package

@blender-bot package
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR121981) when ready.
First-time contributor

Generally I think it feels good! In terms of the input it feels like it doesn't need the confirmation click, could just be active while holding V (not sure if that's possible in the keymap though).
The heuristic for what gets selected is unclear (see video). It's nice that it will effect less of the node tree though than just bisecting the whole canvas.
That said, I would prefer just a simple position.x +/- slide that behaves predictably than one that's not clear how it'll effect different branches.
As @Bradley_G mentions, maybe Y direction also makes sense for Blender's node trees

Generally I think it feels good! In terms of the input it feels like it doesn't need the confirmation click, could just be active while holding V (not sure if that's possible in the keymap though). The heuristic for what gets selected is unclear (see video). It's nice that it will effect less of the node tree though than just bisecting the whole canvas. That said, I would prefer just a simple position.x +/- slide that behaves predictably than one that's not clear how it'll effect different branches. As @Bradley_G mentions, maybe Y direction also makes sense for Blender's node trees
Contributor

Was probably the same as #122051. I fixed it in main and merged it into this branch. Will create a new package build.

Yep this is fixed for me.

Looks wrong. Might be related to interface scaling, checking...

This is also now fixed for me with the new build.

> Was probably the same as #122051. I fixed it in main and merged it into this branch. Will create a new package build. Yep this is fixed for me. > Looks wrong. Might be related to interface scaling, checking... This is also now fixed for me with the new build.
First-time contributor

The crash situation is fixed, and so is the issue with frames. Some nodes are still not responding : anywhere there's a group input node or a named attribute node it seems to break. At some point (see near the end of capture) a spline parameter connected to a map range breaks too.

It is a great step in usability. I'm not sure it needs a visual indicator at all, imho the nodes moving are all I need to understand what is going on. I have no strong opinion, visual feedback is always nice but not always necessary

The crash situation is fixed, and so is the issue with frames. Some nodes are still not responding : anywhere there's a _group input_ node or a _named attribute_ node it seems to break. At some point (see near the end of capture) a _spline parameter_ connected to a _map range_ breaks too. It is a great step in usability. I'm not sure it needs a visual indicator at all, imho the nodes moving are all I need to understand what is going on. I have no strong opinion, visual feedback is always nice but not always necessary
First-time contributor

Would be nice, but it's also a very different problem I think. Should also be less common and doesn't have as high of a priority right now. How would you approach sliding in the vertical direction?

I think it's quite common, since the good part of procedural node system is to use the same value in multiple places. The node tree very unlikely will be a linear one but rather many different parallel paths that are finally joined together by join geometry.

I agree it's a very different problem and require different mechanisms. (may use same or different shortcuts to trigger too)
It doesn't need to be urgent if the given difficulty is very high or if the designs require more discussion, etc.
This may also not be important since we can ultimately just box select and grab.
but the benefit of having a slide operator:

  1. easy & quick.
  2. we don't need to zoom out the view in order to have enough range to box select and zoom back to the area we were working with.

Currently my assumed approach focuses on full range horizontal split of "the current visible area in editor", and push more nodes away if they starts to vertically overlap outside the view. (not sure if these are possible of course)
The dependency may not be really worried imo for this case.
image

> Would be nice, but it's also a very different problem I think. Should also be less common and doesn't have as high of a priority right now. How would you approach sliding in the vertical direction? I think it's quite common, since the good part of procedural node system is to use the same value in multiple places. The node tree very unlikely will be a linear one but rather many different parallel paths that are finally joined together by join geometry. I agree it's a very different problem and require different mechanisms. (may use same or different shortcuts to trigger too) It doesn't need to be urgent if the given difficulty is very high or if the designs require more discussion, etc. This may also not be important since we can ultimately just box select and grab. but the benefit of having a slide operator: 1. easy & quick. 2. we don't need to zoom out the view in order to have enough range to box select and zoom back to the area we were working with. Currently my assumed approach focuses on full range horizontal split of "the current visible area in editor", and push more nodes away if they starts to vertically overlap outside the view. (not sure if these are possible of course) The dependency may not be really worried imo for this case. ![image](/attachments/67b8accb-637f-42b3-a92d-bf1a07bf0b9d)
Simon Thommes requested changes 2024-05-22 20:22:12 +02:00
Simon Thommes left a comment
Member

This will definitely be super useful! I do think there are quite a few things to iron out here though.

  • imo we definitely need some visual feedback
  • we talked about differentiating between using node-tree topology vs pure location as grouping heuristics based on invoking the operator on top of a node vs in a free space of the node-tree. I still think that is a good idea, since I can already see the current context-dependent behavior being useful, but straight up moving based on location as well. This will be more more intuitive with visual feedback imo
  • I'm a little bit confused with the current heuristics for grouping nodes. It seems like some nodes get left behind and some are 'sticky' depending how much the cursor has already been moved. I'm not sure how to best proceed with this, since I'm sure this is not easy to get perfectly reliable, but this definitely still needs some iteration.
  • the key interaction should work differently imo: I'd propose to trigger/confirm the sliding action with clicking and holding/letting go of the left mouse button while holding down a modifier key. Since we're running out of modifier keys I'd be fine doing it like the draw tool on D and use 'V' as you chose as a modifier key. I'd be open for other suggestions but imo the main interaction should be on the mouse.
    • alternatively I think ALT+MMB would be a nice fit for this, but afaik that combination is illegal due to 3 button mouse emulation
  • sliding horizontally/vertically depending on the initial drag direction sounds good to me
This will definitely be super useful! I do think there are quite a few things to iron out here though. - imo we definitely need some visual feedback - we talked about differentiating between using node-tree topology vs pure location as grouping heuristics based on invoking the operator on top of a node vs in a free space of the node-tree. I still think that is a good idea, since I can already see the current context-dependent behavior being useful, but straight up moving based on location as well. This will be more more intuitive with visual feedback imo - I'm a little bit confused with the current heuristics for grouping nodes. It seems like some nodes get left behind and some are 'sticky' depending how much the cursor has already been moved. I'm not sure how to best proceed with this, since I'm sure this is not easy to get perfectly reliable, but this definitely still needs some iteration. - the key interaction should work differently imo: I'd propose to trigger/confirm the sliding action with clicking and holding/letting go of the left mouse button while holding down a modifier key. Since we're running out of modifier keys I'd be fine doing it like the draw tool on `D` and use 'V' as you chose as a modifier key. I'd be open for other suggestions but imo the main interaction should be on the mouse. - alternatively I think ALT+MMB would be a nice fit for this, but afaik that combination is illegal due to 3 button mouse emulation - sliding horizontally/vertically depending on the initial drag direction sounds good to me
First-time contributor

hmmm, wasn't expecting different opinions on keys.
I am personally satisfied with current state of single hit + click confirmation
because it's comparable to G, which you only hit once, no need to hold it, and confirm with another click.
I think it maximize the convenience to users, and it's like the old way how people organize node tree: keep box select and G...

Draw Tool like action gives me an impression our mouse should move more freely in all directions
but we are sliding at most bidirectionally.
just personal thoughts, and I don't have strong opinions for this topic.

hmmm, wasn't expecting different opinions on keys. I am personally satisfied with current state of single hit + click confirmation because it's comparable to G, which you only hit once, no need to hold it, and confirm with another click. I think it maximize the convenience to users, and it's like the old way how people organize node tree: keep box select and G... Draw Tool like action gives me an impression our mouse should move more freely in all directions but we are sliding at most bidirectionally. just personal thoughts, and I don't have strong opinions for this topic.
Member

I am personally satisfied with current state of single hit + click confirmation because it's comparable to G, which you only hit once, no need to hold it, and confirm with another click.

This is different to G in that G isn't context aware, it doesn't matter where in the node-tree you invoke the operator. If we add functionality that depends on the precise location of the cursor as the operation is invoked, it should be triggered by a click on the mouse imo. I do feel quite strongly that that's the right way to go tbh.

Draw Tool like action gives me an impression our mouse should move more freely in all directions but we are sliding at most bidirectionally.

I'm not sure how changing the key would have any impact on this tbh. Constraining the direction of an operation as you freely use your mouse is something we have in several places in Blender and whether this happens as you click-drag while holding a modifier key or just drag after invoking an operator doesn't make a difference imo.

If the draw tool was triggered immediately as you hold D, rather than once you use the mouse button to draw the usability would go down significantly. I get that this is a more extreme case but imo this is the same general type of interaction.
If I think about this functionality with tablet use for example, it seems strange to me why the interaction wouldn't be connected to the actual pointer that I'm using to specify the precise point of where it happens.

> I am personally satisfied with current state of single hit + click confirmation because it's comparable to G, which you only hit once, no need to hold it, and confirm with another click. This is different to G in that G isn't context aware, it doesn't matter where in the node-tree you invoke the operator. If we add functionality that depends on the precise location of the cursor as the operation is invoked, it should be triggered by a click on the mouse imo. I do feel quite strongly that that's the right way to go tbh. > Draw Tool like action gives me an impression our mouse should move more freely in all directions but we are sliding at most bidirectionally. I'm not sure how changing the key would have any impact on this tbh. Constraining the direction of an operation as you freely use your mouse is something we have in several places in Blender and whether this happens as you click-drag while holding a modifier key or just drag after invoking an operator doesn't make a difference imo. If the draw tool was triggered immediately as you hold D, rather than once you use the mouse button to draw the usability would go down significantly. I get that this is a more extreme case but imo this is the same general type of interaction. If I think about this functionality with tablet use for example, it seems strange to me why the interaction wouldn't be connected to the actual pointer that I'm using to specify the precise point of where it happens.
Jacques Lucke added 4 commits 2024-05-31 15:08:29 +02:00
Member

imo the interaction with the mouse feels a lot better! It would still be nicer to use a proper modifier key instead of V, but we are already pretty much out of those. The only other option I see would be to convert this into a tool, which would have the benefit that we could in theory even utilize more modifier keys on top of having the tool selected. But since nobody as far as I'm aware uses tools in the node-editor, that's probably not the greatest idea paradigm shift...
Also, this tool should be easy enough to initialize that it can become a natural part of the workflow and switching into a different context every time you want to use it seems too much.

I think it would be better for the interaction of the operator to lock the nodes that will be moved when starting the motion, rather than remembering the starting position and deciding based on that. In theory visual feedback could help by indicating where the action was started, but I actually think it's better to stick to an initial decision here. This would allow also to move all nodes on the left towards the right for example, which can be quite useful in situations like this one (which is quite common with fields):
image

How about using frames to restrict the scope of nodes when clicking on an empty space within a frame? That seems like it would give more precise control and the current functionality could still be achieved by moving the mouse outside of the frame instead.

I think the current heuristic about which nodes to move based on node context works fine for upstream nodes, but for downstream it happens quite easily that some nodes are lost along the way:
image
I don't really know if this is solvable, I'd have to think about it more. Maybe there could be an exception for single nodes that go back upstream for 1 step.
Since the current behavior is reliable though, I'd be fine leaving it like it is for the time being.

Some additional, not entirely sorted thoughts out of the scope of this initial implementation:

This idea could be taken even further and rely on the initial direction of the cursor for selecting the group of nodes to be moved and then unlocking the axis to place them freely in 2D. At that point this could also just be a gesture based selection tool to add nodes upstream/downstream/left/right to the current selection

imo the interaction with the mouse feels a lot better! It would still be nicer to use a proper modifier key instead of `V`, but we are already pretty much out of those. The only other option I see would be to convert this into a tool, which would have the benefit that we could in theory even utilize more modifier keys on top of having the tool selected. But since nobody as far as I'm aware uses tools in the node-editor, that's probably not the greatest idea paradigm shift... Also, this tool should be easy enough to initialize that it can become a natural part of the workflow and switching into a different context every time you want to use it seems too much. I think it would be better for the interaction of the operator to lock the nodes that will be moved when starting the motion, rather than remembering the starting position and deciding based on that. In theory visual feedback could help by indicating where the action was started, but I actually think it's better to stick to an initial decision here. This would allow also to move all nodes on the left towards the right for example, which can be quite useful in situations like this one (which is quite common with fields): ![image](/attachments/35f2b39a-1055-4d70-94e7-2ff34315aa5f) How about using frames to restrict the scope of nodes when clicking on an empty space within a frame? That seems like it would give more precise control and the current functionality could still be achieved by moving the mouse outside of the frame instead. I think the current heuristic about which nodes to move based on node context works fine for upstream nodes, but for downstream it happens quite easily that some nodes are lost along the way: ![image](/attachments/d2547e83-b837-415d-965d-99ba5c144dca) I don't really know if this is solvable, I'd have to think about it more. Maybe there could be an exception for single nodes that go back upstream for 1 step. Since the current behavior is reliable though, I'd be fine leaving it like it is for the time being. Some additional, not entirely sorted thoughts out of the scope of this initial implementation: This idea could be taken even further and rely on the initial direction of the cursor for selecting the group of nodes to be moved and then unlocking the axis to place them freely in 2D. At that point this could also just be a gesture based selection tool to add nodes upstream/downstream/left/right to the current selection
Jacques Lucke added 3 commits 2024-06-01 10:30:27 +02:00
select trigger nodes from frame under mouse
Some checks failed
buildbot/vexp-code-patch-lint Build done.
buildbot/vexp-code-patch-darwin-x86_64 Build done.
buildbot/vexp-code-patch-darwin-arm64 Build done.
buildbot/vexp-code-patch-linux-x86_64 Build done.
buildbot/vexp-code-patch-windows-amd64 Build done.
buildbot/vexp-code-patch-coordinator Build done.
62f2f4df84
Author
Member

I think it would be better for the interaction of the operator to lock the nodes that will be moved when starting the motion

Fine with me, done.

How about using frames to restrict the scope of nodes when clicking on an empty space within a frame?

Sounds like a good idea, just implemented that. I changed it a little bit in that nodes upstream of the frames will move too.

I think the current heuristic about which nodes to move based on node context works fine for upstream nodes, but for downstream it happens quite easily that some nodes are lost along the way. I don't really know if this is solvable, I'd have to think about it more. Maybe there could be an exception for single nodes that go back upstream for 1 step.

Yeah, noticed that too. I don't think having an exception for single nodes is a solution. It still won't work when there are e.g. two nodes. I do wonder whether it can make sense to just limit the behavior to always move the nodes on the left side. Then we wouldn't need the initial gesture to select the nodes to move and could support moving in every direction immediately. It feels like this would still cover the main use case with potentially less gotchas.

> I think it would be better for the interaction of the operator to lock the nodes that will be moved when starting the motion Fine with me, done. > How about using frames to restrict the scope of nodes when clicking on an empty space within a frame? Sounds like a good idea, just implemented that. I changed it a little bit in that nodes upstream of the frames will move too. > I think the current heuristic about which nodes to move based on node context works fine for upstream nodes, but for downstream it happens quite easily that some nodes are lost along the way. I don't really know if this is solvable, I'd have to think about it more. Maybe there could be an exception for single nodes that go back upstream for 1 step. Yeah, noticed that too. I don't think having an exception for single nodes is a solution. It still won't work when there are e.g. two nodes. I do wonder whether it can make sense to just limit the behavior to always move the nodes on the left side. Then we wouldn't need the initial gesture to select the nodes to move and could support moving in every direction immediately. It feels like this would still cover the main use case with potentially less gotchas.
Member

Overall the changes feel good to me!

I changed it a little bit in that nodes upstream of the frames will move too.

I'm not convinced by this though. It doesn't always have the desired effect since sometimes there is enough space to move the nodes without moving up/downstream. So I'd prioritize consistency and stick to the rule of not doing that sort of propagation when clicking on an empty space.
The same current behavior can still be achieved by clicking on a node/selected nodes instead.

I do wonder whether it can make sense to just limit the behavior to always move the nodes on the left side.

I'm not sure I understand exactly what you are proposing here. You definitely should be able to slide nodes to either side with this operator imo. And in theory the problem exists in both directions, it's just more common with the downstream propagation.

Overall the changes feel good to me! > I changed it a little bit in that nodes upstream of the frames will move too. I'm not convinced by this though. It doesn't always have the desired effect since sometimes there is enough space to move the nodes without moving up/downstream. So I'd prioritize consistency and stick to the rule of not doing that sort of propagation when clicking on an empty space. The same current behavior can still be achieved by clicking on a node/selected nodes instead. > I do wonder whether it can make sense to just limit the behavior to always move the nodes on the left side. I'm not sure I understand exactly what you are proposing here. You definitely should be able to slide nodes to either side with this operator imo. And in theory the problem exists in both directions, it's just more common with the downstream propagation.
First-time contributor

Is there an up to date test build?

Is there an up to date test build?
Author
Member

@blender-bot package

@blender-bot package
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR121981) when ready.
Jacques Lucke added 3 commits 2024-06-03 18:06:48 +02:00
First-time contributor

We could have a dotted circle like in mesh proportional editing to influence the height/wideness of the zone influenced by the sliding.

We could have a dotted circle like in mesh proportional editing to influence the height/wideness of the zone influenced by the sliding.
Author
Member

A circle doesn't seem to make sense here because the influence region is not actually a circle (or any other specific shape).

A circle doesn't seem to make sense here because the influence region is not actually a circle (or any other specific shape).
First-time contributor

I like the V+click approach much more, this way it seems more deliberate. However, since it now requires a click, the pointer positioning needs to be much more accurate because you have to actually grab a node by its header now, instead of loosely aiming at it. If you accidentally click over a number field, Blender will just edit the number field. Ideally, holding V would ignore the widget hitboxes and just make entire nodes grabbable, so that you can do this from a distance (zoomed out). That's not a dealbreaker by any means.

If I understand correctly, you commit to a direction initially and it determines what gets moved. Is there a reason why both directions can't be accounted for, when sliding either left or right? It seems it only really works when dragging to the left. When dragging to the right, upstream branches are left out.

I like the V+click approach much more, this way it seems more deliberate. However, since it now requires a click, the pointer positioning needs to be much more accurate because you have to actually grab a node by its header now, instead of loosely aiming at it. If you accidentally click over a number field, Blender will just edit the number field. Ideally, holding V would ignore the widget hitboxes and just make entire nodes grabbable, so that you can do this from a distance (zoomed out). That's not a dealbreaker by any means. If I understand correctly, you commit to a direction initially and it determines what gets moved. Is there a reason why both directions can't be accounted for, when sliding either left or right? It seems it only really works when dragging to the left. When dragging to the right, upstream branches are left out.
Member

I agree that holding down the modifier key for this operator should disable any interactions with the node interface like sliders and toggles.

I think even the most basic version of this operator should at least have some UI for the mode when clicking on empty space, since then the context looks a bit arbitrary right now. I'm just thinking of drawing vertical lines across the region on the initial and the current position and a highly transparent rectangle between them.

I agree that holding down the modifier key for this operator should disable any interactions with the node interface like sliders and toggles. I think even the most basic version of this operator should at least have some UI for the mode when clicking on empty space, since then the context looks a bit arbitrary right now. I'm just thinking of drawing vertical lines across the region on the initial and the current position and a highly transparent rectangle between them.
Jacques Lucke added 1 commit 2024-08-18 13:38:56 +02:00
Merge branch 'main' into slide-nodes
All checks were successful
buildbot/vexp-code-patch-lint Build done.
buildbot/vexp-code-patch-darwin-x86_64 Build done.
buildbot/vexp-code-patch-darwin-arm64 Build done.
buildbot/vexp-code-patch-linux-x86_64 Build done.
buildbot/vexp-code-patch-windows-amd64 Build done.
buildbot/vexp-code-patch-coordinator Build done.
50d0480ab1
Author
Member

@blender-bot package

@blender-bot package
Member

Package build started. Download here when ready.

Package build started. [Download here](https://builder.blender.org/download/patch/PR121981) when ready.
Author
Member
Finally created the feedback thread: https://devtalk.blender.org/t/slide-nodes-operator-feedback/36284
All checks were successful
buildbot/vexp-code-patch-lint Build done.
buildbot/vexp-code-patch-darwin-x86_64 Build done.
buildbot/vexp-code-patch-darwin-arm64 Build done.
buildbot/vexp-code-patch-linux-x86_64 Build done.
buildbot/vexp-code-patch-windows-amd64 Build done.
buildbot/vexp-code-patch-coordinator Build done.
This pull request has changes conflicting with the target branch.
  • scripts/presets/keyconfig/keymap_data/blender_default.py

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u slide-nodes:JacquesLucke-slide-nodes
git checkout JacquesLucke-slide-nodes
Sign in to join this conversation.
No reviewers
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Viewport & EEVEE
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Module
Viewport & EEVEE
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Severity
High
Severity
Low
Severity
Normal
Severity
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
8 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#121981
No description provided.