feedback loops occuring with Geonode Modifier when working with vertex-group attr #84757

New Issue

DorianB · 2021-01-15T21:34:09+01:00

DorianB commented

2021-01-15 21:34:09 +01:00

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

Blender Version
Broken: version: 2.92.0 Alpha, branch: master, commit date: 2021-01-12 20:03, hash: 719bea0d6d

Short description of error
In this simple example (file available below) I created a vertex group that i used as an attr in a geonode modifier then remove some weight using an attr math node, at first glance everything seem to work fine. But on some condition (entering a field then hit esc, or evaluating the depsgraph with python or else?) the node keep re-evaluating itself, this can be repeated indefinitely.

So the attr workflow seems to re-evaluate the attr it produces (feedback loop) This is quite an unexpected workflow-breaking behavior, it's the first time that a modifier re-evaluate something that it produces (for example the vgedit modifier only evaluate the vertex-group initially, and don't re-evaluate the resulting vertex-group) Somehow this is not making any crashes as the re-evaluation is not continuous. blender is re-evaluating only on some conditions, not sure why and when this re-evaluation occurs?

this is significantly breaking the attr workflow.
here's a gif illustrating the issue

Exact steps for others to reproduce the error
Blank file:

Create a new vertex group on a subdivided plane and paint something
Create a new geonode modifier, and add a node that will change the vertex-group weight.
Evaluating the mesh with his modifiers using python or entering and quitting the B arg of the math node will trigger a re-evaluation of the node. this re-evaluation may be triggered by some other events.

Use file below:

just enter in the edition of the "B" FloatProperty of the AttributeMath node then hit ESC witouth changing any values, this is one way to trigger a re-evaluation of the node resulting in a change of this vertex-group
feedback_loop.blend

note that entering edit mode will reset the weight

**System Information** Operating system: Windows-10-10.0.19041-SP0 64 Bits Graphics card: GeForce RTX 2080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 452.06 **Blender Version** Broken: version: 2.92.0 Alpha, branch: master, commit date: 2021-01-12 20:03, hash: `719bea0d6d` **Short description of error** In this simple example (file available below) I created a vertex group that i used as an attr in a geonode modifier then remove some weight using an attr math node, at first glance everything seem to work fine. But on some condition (entering a field then hit esc, or evaluating the depsgraph with python or else?) the node keep re-evaluating itself, this can be repeated indefinitely. So the **attr workflow seems to re-evaluate the attr it produces (feedback loop)** This is quite an unexpected workflow-breaking behavior, it's the first time that a modifier re-evaluate something that it produces (for example the vgedit modifier only evaluate the vertex-group initially, and don't re-evaluate the resulting vertex-group) Somehow this is not making any crashes as the re-evaluation is not continuous. blender is re-evaluating only on some conditions, not sure why and when this re-evaluation occurs? this is significantly breaking the attr workflow. here's a gif illustrating the issue ![2e5156f3fb2b388f148118bf94764bd57ebbaa18.gif](https://archive.blender.org/developer/F9580942/2e5156f3fb2b388f148118bf94764bd57ebbaa18.gif) **Exact steps for others to reproduce the error** Blank file: - Create a new vertex group on a subdivided plane and paint something - Create a new geonode modifier, and add a node that will change the vertex-group weight. - Evaluating the mesh with his modifiers using python or entering and quitting the B arg of the math node will trigger a re-evaluation of the node. this re-evaluation may be triggered by some other events. Use file below: - just enter in the edition of the "B" FloatProperty of the AttributeMath node then hit ESC witouth changing any values, this is one way to trigger a re-evaluation of the node resulting in a change of this vertex-group [feedback_loop.blend](https://archive.blender.org/developer/F9580897/feedback_loop.blend) note that entering edit mode will reset the weight

DorianB commented

2021-01-15 21:34:09 +01:00

Added subscriber: @dodododorian

DorianB changed title from ~~Geonode Modifier is creating feedback loops when changing vertex-groups (possibily with other attr?)~~ to feedback loops occuring with Geonode Modifier when working with vertex-group attr

2021-01-15 22:03:29 +01:00

Robert Guetzkow commented

2021-01-16 12:16:34 +01:00

Added subscribers: @JulianEisel, @rjg

