WIP: Node Editor: Improve frame joining during transform #105457

Draft
Leon Schittek wants to merge 18 commits from lone_noel/blender:node-editor-frame-joining into main

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

Improve frame joining during transform:

  • Detach nodes from frames during transform by pressing Shift
  • Base frame joining on the bounding box center of the selection
  • Indicate the center of the selection with a small dot (placeholder for now)
  • Highlight frames, when nodes are about to be added to them

Motivation
The current behavior does work well enough in most simple cases, but there are some issues, that could be improved:

  1. Which frame is joined into is determined via the cursor position.
  2. There is no indication which frame is chosen for joining during transform.
  3. Not all transformed nodes can necessarily be joined into a frame and there is no indication which nodes actually will be joined leaving the user to figure out if the action had the desired effect after the fact.

Point (1.) and (2.) are problematic because during transform there can be a huge disconnect between the position of the transformed nodes and the frame they are joined into. The cursor isn't necessarily in the users focus while positioning the nodes.
This can be especially confusing when combined with inserting nodes into links which actually is based on the node's position.

Video of the issue: frame-node-join-issue.mp4

Improve frame joining during transform: * Detach nodes from frames during transform by pressing `Shift` * Base frame joining on the bounding box center of the selection * Indicate the center of the selection with a small dot (placeholder for now) * Highlight frames, when nodes are about to be added to them --- **Motivation** The current behavior does work well enough in most simple cases, but there are some issues, that could be improved: 1. Which frame is joined into is determined via the cursor position. 2. There is no indication which frame is chosen for joining during transform. 3. Not all transformed nodes can necessarily be joined into a frame and there is no indication which nodes actually will be joined leaving the user to figure out if the action had the desired effect after the fact. Point (1.) and (2.) are problematic because during transform there can be a huge disconnect between the position of the transformed nodes and the frame they are joined into. The cursor isn't necessarily in the users focus while positioning the nodes. This can be especially confusing when combined with inserting nodes into links which actually _is_ based on the node's position. *Video of the issue: [frame-node-join-issue.mp4](/attachments/2ed90552-222d-4686-b92d-8de07006599f)*
Leon Schittek added the
Interest
User Interface
Interest
Nodes & Physics
labels 2023-03-05 13:00:14 +01:00

In a strange way, when I recalled previously seen examples of this, for some reason my brain told me that the nodes of the frame were animatedly growing to show that they were now the parent of this node...

In a strange way, when I recalled previously seen examples of this, for some reason my brain told me that the nodes of the frame were animatedly growing to show that they were now the parent of this node...
Leon Schittek force-pushed node-editor-frame-joining from d0974fd25e to 38d4153b8e 2023-03-11 10:34:43 +01:00 Compare
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/PR105457) when ready.
Leon Schittek force-pushed node-editor-frame-joining from 38d4153b8e to 74e7e20ea3 2023-04-01 18:15:39 +02:00 Compare
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/PR105457) when ready.
Leon Schittek force-pushed node-editor-frame-joining from 74e7e20ea3 to 8ec8733806 2023-04-10 18:41:16 +02:00 Compare
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/PR105457) when ready.
Leon Schittek force-pushed node-editor-frame-joining from 8ec8733806 to 17c3d10a4e 2023-05-08 17:18:54 +02:00 Compare
Leon Schittek force-pushed node-editor-frame-joining from 17c3d10a4e to 069b5156d0 2023-06-23 13:30:35 +02:00 Compare
Leon Schittek force-pushed node-editor-frame-joining from 069b5156d0 to e2c4e057c4 2023-09-22 13:58:18 +02:00 Compare
Author
Member

I updated the PR according to some feedback here: #108358 (comment)

The behavior works as follows:

  • Detach nodes from frames during transform by pressing Shift
  • Base frame joining on the bounding box center of the selection
  • Indicate the center of the selection with a small dot (placeholder for now)
  • Highlight frames, when nodes are about to be added to them

Here's a quick screenshot of what that looks like:
transformed-nodes-with-indicator.png

