Page MenuHome

Improve integration of generic attributes
Confirmed, NormalPublicDESIGN

Description

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.

Event Timeline

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

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.

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, T91379 should help.

Hans Goudey (HooglyBoogly) renamed this task from Improve integration of generic attributes. to Improve integration of generic attributes.Dec 3 2021, 3:16 PM
Hans Goudey (HooglyBoogly) changed the task status from Needs Triage to Confirmed.

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, T91379 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

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

Yuro (Yuro) added a subscriber: Yuro (Yuro).