Robert Guetzkow commented

2021-01-16 12:16:34 +01:00

I'm not familiar with the design decision here so this is more of an observation/comment than triaging.

@JacquesLucke CC

@dodododorian I can see that this might be an issue if this would be a continuous loop or cause unexpected internal state. However, as far as I can tell, this is not the case and since you are deliberately using the same attribute for input and output, ~~I'm not entirely sure what behavior you're expecting~~? The way is see this, the implementation could either update the attribute that it is using as an input for subsequent evaluation or refuse to write to an attribute that it uses as input*. Evaluating it only once doesn't seem like a plausible solution.

(*) Edit: Always starting the evaluation with the original value would make sense I suppose.

The current behavior does seem to match the description in the manual that states:

Result
Name of the attribute where the computed result it stored. A new attribute with that name is added if it does not exist yet. If it does exist, the values of the existing attribute are overridden.

I'm not familiar with the design decision here so this is more of an observation/comment than triaging. @JacquesLucke CC @dodododorian I can see that this might be an issue if this would be a continuous loop or cause unexpected internal state. However, as far as I can tell, this is not the case and since you are deliberately using the same attribute for input and output, ~~I'm not entirely sure what behavior you're expecting~~? The way is see this, the implementation could either update the attribute that it is using as an input for subsequent evaluation or refuse to write to an attribute that it uses as input*. Evaluating it only once doesn't seem like a plausible solution. (*) Edit: Always starting the evaluation with the original value would make sense I suppose. The current behavior does seem to match the description in the manual that states: > **Result** > Name of the attribute where the computed result it stored. A new attribute with that name is added if it does not exist yet. If it does exist, the **values of the existing attribute are overridden.**

Robert Guetzkow commented

2021-01-16 12:28:38 +01:00

Added subscriber: @JacquesLucke

Robert Guetzkow commented

2021-01-16 12:28:45 +01:00

Removed subscriber: @JulianEisel

Jacques Lucke commented

2021-01-16 13:09:41 +01:00

I haven't looked at the file yet, but I'm pretty sure this is a bug. We do not support any kind of feedback loops yet.
My guess is that we forgot to copy a referenced custom data layer in the attribute system. Will check it in more detail a bit later.

I haven't looked at the file yet, but I'm pretty sure this is a bug. We do not support any kind of feedback loops yet. My guess is that we forgot to copy a referenced custom data layer in the attribute system. Will check it in more detail a bit later.

DorianB commented

2021-01-16 13:36:52 +01:00

and since you are deliberately using the same attribute for input and output

The goal of this example is to do operations on vertex groups, similar to modifiers like VG-edit or VG-proximity (input is also output in these cases).
the geometry node is a modifier like any other. no current modifiers can evaluate the content it creates, only evaluates what's above of them on the stack
If this is by design, there's a strong contradiction with current established modifiers behaviors

> and since you are deliberately using the same attribute for input and output > The goal of this example is to do operations on vertex groups, similar to modifiers like VG-edit or VG-proximity (input is also output in these cases). the geometry node is a modifier like any other. no current modifiers can evaluate the content it creates, only evaluates what's above of them on the stack If this is by design, there's a **strong** contradiction with current established modifiers behaviors

Robert Guetzkow commented

2021-01-16 14:14:36 +01:00

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

Robert Guetzkow commented

2021-01-16 14:14:36 +01:00

You're right, the geometry nodes should operate like a modifier. From this perspective the behavior is definitely wrong. Apologies for my misunderstanding/uninformedness. Given that @JacquesLucke confirmed that geometry nodes are not supposed to break with the convention of modifiers and I can reproduce the behavior, I'm marking this ticket as confirmed.

blender-admin commented

2021-01-16 15:24:22 +01:00

This issue was referenced by 1e193a0b56

This issue was referenced by 1e193a0b564c72c006203a1e349269e4bb004d0e

Jacques Lucke commented

2021-01-16 15:26:14 +01:00

Changed status from 'Confirmed' to: 'Resolved'

Jacques Lucke closed this issue

2021-01-16 15:26:14 +01:00

Jacques Lucke self-assigned this 2021-01-16 15:26:14 +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

feedback loops occuring with Geonode Modifier when working with vertex-group attr #84757