Persistent/named attribute nodes #90864

New Issue

Jacques Lucke · 2021-08-23T10:17:25+02:00

Jacques Lucke commented

2021-08-23 10:17:25 +02:00

The fields attribute workflow allows us to get rid of explicitly named attributes in the majority of cases. However, when passing data between different systems, explicit attribute names are still important. Examples:

Passing attributes to render engines.
Exporting geometry to other software.
Importing geometry from files on disk.
Reading attributes on other objects.

Named attributes should not be considered a solution to avoid potentially long links in a node group. While they could be used for that, long links are a more general problem that is not limited to geometry attributes. If required, we need to find a different solution for that.

Users should be encouraged to use named attributes only at the boundaries to other systems and to use fields within geometry nodes. This ensures good reusability of node groups because it avoids name collisions and improves flexibility.

The goal of this task is to define a set of nodes that deals with named attributes. There are three distinct tasks one has to perform on named attributes:

Create named attributes that are initialized by a field (this can also overwrite existing named attributes).
Access data from named attributes as a field.
Delete named attributes from a geometry.

The fields attribute workflow allows us to get rid of explicitly named attributes in the majority of cases. However, when passing data between different systems, explicit attribute names are still important. Examples: * Passing attributes to render engines. * Exporting geometry to other software. * Importing geometry from files on disk. * Reading attributes on other objects. Named attributes should not be considered a solution to avoid potentially long links in a node group. While they could be used for that, long links are a more general problem that is not limited to geometry attributes. If required, we need to find a different solution for that. Users should be encouraged to use named attributes only at the boundaries to other systems and to use fields within geometry nodes. This ensures good reusability of node groups because it avoids name collisions and improves flexibility. ---- The goal of this task is to define a set of nodes that deals with named attributes. There are three distinct tasks one has to perform on named attributes: * Create named attributes that are initialized by a field (this can also overwrite existing named attributes). * Access data from named attributes as a field. * Delete named attributes from a geometry.

Jacques Lucke commented

2021-08-23 10:17:25 +02:00

Added subscriber: @JacquesLucke

Dalai Felinto commented

2021-08-24 14:52:38 +02:00

Added subscriber: @dfelinto

Dalai Felinto commented

2021-08-24 14:52:38 +02:00

I still don't see why we need to have generic attribute read/write nodes with hardcoded names.

Passing attributes to render engines.

Having the attribute created outside the modifier is a more explicit solution and avoids hard-coded names.

Exporting geometry to other software.

A custom-made nodegroup can be used as a modifier for that. Leaving the hardcoded names all outside the nodegroup.

Importing geometry from files on disk.

The node that supports the importing of arbritary data (e.g., OpenVDB Info Node) could be the one where the mapping happens.

Reading attributes on other objects.

Leave it to the Object Info Node to add more attribute sockets from the object.

I still don't see why we need to have generic attribute read/write nodes with hardcoded names. > * Passing attributes to render engines. Having the attribute created outside the modifier is a more explicit solution and avoids hard-coded names. > * Exporting geometry to other software. A custom-made nodegroup can be used as a modifier for that. Leaving the hardcoded names all outside the nodegroup. > * Importing geometry from files on disk. The node that supports the importing of arbritary data (e.g., OpenVDB Info Node) could be the one where the mapping happens. > * Reading attributes on other objects. Leave it to the Object Info Node to add more attribute sockets from the object.

Jacques Lucke commented

2021-08-25 13:46:37 +02:00

https://devtalk.blender.org/t/hardcoded-attribute-names-removal-proposal/20138