Regression: Missing update and false input of reroute node when connected to boolean socket #101410

New Issue

Zach Eastin · 2022-09-27T17:39:02+02:00

Zach Eastin commented

2022-09-27 17:39:02 +02:00

System Information
Operating system: Windows-10-10.0.22000-SP0 64 Bits
Graphics card: NVIDIA GeForce RTX 2080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 517.40

Blender Version
Broken: version: 3.4.0 Alpha, branch: master, commit date: 2022-09-26 00:52, hash: 3a7dc572dc
Worked: 3.3
Caused by 4130f1e674

Short description of error
When connecting a loose reroute to the input socket of a node it is evaluated as falsey.
In previous versions this behavior caused the socket to be evaluated as unconnected and to use the default value when unconnected.

Also there is missing update in newer version when reroute node is only connected to boolean socket: i.e. in given file, points will not disappear until we tweak node-tree

Exact steps for others to reproduce the error

Open .blend file
Connect reroute node to selection socket of Distribute points on faces node
All points will disappear. Sometimes they don't disappear until we tweak any property in node-tree

Maybe this is the new expected behavior and was a fix instead of a bug, and if so I apologize for wasting time, but it was unexpected behavior and unfortunately changed how my node groups worked for True-Terrain
#101410.blend
reroute_node_bug.webm

**System Information** Operating system: Windows-10-10.0.22000-SP0 64 Bits Graphics card: NVIDIA GeForce RTX 2080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 517.40 **Blender Version** Broken: version: 3.4.0 Alpha, branch: master, commit date: 2022-09-26 00:52, hash: `3a7dc572dc` Worked: 3.3 Caused by 4130f1e674 **Short description of error** When connecting a loose reroute to the input socket of a node it is evaluated as falsey. In previous versions this behavior caused the socket to be evaluated as unconnected and to use the default value when unconnected. Also there is missing update in newer version when reroute node is only connected to boolean socket: i.e. in given file, points will not disappear until we tweak node-tree **Exact steps for others to reproduce the error** - Open .blend file - Connect reroute node to `selection` socket of `Distribute points on faces` node All points will disappear. Sometimes they don't disappear until we tweak any property in node-tree Maybe this is the new expected behavior and was a fix instead of a bug, and if so I apologize for wasting time, but it was unexpected behavior and unfortunately changed how my node groups worked for True-Terrain [#101410.blend](https://archive.blender.org/developer/F13585669/T101410.blend) [reroute_node_bug.webm](https://archive.blender.org/developer/F13582471/reroute_node_bug.webm)

Zach Eastin commented

2022-09-27 17:39:02 +02:00

Added subscriber: @Zeastin

Iliya Katushenock commented

2022-09-27 18:08:18 +02:00

Added subscriber: @mod_moder

Iliya Katushenock commented

2022-09-27 18:08:18 +02:00

Changed status from 'Needs Triage' to: 'Needs User Info'

Iliya Katushenock commented

2022-09-27 18:08:18 +02:00

This comment was removed by @mod_moder

*This comment was removed by @mod_moder*

Iliya Katushenock commented

2022-09-27 18:13:50 +02:00

Changed status from 'Needs User Info' to: 'Confirmed'

Iliya Katushenock commented

2022-09-27 18:13:50 +02:00

Regression. Reconnect node randomly produces an incorrect different result
Don't repeat in: version: 3.4.0 Alpha, branch: master, commit date: 2022-09-09 00:25, hash: 81558783e4
2022-09-27 19-08-52.mp4

Regression. Reconnect node randomly produces an incorrect different result Don't repeat in: version: 3.4.0 Alpha, branch: master, commit date: 2022-09-09 00:25, hash: `81558783e4` [2022-09-27 19-08-52.mp4](https://archive.blender.org/developer/F13582296/2022-09-27_19-08-52.mp4)

Zach Eastin commented

2022-09-27 18:47:30 +02:00

Noticed that the random result is done away with when you force an update (or whatever is happening) by clicking on an input's default value and hitting enter. This may also be documentation that the node tree doesn't consistently auto-update when adding or removing node links

reroute_node_bug.webm

Noticed that the random result is done away with when you force an update (or whatever is happening) by clicking on an input's default value and hitting enter. This may also be documentation that the node tree doesn't consistently auto-update when adding or removing node links [reroute_node_bug.webm](https://archive.blender.org/developer/F13582471/reroute_node_bug.webm)

Jacques Lucke commented

2022-09-27 20:35:29 +02:00

Added subscriber: @JacquesLucke

Jacques Lucke commented

2022-09-27 20:35:29 +02:00

This behavior changed indeed. Generally, I prefer the new behavior. Mainly because I don't see why the value of a socket should be used when it is linked (it's tooltip even used to say that the value will only be used when it is not linked). It's easier to have predictable socket values with the new behavior.
We could revert back to the old behavior if someone really cares, but I'd hope that no one depends on the details of this behavior.

