I think we’re looking at the word ‘Attribute’ through a looking glass and it’s gotten bigger than it really is. Attributes are just named characteristics associated with Blender geometry - things we have been using for years.
Consider the vertices of a mesh. Their positions in space are just attributes of these vertices - no more, no less.
Running with @Kenzie’s spreadsheet analogy (thanks for that!), we can take three columns, merge a spanner header cell above them and write in it the label position. Position is an intrinsic vertex attribute. It is hard to think about vertices without also thinking about where they are. We don’t attach intrinsic attributes to geometry: in the geometry node world, such attributes are already built in the geometry.
We may tack on another single column and label it weight because it pleases us to associate zero-to-one weighting values with our vertices. Intrinsic? I hesitate. I can think of vertices with or without weight. On the other hand, I can reach around/behind/beyond the geometry node world, go into Blender’s property panel and assign a Vertex Group, and that vertex group comes across to the node world as an intrinsic attribute.
Soon, ditto, Vertex Colors (but not yet). We may tack on four more columns to the right of weight, and write in this spanning header the label: colorwithalpha, referring to the vertex colors that we are also pleased to associate with vertices.
We may tack on yet another column and call it Foobar - it associates True/False boolean flags with each of the vertices. What the H, E, Double-toothpicks is Foobar?
I’m a lousy programmer and tend to write non-descriptive names. Presumably I’m thinking of a boolean mask attribute to group the geometry’s vertices one way or the other. In any case, Foobar is an extrinsic attribute. It didn’t come, predefined, into the node world with geometry. I made it up on-the-fly by tacking on another column, or - in the node world - writing it into an Attribute -X- node as an attribute operand.
What is a geometry set? To continue with @Kenzie’s example, it’s pretty much the entire spreadsheet that contains these attribute columns - no more, no less. The depth of the spreadsheet - the number of rows it has - is intrinsic to the geometry set. A mesh only has so many vertices; that count directly translates to the number of rows in the spreadsheet.
That a spreadsheet page of attributes has a specific number of rows is the reason we just can’t pick up an attribute column in one spreadsheet page and put it down in a spread sheet page of another geometry set. What are you going to do about the row mismatch? That question must be addressed by whatever the ‘pick-up-and-put-down’ process is: what I called an ‘attribute transform node’ in my upstream post. That process may decide to interpolate 27 rows from one geometry set to the 1,357 rows of the other geometry set. Or maybe fill in default values instead. In any case, we just can’t pickup an attribute from one geometry set and paste it into another without some idea about what to do with the mismatch.
Some of you may have caught my ‘pretty much’ weasel words when making an analogy between a spreadsheet page and a geometry set. What am I hiding? I confess. Meshes are more than just vertices. Edges connect vertices and winding loops of edges define faces. So the geometry set is actually a workbook of spreadsheet pages. For meshes, there are vertex, edge, and face spreadsheet pages. Geonode docuentation calls these spreadsheet pages domains. So, without the weasel words, a geometry set is a workbook with a number of domains, spreadsheet pages, each that have grouped columns of attributes that directly map, row-by-row and one-to-one, to the items comprising the domain, be they vertices, edges, faces, point cloud radii, or voxel density.
As you have probably gathered, attributes reflect a particular data arrangement, or types. Foobar: a list of True/False booleans. weight: a floating point in the range [0 - 1]. position a vector of three floats. colorwithalpha a vector of four floats.
As you have probably also gathered, geometry sets also have types, reflected by the number of spreadsheet pages - domains - that they have, alternatively, the Blender object they represent. Pointcloud geometry sets don’t have edges and faces, so its workbook doesn’t have those sheets, but it does have (sampling) radius as an intrinsic - and color too, so those sheets are part of its workbook.
I feel there are two broad sources of pain with Geometry Nodes, one representational and one operational:
- Representational: The node tree graph is struggling to represent interrelationships among things at different scale. Attribute nodes operate on ‘spreadsheet columns’ but transformational nodes like
Point Distribute
reads and translate entire workbooks. Yet someone who has just fallen into this rabbit hole beholds a node tree, sees attribute nodes and transformation nodes represented more or less with the same graphics, and that gives a false sense of equivalency. How to represent interactions among attributes - columns - on the vertex spreadsheet and face spreadsheet? How vertex, edge, face domains decorate attributes is not clear yet.
- Operational: What I called ‘scopes’ in my last post - the region in a geometry node graph where one geometry set prevails - does not have many ways to convey geometric data to other geometry sets that need to operate on that data. Face normal attributes in a mesh geometry set may, from time to time, need to orient instanced point clouds in a distant scope - that transfer node does not exist yet. Do I open up a ‘drill-down’ graph - a node workspace within a node workspace - to construct that transfer node from math primitives? I don’t know yet.
Neither of these are well settled yet and erect brick walls. How this settles - and whether it settles sensibly or not - is a matter of concern. I strongly agree with @JuanGea that these issues have to settle in a good way, and that a rushed official release of Geometry Nodes - prematurely to make a big YouTube splash, perhaps - would probably not be a good thing.