In late June a Nodes workshop took place at the Blender HQ in Amsterdam. The goal of that workshop was to map out the future of the Geometry Nodes and simulation systems. Besides formalizing some design decisions for the projects, a lot was done in regard to the solvers design. However there was still a big inconclusive topic: better attributes workflow.

Now in August it was time for another round of meetings to land this home.

The Geometry Nodes system has already been used in a few productions. Nonetheless, what is now in Blender (2.93) has clear shortcomings. The main one is that artists should be able operate directly on attributes. How to do that, however, was not clear.

After the June workshop the Geometry Nodes team worked on different proposals, and opened a discussion with the community:

• Proposal for attribute socket types – Jun 11
• Fields and Static Attributes – Jun 30
• Attributes Sockets and Geometry Nodes 2.0 – Jul 1
• Expandable Geometry Socket – Jul 11
• Files + workflows and the impact of Geometry Nodes design changes – Jul 13
• Static Attributes, Attribute Sockets and Node Group Processors – Jul 16

To move the discussion forward two different designs were chosen:

• Fields gives the most flexibility when building the node-tree. Its concept is rather abstract, but very similar to the existing shader node-trees.
• Expandable Geometry Socket has a simpler metaphor. There is a single data flow in the entire node-tree (either geometry or a list of values).

A week of development was reserved for each design to build a working prototype. They were available to the community for testing and ready on time for another round of face-to-face workshops in early August. In the end the Fields was picked as the best option to move forward.

---

Data Flow and Function Flow

Fields introduces two distinct flows in the node tree: a data flow and a function flow. This design is closer to the underlying software design. That design is then exposed to the users in a true “form follow function” fashion.

Data Flow

The data flow goes from left to right and operates directly in the geometry (usually a geometry is passed to the node, which outputs a new modified geometry).

Function Flow

The function flow is a sequence of function nodes that are passed to the geometry nodes and are read backwards, as a callback.

---

Prototype and Example

The complexity of understanding how the different flows work is overcame when the system is used hands-on. Artists familiar with the shader system may see similarities with the fields and the shader node-trees.

The prototype didn’t manage to cover all the upcoming design changes (e.g., to more easily distinguish between the different flows). But it helped to sell the idea of operations directly in the attributes, and the flexibility of working with fields. Artists don’t need to worry about attribute domains (e.g., converting a face attribute to a vertex attribute), and are free the change the topology of the geometry while the function flow still works as expected.

There are still design topics that need to be addressed, but the main story of the system was better defined and reiterated over during the workshop.

Definitions

• Geometry sockets/noodles: Data transport + operation order (geometry nodes).
• Attribute and field sockerts/noodles: Functions “programming” (function / field nodes).

Names may change when this moves to the final documentation. But the underlying definitions are valid already.

Fields

• A function with variables (such as attribute names).
• Evaluates on a geometry.
• Evaluates to data.
• Can be combined into new Fields.

Attribute

• Geometry data stored per element (vertex, edge, …).
• Can be accessed as Fields.
• Are propagated through Geometry nodes.
• Types:
  • Dynamic: always available global names (position, material_index, …).
  • Static: user data or generated (UVs, selection, …).

Geometry Node

• A node that operates on a geometry.
• Can accept Fields as inputs (evaluates input Fields on the node’s geometry).
• Can create attributes which are outputted as Fields (generated Static attributes).
• Can edit/write only to Built-in attributes.
• Outputs a new geometry.

Function Node

• Can accept Fields as inputs.
• Has no Geometry input.
• Doesn’t evaluate Fields inputs (since it has no geometry).
• Outputs Fields.

---

Next Steps

There are still a lot of open design questions on how to integrate Fields into Blender:

• A new socket design for Fields.
• Function and Geometry nodes should look different.
• Visual distinction between the data transport and the functions flow.
• Clear relation between an attribute and the geometries that can access it.
• Spreadsheet editor to show Built-in, Propagated, and Static attributes (through a Viewer node).

On top of the designs, there is work to be done for backward compatibility. This is all scheduled for Blender 3.0 and will be the focus of the Geometry Nodes module. That means the core developers and the community will prioritize this over adding new nodes/features.

After that, the focus will shift to expand the Fields design for future node systems.

Try it Yourself

Download the experimental build (temp-geometry-nodes-fields-prototype) and the doughnut file to get a feeling of the new system. Remember that experimental builds should not be used in production as they might be unstable or corrupt your data.