This behavior changed indeed. Generally, I prefer the new behavior. Mainly because I don't see why the value of a socket should be used when it is linked (it's tooltip even used to say that the value will only be used when it is not linked). It's easier to have predictable socket values with the new behavior. We could revert back to the old behavior if someone really cares, but I'd hope that no one depends on the details of this behavior.

Iliya Katushenock commented

2022-09-27 20:42:52 +02:00

I wanted to say that this is clearly not normal behavior, since it is now chaotic. With identical noodles, we have a different result.

This is shown in my video. Several times if the noodles are connected, or there or not.

I wanted to say that this is clearly not normal behavior, since it is now chaotic. With identical noodles, we have a different result. This is shown in my video. Several times if the noodles are connected, or there or not.

Zach Eastin commented

2022-09-27 20:45:54 +02:00

I feel everything you said at a core level! lol As the lead programmer for True-Terrain I also make changes that make more sense for user experience but usually get questioned and complained about when released. So while I am depending upon this for True-Terrain's modifier system it's mainly just to not write in extra code to link and unlink nodes depending on if the user is using any modifiers for their scatter system.

Could it be that if the default value is hidden in the node's UI it would stay whatever the unconnected default value is (like it has been in 3.0-3.3) but if the input's value UI is visible it would use the node tree default as it currently is in 3.4?

I feel everything you said at a core level! lol As the lead programmer for True-Terrain I also make changes that make more sense for user experience but usually get questioned and complained about when released. So while I am depending upon this for True-Terrain's modifier system it's mainly just to not write in extra code to link and unlink nodes depending on if the user is using any modifiers for their scatter system. Could it be that if the default value is hidden in the node's UI it would stay whatever the unconnected default value is (like it has been in 3.0-3.3) but if the input's value UI is visible it would use the node tree default as it currently is in 3.4?

Jacques Lucke commented

2022-09-27 21:30:29 +02:00

Oh, I forgot to mention that there are two independent issues at play here. One is a simple update issue, where the node tree does not update immediately when a reroute is linked to an input. That's the reason for the inconsistent behavior even when the node setup is the same. This should be fixed either way.

My first response was only regarding the issue described in the title of this task.

Could it be that if the default value is hidden in the node's UI it would stay whatever the unconnected default value is (like it has been in 3.0-3.3) but if the input's value UI is visible it would use the node tree default as it currently is in 3.4?

Not sure what you mean by "node tree default". Can you provide examples for the different cases?

Oh, I forgot to mention that there are two independent issues at play here. One is a simple update issue, where the node tree does not update immediately when a reroute is linked to an input. That's the reason for the inconsistent behavior even when the node setup is the same. This should be fixed either way. My first response was only regarding the issue described in the title of this task. > Could it be that if the default value is hidden in the node's UI it would stay whatever the unconnected default value is (like it has been in 3.0-3.3) but if the input's value UI is visible it would use the node tree default as it currently is in 3.4? Not sure what you mean by "node tree default". Can you provide examples for the different cases?

Zach Eastin commented

2022-09-28 05:31:07 +02:00

By "node tree default" all I meant was what you had it being set to by default when the reroute node was connected without the reroute node's input having a connection (ie 0, False, None/Empty).

After saying all that I did before and then thinking on this some more I do think that this is a loss of functionality and we are currently, to a degree, depending upon the details of this behavior. Let me try and explain our use of this behavior with True-Terrain.

True-Terrain uses modifiers (node groups) to mask distributed points across an object. I've simplified the nodes here in the following screenshot. You'll notice that by default there are 0 node groups in the modifiers frame or connected to the 'END OF MODS' Reroute node. In v3.3 the disconnected reroutes kept the sockets they were connected to in their "disconnected" state using their default values even though they weren't technically disconnected.

Once a user adds in modifiers for masking the points the sockets behave as expected, ignoring their default values in exchange for the values that are passed to it through the link.

