Confusion on Muting Nodes + Internal Links should have is_enabled field #55119

New Issue

Philipp Oeser · 2018-05-19T03:27:44+02:00

(Deleted) commented

2018-05-19 03:27:44 +02:00

(Migrated from localhost:3001)

Blender Version 2.79

1.
As you see in the screenshot on muting the node which is muted appears to be red.
When you look at this node graph you could think that muting causes a PASS THROUGH, so that the tree under the muted node would be still alive. But obviously muting means, that the entire path under the node is down.
So either all related nodes in the path under the muted one should appear red, or muting should work as a "pass through".
The way it is now is confusing.

And 2.:
In the doc: "internal_links : Internal input-to-output connections for muting" https:*docs.blender.org/api/blender_python_api_2_77_0/bpy.types.Node.html
On a "ShaderNodeAddShader" when muting and then muting off, these internal links are even updated when
the outside socket links change. But then when the node is fully connected again the internal links
remain there (even when not muted). I checked it with a Python script.
When the AddShader only has one used socket the internal links are updated even when not muted. And on them is_valid is true and is_hidden is false. So maybe a switch is_enabled could be added there to make clear, whether the internal links are usable also when muting is off.
see example in this blend file:
AddShaderTest0.blend

Blender Version 2.79 ![NodeMute.jpg](https://archive.blender.org/developer/F3394495/NodeMute.jpg) 1. As you see in the screenshot on muting the node which is muted appears to be red. When you look at this node graph you could think that muting causes a PASS THROUGH, so that the tree under the muted node would be still alive. But obviously muting means, that the entire path under the node is down. So either all related nodes in the path under the muted one should appear red, or muting should work as a "pass through". The way it is now is confusing. And 2.: In the doc: "internal_links : Internal input-to-output connections for muting" [https:*docs.blender.org/api/blender_python_api_2_77_0/bpy.types.Node.html ](https:*docs.blender.org/api/blender_python_api_2_77_0/bpy.types.Node.html) On a "ShaderNodeAddShader" when muting and then muting off, these internal links are even updated when the outside socket links change. But then when the node is fully connected again the internal links remain there (even when not muted). I checked it with a Python script. When the AddShader only has one used socket the internal links are updated even when not muted. And on them is_valid is true and is_hidden is false. So maybe a switch is_enabled could be added there to make clear, whether the internal links are usable also when muting is off. see example in this blend file: [AddShaderTest0.blend](https://archive.blender.org/developer/F3394504/AddShaderTest0.blend)

(Deleted) commented

2018-05-19 03:27:44 +02:00

(Migrated from localhost:3001)

Added subscriber: @(Deleted)

Philipp Oeser commented

2018-05-25 11:16:07 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2018-05-25 11:16:08 +02:00

Regarding 1: not sure if I understand correctly, but muting works as a passthrough, the nodes "under" a muted node are not "down" but "alive".
See for example:

Regarding 2: again not sure if I understand correctly, but could you be more specific in regards to what the problem is here? internal_links are not used when muting is off, why not check mute on the node (instead of having an extra prop on the link)?

Marking as incomplete for now until there is an answer

Regarding 1: not sure if I understand correctly, but muting works as a passthrough, the nodes "under" a muted node are not "down" but "alive". See for example: ![#55119.png](https://archive.blender.org/developer/F3452969/T55119.png) Regarding 2: again not sure if I understand correctly, but could you be more specific in regards to what the problem is here? internal_links are not used when muting is off, why not check `mute` on the node (instead of having an extra prop on the link)? Marking as incomplete for now until there is an answer

(Deleted) commented

2018-05-29 22:45:58 +02:00

(Migrated from localhost:3001)

1:
Here I give you an example of what I mean:

If there are connections between Color and Shader sockets their behaviour is different when they are directly connected, or when they are connected through a muted BSDF node. Connecting Shader to Shader works, but other combinations (which might be artistic only because they can lead to physically incorrect results) behave different. Independent from their physical correctness connections should behave the same in all cases, shouldn't they?

2:
ok, I did not find anything in the documentation, that MUTE has a higher priority than the internal links. So they are by design dependent on the MUTE. Solved.

1: Here I give you an example of what I mean: ![NodeMute2.jpg](https://archive.blender.org/developer/F3507576/NodeMute2.jpg) If there are connections between Color and Shader sockets their behaviour is different when they are directly connected, or when they are connected through a muted BSDF node. Connecting Shader to Shader works, but other combinations (which might be artistic only because they can lead to physically incorrect results) behave different. Independent from their physical correctness connections should behave the same in all cases, shouldn't they? 2: ok, I did not find anything in the documentation, that MUTE has a higher priority than the internal links. So they are by design dependent on the MUTE. Solved.

Philipp Oeser commented

2018-05-30 09:46:27 +02:00

Changed status from 'Open' to: 'Archived'

Philipp Oeser closed this issue

2018-05-30 09:46:27 +02:00

Philipp Oeser self-assigned this 2018-05-30 09:46:27 +02:00

Philipp Oeser commented

2018-05-30 09:46:27 +02:00

Regarding 1:
connections between color sockets and shader sockets are usually not supported and are ignored in both cycles and upcoming eevee (the third row in your example image only works in 2.79 material viewport and afaics this behaviour is actually not correct). For the same reason [no connections between color and shader sockets allowed] there is no internal_link for a BSDF node [there is no reasonable connection from any of its inputs to its output -- thus you dont see an internal red noodle when muted]. So yeah, a BSDF node doesnt act as a passthrough (because there is no internal link).
Anyways, it is not correct to say that the muted BSDF node blocks the entire downchain, you could still use the Voronoi texture somewhere else in your tree (it is not "down").

Hope this helps, still dont see a bug here. Archiving for now, feel free to reopen if you still think you found a bug.

Regarding 1: connections between color sockets and shader sockets are usually not supported and are ignored in both cycles and upcoming eevee (the third row in your example image only works in 2.79 material viewport and afaics this behaviour is actually not correct). For the same reason [no connections between color and shader sockets allowed] there is no internal_link for a BSDF node [there is no reasonable connection from any of its inputs to its output -- thus you dont see an internal red noodle when muted]. So yeah, a **BSDF** node doesnt act as a passthrough (because there is no internal link). Anyways, it is not correct to say that the muted BSDF node blocks the entire downchain, you could still use the Voronoi texture somewhere else in your tree (it is not "down"). Hope this helps, still dont see a bug here. Archiving for now, feel free to reopen if you still think you found a bug.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Confusion on Muting Nodes + Internal Links should have is_enabled field #55119