Attributes Sockets and Geometry Nodes 2.0 [Proposal]

As a follow up to the Nodes workshop I’ve been working in a design for how to handle attributes in a more direct way and to have a way to better abstract hardcoded values for re-usable assets. Here is my latest proposal.

Attributes and attribute sockets

Attributes are commonly referred to as columns. This is a reference to how they are visualized in the spreadsheet. Attribute sockets are sockets that pass an entire column from the spreadsheet containing:

  • List (array) of elements.
  • Datatype (float, integer, boolean).
  • Domain (vertex, face, …).

So far every node were allowed to read and write any attribute to the geometry, and the result was incorporated as part of the outputted geometry. This leads to an extremely linear nodetree that makes it hard to read.

Instead, it will be interesting to pass the attributes around directly, so the operations can happen independently of the original geometry.

This was avoided in the original design because users can easily shoot themselves in the foot by connecting attributes from geometries with different index orders or length leading to unpredictable results. At the moment though, its benefits outweigh those issues.

Selections are just a an attribute socket with a list of booleans.

Asset vs on-the-fly creation

There are very distinct workflows for using geometry nodes, asset and on-the-fly creation.

At one extreme there are artists creating well crafted reusable assets where no hard-coded values are assumed, and everything the node group needs is passed via the modifier parameters. This means someone trying to re-use this asset can just plug different objects and deciding which vertex group to use from the new object.

On the other side we have an artist creating an one-off asset, with disregard to hardcoded values and “data abstraction”. A modifier in this case needs no external parameters since everything could be defined inside the node tree. The resulting asset cannot be plugged into another object and expect to work without a careful memory of which vertex group names are required for which parts of the nodetree.

There are benefits of both approaches, and the reality is that often artists start on-the-fly creation to only later prepare the asset for shareability. For this proposal the asset creation is prioritized whenever there are conflicting options.

Geometry Nodes Modifier

Let’s start by looking at a simple geometry node modifier. The first new thing you can see is that all the
attributes expected from this mesh and generated from the node tree are explicitly visible in the modifier.

Note also that those attribute fields (mushroom, scale, rusty_weight, mushroom_uv) are not simply strings. They are attributes that are expected to exist in the mesh. While they are referred to as strings, inside the nodetree they are passed around as attributes (i.e., list of values).


Group and Attribute Inputs

Every group input could be presented as its own node. Those nodes should be clearly identified, and prevents the long lines we have connecting the one group input allover the nodetree. Among the group inputs there is


Among those input nodes there are the attribute inputs. Those nodes are exposed in the modifier UI as “strings” (that can be kept in sync with the original attribute name) while inside they are just a list of values.


Users can drag a UV layer from the active object in the nodeetree and get an Attribute Input for this attribute, while under the hood Blender creates a new Group Input, set the modifier value for this input, and create the Attribute Input.

Updated Attribute Nodes

(See updated proposal).

Updated attributes are used when an attribute needs to be accessed after topology change.


When a new Group Input is added, it becomes possible to add the corresponding Attribute Input or Updated Attribute node.


Advanced Group Input/Output Sockets

A modifier can only handle one geometry as input, and one geometry as output.

However the geometry nodes datablock can be re-used inside a nodetree. In this case complex systems can benefit from optional inputs and outputs that can’t be used when in a modifier.


Those sockets can be marked so that they don’t show in the modifier. For the geometries this can be automatic because of the one-geometry per modifier restriction.


When using this node group inside a nodetree there is no distinction between the modifier parameters and the others. Also in this case the attribute socket expects the whole attribute (list of values) not the name of the attribute.


In this design the relation between the geometries and their attributes is loose and not enforced. For the update attribute node to fully work, it will require all the input attributes to be included in all the geometry inputs. The same for the output attributes and geometries.

Local Attributes

Local attributes are the main place where hard-coded strings are allowed - useful to save an attribute to re-use later or to get the same attribute after topologies changes. Name clashes with existing built-in attributes can be avoided by using namespaces.


The output and input of those nodes (besides the geometry) is the attribute name. This is not the attribute itself. This permits the nodes to be connected among themselves to retrieve a local attribute after topology changes.


Local attributes are not outputted in the final geometry. To do that a Get Local Attribute node needs to be connected to an Attribute Output node. Those attributes will be clearly indicated in the spreadsheet.

Built-In Attributes

Built-in attributes are attributes whose type and domain is fixed and cannot be changed.

Some attributes can be expected for any geometry. It is safe to access them directly by name. For example: “position”, “material_id”, “radius”.


They may just be the same nodes as Set/Get Local Attributes, making both built-in and local clearly distinguishable.

Object Info

When the object comes from outside, its attributes should also be defined outside.


However when the object itself is hard-coded, the name of its attributes are also expected to be hard-coded. In this case the attributes need to be accessed with one of the Get Attribute nodes.


