Nodes: new interactive operator to slide nodes #121981
No reviewers
Hans Goudey
Simon Thommes
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Code Documentation
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
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#121981
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "JacquesLucke/blender:slide-nodes"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
TODO:
@blender-bot package
Package build started. Download here when ready.
Thanks for adding this feature. I did some quick tests, here are some of my findings:
I am not too sure how validation bubble is constructed in this extreme case:
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.
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.
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.
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.
Thanks for the feedback so far.
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.
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?
Was probably the same as #122051. I fixed it in
mainand merged it into this branch. Will create a new package build.Looks wrong. Might be related to interface scaling, checking...
@blender-bot package
Package build started. Download here when ready.
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
Yep this is fixed for me.
This is also now fixed for me with the new build.
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
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:
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.
This will definitely be super useful! I do think there are quite a few things to iron out here though.
Dand 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.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.
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.
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.
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):
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:
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
Fine with me, done.
Sounds like a good idea, just implemented that. I changed it a little bit in that nodes upstream of the frames will move too.
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.
Overall the changes feel good to me!
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'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.
Is there an up to date test build?
@blender-bot package
Package build started. Download here when ready.
We could have a dotted circle like in mesh proportional editing to influence the height/wideness of the zone influenced by the sliding.
A circle doesn't seem to make sense here because the influence region is not actually a circle (or any other specific shape).
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 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.
@blender-bot package
Package build started. Download here when ready.
Finally created the feedback thread: https://devtalk.blender.org/t/slide-nodes-operator-feedback/36284
Checkout
From your project repository, check out a new branch and test the changes.