Improve integration of generic attributes #89054

New Issue

Jacques Lucke · 2021-06-11T12:17:30+02:00

Jacques Lucke commented

2021-06-11 12:17:30 +02:00

Broadly speaking, Blender has two different kinds of attributes currently.

Task specific attributes: That includes basically all the attributes that were used before geometry nodes existed (uv layers, vertex groups, vertex colors).
Generic attributes: While those attributes existed before geometry nodes already, only through geometry nodes they became significantly more useful. They are not attached to any specific task but are generic data containers.

Since generic attributes were rarely used, they are not supported by many features in Blender. In particular, most modifiers do not support them. Also, Eevee is still lacking support for using generic attributes for shading while Cycles got support recently. Modifiers and Eevee are however supporting many of the task specific attributes when appropriate.

The problem now is that e.g. the Displace modifier does support vertex groups but not generic attributes. It is very reasonable to assume that it should support generic attributes (e.g. generated by geometry node) as well. The situation is made worse by the fact that geometry nodes sometimes has to convert task-specific to generic attributes, breaking usages of the attribute further down the line.

Below are some possible short- and long-term solutions with pros and cons. Feel free to add more possible solutions and arguments to the list.

(A) Support task-specific and generic attributes everywhere.

Pros:

Can be rolled out gradually, e.g. one modifier at a time.
Does not require versioning and scripts keep working.

Cons:

Will probably be rolled out gradually, implying that some modifiers might support generic attributes while others don't. That could be confusing.
Will probably make the code of all modifiers more complex (unless we do cleanup at the same time).

(B) Drop task-specific and use only use generic attributes.

Pros:

Having only generic attributes can simplify code by removing special cases.
Might make learning about attributes simpler.

Cons:

Task specific attributes on original data often have additional data attached (e.g. selection state). We'd have to find a way to store that somewhere else.
Requires lots of versioning and breaks a significant number of scripts and tutorials.
Currently, generic attributes are not able to replace vertex groups which are stored very differently due to memory and access requirements. While generic attributes could be extended to support similar data layouts, we do not have a design for that yet.

(C) New node for converting generic to task-specific attributes.

Pros:

Easy to implement and is an isolated change.
Provides a workaround for the issue of not being able to use generated attribute.

Cons:

Forces the user to learn when this conversion is necessary and when not. Some users might just do the conversion all the time even when not necessary.
Since studio needs are fulfilled by the workaround, the incentive to solve the actual underlying problem becomes much smaller. There is a risk that it will never be solved because there is a "simple" workaround.

(D) Eagerly convert generic to task-specific attributes automatically.

This means that e.g. after the geometry nodes modifier is done, all attributes fulfilling some criteria will be converted to task-specific attributes.
The criteria could be that the attribute exist on the original data and has not changed the data type.

Pros:

Hides the problem from the user for the most part.
Fairly easy to implement and is an isolated change.

Cons:

Might not be clear when attributes are converted and when not. E.g. what happens when you use the object info node to pull in the geometry of another object. Should its attributes be converted as well?
If people/addons start depending on this, it might be hard to move to a better long term solution later on.

(E) Lazily convert generic to task-specific attributes automatically.

This means that e.g. modifiers will convert data into the format they support automatically.

Pros:

Hides the problem from the user even better than the eager approach.
Fairly easy to implement but requires changes in many places.

Cons:

Unclear whether this conversion should be noticable for the user or if the conversion should be temporary.
When rolled out incrementally, generic attributes might be support in some places but not in all.

I do not have a strong opinion on what the right approach is, feedback is welcome.

