Maniphest T95084

Geometry Nodes modifier with dependent outputs use modified value
Closed, ResolvedBUG

Assigned To
Jacques Lucke (JacquesLucke)
Authored By
Lukas Tönne (lukastoenne)
Jan 20 2022, 2:13 PM
Tags
  • BF Blender
  • Nodes & Physics
  • Geometry Nodes
Subscribers
Hans Goudey (HooglyBoogly)
Jacques Lucke (JacquesLucke)
Lukas Tönne (lukastoenne)
Philipp Oeser (lichtwerk)

Description

System Information
Operating system: Windows-10-10.0.19044-SP0 64 Bits
Graphics card: GeForce GTX 1080/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 456.71

Blender Version
Broken: version: 3.1.0 Alpha, branch: master, commit date: 2022-01-20 00:21, hash: rBb47a1867e8bc
Worked: n/a

Short description of error
Geometry nodes modifier will use the output attribute result for attribute evaluations further down the stack, instead of the original value.

Exact steps for others to reproduce the error

  1. Open test file below
  2. The GN modifier has two outputs A and B, and one input. Input A reads from an attribute "Attribute" (declared in mesh data) which defaults to 0. One output also writes back to "Attribute"
  3. Nodes replace "Attribute" value with 0.5, and the second output adds 2.0 to "Attribute" value.


Observed: B output value is 2.5, it uses the modified value of "Attribute" 0.5 instead of the original value of 0.0.
Expected: B should be using the original input of "Attribute", so output should be A==0.5, B==2.0.
The behavior also depends on ordering: If output B is moved to the top it gets evaluated before A and uses the original value as expected (this can be used a workaround if outputs can be sorted by dependency). The result of the modifier should not depend on the order of output attributes.

Revisions and Commits

rB Blender
D13983

Event Timeline

Lukas Tönne (lukastoenne) created this task.Jan 20 2022, 2:13 PM
Lukas Tönne (lukastoenne) added a comment.Jan 20 2022, 2:22 PM

I realized there is still some of ambiguity here even if input attributes are cached somehow and all output paths use the same input values. For example: multiple outputs can write to the same mesh attributes, so that would also be order dependent. But at least then it would be consistent inside the node tree, where i would expect values to not depend on the order of outputs.

Philipp Oeser (lichtwerk) changed the task status from Needs Triage to Confirmed.Jan 20 2022, 2:37 PM
Philipp Oeser (lichtwerk) added projects: Nodes & Physics, Geometry Nodes.
Philipp Oeser (lichtwerk) changed the subtype of this task from "Report" to "Design".
Philipp Oeser (lichtwerk) added subscribers: Hans Goudey (HooglyBoogly), Jacques Lucke (JacquesLucke), Philipp Oeser (lichtwerk).

Hm, interesting, can confirm the behavior.

@Hans Goudey (HooglyBoogly) , @Jacques Lucke (JacquesLucke) : is this something you have a solution for?

Jacques Lucke (JacquesLucke) added a comment.Jan 20 2022, 3:02 PM

Ah right, I wanted to look into this. Haven't looked into this specific bug in detail yet, but it's probably the same as T93715. Just that the files looks simpler, which is nice.

Lukas Tönne (lukastoenne) added a comment.Jan 20 2022, 3:54 PM

I also have a suspicion that using the same mesh attribute for input and output can cause multiple modifier evaluations. Are attribute layers represented as individual depsgraph nodes?
Will try to make a test file to demonstrate. My use-case is a bit unconventional (iterative mesh manipulation over multiple frames), so i'm trying to boil it down to a simpler case that should be more obviously supported.

Jacques Lucke (JacquesLucke) added a comment.Jan 20 2022, 4:08 PM

Are attribute layers represented as individual depsgraph nodes?

No. The entire modifier stack evaluation is a single depsgraph node currently.

I also have a suspicion that using the same mesh attribute for input and output can cause multiple modifier evaluations.

Not sure how that could happen. Maybe a call to CustomData_duplicate_referenced_layer is missing somewhere.

Hans Goudey (HooglyBoogly) changed the subtype of this task from "Design" to "Bug".Jan 21 2022, 1:29 AM
Lukas Tönne (lukastoenne) added a comment.EditedJan 21 2022, 11:51 AM

I also have a suspicion that using the same mesh attribute for input and output can cause multiple modifier evaluations.

My mistake after all: I am copying the depsgraph result mesh and replace the object mesh data with python to implement a kind of iterative process. I was doing this copy in a post-step handler, which means that the viewport will always display the result of the next frame, effectively skipping ahead one iteration. I need to tweak this process a bit to get the result i was expecting and show the output of the last step instead of the next one.
Sorry for the noise.

Lukas Tönne (lukastoenne) added a comment.Jan 21 2022, 2:33 PM

I can also confirm that capturing input attributes at the start of the node tree as suggested in T93715 helps avoid the issue.

Jacques Lucke (JacquesLucke) moved this task from Backlog/Bugs to Next Release Targets on the Geometry Nodes board.Jan 31 2022, 6:08 PM
Hans Goudey (HooglyBoogly) moved this task from Next Release Targets to Waiting for Feedback/Review on the Geometry Nodes board.Jan 31 2022, 11:25 PM
Hans Goudey (HooglyBoogly) moved this task from Waiting for Feedback/Review to Next Release Targets on the Geometry Nodes board.Feb 1 2022, 12:05 AM
Jacques Lucke (JacquesLucke) claimed this task.Feb 1 2022, 1:43 PM
Jacques Lucke (JacquesLucke) moved this task from Next Release Targets to Waiting for Feedback/Review on the Geometry Nodes board.Feb 1 2022, 5:55 PM
Jacques Lucke (JacquesLucke) closed this task as Resolved by committing rBa985f558a6eb: Fix T95084: evaluate all output attributes before changing geometry.Feb 2 2022, 10:56 AM
Jacques Lucke (JacquesLucke) added a commit: rBa985f558a6eb: Fix T95084: evaluate all output attributes before changing geometry.