I use reroutes to easily target connections to the rest of the node tree in Python so as to not target individual sockets by name or index. The reroute node is perfect for this behavior as it does not change. It has a single input and output socket. It will never become a multi-inputted socket. Any connection coming from the reroute to a node that is later deprecated or its input sockets rearranged, renamed, or added/removed will be (or at least usually is) correctly handled by Blender. Developing TT since the last LTS release through the 3.X series has seen quite a lot of changes in nodes, socket names, socket indices, etc. All of these have been for the complete best of the software, but at the same time adds more potential bug-fixing troubles for the developers especially if we're targeting multiple versions of Blender. Geo-Nodes is still being actively developed. Blender 3.4 brings more backward compatibility issues to the LTS that was just released. And I'm grateful for it! I want all these geo-node goodies that lead us closer to Everything-Nodes. But maybe this one feature could remain to help developers or anyone else using this feature in other ways to not be confused as to why their node groups worked in 3.3 and not in 3.4. I also cannot find any way to replicate this behavior with existing nodes without having to rewrite code (I know, boo-hoo, that's the job).

If that more individualistic argument is not enough to convince or is just not well explained consider the following arguments:

It is, in my view, the logical consistent behavior of the Reroute node.
Reroute nodes have no value (float, material, geometry, etc) to evaluate.
It is in the Layout category with the Frame node which itself has no value type.
Because it isn't a value type it is not thought of as impacting the tree in any way than visually.
Nothing ("no value" as opposed to a "None" value) exists to pass to the node from a reroute node on its own. The node is only linked to something visually, but according to the evaluator, its connection returns nothing and is therefore not worth evaluating (he says to the one actively working on the evaluator and has from the beginning and he not knowing the intricacies of the current evaluator let alone the new one you're working on). No value is passed to the socket as though the socket itself were unconnected
If a user wants to input a value's respective 'None' or 'Falsey' type they can explicitly with its respective input node
There is no other way to handle this behavior if taken away, whereas there are 'None' and 'Falsey' ways to input for each value type if unconnected reroutes don't return a value
It will make it easier for users to make mistakes. Noodles (long ones) linked to reroutes may be severed purposely but reroutes accidentally left connected off-screen (or too small to notice when zoomed out) and instead of the expected default value behavior of the respective socket, the user will have to debug why they are getting unexpected results due to unconnected reroutes returning values the user did not expect or mean.

May I ask if evaluating an unconnected reroute node as 'Falsey' provides any significant speed increases or allows for better features in the future such as caching? Because those would probably be worth the change.

By "node tree default" all I meant was what you had it being set to by default when the reroute node was connected without the reroute node's input having a connection (ie 0, False, None/Empty). After saying all that I did before and then thinking on this some more I do think that this is a loss of functionality and we are currently, to a degree, depending upon the details of this behavior. Let me try and explain our use of this behavior with True-Terrain. True-Terrain uses modifiers (node groups) to mask distributed points across an object. I've simplified the nodes here in the following screenshot. You'll notice that by default there are 0 node groups in the modifiers frame or connected to the 'END OF MODS' Reroute node. In v3.3 the disconnected reroutes kept the sockets they were connected to in their "disconnected" state using their default values even though they weren't technically disconnected. ![image.png](https://archive.blender.org/developer/F13583430/image.png) Once a user adds in modifiers for masking the points the sockets behave as expected, ignoring their default values in exchange for the values that are passed to it through the link. ![image.png](https://archive.blender.org/developer/F13583501/image.png) ![image.png](https://archive.blender.org/developer/F13583498/image.png) I use reroutes to easily target connections to the rest of the node tree in Python so as to not target individual sockets by name or index. The reroute node is perfect for this behavior as it does not change. It has a single input and output socket. It will never become a multi-inputted socket. Any connection coming from the reroute to a node that is later deprecated or its input sockets rearranged, renamed, or added/removed will be (or at least usually is) correctly handled by Blender. Developing TT since the last LTS release through the 3.X series has seen quite a lot of changes in nodes, socket names, socket indices, etc. All of these have been for the complete best of the software, but at the same time adds more potential bug-fixing troubles for the developers especially if we're targeting multiple versions of Blender. Geo-Nodes is still being actively developed. Blender 3.4 brings more backward compatibility issues to the LTS that was just released. And I'm grateful for it! I want all these geo-node goodies that lead us closer to Everything-Nodes. But maybe this one feature could remain to help developers or anyone else using this feature in other ways to not be confused as to why their node groups worked in 3.3 and not in 3.4. I also cannot find any way to replicate this behavior with existing nodes without having to rewrite code (I know, boo-hoo, that's the job). If that more individualistic argument is not enough to convince or is just not well explained consider the following arguments: - It is, in my view, the logical consistent behavior of the Reroute node. - Reroute nodes have no value (float, material, geometry, etc) to evaluate. - It is in the Layout category with the Frame node which itself has no value type. - Because it isn't a value type it is not thought of as impacting the tree in any way than visually. - Nothing ("no value" as opposed to a "None" value) exists to pass to the node from a reroute node on its own. The node is only linked to something visually, but according to the evaluator, its connection returns nothing and is therefore not worth evaluating (he says to the one actively working on the evaluator and has from the beginning and he not knowing the intricacies of the current evaluator let alone the new one you're working on). No value is passed to the socket as though the socket itself were unconnected - If a user wants to input a value's respective 'None' or 'Falsey' type they can explicitly with its respective input node - There is no other way to handle this behavior if taken away, whereas there are 'None' and 'Falsey' ways to input for each value type if unconnected reroutes don't return a value - It will make it easier for users to make mistakes. Noodles (long ones) linked to reroutes may be severed purposely but reroutes accidentally left connected off-screen (or too small to notice when zoomed out) and instead of the expected default value behavior of the respective socket, the user will have to debug why they are getting unexpected results due to unconnected reroutes returning values the user did not expect or mean. May I ask if evaluating an unconnected reroute node as 'Falsey' provides any significant speed increases or allows for better features in the future such as caching? Because those would probably be worth the change.

Pratik Borhade commented

2022-09-28 07:08:33 +02:00

Added subscriber: @PratikPB2123

Pratik Borhade commented

2022-09-28 07:08:33 +02:00

This behavior changed indeed. Generally, I prefer the new behavior. Mainly because I don't see why the value of a socket should be used when it is linked (it's tooltip even used > to say that the value will only be used when it is not linked)

Unsure if other GN developers, artists are aware of new behavior.
This new change won't break any .blend files since this only happens when loose reroute is connected to boolean socket.
I'll update the report to address both the issue

> This behavior changed indeed. Generally, I prefer the new behavior. Mainly because I don't see why the value of a socket should be used when it is linked (it's tooltip even used > to say that the value will only be used when it is not linked) Unsure if other GN developers, artists are aware of new behavior. This new change won't break any .blend files since this only happens when loose reroute is connected to boolean socket. I'll update the report to address both the issue

Pratik Borhade changed title from ~~Input connected to reroute evaluates to False when input of reroute is not connected~~ to Regression: Input connected to reroute evaluates to False when input of reroute is not connected

2022-09-28 07:31:54 +02:00

Pratik Borhade commented

2022-09-28 07:32:03 +02:00

Affected by @JacquesLucke's commit 4130f1e674 :)

Affected by @JacquesLucke's commit 4130f1e674 :)

Pratik Borhade changed title from ~~Regression: Input connected to reroute evaluates to False when input of reroute is not connected~~ to Regression: Missing update and false input of reroute node when connected to boolean socket

2022-09-28 07:34:11 +02:00

Jacques Lucke commented

2022-09-28 09:16:53 +02:00

Added subscriber: @HooglyBoogly

Jacques Lucke commented

2022-09-28 09:16:53 +02:00

I'm ok with bringing back the old behavior. @HooglyBoogly what do you think?

Iliya Katushenock commented

2022-09-28 15:10:40 +02:00

Do shaders and other systems still use the old behavior?
The new estimator was supposed to affect only the nodes of the geometry

Do shaders and other systems still use the old behavior? The new estimator was supposed to affect only the nodes of the geometry

Iliya Katushenock commented

2022-09-28 15:29:39 +02:00

2022-09-28 16-28-51.mp4

[2022-09-28 16-28-51.mp4](https://archive.blender.org/developer/F13587535/2022-09-28_16-28-51.mp4)

Jacques Lucke commented

2022-09-28 15:32:34 +02:00

No need to add more information here. I know what the issues are here.
The evaluation systems for the geometry/shading/compositing etc. are separate.

No need to add more information here. I know what the issues are here. The evaluation systems for the geometry/shading/compositing etc. are separate.

Iliya Katushenock commented

2022-09-28 16:30:13 +02:00

Oh I didn't know that
Usually at such moments I was guided by other editors, now I will know

Oh I didn't know that Usually at such moments I was guided by other editors, now I will know

blender-admin commented

2022-09-29 13:03:15 +02:00

This issue was referenced by db0ef8b00d

This issue was referenced by db0ef8b00d3c92751ff80a3fc061a4e663639d4b

Jacques Lucke commented

2022-09-29 13:03:45 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Jacques Lucke closed this issue

2022-09-29 13:03:45 +02:00

Jacques Lucke self-assigned this 2022-09-29 13:03:45 +02:00

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

Regression: Missing update and false input of reroute node when connected to boolean socket #101410