Regression: Node tree result changed in other version #112746
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser Project (Legacy)
Interest
Asset System
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
4 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#112746
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: 3 GHz Dual-Core Intel Core i7
Graphics card: Intel Iris 1536 MB
Blender Version
Broken: version: 3.6.0 Alpha, branch: main, commit date: 2023-05-01 20:15, hash:
0652945dbda7Worked: version: 3.6.0 Alpha, branch: geometry-nodes-simulation, commit date: 2023-04-28 15:00, hash:
4129e1553d73Behavior changed in
0652945dbdShort description of error
The endresult of my nodetree changed, because some nodes are added to the tree.
By just removing them it's not fixed.
Exact steps for others to reproduce the error
Just open the file and you will see the difference in 3.5 and 3.6.
The nodetree is ment to make designing easier. By just drawing a curve, creating a woody construction, with multiple options. The problem is in the whole tree I think, so I cant exact tell what the problem is. I red something about the " sample nearest face " node. Maybe it has to do something with this.
Hey, please, make this node tree more simple!
Node tree changed in 3.6, so that my end result changedto Regression: Node tree result changed in other versionEven if the nodetree could be simplified, will check when behavior changed
Behavior changed in
0652945dbdCC @mod_moder
CC @HooglyBoogly
Cannot really tell if this is expected behavior, will raise prio for now since it looks like regression from user perspective
I will check this later today.
If so, then this is expected. When a result became deterministic, any other, non-deterministic result became incorrect. It is expected that incorrect results are no longer relevant.
There should be no problem for you, since previously this would have been incorrect behavior.
I found the fact that the results are different in different versions due to different normals. Inverting them solves the problem of one of the groups working the same way.
Please simplify your report. This will be a multi report if the problem is in
0652945dbdones, but the bug is also related to the Mesh Extrude node \ mesh normals.Please, parse your node trees and report any problems separately. And make a maximum of 10 nodes in the file!
@lichtwerk I can't confirm this, undoing the changes in current main does not solve this.
Hey everybody,
I'm sorry I didn't react earlier. Bussy with other stuff.
And sorry for this nodetree to be so difficult.
Maybe I can give it a try to simplefy it, but that won't be for this week.
If I understand it well there is a problem with the normals.
I hope I helped you anyway to make blender even more fantastic.
If I can help explaining things, just ask me, I'll check my account more often ;)
I did some quick changes, but I can't change to much or it will effect the result.
The pic with one big node is the same as the pic with 40 nodes. Its just the first element. Each node generates an element. So now just the first one.
The second pic with the yellow and red node generates the element. The yellow one generates the heads and the red one the middle. As you can see are the heads ok, but is the middle messed up. Funny enough I can't see any changes in the red one. So I think it's the yellow one that gives wrong data to the red one.
I've tried to just delete the added nodes but it doesn't solve it.
There are also added store named attributes to the cubes ( first pic ), I didn't do this, but I think it has something to do with the extra output of a meshnode.
I spend over an hour trying to simplify the node tree now, trying to find a fix. Unfortunately, I was not sucessfull. I mostly tried ungrouping node groups and then having the old and new Blender version side by side and using the viewer node to see where things changed.
I did find at least one index-based selection with a hard-coded index, which is highly discouraged, because many nodes are allowed to output elements in a different order between Blender versions. This is often necessary to improve performance. Unfortunately, I can't tell you where you find that specific index based selection, because I found it only after I ungrouped multiple levels of node groups (you can try to find it yourself by looking for an
Indexnode followed by aComparenode, where the index that you compare to is some single value).Unfortunately, all of that leads me to conclude that this issue (bug or not) is not actionable for us in this current state. It would take way to much time to dig even deeper into the node tree to understand the issue. Personally, I think it's most likely that you depended on index based selection in places where you shouldn't and that causes the difference between Blender versions.
Maybe you can use the same technique I described above to debug your node tree and to see what's the earliest point where the old and new versions differ. Then try to simplify the file as much as possible, or even better, reproduce that issue in a new file. Then you can create a new bug report.
Sorry, I didnt get to my own try of reproducing in a simplified file yet (at least not to the point where it actually triggered the bug).
Will continue doing this and make a new report if I manage to do this.