Pain Points and Extra Notes

  1. Get/Set Built-In and Local attributes nodes could be unified in a single node combining both namespaces.
  2. For the geometry and attributes to be unrelated we need to write all the attributes to all the geometries.
  3. We still need a way to access user attributes for the Object Info node when hard-coding attributes.
  4. The name of “Updated Attribute” is not the greatest.
  5. Backward compatibility is possible for most of the nodes. If not, Blender 3.0 is the time we can permit Blender to break this anyways.

I believe that having a single Get/Set Attribute node that contains all the available attributes solves the main issues here. I left them as separate nodes in this proposal for overall clarity:

  • When getting the geometry from the Group Input only the built-in attributes would be available.
  • Local attributes can be explicitly stored along the tree.
  • When getting the geometry from the Object/Collection Info nodes the user attributes (UV, …) would also be available, beside the built-in attributes.
  • In the attribute property search and the spreadsheet it should be easy to tell the attributes apart (built-in, user and local).

See updated proposal - basically unifying Get/Set nodes.


All these examples already include the unified Get/Set nodes.

Storing local selections to re-use after topology change for extrude operations:

Extrude every Nth face:

Select More used to displace points around. (note that in this case the result is the same as the fields proposal).

Distribute Points with multiplied attribute:

Distribute Points with multiplied attribute and topology change:

Object Info when the object is defined inside the nodetree:

Object info when the object is defined outside the nodetree:

Comparison with Fields

The Get Attribute Node would be similar, the difference is that for Fields, the Get Attribute Node has no Geometry input. Things get very different when we talk about Local Attributes though.

Fields require no local attributes since attributes can be passed around anonymously. With this proposal you have to be explicit about Setting/Getting those attributes if you need them after topology changes.

One possibility I contemplate is to use Fields only for anonymous attributes. That makes it more similar to passing attributes as reference. I haven’t thought about all of its implications though.


Lots of good things about this proposal.
perhaps the object info node could look more like the bottom of compositors render layers node and add a dropdown menu or two.

what about instead of the name updated attribute use instead “diverged attribute”
since something in the topology has changed, gone down a different path but you need to access it again.

I like the idea of get and set nodes being together. Its a big shift but things like built in attributes being in their own section of the spreadsheet would make thing more user friendly.

Group input/output splitting into individual nodes is a general improvement. I’m all for it, but should be its own task IMO, along with other group node improvements, like ability to change socket types.

As for marking inputs/outputs to exclude from the modifier: this could also be a general feature, marking sockets as “advanced” which are hidden by default.

Instead of having “Attribute Input” i would suggest just calling “Updated Attribute” → “Get Attribute”. If you want the original attribute just pass in the original geometry. At least we could start with that and then add a “Get Input Attribute” as a shortcut if it turns out really useful. No strong opinion, but i would keep the “API surface” small until we know what’s needed.

I like the Local Attribute idea, good way to add flexibility. How will they show up in the spreadsheet though, if local attributes are not part of the final mesh? Would they only show up when using a debug viewer? (however those will work eventually)

Have attribute outputs to work with it and mix between different geometries is a huge improvement


Great proposal! I think there’s a lot of common ground between what everyone’s talking about in terms of the UX, though the consensus is definitely different from the current system.

It would be good to see a node tree mockup to see how this proposal would be put together for an actual use case.

I can only see this as good thing. There would need to be some standard method to correct for different lengths (repeating last index of the shorter set until they match would be the same behaviour as other platforms). It’s best artists have control and can choose to break things and use different index order to their advantage. Procedural systems are never going to be completely beginner-proof so I don’t think it’s so important to safeguard them especially if it means losing more advanced functionality.

I’m a bit unclear on this bit. If you can drag attributes around visually, aren’t we already going to have access to the original attribute if connected from earlier in the tree or the new updated attribute if we’re taking it later on in the tree? If 5+ topological operations have been done, where is the updated attribute being calculated from on that specific node?

Will this cause performance issues with complex models?

Agreed. Node groups are going to become an important shareable asset so could really use some love.

1 Like

Thanks everyone for the feedback.

  1. I agree that Individual Groups Inputs are almost a separate topic. But I wanted to bring them in to show the workflow of drag & dropping attributes (e.g., vertex groups) in the node editor.
  2. Also agree that the advanced options in the Node Group are also a separate topic. But I wanted to have them here to address the scenarios where the node group is used inside a node tree.
  3. @Erindale I will work on some examples. This is also something @jacqueslucke asked me about.
  4. Attribute Input node: It should be possible to replace the attribute input node with the Get Attribute node and no geometry input. However I also think it is important to have a clear distinction between the input nodes and every other node. Specially if they can be spread throughout the nodetree. So I think it may be worth to having it around. Besides, if we will have one input node for any other input, we may as well have one for attributes.
  5. Unifying the Get/Set Nodes:

I sketched this out and I think it can work. The name of the corresponding categories/namespaces are still in the air. But the overall behaviour would be:

In the image you can see under the nodes the options you get in the attribute search input.

Also, as you can see, when the object/collection info has the object defined inside the nodetree, the Asset namespace will also be exposed in the geometry.


