Evaluate fields to attributes in repeat zone #116427

New Issue

Simon Thommes · 2023-12-21T13:36:24+01:00

Simon Thommes commented

2023-12-21 13:36:24 +01:00

Currently the repeat zone behaves as if literally the nodes inside were just duplicated a number of times and run in series, while removing the repeat in and output nodes.

This is generally very useful functionality as it is very generic and extend to several different contexts and applications. For example to build complex fields that rely on convoluting field logic over and over creating one big callback function. But at the same time this behavior poses a great danger in exploding execution cost, especially since it isn't represented in any special way that is clear compared how field evaluation is communicated anywhere else in Geometry Nodes.

Showcase of the issue:
Both these images show a node-tree that smears an attribute along a spline. The numerical result in both setups is identical, yet does the first one show an execution cost that rises exponentionally with number of iterations. As you can see here for 20 iterations on a simple curve with 50 this already goes up to over 3 seconds of evaluation time, while the bottom screenshot takes under 0.1ms.

This enormous discrepancy is understandable once you realize what is actually happening here, since the first example simply passes through the geometry without changing it at all and processes the field separately from it. Which means that evaluating the field on a different index every iteration creates a field that doubles in complexity every iteration, so 2^20=1048576, for what should be a linear cost.

My main problem here is not that it is possible for the user to create such a complex field. It's honestly great that this actually works. But the problem here is in how this is presented in the UI.
There is virtually nothing in the UI pointing to this behaving differently than for example the simulation zone or simply the attribute capture node.
We are still lacking a good way to communicate in the node-tree UI how and when a field is actually evaluated into an attribute. But at the same time the existing nodes establish a visual language of what kind of behavior to expect.

There are multiple possibilities that would address this issue and make it harder to build unnecessarily complex field setups:

Make some implicit/explicit logic to handle capturing attributes on a geometry. This is kind of already done for the simulation zone, where attributes following a geometry are evaluated on that geometry socket.
Make it a setting in the in-/ouptut node to evaluate the data on every loop

Would be good to evaluate the different solutions in the context of common uses of the repeat zone and see how much they would compromise the versatility of the repeat zone and come up with a design that respects also the overall plans for the node-tree UI.

Currently the repeat zone behaves as if literally the nodes inside were just duplicated a number of times and run in series, while removing the repeat in and output nodes. This is generally very useful functionality as it is very generic and extend to several different contexts and applications. For example to build complex fields that rely on convoluting field logic over and over creating one big callback function. But at the same time this behavior poses a great danger in exploding execution cost, especially since it isn't represented in any special way that is clear compared how field evaluation is communicated anywhere else in Geometry Nodes. Showcase of the issue: Both these images show a node-tree that smears an attribute along a spline. The numerical result in both setups is identical, yet does the first one show an execution cost that rises exponentionally with number of iterations. As you can see here for 20 iterations on a simple curve with 50 this already goes up to over 3 seconds of evaluation time, while the bottom screenshot takes under 0.1ms. ![image](/attachments/7c2f0b3e-135b-4994-ab68-68b6ef6daffb) ![image](/attachments/3dcd357a-f48f-4dda-b8c3-79014e126b09) This enormous discrepancy is understandable once you realize what is actually happening here, since the first example simply passes through the geometry without changing it at all and processes the field separately from it. Which means that evaluating the field on a different index every iteration creates a field that doubles in complexity every iteration, so 2^20=1048576, for what should be a linear cost. My main problem here is not that it is possible for the user to create such a complex field. It's honestly great that this actually works. But the problem here is in how this is presented in the UI. There is virtually nothing in the UI pointing to this behaving differently than for example the simulation zone or simply the attribute capture node. We are still lacking a good way to communicate in the node-tree UI how and when a field is actually evaluated into an attribute. But at the same time the existing nodes establish a visual language of what kind of behavior to expect. There are multiple possibilities that would address this issue and make it harder to build unnecessarily complex field setups: - Make some implicit/explicit logic to handle capturing attributes on a geometry. This is kind of already done for the simulation zone, where attributes following a geometry are evaluated on that geometry socket. - Make it a setting in the in-/ouptut node to evaluate the data on every loop Would be good to evaluate the different solutions in the context of common uses of the repeat zone and see how much they would compromise the versatility of the repeat zone and come up with a design that respects also the overall plans for the node-tree UI.

