Shareable Named Attribute Node [Proposal]

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).

image

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.

image
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.

31 Likes

Further mockups of this idea:

It’s a bit clearer how this would work now, but it’s also a bit clearer (to me at least) that this is reinventing a lot of the existing group output and input behavior for node trees, which isn’t a good thing.

However, I don’t think putting this behavior into the group output node is good, since the attribute being created or edited doesn’t have to be on the output geometry like that would imply, and for a few other reasons.

So I personally think it would make more sense to display the areas where hardcoded names are used in the node tree, but not to provide this sort of “attribute name mapping override” in the modifier. Instead the string socket would just be exposed to the modifier like any other string property. That would be much simpler anyway, so probably easier to use and understand.

10 Likes

Likewise. I think it’s the responsibility of whomever shares their node group to make sure it’ll work in a different context. However, I like the idea of communicating the potential risk that hardcoded names represent. After a while, this all should have sunk into the “best practices” guidebook everyone keeps close, or even worse : in the documentation

edit that being said your idea here is pretty non-invasive… it can’t really hurt. Maybe if name conflicts turn out to actually be an issue…

7 Likes

It seems that all these concepts topic are finally hitting reality now, surprising some users

Touché

Note that I do not understand why this “problem” of sharability is such a big deal.

Such a big deal, that it apparently justified the removal of the get/input named attribute accessibility within nodetree?

As @Hadriscus Said well

Also, important point:
Assuming constant re-usability is a wrong assumption.

The design paradigm of re-usable nodegroups do not apply to geometry node, because of the fact that using a nodegroup is mandatory in order to create a geometry node modifier at the first place.

These geometry modifiers (in blender or c4d or H…) are most of the time a one time usage, with no intention of re-usability except toward applying the effect on other objects.

So it seems that the root of the problem is coming from the fact that two very different paradigm, modifiers and nodegroups, are mixed together. This is creating “re-usability” conflict that cannot truly be resolved, as both paradigm have very different context

What do you think of this @HooglyBoogly ?
I hope that the designer who wanted to push re-usability is aware of this conflict.

16 Likes