Page MenuHome

feedback loops occuring with Geonode Modifier when working with vertex-group attr
Closed, ResolvedPublic

Description

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

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

note that entering edit mode will reset the weight

Event Timeline

dorian (helloidonthaveanyideaformyusername) renamed this task 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.Jan 15 2021, 10:02 PM

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

@Jacques Lucke (JacquesLucke) CC

@dorian (helloidonthaveanyideaformyusername) 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 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.

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 (rjg) changed the task status from Needs Triage to Confirmed.EditedJan 16 2021, 2:14 PM

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 @Jacques Lucke (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.