repeat_zone_field.blend

1.2 MiB

image.png

127 KiB

image.png

119 KiB

Simon Thommes added the

Type

Design

label 2023-12-21 13:36:24 +01:00

Simon Thommes added this to the Nodes & Physics project 2023-12-21 13:36:26 +01:00

Iliya Katushenock commented

2023-12-21 17:49:38 +01:00

This is not real solution, and not comething that should be done at all:

Repeat Zone for fields only? Without way to capture temporal values.
Repeat Zone with multiple geometries? To do not compute field for every geometry.

The main issue here is the fact that currently field evaluation is recursive.
Just like https://archive.blender.org/developer/T98492, field evaluation can be improved to be more cheap for repeat zone.
This is not something that is planned for now, so this is not priority, but this is still worked solution.

This is not real solution, and not comething that should be done at all: - Repeat Zone for fields only? Without way to capture temporal values. - Repeat Zone with multiple geometries? To do not compute field for every geometry. The main issue here is the fact that currently field evaluation is recursive. Just like https://archive.blender.org/developer/T98492, field evaluation can be improved to be more cheap for repeat zone. This is not something that is planned for now, so this is not priority, but this is still worked solution.

Simon Thommes commented

2023-12-21 18:41:07 +01:00

The main issue here is the fact that currently field evaluation is recursive.
Just like https://archive.blender.org/developer/T98492, field evaluation can be improved to be more cheap for repeat zone.
This is not something that is planned for now, so this is not priority, but this is still worked solution.

The evaluation can be optimized to solve the performance issue, sure. But I'm also talking about the UI issue that we we have regardless of that. There is no way for the user to identify that the behavior here is different to e.g. the simulation zone, while it's presented visually the same way. And this is not something that would be obvious enough to say it doesn't need to be communicated visually somehow.

> The main issue here is the fact that currently field evaluation is recursive. > Just like https://archive.blender.org/developer/T98492, field evaluation can be improved to be more cheap for repeat zone. > This is not something that is planned for now, so this is not priority, but this is still worked solution. The evaluation can be optimized to solve the performance issue, sure. But I'm also talking about the UI issue that we we have regardless of that. There is no way for the user to identify that the behavior here is different to e.g. the simulation zone, while it's presented visually the same way. And this is not something that would be obvious enough to say it doesn't need to be communicated visually somehow.

Iliya Katushenock commented

2023-12-22 08:24:07 +01:00

I don't see a problem with the fields not being captured. It`s naturally. If the user does not explicitly do this, then this should not happen. The simulation node requires capture for technical reasons. Unlike a simulation node, repeat nodes don't need to create any more complex logic, since all there needs to be is iteration.
Existing nodes either evaluate field explicitly or technically require it. Repeat Zone nodes do not technically require this, and therefore do not have to do it explicitly. Changing the specifics of field evaluation to a more linear one will solve the problem of exponential growth, after which implicit capture will be redundant.

I don't see a problem with the fields not being captured. It`s naturally. If the user does not explicitly do this, then this should not happen. The simulation node requires capture for technical reasons. Unlike a simulation node, repeat nodes don't need to create any more complex logic, since all there needs to be is iteration. Existing nodes either evaluate field explicitly or technically require it. Repeat Zone nodes do not technically require this, and therefore do not have to do it explicitly. Changing the specifics of field evaluation to a more linear one will solve the problem of exponential growth, after which implicit capture will be redundant.

Simon Thommes commented

2024-01-02 10:45:37 +01:00

I'm purely talking UI here. For the user there is nothing explicit about something that happens completely regardless of what is indicated in the UI in my opinion.

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

Evaluate fields to attributes in repeat zone #116427