Broadly speaking, Blender has two different kinds of attributes currently. * Task specific attributes: That includes basically all the attributes that were used before geometry nodes existed (uv layers, vertex groups, vertex colors). * Generic attributes: While those attributes existed before geometry nodes already, only through geometry nodes they became significantly more useful. They are not attached to any specific task but are generic data containers. Since generic attributes were rarely used, they are not supported by many features in Blender. In particular, most modifiers do not support them. Also, Eevee is still lacking support for using generic attributes for shading while Cycles got support recently. Modifiers and Eevee are however supporting many of the task specific attributes when appropriate. The problem now is that e.g. the Displace modifier does support vertex groups but not generic attributes. It is very reasonable to assume that it should support generic attributes (e.g. generated by geometry node) as well. The situation is made worse by the fact that geometry nodes sometimes has to convert task-specific to generic attributes, breaking usages of the attribute further down the line. Below are some possible short- and long-term solutions with pros and cons. Feel free to add more possible solutions and arguments to the list. ------------------ **(A) Support task-specific and generic attributes everywhere.** Pros: * Can be rolled out gradually, e.g. one modifier at a time. * Does not require versioning and scripts keep working. Cons: * Will probably be rolled out gradually, implying that some modifiers might support generic attributes while others don't. That could be confusing. * Will probably make the code of all modifiers more complex (unless we do cleanup at the same time). **(B) Drop task-specific and use only use generic attributes.** Pros: * Having only generic attributes can simplify code by removing special cases. * Might make learning about attributes simpler. Cons: * Task specific attributes on original data often have additional data attached (e.g. selection state). We'd have to find a way to store that somewhere else. * Requires lots of versioning and breaks a significant number of scripts and tutorials. * Currently, generic attributes are not able to replace vertex groups which are stored very differently due to memory and access requirements. While generic attributes could be extended to support similar data layouts, we do not have a design for that yet. **(C) New node for converting generic to task-specific attributes.** Pros: * Easy to implement and is an isolated change. * Provides a workaround for the issue of not being able to use generated attribute. Cons: * Forces the user to learn when this conversion is necessary and when not. Some users might just do the conversion all the time even when not necessary. * Since studio needs are fulfilled by the workaround, the incentive to solve the actual underlying problem becomes much smaller. There is a risk that it will never be solved because there is a "simple" workaround. **(D) Eagerly convert generic to task-specific attributes automatically.** This means that e.g. after the geometry nodes modifier is done, all attributes fulfilling some criteria will be converted to task-specific attributes. The criteria could be that the attribute exist on the original data and has not changed the data type. Pros: * Hides the problem from the user for the most part. * Fairly easy to implement and is an isolated change. Cons: * Might not be clear when attributes are converted and when not. E.g. what happens when you use the object info node to pull in the geometry of another object. Should its attributes be converted as well? * If people/addons start depending on this, it might be hard to move to a better long term solution later on. **(E) Lazily convert generic to task-specific attributes automatically.** This means that e.g. modifiers will convert data into the format they support automatically. Pros: * Hides the problem from the user even better than the eager approach. * Fairly easy to implement but requires changes in many places. Cons: * Unclear whether this conversion should be noticable for the user or if the conversion should be temporary. * When rolled out incrementally, generic attributes might be support in some places but not in all. ------------ I do not have a strong opinion on what the right approach is, feedback is welcome.

Jacques Lucke commented

2021-06-11 12:17:30 +02:00

Added subscriber: @JacquesLucke

blender-admin commented

2021-06-11 12:17:30 +02:00

#90431 was marked as duplicate of this issue

blender-admin commented

2021-06-11 12:17:30 +02:00

#87590 was marked as duplicate of this issue

blender-admin commented

2021-06-11 12:17:30 +02:00

#88905 was marked as duplicate of this issue

blender-admin commented

2021-06-11 12:17:30 +02:00

#89091 was marked as duplicate of this issue

Bent Hillerkus commented

2021-06-11 15:29:34 +02:00

Added subscriber: @bent

Some User commented

2021-06-11 17:52:38 +02:00

Added subscriber: @someuser

Some User commented

2021-06-11 17:52:38 +02:00

i am biased to: (B) Drop task-specific and use only use generic attributes:
vertex groups are basically a selection right, which means after planning how selection attributes should work, it in theory possible to port ancient vertex groups workflow to more generic selection workflow (for example replace vertex group list in the gui and expose selection attributes list there)
also i think with 3.0 is fine to break compatibility

i am biased to: (B) Drop task-specific and use only use generic attributes: vertex groups are basically a selection right, which means after planning how selection attributes should work, it in theory possible to port ancient vertex groups workflow to more generic selection workflow (for example replace vertex group list in the gui and expose selection attributes list there) also i think with 3.0 is fine to break compatibility

Paul Larson commented

2021-06-11 19:36:02 +02:00

Added subscriber: @GeorgiaPacific

Jacques Lucke commented

2021-06-14 10:50:25 +02:00

Added subscribers: @blendersamsonov, @PratikPB2123

Jacques Lucke commented

2021-06-14 11:13:36 +02:00

Added subscriber: @eliassuzumura

Jacques Lucke commented

2021-06-14 12:21:48 +02:00

Added subscribers: @EvaVomhoff, @ankitm

Sybren A. Stüvel commented

2021-06-18 11:05:18 +02:00

Added subscriber: @dr.sybren

Sybren A. Stüvel commented

2021-06-18 11:05:18 +02:00

My two cents:

(A) Support task-specific and generic attributes everywhere. I think this one has my preference. The confusion of which modifier supports generic attributes can be resolved by documenting well. A not-supporting modifier UI panel could also show a warning when it's used on a mesh with generic attributes.
(B) Drop task-specific and use only use generic attributes. This seems a nice idea, but for me it would be too early to choose something like this. The different access patterns make it hard to really get a good feel for the performance impact.
(C-E). These all have the downside that they have potentially unnecessary performance costs, and that they might be hard to remove in the future. That just doesn't feel that nice.

Solution (B)can also be implemented after(A); after all, once the modifiers support generic attributes, making support only generic attributes should be relatively straight-forward.

