Geometry Nodes modifier with dependent outputs use modified value #95084

New Issue

Lukas Tönne · 2022-01-20T14:13:19+01:00

Lukas Tönne commented

2022-01-20 14:13:19 +01:00

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: b47a1867e8
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

Open test file below
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"
  {F12812655}

Nodes replace "Attribute" value with 0.5, and the second output adds 2.0 to "Attribute" value.

  {F12812659}

attribute_output_dependencies.blend
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.

**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: `b47a1867e8` 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" {F12812655} ``` 3. Nodes replace "Attribute" value with 0.5, and the second output adds 2.0 to "Attribute" value. ``` {F12812659} ``` [attribute_output_dependencies.blend](https://archive.blender.org/developer/F12812651/attribute_output_dependencies.blend) **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.

Lukas Tönne commented

2022-01-20 14:13:19 +01:00

Added subscriber: @LukasTonne

Lukas Tönne commented

2022-01-20 14:22:54 +01:00

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 commented

2022-01-20 14:37:26 +01:00

Added subscribers: @HooglyBoogly, @JacquesLucke, @lichtwerk

Philipp Oeser commented

2022-01-20 14:37:26 +01:00

Changed status from 'Needs Triage' to: 'Confirmed'

Philipp Oeser commented

2022-01-20 14:37:26 +01:00

Hm, interesting, can confirm the behavior.

@HooglyBoogly , @JacquesLucke : is this something you have a solution for?

Hm, interesting, can confirm the behavior. @HooglyBoogly , @JacquesLucke : is this something you have a solution for?

Jacques Lucke commented

2022-01-20 15:02:06 +01:00

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 #93715. Just that the files looks simpler, which is nice.

Lukas Tönne commented

2022-01-20 15:54:22 +01:00

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.

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 commented

2022-01-20 16:08:54 +01:00

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.

> 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.

Lukas Tönne commented

2022-01-21 11:51:00 +01:00

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.

> 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 commented

2022-01-21 14:33:52 +01:00

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

Jacques Lucke self-assigned this 2022-02-01 13:43:15 +01:00

blender-admin commented

2022-02-02 10:54:54 +01:00

This issue was referenced by a985f558a6

This issue was referenced by a985f558a6eb16cd6f00b550712b86923ab33fd3

Jacques Lucke commented

2022-02-02 10:56:00 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Jacques Lucke closed this issue

2022-02-02 10:56:00 +01: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

Geometry Nodes modifier with dependent outputs use modified value #95084