Geometry Attributes Design #76659

New Issue

Brecht Van Lommel · 2020-05-11T23:09:46+02:00

Brecht Van Lommel commented

2020-05-11 23:09:46 +02:00

Blender geometry datablocks like meshes, pointclouds, hair need support for arbitrary attributes on vertices, edges, corners, faces, points and curves. Internally there exists a custom data layer system to support this. But there is no user interface and the types of data layers available s predefined.

Arbitrary attributes will serve a few purposes:

Compatibility for old per-corner colors to be replaced by per-vertex colors (#71947)
(Particle) simulation nodes that need to store arbitrary layers like velocity, radius, color, or other user defined properties
Import of geometry from other applications with such attributes

The proposed design is as follows:

New mesh.attributes, hair.attributes, pointcloud.attributes collection property on datablocks with each item an Attribute.
Attribute has:
** .name: unique name
** .type: float, int, color, 3D vector, string, ...
** .domain:
*** (whole) geometry
vertex edge (mesh only)
corner (mesh only) primitive (face for mesh, curve for hair)
*grids (multires grids for mesh) .data: values of the attributes, data type depends on type, length depends on domain
** .usage: describes the default meaning of the attribute: position, direction, normal, UV map, ...
Existing data layers like UVs, (old and new) vertex colors or sculpt mask are also in this list of attributes
Attribute Edit mode to edit and visualize such attributes

This change can be done incrementally, and more currently "hardcoded" attributes can become available in this list once the initial design is worked out. We would start supporting only a subset of the domains and data types, and extend this over time so that (nearly?) any data layer becomes available as a generic attribute.

The initial steps for an implementation to support new sculpt vertex colors could be as follows:

Add data types CD_PROP_COLOR, CD_PROP_VECTOR custom data layers in addition to the existing CD_PROP_FLOAT (CD_PROP_COLOR is just a renamed CD_MVERTCOL from sculpt vertex colors).
Implement Attribute RNA type that wraps CustomDataLayer with data type CD_PROP_*. Initially only support for vertex, corner and primitive domains, and float, color and vector data types.
Implement .attributes collection property, which iterates over custom data layers on all supported domains and supported data types. And which has add/remove API functions.
Add "Attributes" user interface panel with operators to add/remove such attributes.
Support rendering such attributes in Eevee and Cycles through the Attribute node.

Then in future releases we'd add support for more domains, data types and bring existing custom data layers into this system. As we add existing data layers into this system, we will also need to consider how to handle unique naming.

Blender geometry datablocks like meshes, pointclouds, hair need support for arbitrary attributes on vertices, edges, corners, faces, points and curves. Internally there exists a custom data layer system to support this. But there is no user interface and the types of data layers available s predefined. Arbitrary attributes will serve a few purposes: * Compatibility for old per-corner colors to be replaced by per-vertex colors (#71947) * (Particle) simulation nodes that need to store arbitrary layers like velocity, radius, color, or other user defined properties * Import of geometry from other applications with such attributes The proposed design is as follows: * New `mesh.attributes`, `hair.attributes`, `pointcloud.attributes` collection property on datablocks with each item an `Attribute`. * `Attribute` has: ** `.name`: unique name ** `.type`: float, int, color, 3D vector, string, ... ** `.domain`: *** (whole) geometry ***vertex*** edge (mesh only) ***corner (mesh only)*** primitive (face for mesh, curve for hair) ***grids (multires grids for mesh)** `.data`: values of the attributes, data type depends on type, length depends on domain ** `.usage`: describes the default meaning of the attribute: position, direction, normal, UV map, ... * Existing data layers like UVs, (old and new) vertex colors or sculpt mask are also in this list of attributes * Attribute Edit mode to edit and visualize such attributes This change can be done incrementally, and more currently "hardcoded" attributes can become available in this list once the initial design is worked out. We would start supporting only a subset of the domains and data types, and extend this over time so that (nearly?) any data layer becomes available as a generic attribute. The initial steps for an implementation to support new sculpt vertex colors could be as follows: - [x] Add data types `CD_PROP_COLOR`, `CD_PROP_VECTOR` custom data layers in addition to the existing `CD_PROP_FLOAT` (`CD_PROP_COLOR` is just a renamed `CD_MVERTCOL` from sculpt vertex colors). - [x] Implement `Attribute` RNA type that wraps `CustomDataLayer` with data type `CD_PROP_*`. Initially only support for vertex, corner and primitive domains, and float, color and vector data types. - [x] Implement `.attributes` collection property, which iterates over custom data layers on all supported domains and supported data types. And which has add/remove API functions. - [x] Add "Attributes" user interface panel with operators to add/remove such attributes. - [x] Support rendering such attributes in Eevee and Cycles through the Attribute node. Then in future releases we'd add support for more domains, data types and bring existing custom data layers into this system. As we add existing data layers into this system, we will also need to consider how to handle unique naming.

Brecht Van Lommel commented

2020-05-11 23:09:46 +02:00

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

Brecht Van Lommel commented

2020-05-11 23:09:46 +02:00

Added subscribers: @brecht, @PabloDobarro, @JacquesLucke, @lichtwerk

Brecht Van Lommel changed title from ~~Geometry Attributes Data and Editing Design~~ to Geometry Attributes Design

2020-05-11 23:11:00 +02:00

Jacques Lucke commented

2020-05-12 14:54:28 +02:00

It all sounds good to me.

Pablo Dobarro commented

2020-05-12 16:45:17 +02:00

I have two questions regarding the implementation of the sculpt vertex colors/new vertex paint mode using this design:

Is the new vertex paint mode is going to paint into a generic layer (type color and domain vertex) or are we going to create a separate UI to manage these layers? I think that we should have a separate UI and system for them to integrate future features like multilayer/multichannel painting.
How are we going to manage the association of a grid domain layer a and a vertex domain layer to propagate the data from the grids to the base mesh when using apply base?

I have two questions regarding the implementation of the sculpt vertex colors/new vertex paint mode using this design: - Is the new vertex paint mode is going to paint into a generic layer (type color and domain vertex) or are we going to create a separate UI to manage these layers? I think that we should have a separate UI and system for them to integrate future features like multilayer/multichannel painting. - How are we going to manage the association of a grid domain layer a and a vertex domain layer to propagate the data from the grids to the base mesh when using apply base?

Brecht Van Lommel commented

2020-05-12 18:03:08 +02:00

Is the new vertex paint mode is going to paint into a generic layer (type color and domain vertex) or are we going to create a separate UI to manage these layers? I think that we should have a separate UI and system for them to integrate future features like multilayer/multichannel painting.

See my explanation in #71947#929316.

All mesh attributes should be available as generic attributes, but for vertex color painting there can be a UI that specifically shows the relevant subset. I think the first iteration would just be a list of vertex colors that you can display and edit one by one.

But beyond that I would imagine this integrates with the material system somehow, similar to texture painting? So that textures and vertex colors can be blended and layered arbitrarily, also with procedural texture nodes.

How are we going to manage the association of a grid domain layer a and a vertex domain layer to propagate the data from the grids to the base mesh when using apply base?

This part of the design is not really worked out.

For vertex colors (and sculpt layers?), I would hope this can be done automatic and there would just be a single grid domain layer in the UI. And Blender internally would be able to use that also for the base level too.

The precise implementation of that I'm not sure about. I think the multires modifier would convert grid domain attributes to vertex domain attributes. And if there is no multires modifier, mesh evaluation could also still do such a conversion. At least render engines would then be able to work with grid attributes without needing any changes. For painting, I guess the sculpt session could store the vertex array somewhere as well.

Alternatively we could have a hidden vertex custom data layer that is synced with the grid custom data layer, but I'd rather avoid that if possible.

> Is the new vertex paint mode is going to paint into a generic layer (type color and domain vertex) or are we going to create a separate UI to manage these layers? I think that we should have a separate UI and system for them to integrate future features like multilayer/multichannel painting. See my explanation in #71947#929316. All mesh attributes should be available as generic attributes, but for vertex color painting there can be a UI that specifically shows the relevant subset. I think the first iteration would just be a list of vertex colors that you can display and edit one by one. But beyond that I would imagine this integrates with the material system somehow, similar to texture painting? So that textures and vertex colors can be blended and layered arbitrarily, also with procedural texture nodes. > How are we going to manage the association of a grid domain layer a and a vertex domain layer to propagate the data from the grids to the base mesh when using apply base? This part of the design is not really worked out. For vertex colors (and sculpt layers?), I would hope this can be done automatic and there would just be a single grid domain layer in the UI. And Blender internally would be able to use that also for the base level too. The precise implementation of that I'm not sure about. I think the multires modifier would convert grid domain attributes to vertex domain attributes. And if there is no multires modifier, mesh evaluation could also still do such a conversion. At least render engines would then be able to work with grid attributes without needing any changes. For painting, I guess the sculpt session could store the vertex array somewhere as well. Alternatively we could have a hidden vertex custom data layer that is synced with the grid custom data layer, but I'd rather avoid that if possible.

Pablo Dobarro commented

2020-05-12 18:28:55 +02:00

Alternatively we could have a hidden vertex custom data layer that is synced with the grid custom data layer, but I'd rather avoid that if possible.

I was thinking on doing the opposite thing when trying to implement Multires for sculpt vertex colors. My idea was to have a hidden grid domain layer per vertex color layer that are created when a Multires modifier is added to the mesh.
I'm not sure what is the use case of having grid datalayers exposed in the UI to edit them directly without a corresponding vertex datalayer in the base mesh (for any kind of attribute). Maybe we can just create them automatically, store the reference in the vertex datalayer and don't expose grids in the UI at all.

> Alternatively we could have a hidden vertex custom data layer that is synced with the grid custom data layer, but I'd rather avoid that if possible. I was thinking on doing the opposite thing when trying to implement Multires for sculpt vertex colors. My idea was to have a hidden grid domain layer per vertex color layer that are created when a Multires modifier is added to the mesh. I'm not sure what is the use case of having grid datalayers exposed in the UI to edit them directly without a corresponding vertex datalayer in the base mesh (for any kind of attribute). Maybe we can just create them automatically, store the reference in the vertex datalayer and don't expose grids in the UI at all.

Brecht Van Lommel commented

2020-05-13 20:21:58 +02:00

In #76659#930127, @PabloDobarro wrote:
I was thinking on doing the opposite thing when trying to implement Multires for sculpt vertex colors. My idea was to have a hidden grid domain layer per vertex color layer that are created when a Multires modifier is added to the mesh.
I'm not sure what is the use case of having grid datalayers exposed in the UI to edit them directly without a corresponding vertex datalayer in the base mesh (for any kind of attribute). Maybe we can just create them automatically, store the reference in the vertex datalayer and don't expose grids in the UI at all.

I agree there should be a single attribute visible in the UI (and Python API?). And maybe under the hood there are two CustomDayaLayer instances if necessary.

But I think it must be possible for an attribute to exist only per-vertex even if multires is used. For vertex colors that might not be needed usually, but I think the generic attribute system should support it. And then that should be configurable for the user somehow, either as a type of domain or another attribute setting.

> In #76659#930127, @PabloDobarro wrote: > I was thinking on doing the opposite thing when trying to implement Multires for sculpt vertex colors. My idea was to have a hidden grid domain layer per vertex color layer that are created when a Multires modifier is added to the mesh. > I'm not sure what is the use case of having grid datalayers exposed in the UI to edit them directly without a corresponding vertex datalayer in the base mesh (for any kind of attribute). Maybe we can just create them automatically, store the reference in the vertex datalayer and don't expose grids in the UI at all. I agree there should be a single attribute visible in the UI (and Python API?). And maybe under the hood there are two `CustomDayaLayer` instances if necessary. But I think it must be possible for an attribute to exist only per-vertex even if multires is used. For vertex colors that might not be needed usually, but I think the generic attribute system should support it. And then that should be configurable for the user somehow, either as a type of domain or another attribute setting.

Pablo Dobarro commented

2020-05-25 19:06:25 +02:00

@brecht Regardless of the Multires/Vertex customdata design to make the propagation work for all attributes, in order to have the new vertex paint tools working the next step would be a patch for the color datalayer, which should be the same as the one in D5975 but renamed to ##CD_PROP_COLOR##, right?

@brecht Regardless of the Multires/Vertex customdata design to make the propagation work for all attributes, in order to have the new vertex paint tools working the next step would be a patch for the color datalayer, which should be the same as the one in [D5975](https://archive.blender.org/developer/D5975) but renamed to ##CD_PROP_COLOR##, right?

Brecht Van Lommel commented

2020-05-25 19:08:48 +02:00

Yes, that's right.

Pablo Dobarro commented

2020-05-27 20:10:26 +02:00

@brecht After the color datalayer in D7838, what should be the next step?

@brecht After the color datalayer in [D7838](https://archive.blender.org/developer/D7838), what should be the next step?

Brecht Van Lommel commented

2020-05-27 22:39:04 +02:00

@PabloDobarro, you could go through the steps in the task description, with the next steps being adding an Attribute RNA type, .attributes and the UI panel for it.

@PabloDobarro, you could go through the steps in the task description, with the next steps being adding an `Attribute` RNA type, `.attributes` and the UI panel for it.

Brecht Van Lommel commented

2020-05-27 22:41:33 +02:00

What would also be good here to go along with this task or do afterwards is to refactor the internal data structure to match the RNA API names proposed here. "custom data layer" is non-standard and confusing in various ways. So CustomData could become AttributeSet and CustomDataLayer could become Attribute internally.

It's probably easiest to do this afterwards to not disturb existing sculpt vertex colors patches.

What would also be good here to go along with this task or do afterwards is to refactor the internal data structure to match the RNA API names proposed here. "custom data layer" is non-standard and confusing in various ways. So `CustomData` could become `AttributeSet` and `CustomDataLayer` could become `Attribute` internally. It's probably easiest to do this afterwards to not disturb existing sculpt vertex colors patches.

Philipp Oeser commented

2020-06-24 13:48:27 +02:00

Have a question about the .name:

atm. this can clash between different types (Sculpt Vertex Colors, Vertex Colors, UV Maps, ...)
this can lead to confusion (at least when using the Attribute shading node) -- this came up in #78187 for example
should these really be ensured to be unique? (and if so, how can we handle old files once we convert more currently "hardcoded" data layers?)
would we need a more sophisticated Attribute shading node? Or only have more specialized nodes like the Vertex Color node or the UV Map node?

Have a question about the `.name`: - atm. this can clash between different types (Sculpt Vertex Colors, Vertex Colors, UV Maps, ...) - this can lead to confusion (at least when using the `Attribute` shading node) -- this came up in #78187 for example - should these really be ensured to be unique? (and if so, how can we handle old files once we convert more currently "hardcoded" data layers?) - would we need a more sophisticated `Attribute` shading node? Or only have more specialized nodes like the `Vertex Color` node or the `UV Map` node?

Jacques Lucke commented

2020-06-24 14:08:33 +02:00

I think we should enforce unique names across all domains and data types. This makes it much easier to work with them in a node based workflow. This is because then an attribute can be referred to by a name and not by a name+domain+type combination. Also have a look at this slightly outdated document: https://wiki.blender.org/wiki/Source/Nodes/MeshTypeRequirements
I'd assume that there are not too many name collisions in current files. I don't really see another option to renaming them in versioning code...
How would a "more sophisticated" Attribute node look like in your opinion?

I think the way one works with the attribute node could be changed a bit. Instead of having to insert a blank attribute node, it would be much nicer if users could just see all the different attributes in a menu (that is dynamically populated based on evaluated objects that use the material). When the user clicks on an attribute name, it inserts a new Attribute node with the name being initialized and only one output socket of the correct type.

I think we should enforce unique names across all domains and data types. This makes it much easier to work with them in a node based workflow. This is because then an attribute can be referred to by a name and not by a name+domain+type combination. Also have a look at this slightly outdated document: https://wiki.blender.org/wiki/Source/Nodes/MeshTypeRequirements I'd assume that there are not too many name collisions in current files. I don't really see another option to renaming them in versioning code... How would a "more sophisticated" Attribute node look like in your opinion? I think the way one works with the attribute node could be changed a bit. Instead of having to insert a blank attribute node, it would be much nicer if users could just see all the different attributes in a menu (that is dynamically populated based on evaluated objects that use the material). When the user clicks on an attribute name, it inserts a new Attribute node with the name being initialized and only one output socket of the correct type.

Brecht Van Lommel commented

2020-06-24 14:13:26 +02:00

The Attribute shading node should be considered to be quite low-level and conflicts can happen there, but we can indeed improve it's UI. For sculpt vertex colors we will get the Vertex Color node working still, which should solve this particular problem.

Enforcing unique naming is something I want to look at once this attributes system is in place. But it will break compatibility in some cases and the UI is challenging as well if all attributes are not displayed in a single list everywhere. So this needs more design work.

A simple first step is to rename the default sculpt vertex colors from "Col" to "Color", that abbreviation is not helpful and avoids the most obvious conflicts.

The Attribute shading node should be considered to be quite low-level and conflicts can happen there, but we can indeed improve it's UI. For sculpt vertex colors we will get the Vertex Color node working still, which should solve this particular problem. Enforcing unique naming is something I want to look at once this attributes system is in place. But it will break compatibility in some cases and the UI is challenging as well if all attributes are not displayed in a single list everywhere. So this needs more design work. A simple first step is to rename the default sculpt vertex colors from "Col" to "Color", that abbreviation is not helpful and avoids the most obvious conflicts.

blender-admin commented

2020-06-24 14:17:44 +02:00

This issue was referenced by e59712b7c8

This issue was referenced by e59712b7c80358f7912eebd55ef08c8cc6daafc4

Philipp Oeser commented

2020-06-24 14:22:06 +02:00

In #76659#964204, @JacquesLucke wrote:
How would a "more sophisticated" Attribute node look like in your opinion?

Having to choose .usage first, then .name? (or any other combination that would make it unique, but name+domain+type would not be enough)
Not a big fan of this either, so maybe your following suggestion is better (this is all not an issue if we dont allow nameclashes, if we do though, changing the name in your suggestion might still be problematic?)

I think the way one works with the attribute node could be changed a bit. Instead of having to insert a blank attribute node, it would be much nicer if users could just see all the different attributes in a menu (that is dynamically populated based on evaluated objects that use the material). When the user clicks on an attribute name, it inserts a new Attribute node with the name being initialized and only one output socket of the correct type.

> In #76659#964204, @JacquesLucke wrote: > How would a "more sophisticated" Attribute node look like in your opinion? Having to choose `.usage` first, then `.name`? (or any other combination that would make it unique, but name+domain+type would not be enough) Not a big fan of this either, so maybe your following suggestion is better (this is all not an issue if we dont allow nameclashes, if we do though, changing the name in your suggestion might still be problematic?) > I think the way one works with the attribute node could be changed a bit. Instead of having to insert a blank attribute node, it would be much nicer if users could just see all the different attributes in a menu (that is dynamically populated based on evaluated objects that use the material). When the user clicks on an attribute name, it inserts a new Attribute node with the name being initialized and only one output socket of the correct type.

Philipp Oeser commented

2020-06-24 14:28:26 +02:00

In #76659#964214, @brecht wrote:
A simple first step is to rename the default sculpt vertex colors from "Col" to "Color", that abbreviation is not helpful and avoids the most obvious conflicts.

Sounds good, maybe this could be explicitly mentioned in {#78041}?

> In #76659#964214, @brecht wrote: > A simple first step is to rename the default sculpt vertex colors from "Col" to "Color", that abbreviation is not helpful and avoids the most obvious conflicts. Sounds good, maybe this could be explicitly mentioned in {#78041}?

Brecht Van Lommel commented

2020-06-24 14:30:09 +02:00

Also something to consider for unique naming is how file formats like USD and Alembic deal with them, and how that affects compatibility. For example in Houdini the name is required to be unique per domain, but not across all domains.

blender-admin commented

2020-07-03 15:30:04 +02:00

This issue was referenced by 565510bd7f

This issue was referenced by 565510bd7fd87ae146cabafb27f1dfd550450f58

blender-admin commented

2020-08-04 12:52:04 +02:00

This issue was referenced by a1397a3cc6

This issue was referenced by a1397a3cc69382a64ab97bb71e4769fc0add0791

Kenzie commented

2020-08-06 01:42:47 +02:00

Added subscriber: @KenzieMac130

Evan Wilson commented

2020-08-10 04:04:07 +02:00

Added subscriber: @EAW

blender-admin commented

2020-08-19 18:12:52 +02:00

This issue was referenced by 370d6e5025

This issue was referenced by 370d6e50252b979433f27959070315911cc340e5

kursad k commented

2020-10-22 01:58:25 +02:00

Added subscriber: @kursadk

kursad k commented

2020-10-22 01:58:25 +02:00

Is there an eta for " Support rendering such attributes in Eevee and Cycles through the Attribute node" ? Thanks

Hans Goudey commented

2020-10-31 05:24:18 +01:00

Added subscriber: @HooglyBoogly

Steffen Dünner commented

2021-01-27 11:27:25 +01:00

Added subscriber: @SteffenD

RedMser commented

2022-01-31 16:40:07 +01:00

Added subscriber: @RedMser

Brecht Van Lommel commented

2022-04-06 18:55:17 +02:00

Changed status from 'Confirmed' to: 'Resolved'

Brecht Van Lommel closed this issue

2022-04-06 18:55:17 +02:00

Brecht Van Lommel self-assigned this 2022-04-06 18:55:17 +02:00

Brecht Van Lommel commented

2022-04-06 18:55:17 +02:00

This has been largely implemented or replaced by more specific tasks in the sculpt/paint and geometry nodes modules.

Crowe commented

2022-05-30 01:00:35 +02:00

Added subscriber: @crowe

Crowe commented

2022-05-30 01:00:35 +02:00

Maybe I'm just stupid, but shouldn't curve attributes be accessible in the same way meshes' are?

You can, for example, do a bpy.context.active_object.data.attributes[idx] to get to a mesh attribute collection, but for the life of me I can't find where the curves attributes are. There's also no UI panel for them, making it look as if it were overlooked.

Maybe I'm just stupid, but shouldn't **curve** attributes be accessible in the same way meshes' are? You can, for example, do a `bpy.context.active_object.data.attributes[idx]` to get to a mesh attribute collection, but for the life of me I can't find where the curves attributes are. There's also no UI panel for them, making it look as if it were overlooked.

Hans Goudey commented

2022-05-30 08:45:53 +02:00

Curves attributes are being implemented for the new Curves object (#68981).

Curves attributes are being implemented for the new *Curves* object (#68981).

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 Attributes Design #76659