I updated the PR according to some feedback here: https://projects.blender.org/blender/blender/pulls/108358#issuecomment-1012819 The behavior works as follows: * Detach nodes from frames during transform by pressing `Shift` * Base frame joining on the bounding box center of the selection * Indicate the center of the selection with a small dot (placeholder for now) * Highlight frames, when nodes are about to be added to them Here's a quick screenshot of what that looks like: ![transformed-nodes-with-indicator.png](/attachments/0d6024df-7c33-46bb-b3eb-c97c3b037209)
Leon Schittek added 1 commit 2023-09-25 16:09:29 +02:00
Member

I really like this approach a lot more, it feels quite natural to me!
Highlighting the frame works great and I'm super happy that moving with G doesn't care about the cursor position anymore.

My only gripe with this would be that the dot doesn't look very elegant/has some readability issues. It should always be drawn on top (which I think it already is). Maybe drawing it a bit thicker and in (selection) orange would look better and more clear.

Additionally I think the unparent behavior should be the same when holding shift before dragging, as I mentioned in #108358 .

Once those two things are figured out and signed off (and code is reviewed) this is ready to merge imo.

I really like this approach a lot more, it feels quite natural to me! Highlighting the frame works great and I'm super happy that moving with G doesn't care about the cursor position anymore. My only gripe with this would be that the dot doesn't look very elegant/has some readability issues. It should always be drawn on top (which I think it already is). Maybe drawing it a bit thicker and in (selection) orange would look better and more clear. Additionally I think the unparent behavior should be the same when holding shift before dragging, as I mentioned in #108358 . Once those two things are figured out and signed off (and code is reviewed) this is ready to merge imo.
Leon Schittek added 5 commits 2023-09-26 11:06:09 +02:00
Author
Member

The dot is now a bit thicker and using the selection color.
Still not great but I haven't come up with anything better, yet, and there doesn't seem to be a similar concept of "selection center indicator" elsewhere in blender to cheat off of.

I'll have to let that simmer a bit to see if I can come up with something better:

orange-dot.png

I also improved the behavior when pressing shift before dragging, but it isn't quite there, yet.
Since Shift + Press is toggling the selection it works nicely when shift + Drag-ing an unselected/inactive node - but unfortunately it will still deselect when dragging the active node...

After tinkering with the keymap I'm unsure if this is something that can easily be worked around. It seems like a more general issue.
E.g. ctrl + Drag-ing a node will just select it rather than moving all currently selected nodes with the "invert snap" option. And the only reason pressing Alt and the dragging works to detach a node is because it happens to not conflict with the selection keymap...

But the whole keymap code seems pretty complicated so I might have mssed something.

The dot is now a bit thicker and using the selection color. Still not great but I haven't come up with anything better, yet, and there doesn't seem to be a similar concept of "selection center indicator" elsewhere in blender to cheat off of. I'll have to let that simmer a bit to see if I can come up with something better: ![orange-dot.png](/attachments/0dfefee3-966c-46f5-91c8-f18eff526351) I also improved the behavior when pressing shift before dragging, but it isn't quite there, yet. Since `Shift + Press` is toggling the selection it works nicely when `shift + Drag`-ing an unselected/inactive node - but unfortunately it will still deselect when dragging the active node... After tinkering with the keymap I'm unsure if this is something that can easily be worked around. It seems like a more general issue. E.g. `ctrl + Drag`-ing a node will just select it rather than moving all currently selected nodes with the "invert snap" option. And the only reason pressing `Alt` and the dragging works to detach a node is because it happens to not conflict with the selection keymap... But the whole keymap code seems pretty complicated so I might have mssed something.
Member

Thanks for the update! This helps a lot with readability. Would be good to run this by the UI module, maybe someone has a good idea. For me a similar equivalent would be the origin point in the 3D viewport or the sequencer. It's not too bad as it is imo.

I think there is still some tweaking that can be done though. The none highlighted version imo is more important to see clearly than the highlighted one. Right now it's the other way around. Maybe they should both be filled, but highlighted changes the color slightly. We already have the frame highlight to indicate this anyways.

