This proposal explores another option for explicitly named attributes in geometry nodes. It is part of T90864, and also related to this post:
Background
One of the main design directives we got for the changes to the attribute workflow in 3.0 was to improve the share-ability of node groups. In 2.93, attribute names are used everywhere, so the names you use to retrieve data from the original object or another object, or to send data to a renderer or an exporter did not stand out at all.
Previous discussion have proposed completely removing every attribute name defined in the node group itself, but that is problematic for a few reasons.
- It makes assumptions about the way people work, and what kind of share-ability people want.
- It adds a limitation that is mostly arbitrary from the user’s perspective, removing flexibility without a benefit.
This proposal offers a way to get the best of both worlds. Attribute names can be defined in the node group itself, but those hard-coded names are easily visible in the modifier, and override-able, so the modifier can have the final say on the attribute name mapping.
Details
Similar to the prototype, this includes adding a “Store Named Attribute” node. It has a field input, a string name input, and allows choosing the geometry domain used to store the field’s result. The node could also have a dark “output” header, to visually distinguish it from the other nodes (since the name input can be overridden by the modifier, which is the special behavior).
However, the large difference with the prototype is that there is a new panel in the modifier, called something like “Attribute Names”. In the panel there is a text box for every “Store Named Attribute” node in the node tree. On the left is a label of the name that was calculated in the node tree for the previous evaluation. When there is no link connected to the name socket, it simply shows the default value.
This is just a rough mockup! The real version would have a “Search” button to display the corresponding node in the node editor.
The second name in the list is not overridden, so it is grayed out. Clicking on the text box would make it active, overriding the name from the node tree with a name from the modifier.
It’s important not to remove the possibility to define attribute names procedurally. This proposal addresses that elegantly, with the same method used as when there is no node link connected to the socket. Each overridden named attribute node just uses the value from the modifier instead of the value from the other nodes.
Conclusion
Named attributes are an essential part of geometry in Blender and in other applications. This method should give users the freedom to use named attributes wherever necessary (for most cases it won’t be that often at all!). But it also enforces the strict design paradigm that geometry node groups are always share-able, and usable in any context someone needs, with any attribute names people have.
Personally I’m not convinced that the complexity of this over the method we used to expose attribute names to the modifier in 2.93 is worth it, but solving the share-ability problem is also very important, and I think this is a satisfying compromise.
