Understanding the concept of "Attribute" in Geometry Nodes

[Orange_Cat]

Does Attribute mean Data / Information?

Question 1.
In this Youtube video, the Tutor pointed at the list of vertices’ positions and said that these pieces of coordinate information are attributes (more specifically, position attributes). Which led me to think, Attribute is data of something (in this case, of vertices): vertices’ positions, vertices’ normal, (…)

Question 2.
Would the Store Named Attribute node be a good way to show me what Attribute is?

So, according to the node, Attribute can be one of those Data Types like Scalars / Floats, Integers, Vectors, (…)
And those Data Types can be on Domains like Points, Edges, (…)
Right? Is it that simple?

Question 3.
Also, am I correct for thinking that Field is just a special case of Attribute?
A Field means a set of unique data assigned to each corresponding vertex, and Attribute just means general data (of vertices)?

---

Thank you!

---

Edit.
I found this answer on StackExchange, which says:

“Every point referenced in an object has an attribute, whether that is vertexes or points generated using a point distribute node. An attribute stores a bit of information of every one of these points. This could be a points scale, location or rotation. It could also be a user generated value such as a vertex group. Think of them as variables for every point in an object.”

Is this a good enough explanation? Is it accurate?
If it is, then it seems that the Attribute’s data listed in the Store Named Attribute such as “Scalars, Vectors, Integers, (…)” don’t match with what this person claims the type of Attribute’s data to be, which are "a point’s scale, location or rotation".

So, what are Attributes? “Scalars, Vectors, Integers, (…)”, or “a point’s scale, location or rotation”?
And if you are gonna answer “a point’s scale, location or rotation”, then why does the node Store Named Attribute says that the Attribute data is “Scalars, Vectors, Integers, (…)”?

[shannonz]

In the beginning, meshes were computer data representations of Vertex-Edge-Face (VEF) graphs. There are many ways to store this information, with different benefits & drawbacks. But for the super simplified sake of argument, pretend that we have an array of all the Vertices (a Domain), along with information about which Edges and Faces are attached to this Vertex. Similarly, pretend we have and array of Edges (another Domain), with information about which Vertices & Faces are attached to this Edge. …ditto a Face array (yet another domain) with information about which Vertices and Edges are attached to this Face.

After the in the beginning, simple VEF graphs became more complicated as more and more information gets tacked on to allow further modeling techniques. A vertex is just XYZ coordinates for a 3d spatial location. But then UV-texturing became a thing, and a Vertex now might also store the 2d UV coordinates for that point. Then Vertex-Colors became a thing… now the vertex is storing { x,y,z ; u,v ; r,g,b,a … }

The Spreadsheet editor in blender gives us a way to see some of this information. The extra columns that get added after a Vertex’s XYZ coords are Attributes. An Attribute is just additional data that is somehow added on to some part of the data-model of the Geometry.

I’m going to get into trouble explaining fields (because I am fuzzy on the specifics of how they are represented and used, sorry). But my understanding, is that an attribute gets computed once and stuck in a column (in the spreadsheet) to become a readable datum. A field (if i understand correctly) is computed repeatedly as needed, and I think does not get stored as an attribute.

A Vertex-Color is a property of that Vertex no matter where the vertex goes, so it can be stored as an attribute. This Vertex’s distance from that moving object over there is not an immutable property / attribute of this Vertex; rather it is a mutable relationship that we express by a bunch of math nodes: the relationship (the equation) holds, but the output of the equation must be recomputed under changed circumstances – thus it often doesn’t make sense to store it in a new column as a new attribute.

I keep taking about Vertex attributes, which is to say I’m discussing the Domain of Vertices. These general principles apply to other domains like Edges, Faces, Point(cloud)s, etc.

I hope that this helps somewhat, and doesn’t cause confusion. My understanding is imperfect, but I too am trying to figure it out.

[stray]

I think, they meant it as an example:

@Orange_Cat