My two cents: - **(A) Support task-specific and generic attributes everywhere.** I think this one has my preference. The confusion of which modifier supports generic attributes can be resolved by documenting well. A not-supporting modifier UI panel could also show a warning when it's used on a mesh with generic attributes. - **(B) Drop task-specific and use only use generic attributes.** This seems a nice idea, but for me it would be too early to choose something like this. The different access patterns make it hard to really get a good feel for the performance impact. - **(C-E).** These all have the downside that they have potentially unnecessary performance costs, and that they might be hard to remove in the future. That just doesn't feel that nice. Solution **(B)**can also be implemented after**(A)**; after all, once the modifiers support generic attributes, making support *only* generic attributes should be relatively straight-forward.

Jacques Lucke commented

2021-08-25 18:02:15 +02:00

Added subscribers: @FrankieHobbins, @HooglyBoogly, @lichtwerk

Vladislav Macíček commented

2021-08-25 22:17:58 +02:00

Added subscriber: @Aeraglyx

Hans Goudey commented

2021-12-03 14:52:14 +01:00

Just noting here that recently we've mostly aligned a combination of A and B. A in the short term and B in the longer term.
Edit mode's capabilities for editing generic attributes will be improved, and sculpt and paint modes should allow painting generic color attributes.
In the longer term, there have been discussions about an "Attribute Edit" mode, though that is less defined.
For compatibility during the transition, #91379 should help.

Just noting here that recently we've mostly aligned a combination of **A** and **B**. **A** in the short term and **B** in the longer term. Edit mode's capabilities for editing generic attributes will be improved, and sculpt and paint modes should allow painting generic color attributes. In the longer term, there have been discussions about an "Attribute Edit" mode, though that is less defined. For compatibility during the transition, #91379 should help.

Hans Goudey changed title from ~~Improve integration of generic attributes.~~ to Improve integration of generic attributes

2021-12-03 15:16:48 +01:00

Hans Goudey commented

2021-12-03 15:16:48 +01:00

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

Ramil Roosileht commented

2021-12-08 14:14:42 +01:00

Added subscriber: @Limarest

Ramil Roosileht commented

2021-12-08 14:14:42 +01:00

In #89054#1264137, @HooglyBoogly wrote:
Just noting here that recently we've mostly aligned a combination of A and B. A in the short term and B in the longer term.
Edit mode's capabilities for editing generic attributes will be improved, and sculpt and paint modes should allow painting generic color attributes.
In the longer term, there have been discussions about an "Attribute Edit" mode, though that is less defined.
For compatibility during the transition, #91379 should help.

While the plan of eventually making every attribute generic is nice, please don't forget about export formats compatibility. Users will still need a way to define which attributes to export with the geometry, and there is no mention of that in the description. Plan B not only breaks some scripts, but removes any way for a user to use these attributes outside Blender, so I think it should be mentioned that export operators refactoring will also be necessary for the system to work as a complete pipeline

> In #89054#1264137, @HooglyBoogly wrote: > Just noting here that recently we've mostly aligned a combination of **A** and **B**. **A** in the short term and **B** in the longer term. > Edit mode's capabilities for editing generic attributes will be improved, and sculpt and paint modes should allow painting generic color attributes. > In the longer term, there have been discussions about an "Attribute Edit" mode, though that is less defined. > For compatibility during the transition, #91379 should help. While the plan of eventually making every attribute generic is nice, please don't forget about export formats compatibility. Users will still need a way to define which attributes to export with the geometry, and there is no mention of that in the description. Plan B not only breaks some scripts, but removes any way for a user to use these attributes outside Blender, so I think it should be mentioned that export operators refactoring will also be necessary for the system to work as a complete pipeline

Hans Goudey commented

2021-12-08 15:24:08 +01:00

Yeah, that's mentioned briefly in the 3.1 targets task, #93203. I agree that it's important.

Yuro commented

2021-12-08 15:43:37 +01:00

Added subscriber: @Yuro

Yuki Hashimoto commented

2022-03-21 13:42:55 +01:00

Added subscriber: @hzuika

Jamell Moore commented

2022-12-13 14:39:45 +01:00

Added subscriber: @JamellMoore

Hans Goudey referenced this issue

2023-04-06 20:55:27 +02:00

Struct of Arrays Refactor for Mesh Edges #95966

Shmuel Israel commented

2023-09-19 21:53:54 +02:00

what attributes are already generic, and which ones still need to be changed? I think it would good idea to have them all link back to a central place to we could track the development progress.

(perhaps there is one but I can't find it and the 'Move bevel weight to generic attribute' tast doesn't link back to anything)

what attributes are already generic, and which ones still need to be changed? I think it would good idea to have them all link back to a central place to we could track the development progress. (perhaps there is one but I can't find it and the 'Move bevel weight to generic attribute' tast doesn't link back to anything)

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

Improve integration of generic attributes #89054