It would be good to see a node tree mockup to see how this proposal would be put together for an actual use case.

Working on that.

If 5+ topological operations have been done, where is the updated attribute being calculated from on that specific node?

The input attributes are also present in the geometry. So you will have access to it interpolated in the geometry itself. In this case the Updated Attribute node is simply using the Input set outside the modifier to get the name of the attribute.

Will this cause performance issues with complex models?

Not necessarily. We can have a system of “copy on write” that only transfer data around if really needed. We already have something like this already.


Do we need to expect downgrades for 3.0?

That’s quite a radical structural change you guys are planning. Personally it’s scaring me a lot, i feel like there’s a lot of instability in the air and we can’t truly settle as advertised (perhaps releasing geonode as experimental would have been a wiser choice…)

Could the team express a bit more infos on how geonode from 3.0 will break things? Will we lose functionalities? I think it’s important for all users to know this.


My take is that it’s probably more important to spend time on solid foundations, even if it means changing things up a few times early on, than settle with a shabby node system just for the sake of not breaking a dozen tutorials.

Yes Jacques I’m calling your project shabby. Just kidding…


The issues here arose from testing/using the system. We can’t know how things turn out before we try them. Not everything can be planned ahead… especially for such a complex system. I don’t think people are going to stop making tutorials because some things are changed, or that anyone is going to be lost when 3.0 releases. Some adjustment will be necessary for sure…

1 Like

How does this work with Jacques’ Fields and Anonymous Attributes Proposal? It seems in this proposal, attributes are still kept in strings:

It seems like instead of having the user to type the name in a string text input on the node, it wraps individual attributes as individual nodes… This feels very different from Jacques’ proposal.

Or am I not understanding it right? These proposals are hard understand…

There are possible overlaps with both proposals. But ultimately they are different proposals that wouldn’t necessarily co-exist.

From user perspective I find Jacque’s proposal much more approachable. It alleviates the burden of thinking about the attributes all the time from the beggining without accualy removing them from the workflow. I think this is much more flexible design, than exposing all the attributes and their dependancies explicitly and making them core working tool for an artist. IMHO that’s the role of the node graph itself. Which I think you agree upon, otherwise you wouldn’t start designing attribute processor.

Operating on values much closer resembles working with masks, where values (or fields in that example) define color, opacity, density or whatever else is needed. That kind of language is better understood by an artist than entire abstraction layer with its own rules that needs constant maintenance. The user can then focus more on scene construction instead on remembering attribute flow that is independent from the node graph. Lastly, a lot less is going on the UI surface, which makes the interface cleaner.

Just my 2 cents.


I agree with @silex . The fields proposal seems better from a user perspective, but I am not nearly the advanced user that @erindale and some others are. Since it appears that it would be an either/or between this proposal and the fields one, I would hope that he (and Simon Thommes) have the time to give their perspective on that either/or before a decision is made.


Yeah people seem to prefer @jacqueslucke proposal,
i’m in too + it seem that his proposal is more easy to implement and won’t break too much stuffs


At the moment geometry nodes is not useful for much more than testing. Nobody uses it in production. It is practically a proof of concept.

They can break it completely if it means they can lay the foundations of a real and usable solution for any case. And now is the time, so don’t be afraid. We have already seen I think too many half-baked implementations that must then be maintained for years because we have not been more “daring” that in the end are far less functional for having tried to play the user’s father.


The ability to be able to decouple attributes from geometry in a way that allows geometry operations to use one attribute multiple times, for example, would be great indeed to reduce the linear workflow of the current design.

Looking forward to a practical example mockup.

If it’s not labeled as Alpha/Beta or Experimental that means that it is supposed to be production ready, thus the need for stability is of course assumed.
When you learn a sofware it is to be expected that the knowledge will not become obsolete 6 months later

They can break it completely if it means they can lay the foundations

Not at all, as a software developer you have responsibilities, users rely on you.
Bad decisions were definitely made. What happened here is completely unprofessional, if we want blender to be taken seriously in the 3D industry well let’s not do that again shall we

i hope that these errors will be recognized and we’ll get a clear explanation on what when wrong during the process

Bad decisions may have been made, but not to solve them now, with this tool having little utility and only a few months of life, is foolish.

I prefer the label of unprofessional and a useful tool than the label of unprofessional and a limited tool.

1 Like

I’m not telling that it should not be solved at all! it’s contrary very important and is good for the future of the sofware! and this change sould be done! i’m 300% in

it’s just important to highlight that something went wrong and we should not ignore this. it’s not something to take lightly, all these youtube content are already worthless.

I hope that the blenderfoundation will adress this issue seriously once the rework is officially released

I prefer the label of unprofessional and a useful tool than the label of unprofessional and a limited tool.

How about not both

BTW Do not get defensive about my post, i love blender too as much as everyone else involved here, it’s just something that has rarely been done in the sofware industry. i never saw a houdini version where they completely changed minds on a new implemented/hyped system a few months later for example.