This could be a points scale, location or rotation

@Orange_Cat

Named Attribute such as “Scalars, Vectors, Integers, (…)”

Attributes can be Vector Attributes and contain information about anything that can be described in a 3D vector form: loc, rot, scale, normals, color… or whatever you can think of that has three components.
They can represent something meaningful like location.
…Or store some randomly generated vectors to use as, say, displacement

[Orange_Cat]

Thank you! Sorry for my late response.

---

Question 1.

@stray

Attributes can be whatever you can think of that has three components.

Got it.
But then why are Scalars aka Float, and Integers included? These types of data are singular values, they don’t have 3 components or coordinates like vectors or points.

---

Question 2.
After reading yours and Shannonz’s answers, I think that the Store Named Attribute Node would be the best way to demonstrate what the concept of Attribute is.

I think:
“Attributes are these types of data: Scalar / Floats, Integers, Vectors, Colors, (…), and these types of data exist in certain Domains of an Imported Object like Vertices, Edges, Faces, (…) of it”

However, it still has the problem of the Question 1 above.

Please share what you think.

[stray]

@Orange_Cat

Question 1.

@stray

Attributes can be whatever you can think of that has three components.

Ah, there’s a misunderstanding.
Attributes can be Vectors… OR floats OR integers OR booleans, etc.

And these attributes can represent any kind of value of appropriate type: location, weight, index, selection, etc…

[shannonz]

during the course of evaluating fields, to satisfy the input to various nodes, anonymous attributes may be created (come & go) as needed by the GeomNodes evaluation logic.

If you want to keep some of these anonymous attributes, or remove their anonymity (ie; name them), the Store_Named_Attribute node lets you control the properties of the attribute you want to make explicit.

In the Store_Named_Attribute node:

• The top menu controls the TYPE of the attribute { float, integer, vector, color … }. If you are saving a “distance” or a (vertex-group) “weight” (scalars), you would most likely want to declare these of TYPE float.
• The 2nd menu controls the DOMAIN – ie; WHERE do you want to store this attribute. Vertex-color or vertex-weight refer to a vertex, so the DOMAIN should be Vertex. Edge-crease or Edge-angle refer to an edge, so the DOMAIN should be EDGE. If you are coloring or scaling a bunch of instances, then those attributes may need to be in domain INSTANCE.
• The NAME field lets you name this attribute (no longer anonymous). The name will let you refer to the attribute elsewhere in this node-group, or possibly output the attribute at the end of the node-group.

See the “stacking boxes” example on this manual page: Accumulate Field Node
…They show you how to stack the boxes, but your boxes will all be the same color. If you want to randomize the colors (as depicted in the accompanying illustration), then you need to add the following nodes (which need to work in coordination with a shader):

GEOM_NODES:
Store_Named_Attribute: Color, Instance, “someName”, ~a random color~
→ Realize_Instances
→ Set_Material (to the shader that has to match)

SHADER_NODES: ( for the material shader that has to match)
Color_Attribute: use “someName” here to fetch previously stored color attribute
→ Principled_BSDF
→ Material_Output

[Hadriscus]

That was stellarly clear

[Orange_Cat]

Thank you for the detailed explanation!

@shannonz

The extra columns that get added after a Vertex’s XYZ coords are Attributes

May I ask, after these vertices’ XYZ coordinates? I’m seeing no extra columns behind them, do I have to do something to have those extra columns?

Also, would these XYZ coordinates themselves be considered Attributes?

[DNorman]

@Orange_Cat

would these XYZ coordinates themselves be considered Attributes?

Yes they are the position attribute. They are the local positions of the vertexes (relative to the objects origin)
You could use this attribute in the shader editor instead of object coordinates via the attribute node.

@Orange_Cat

I’m seeing no extra columns behind them

Because for the moment there are no other attributes assigned to those vertexes.

If you make a vertex group you will then see the vertex group in a new column.

Or you could store a named attribute to them.