Thanks for the update! This helps a lot with readability. Would be good to run this by the UI module, maybe someone has a good idea. For me a similar equivalent would be the origin point in the 3D viewport or the sequencer. It's not too bad as it is imo. I think there is still some tweaking that can be done though. The none highlighted version imo is more important to see clearly than the highlighted one. Right now it's the other way around. Maybe they should both be filled, but highlighted changes the color slightly. We already have the frame highlight to indicate this anyways.
Leon Schittek added 4 commits 2023-10-04 12:42:36 +02:00
Author
Member

I tweaked the dot a bit to make it more prominent. Will bring it up with the UI module now that 4.0 is in bcon3.

During my attempts to tweak the keymap I've also looked through some of the other editors it seems like shift + drag-ing something never actually triggers the transform operator. So while this is not great, it's consistent and changing this probably has to be discussed separately...

Just to test the behavior for now I've changed the node editor selection keymap so that pressing shift always adds the node to the selection when clicking on it, while pressing ctrl will always deselect it. This is consistent with the behavior of the other selection modes (box, lasso, circle) and works as desired for unparenting nodes, but it's different from all the other editors where shift + click is set to togge the selection state.
So I'm not sure this is a viable option. But I wonder what's the reason for toggling the selection on shift + click rather than having the same behavior as the other selection modes.

I tweaked the dot a bit to make it more prominent. Will bring it up with the UI module now that 4.0 is in bcon3. During my attempts to tweak the keymap I've also looked through some of the other editors it seems like `shift + drag`-ing something never actually triggers the transform operator. So while this is not great, it's consistent and changing this probably has to be discussed separately... Just to test the behavior for now I've changed the node editor selection keymap so that pressing `shift` always adds the node to the selection when clicking on it, while pressing `ctrl` will always deselect it. This is consistent with the behavior of the other selection modes (box, lasso, circle) and works as desired for unparenting nodes, but it's different from all the other editors where `shift + click` is set to togge the selection state. So I'm not sure this is a viable option. But I wonder what's the reason for toggling the selection on `shift + click` rather than having the same behavior as the other selection modes.
Leon Schittek added 4 commits 2023-10-30 21:50:00 +01:00
Leon Schittek added 2 commits 2023-11-10 00:35:12 +01:00
Author
Member

I couldn't get things to work via the keymap. So I've now added a macro operator mapped to shift + drag that first selects the node and then calls the move operator.
So now you can hold shift even before clicking to pull nodes out of frames.

@SimonThommes, I'd like to hear your opinion on the selection behavior when shift + drag-ing a node:

  1. Right now I've made it so that shift+ drag-ing extends the selection since is is closer to the "toggle" behavior that shift is usually associated with. So shift + drag-ing a node will move the dragged node and all other selected nodes.
  2. Alternatively shift + drag-ing could mimic the "tweak" behavior:
    • move all selected nodes, when the dragged node is already selected
    • only move the dragged node and deselect all others, when the dragged node is currently unselected
I couldn't get things to work via the keymap. So I've now added a macro operator mapped to `shift + drag` that first selects the node and then calls the move operator. So now you can hold `shift` even before clicking to pull nodes out of frames. @SimonThommes, I'd like to hear your opinion on the selection behavior when `shift + drag`-ing a node: 1. Right now I've made it so that `shift+ drag`-ing *extends* the selection since is is closer to the "toggle" behavior that `shift` is usually associated with. So `shift + drag`-ing a node will move the dragged node and all other selected nodes. 2. Alternatively `shift + drag`-ing could mimic the "tweak" behavior: * move all selected nodes, when the dragged node is already selected * only move the dragged node and deselect all others, when the dragged node is currently unselected
Leon Schittek added 1 commit 2023-11-10 10:55:47 +01:00
This pull request has changes conflicting with the target branch.
  • source/blender/editors/space_node/node_relationships.cc
  • source/blender/editors/transform/transform_convert_node.cc

Checkout

From your project repository, check out a new branch and test the changes.
git fetch -u node-editor-frame-joining:lone_noel-node-editor-frame-joining
git checkout lone_noel-node-editor-frame-joining
Sign in to join this conversation.
No reviewers
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
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
EEVEE & Viewport
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
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
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
EEVEE & Viewport
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
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
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
4 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#105457
No description provided.