Regression: Missing update and false input of reroute node when connected to boolean socket #101410
Labels
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
5 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#101410
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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
selection
socket ofDistribute points on faces
nodeAll 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
Added subscriber: @Zeastin
Added subscriber: @mod_moder
Changed status from 'Needs Triage' to: 'Needs User Info'
This comment was removed by @mod_moder
Changed status from 'Needs User Info' to: 'Confirmed'
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
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
Added subscriber: @JacquesLucke
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.
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 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?
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.
Not sure what you mean by "node tree default". Can you provide examples for the different cases?
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:
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.
Added subscriber: @PratikPB2123
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
Input connected to reroute evaluates to False when input of reroute is not connectedto Regression: Input connected to reroute evaluates to False when input of reroute is not connectedAffected by @JacquesLucke's commit
4130f1e674
:)Regression: Input connected to reroute evaluates to False when input of reroute is not connectedto Regression: Missing update and false input of reroute node when connected to boolean socketAdded subscriber: @HooglyBoogly
I'm ok with bringing back the old behavior. @HooglyBoogly what do you think?
Do shaders and other systems still use the old behavior?
The new estimator was supposed to affect only the nodes of the geometry
2022-09-28 16-28-51.mp4
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.
Oh I didn't know that
Usually at such moments I was guided by other editors, now I will know
This issue was referenced by
db0ef8b00d
Changed status from 'Confirmed' to: 'Resolved'