Geometry Nodes in Blender 3.0 - Status Update

We are getting close to the end of Blender 3.0 bcon2 and I would like to share the current status of the geometry nodes and what is still expected for this release.


If you are not yet familiar with the concept of field (and the function flow) please first read this blog post.

Fields Visualization

In order to clearly communicate the difference between the existing flows (data and function), sockets and noodles are drawn differently.

  • Data flow is represented by a thick continuous line.
  • Function flow is a dimmed dashed line.
  • Data sockets are a circle (and can have its value inspected).
  • Field sockets are a diamond (and upon inspection show what they depend on).
  • Unlinked sockets that can receive either a field or data are a diamond with a circle.

Nodes and Noodles Design

Pablo Vazquez is working on a proposal that changes how all the nodes are visualized. It also includes alternative ways to visualize the different noodles. It is not clear when the design will be finalized, approved and committed. So for the scope of geometry nodes, testing, and get things ready for 3.0, those changes are not considered to be blocking.

Built-in Attributes

Built-in attributes always exist, and cannot be removed. Their data type and domain can not be changed. - User Manual

The built-in attributes can be accessed directly inside the node-tree. At the moment only the Position is available, but other attributes will be added shortly (e.g, shade_smooth, material_index, …).


The plan is to expose most of the built-in attributes this way. However, all the attributes can already be accessed using the Group Input and Output, and typing their name in the modifier.

Custom Attributes and Shareability

Vertex groups, UV maps and vertex colors are available as attributes in geometry nodes. However, while in 2.93 they were accessible from inside the node-tree with hardcoded get/set nodes, in 3.0 they are exposed via the Group Input/Output node.

This is part of a fundamental design of the geometry nodes which is the idea of shareability. You should be able to create a geometry nodes node group, share it with the world, and let people use that functionality in their own projects, with their own models. In order to guarantee that, there is a separation between the functionality (the nodes) and the data this operates on (the attributes). The data is mapped outside the nodegroup, as part of the modifier interface.


This also prevents invisible data being created deep inside a node group that is required in a different part of the node tree (or even outside, like in a material). This way, a node group works locally as a black box.

The exception are the object and collection info nodes that allows artists to define datablocks that are shared with the nodegroup. Although they still create “invisible data”, the behaviour is self-contained (the data they depend on, is shipped with them) and the node groups and modifier panel can be used to indicate the data it is creating.

This design principle comes with a cost. It hinders flexibility of artists who are not concerned with shareability. In 2.93 even artists sharing node groups would often start by hardcoding all the attributes inside the node group before exposing a few hand-picked ones.

Stable ID

To make sure the distribution of points is locally stable we need something called “stable id”. In 2.93 this was mostly hidden from the users. In master at the moment, this is explicitly exposed in the “Distribute Points on Faces” node.

Stable distribution are so important, that for a simple setup of distributing random collection children with random scale and random rotation you need to connect the Stable ID at least four times.

In Blender 3.0 this will be the default fallback for the sockets that can have an ID as input. That means that users won’t have to worry about that unless they really need. To read more about this follow this task.


There is a lot of activity going on around porting the old nodes to fields. Most of the nodes already have a patch, where artists can help testing and providing feedback. Some worthy mentions:

  • Object Info node is ported, but still needs to output the object attributes.
  • The Volume to Mesh node still has the hardcoded “density” input.
  • The primitive nodes will still have more outputs for UV and selections (if not in 3.0, for later).
  • The Texture node is being replaced by individual Texture nodes like the Image Texture node.


The user manual is still getting updated. A lot of the new nodes are already there, but there is still work to be done on updating the old nodes and present the new concepts.

For the nodes that have no official documentation yet, check the Release Notes.

Test Files

The original Geometry Nodes demo files is vastly mildly out of date. Those files are useful not only to demo the system, but for developers to test and develop new features. I started porting the initial files:

Updates and new files from the community:

New files (or the converted version of the original suite) are welcome. If you have a work that you can share as creative-common feel free to post the art here in this thread with a link to the file and the full credit. Even if it doesn’t make into the final suite it can help testing.

If your artwork is not fully ported, feel free to share work in progress and which nodes are missing for the final conversion.


If anyone needs any clarification on the current design, I will be glad to elaborate further.

