Page MenuHome

Mute node links (design task)
Open, NormalPublic

Description

This is a design task created on behalf of @Charlie Jolly (charlie) to review functionality from D2807

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

Details

Differential Revisions
D2807: Mute node wires
Type
Design

Event Timeline

Campbell Barton (campbellbarton) renamed this task from Mute node wires (design task) to Feature Suggestion: Mute node links (design task).Sep 6 2017, 7:19 AM
Campbell Barton (campbellbarton) renamed this task from Feature Suggestion: Mute node links (design task) to Mute node links (design task).

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.

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:

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.

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 :)

@Campbell Barton (campbellbarton) - 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.

Alternative solution with added horizontal bar.

Zoomed out.

@Charlie Jolly (charlie) new display is better, nice it can be seen when zoomed out.

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.

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.

@Dalai Felinto (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.

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.

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.

What does the little E next to the cursor mean?

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

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?

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 !

Updated D2807 to Blender 2.8.

Todo: cursor and bar

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.

Added back bar.

Simplified colouring and reduced logic in glsl.

I pretty much consider this final now.