The discussion of named attribute nodes in 3.0 has been going on in the update thread below. While I agree that it’s a very important topic, it’s best to respect the original goal of the thread, which was a more general status update.
To that end, I hope this thread can be a place to clarify the reasoning for keeping the named attribute input and output nodes in 3.0.
In my opinion, there are plenty of reasons to include these nodes in 3.0. Many of them have been discussed quite a lot, so I won’t bother making a list here. I’ll recommend the list that @BD3D has created:
One of the most striking reason is related to a design decision we made regarding the “Stable ID” output of the distribution node last week. The feedback we got was that it’s confusing, and takes too much time to manually connect the stable ID output to every place that needs it. Of course, the way around that problem is to allow an “invisible” means of passing around the data. In that case, we decided to make the “random_id” a builtin attribute. In other words, it has a name, and the usability for the vast majority of users will be much better.
If we disallow named attribute nodes, it means creators using geometry nodes to create shareable assets will not be able to make similar decisions. One of the goals of everything nodes is to expose the flexibility that would allow technical users to make the same type of decisions that developers can make, just like you can now rebuild the shrink-wrap modifier with geometry nodes.
This node is already planned, and is being developed in D12685, where most of the work is already finished. The remaining question is whether to solve the share-ability design goal with an name override map in the modifier, or with an operator that automatically creates the node links to expose the name to the modifier interface.
This node has not been officially agreed upon by the geometry nodes team. However, there is a working version in the patch linked above as well, meant for testing.
The same decision applies here-- whether to use the name mapping or the “expose name” operator.
One of the last major parts of the design to finalize for 3.0 is how named attributes are retrieved from geometry external from the node tree-- geometry that comes from the object info and collection info nodes. We have considered a few solutions. The solution that would be used without the named attribute input node is adding attribute output sockets directly to the two info nodes. However, that approach has quite a few problems:
- Both of those nodes can output instances. It does not make sense to output attributes directly from the node when the output is instances, which do not have named attributes.
- It requires different solutions for when the object is chosen in the object info node vs. when it is exposed to the modifier or otherwise chosen elsewhere.
- This complicates understanding of the system for the user, since it would inevitably require specialized behavior.
- The mechanics of choosing types for a dynamic number of output attributes would be cumbersome.
- The system would be much more complicated to develop.
- Even with this complexity, you still have to choose attribute names, so it is not more shareable than having a dedicated node.
- As more outputs are added to those nodes, they become very large.
An alternative is simply relying on the named attribute input node to access attributes in these cases. This solution that would already exist, so it’s simpler to understand, and simpler to use. Plus, the mapping of names would already be visible in the modifier, so it is a share-ability improvement.
Anyway, thanks for the consistent testing and the feedback over the last few months. My hope is that the solution proposed in D12685: Geometry Nodes: Named attribute nodes with visible mapping can satisfy everyone.