![]() It does not make sense to output attributes directly from the node when the output is instances, which do not have named attributes. Both of those nodes can output instances.However, that approach has quite a few problems: The solution that would be used without the named attribute input node is adding attribute output sockets directly to the two info nodes. 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. A Solution to Object Info and Collection Info Attributes The same decision applies here- whether to use the name mapping or the “expose name” operator. ![]() However, there is a working version in the patch linked above as well, meant for testing. This node has not been officially agreed upon by the geometry nodes team. 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 is already planned, and is being developed in D12685, where most of the work is already finished. 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. If we disallow named attribute nodes, it means creators using geometry nodes to create shareable assets will not be able to make similar decisions. In other words, it has a name, and the usability for the vast majority of users will be much better. In that case, we decided to make the “random_id” a builtin attribute. Of course, the way around that problem is to allow an “invisible” means of passing around the data. 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. 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. ![]() Right now it might seem to the untrained eye that this is only but a UX change, but if you look closely this change has profound implications on a core… This is not a ‘light’ change yet it is presented as one, in a status update? Prioritizing share-ability, here, means the complete removal of accessing named attributes within node trees. ![]() Yet, the get/set nodes are in direct correlation with the limitation imposed for this abstract concept of “share-ability”. Named Attribute Nodes in Blender 3.0 Geometry Nodes ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |