Mute node links (design task) #52659

Closed
opened 2017-09-06 07:13:16 +02:00 by Campbell Barton · 26 comments

This is a design task created on behalf of @CharlieJolly to review functionality from D2807

Code review can happen separate, question is if the functionality is helpful - all things considered.

This is a design task created on behalf of @CharlieJolly to review functionality from [D2807](https://archive.blender.org/developer/D2807) Code review can happen separate, question is if the functionality is helpful - all things considered.
Charlie Jolly was assigned by Campbell Barton 2017-09-06 07:13:16 +02:00
Author
Owner

Changed status to: 'Open'

Changed status to: 'Open'
Author
Owner
Added subscribers: @CharlieJolly, @ideasman42, @pablovazquez, @JulianEisel, @sebastian_k
Campbell Barton changed title from Mute node wires (design task) to Feature Suggestion: Mute node links (design task) 2017-09-06 07:19:14 +02:00
Campbell Barton changed title from Feature Suggestion: Mute node links (design task) to Mute node links (design task) 2017-09-06 07:19:25 +02:00

I didn't test this yet, but I can see how this can be quite useful, especially in large and complex nodetrees with long noodle connections, where you want to compare the effect of a node input with the original node input value. Visually it is consistent with the red color of the mute node functionality and seems pretty straight forward to use.

I didn't test this yet, but I can see how this can be quite useful, especially in large and complex nodetrees with long noodle connections, where you want to compare the effect of a node input with the original node input value. Visually it is consistent with the red color of the mute node functionality and seems pretty straight forward to use.
Member

Added subscriber: @GregZaal

Added subscriber: @GregZaal
Member

Initially I wasn't sure if/when this feature would be used, but thinking about it I often like to temporarily add reroute nodes before breaking a connection (like this) to make it easier to re-add the connection after testing something, especially when dealing with large node trees.

I'm not sure what the current state of sticky keys is (D840), but usage of this feature would be most intuitive (imo) by holding down M and left-click dragging over the lines (like the current Ctrl-LMB to cut connections, but with M as the modifier key instead of Ctrl). M is the same hotkey to mute nodes, but here it is held down while drawing instead of just pressed. This would be less likely to be done by accident I think.

As Campbell mentioned in the other thread, red is used for errors (e.g. cyclic links). Perhaps it would make more sense visually as a faded dashed line like: n3.png

This is obviously far less noticable at a glance than a red line, but I think as long as it's hard to activate by accident, it doesn't matter.

Would be interested to hear from users who work with others, sharing complex node groups for eg.

While random hard-to-find muted links would certainly make understanding someone else's node tree harder, there are many other ways to get confused already: muted nodes hidden in groups, non-active output nodes, lack of frames & reroutes, etc - it's up to the author of the node tree to make sure it is readable if he/she is sharing it with others. I believe the majority of blender users work alone, so this shouldn't be a major reason for dismissing the patch.

Initially I wasn't sure if/when this feature would be used, but thinking about it I often like to temporarily add reroute nodes before breaking a connection ([like this](https://i.imgur.com/sWM0RWs.png)) to make it easier to re-add the connection after testing something, especially when dealing with large node trees. I'm not sure what the current state of sticky keys is ([D840](https://archive.blender.org/developer/D840)), but usage of this feature would be most intuitive (imo) by holding down `M` and left-click dragging over the lines (like the current `Ctrl`-`LMB` to cut connections, but with `M` as the modifier key instead of `Ctrl`). `M` is the same hotkey to mute nodes, but here it is held down while drawing instead of just pressed. This would be less likely to be done by accident I think. As Campbell mentioned in the other thread, red is used for errors (e.g. [cyclic links](https://i.imgur.com/CRvcoRM.png)). Perhaps it would make more sense visually as a faded dashed line like: ![n3.png](https://archive.blender.org/developer/F775381/n3.png) This is obviously far less noticable at a glance than a red line, but I think as long as it's hard to activate by accident, it doesn't matter. > Would be interested to hear from users who work with others, sharing complex node groups for eg. While random hard-to-find muted links would certainly make understanding someone else's node tree harder, there are many other ways to get confused already: muted nodes hidden in groups, non-active output nodes, lack of frames & reroutes, etc - it's up to the author of the node tree to make sure it is readable if he/she is sharing it with others. I believe the majority of blender users work alone, so this shouldn't be a major reason for dismissing the patch.
Author
Owner

Main risk AFAICS is this isn't obvious when zoomed out and users loose time troubleshooting someone elses file only to find a link was muted.

Subtle red/green color blindness is common, thin lines make the color difference harder to see.

Black and yellow stipple is too ugly to miss, but expect the UI mafia wont like it :)

Main risk AFAICS is this isn't obvious when zoomed out and users loose time troubleshooting someone elses file only to find a link was muted. Subtle red/green color blindness is common, thin lines make the color difference harder to see. Black and yellow stipple is too ugly to miss, but expect the UI mafia wont like it :)
Member

@ideasman42 - Thanks for creating a task.

For comparison, the following image shows from top to bottom, cyclic link, muted node and muted wire. Visually they all indicate that there is a change to the normal node behaviour which is consistent. The muted node shows a wire in red that is connected. The muted node wire is also only red on the output side. I think a dashed line maybe more distracting.

image.png

Alternative solution with added horizontal bar.

image.png

Zoomed out.

image.png

@ideasman42 - Thanks for creating a task. For comparison, the following image shows from top to bottom, cyclic link, muted node and muted wire. Visually they all indicate that there is a *change* to the normal node behaviour which is consistent. The muted node shows a wire in red that is connected. The muted node wire is also only red on the output side. I think a dashed line maybe more distracting. ![image.png](https://archive.blender.org/developer/F775402/image.png) Alternative solution with added horizontal bar. ![image.png](https://archive.blender.org/developer/F775452/image.png) Zoomed out. ![image.png](https://archive.blender.org/developer/F775482/image.png)
Member

Added subscriber: @JacquesLucke

Added subscriber: @JacquesLucke
Author
Owner

@CharlieJolly new display is better, nice it can be seen when zoomed out.

In #52659#457337, @GregZaal wrote:

Would be interested to hear from users who work with others, sharing complex node groups for eg.

While random hard-to-find muted links would certainly make understanding someone else's node tree harder, there are many other ways to get confused already: muted nodes hidden in groups, non-active output nodes, lack of frames & reroutes, etc - it's up to the author of the node tree to make sure it is readable if he/she is sharing it with others. I believe the majority of blender users work alone, so this shouldn't be a major reason for dismissing the patch.

This attitude I find a bit defeatist "We can shoot ourselves in the foot in many ways - so adding another is OK" ~
The opposite argument can be made too "There are already many ways to shoot yourself in the foot, so lets not add more!".

It's possible I have a biased view from getting bug reports that turn out to be some obscure feature toggled by accident.

@CharlieJolly new display is better, nice it can be seen when zoomed out. > In #52659#457337, @GregZaal wrote: >> Would be interested to hear from users who work with others, sharing complex node groups for eg. > > While random hard-to-find muted links would certainly make understanding someone else's node tree harder, there are many other ways to get confused already: muted nodes hidden in groups, non-active output nodes, lack of frames & reroutes, etc - it's up to the author of the node tree to make sure it is readable if he/she is sharing it with others. I believe the majority of blender users work alone, so this shouldn't be a major reason for dismissing the patch. This attitude I find a bit defeatist *"We can shoot ourselves in the foot in many ways - so adding another is OK"* ~ The opposite argument can be made too *"There are already many ways to shoot yourself in the foot, so lets not add more!"*. It's possible I have a biased view from getting bug reports that turn out to be some obscure feature toggled by accident.

Added subscriber: @dfelinto

Added subscriber: @dfelinto

My suggestion instead:

  • Add a re-route socket when disconnecting a socket.
  • If you draw a re-route socket into an empty socket, you remove the re-route socket, and link the re-route socket input with this new socket.

This way you can still easily disconnect and reconnect sockets in an almost non-destructive way. And it doesn't add any new functionality to Blender, just polish the existent ones.

My suggestion instead: * Add a re-route socket when disconnecting a socket. * If you draw a re-route socket into an empty socket, you remove the re-route socket, and link the re-route socket input with this new socket. This way you can still easily disconnect and reconnect sockets in an almost non-destructive way. And it doesn't add any new functionality to Blender, just polish the existent ones.
Author
Owner

@dfelinto generally sounds good. Just wondering if people will be annoyed if they have to manually delete the dangling sockets - where they didnt have to previously.

They can always use the knife (Ctrl-LMB) tool to cut links without messing with sockets so it could be OK.

@dfelinto generally sounds good. Just wondering if people will be annoyed if they have to manually delete the dangling sockets - where they didnt have to previously. They can always use the knife (Ctrl-LMB) tool to cut links without messing with sockets so it could be OK.
Member

In #52659#457475, @dfelinto wrote:
My suggestion instead:

  • Add a re-route socket when disconnecting a socket.
  • If you draw a re-route socket into an empty socket, you remove the re-route socket, and link the re-route socket input with this new socket.

This way you can still easily disconnect and reconnect sockets in an almost non-destructive way. And it doesn't add any new functionality to Blender, just polish the existent ones.

TBH this sounds like a rather confusing workaround to me :) Imagine a new reroute socket appears each time you disconnect sockets. It would be a confusing surprise to see those reroutes appear out of the blue ("what are these little dots that keep appearing?!") . A different behavior when using knife cutting would be even more confusing. And like Campbell mentioned, you had to remove them all the time.

Simply muting a link seems pretty intuitive to me OTOH. The state (muted or not) just has to be communicated well enough. It's not any new functionality, we allow muting/hiding entities (as in objects, VSE strips, nodes, masks, ...) all over in Blender, it's just applying it to a new entity.

> In #52659#457475, @dfelinto wrote: > My suggestion instead: > > * Add a re-route socket when disconnecting a socket. > * If you draw a re-route socket into an empty socket, you remove the re-route socket, and link the re-route socket input with this new socket. > > This way you can still easily disconnect and reconnect sockets in an almost non-destructive way. And it doesn't add any new functionality to Blender, just polish the existent ones. TBH this sounds like a rather confusing workaround to me :) Imagine a new reroute socket appears each time you disconnect sockets. It would be a confusing surprise to see those reroutes appear out of the blue ("what are these little dots that keep appearing?!") . A different behavior when using knife cutting would be even more confusing. And like Campbell mentioned, you had to remove them all the time. Simply muting a link seems pretty intuitive to me OTOH. The state (muted or not) just has to be communicated well enough. It's not any new functionality, we allow muting/hiding entities (as in objects, VSE strips, nodes, masks, ...) all over in Blender, it's just applying it to a new entity.
Member

It should be noted that the original idea for this feature came from Thomas Heizle, who was using Blender as an example for suggesting new node features to an audio application called Usine, worth checking his original post here: http://www.sensomusic.org/forums/viewtopic.php?id=4918

If you are able to try the patch, muting the links is certainly intuitive and fits nicely with the current methods for deleting and rerouting links.

It should be noted that the original idea for this feature came from Thomas Heizle, who was using Blender as an example for suggesting new node features to an audio application called Usine, worth checking his original post here: http://www.sensomusic.org/forums/viewtopic.php?id=4918 If you are able to try the patch, muting the links is certainly intuitive and fits nicely with the current methods for deleting and rerouting links.
Member

mute.gif

![mute.gif](https://archive.blender.org/developer/F779760/mute.gif)
Member

What does the little E next to the cursor mean?

What does the little `E` next to the cursor mean?
Member

It's the edit cursor. I couldn't use the cross or knife cursor as they are used by the cut and reroute operators ?

It's the edit cursor. I couldn't use the cross or knife cursor as they are used by the cut and reroute operators ?
Member

Added subscriber: @tetha.z

Added subscriber: @tetha.z
Member

Could this task be considered for inclusion in 2.8 during one of the CodeQuest UI meetings? I'm wondering if there is anything else that needs to be done for this?

Could this task be considered for inclusion in 2.8 during one of the CodeQuest UI meetings? I'm wondering if there is anything else that needs to be done for this?
Member

In #52659#457839, @CharlieJolly wrote:
mute.gif

This looks very clean! The only thing is the cursor that is a bit confusing, as E doesn't stand for anything close to Disable or Mute. I'd rather not have a cursor than having one that is confusing.

Besides that, +1 !

> In #52659#457839, @CharlieJolly wrote: > ![mute.gif](https://archive.blender.org/developer/F779760/mute.gif) This looks very clean! The only thing is the cursor that is a bit confusing, as E doesn't stand for anything close to Disable or Mute. I'd rather not have a cursor than having one that is confusing. Besides that, +1 !
Member

Updated D2807 to Blender 2.8.

Todo: cursor and bar

Updated [D2807](https://archive.blender.org/developer/D2807) to Blender 2.8. Todo: cursor and bar
Member

Added new mute cursor and adjusted the way lines are drawn. This is better for long links and works with the new way that 2.8 draws links, previous 2.7x patch was completely different. Also fixed highlighting when nodes are selected.

mute_nodes.gif

Added new mute cursor and adjusted the way lines are drawn. This is better for long links and works with the new way that 2.8 draws links, previous 2.7x patch was completely different. Also fixed highlighting when nodes are selected. ![mute_nodes.gif](https://archive.blender.org/developer/F3457951/mute_nodes.gif)
Member

Added back bar.

Simplified colouring and reduced logic in glsl.

image.png

I pretty much consider this final now.

Added back bar. Simplified colouring and reduced logic in glsl. ![image.png](https://archive.blender.org/developer/F3503548/image.png) I pretty much consider this final now.

This issue was referenced by blender/cycles@5f3566fbea

This issue was referenced by blender/cycles@5f3566fbea023029a4a428c67a4a291852dc3a83

This issue was referenced by 266cd7bb82

This issue was referenced by 266cd7bb82ce4bfed20a3d61a84f25e2bacfca2b
Member

Changed status from 'Confirmed' to: 'Resolved'

Changed status from 'Confirmed' to: 'Resolved'
Sign in to join this conversation.
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
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
10 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#52659
No description provided.