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.
- Can be rolled out gradually, e.g. one modifier at a time.
- Does not require versioning and scripts keep working.
- 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.
- Having only generic attributes can simplify code by removing special cases.
- Might make learning about attributes simpler.
- 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.
- Easy to implement and is an isolated change.
- Provides a workaround for the issue of not being able to use generated attribute.
- 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.
- Hides the problem from the user for the most part.
- Fairly easy to implement and is an isolated change.
- 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.
- Hides the problem from the user even better than the eager approach.
- Fairly easy to implement but requires changes in many places.
- 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.