That said, I know some people want to talk about the Get/Set nodes, and this is not the point of this post. The focus here is on getting everyone aligned for the 3.0 release, so everyone can help with testing, new files, documentation, …

Whether to support those nodes is a topic that can be revisited for 3.1. For now, there is enough on the agenda. And the current design of shareability is still the driving force of the system.


Please, no polls here.


Could you perhaps explain why ? knowing what the community thinks about this removal do not interest you? :frowning_face_with_open_mouth:

1 Like

Hi, can you share what you are trying to do with geometry nodes/fields at the moment?

As I mentioned, this post is about clarifying the current design. And for people to show what they can already do with it (and will be able to do in 3.0). I don’t see how the poll can help with that.

People are free to have this conversation elsewhere, of course. But I don’t want to scare away people who may be interested on the current system, but who won’t stick around if this turns into a lengthy debate about possible 3.1 only targets.

1 Like

perhaps because some users might not be happy about this design change


18 posts were merged into an existing topic: Named attribute nodes in 3.0

I tried to create something like “shape keys” with GN nodes.

There are two modifiers. M1 and M2 in the modifier stack. Custom attribute “my_cache” used to store vertex positions of the mesh.


M1 stores position to attribute “my_cache”. M2 reads a position value from “my_cache” and blends it with the current value of position.

M1 …

and M2 …

The idea was to use M1 to store the vertex positions into my_cache. Then hide the modifier and edit the mesh.
After, I would try to use ‘my_cache’ in M2 to blend the shapes.

It did not work as expected, because the value of my_cache is zero that moment I hide M1. But the little experiment also shows me some other things.

  • Multiple group inputs could help to get a clean node graph. (A very good workflow idea someone shared in the devtalk forum)
  • One also might try to use multiple group outputs for the same reason. Splitting outputs, to get a cleaner node graph. But this seems not to work. Using more than one group output gives wrong results for output attributes. (Edit, currently I am doing a mess with output nodes. May multiple output nodes be dangerous?)
1 Like

I think shareability is as important as to give users control. Also, for anyone starting out with GN, I think it’s important to have some initial path to start over. It makes me a little concerned me that GN looks, at the moment, to be target only towards the technical artist or director. I mean, some build in node groups with some common user cases would make it easier to people to start over, maybe a call for content for the 3.0 realease @dfelinto


I would be happy to contribute to a 3.0 asset pack. I’m sure there are many other experienced users that are willing to help too.

@LeonardSiebeneicher, how is your test expected to work? No changes were made between the store and set.


This is a good one! However I think the “texture pointer” idea in Luxcore is great to have. It’s basically a method to define a procedural or image texture in its own node editor, and can be shared and used globlly. User can change it in the node editor and anywhere it’s been referenced will sync with it automatically.


I thought, storing happens if I unhide M1.
If the stored attribute prevailed after hiding M1, I thought it could work like a blend shape. When hiding M1, the attribute gets zero (not initialized).

I expected GN custom attributes to act like caches. Probably, current custom GN attributes are for a different purpose.


That’s a “variable” definition, and I also expect this in some situations, not all situations.

@dfelinto, pardon me please. This page was not meant to become a discussion about the removal of get/set nodes, and I was one of those who helped push it in that direction.

However, I believe this situation is one that should be addressed soon. Please take the calls of the community into consideration.

@Laulau, if everything in blender development was settled on by a poll, blender 2.93 would still look like blender 1.0.

1 Like

Hi, as requested above, I moved discussion of named attribute nodes to a dedicated post. That is not because I don’t think it’s important, but because I think it’s best to respect the intention of this post.


There are still nodes missing the documentation in the user manual. I added a note to direct artist to the release notes for now.


Hi, I am willing share this demo file for the new curve support 3.0. Please affirm that this can be accepted so that I can go ahead with the cleanup process. (it also uses the old point instance)


This looks really nice, it will be great to include in the demos. (bonus if you can make them look nice when rendering).

Besides cleanup, can you please also add a README with instructions on how to explore the file, and basic credits and the corresponding CC license?

That said the new demo files should all have only the new nodes. So in your case you need to replace the Point Instance with the Distribute Points on Faces nodes.

Thanks, I will have a look at other demo files for examples. It also needs the subdivision surface surface node which does not seem to be available right now in master.

Of course