Nodes Workshop – June 2021

The Geometry Nodes project has just finished its third 2-month cycle. This time the target was an improved material pipeline, curves, volumes and designing a system to pass attributes more directly. To help wrap this up and prepare for Blender 3.0, part of the team gathered in Amsterdam for a nodes workshop from June 22 […]

The Geometry Nodes project has just finished its third 2-month cycle. This time the target was an improved material pipeline, curves, volumes and designing a system to pass attributes more directly. To help wrap this up and prepare for Blender 3.0, part of the team gathered in Amsterdam for a nodes workshop from June 22 to 25.

Attribute Processor presentation and discussions.

The workshop was organized by Dalai Felinto and Jacques Lucke. They picked the topics to work on, updated its latest designs, and once ready, presented them for further debate to a wider audience (Andy Goralczyk, Brecht Van Lommel, Pablo Vazquez, Simon Thommes, Ton Roosendaal).

The topics covered were:

  • Simulation Solvers
  • Geometry Checkpoints
  • Attribute Sockets
  • Particle Nodes
  • Physics Prototype

Simulation Solvers

How to integrate simulation with geometry nodes?

The simulation solvers will be integrated in the pipeline at the Geometry Nodes level. The solver nodes get geometry inputs and outputs, so it can be transformed with further nodes, or even connected to a different solver afterwards. While some solvers can support a single node with inputs and outputs, other solvers will have multiple input and output sockets.

A solver node will point to a separate data-block. The same data-block can be used in different Geometry Nodes trees. This way, multiple geometries can be solved together, each interacting with each other in the same solver (e.g., different pieces of cloth colliding among themselves).

Colliders and force fields will still be defined in the object level. This will allow any object outside the Geometry Nodes system to influence multiple solvers.

Because there is a dependency of solver evaluation depending on how they are connected in the node trees, it is important to display an overview of their relations. In a View Layer level users will be able to inspect (read-only) the dependency between the different solver systems and eventual circular dependencies. Their order is defined in the geometry-node trees though.

View Layer overview of solvers dependencies.

Geometry Checkpoints

How to mix nodes edit mode and more nodes?

Sometimes artists need to use procedural tools, manually tweak the work, and then have more procedural passes. For example, an initial point distribution can be created using Geometry Nodes, then frozen. At that point, the artist could go to edit mode, delete some points, move others around, and then use Geometry Nodes again to instance objects.

For this we introduce the concept of checkpoints, a place (node) in the node tree that can be frozen. The geometry created up to that point is baked and can be edited directly in edit mode. Any nodes leading to the checkpoint cannot be changed without invalidating the manual tweaks.

For simulation systems, like hair, this is also desirable. Distribute hair, comb it, add more complexity via nodes, simulate them and add more nodes. Even if the simulated data cannot be edited, freezing the simulation allows for performance improvements. You can simulate one frame, freeze, and still see how the rest of the tree will work animated. Without having the re-evaluate the simulation for every frame.

A live simulation or a baked cache are interchangeable. A node that reads from a cache (VDB, Alembic, etc.) should behave the same way as a solver node. This overall concept was only briefly presented and still need to be explored further and formally approved.

Attribute Sockets

How to pass attributes directly from one node to another?

At the moment each geometry node operates on the entire geometry. A node gets an entire geometry in, and outputs an entire geometry. There is no granular way to operate on attributes directly, detached from the entire geometry. This leads to an extremely linear node tree, which is hard to read.

The initial proposal to address this was called the attribute processor. This was discussed but it faced a few problems:

  • No topology change is possible within the attribute processor.
  • Having a different context inside geometry node group adds a level of complexity.
  • There is no way to pass attributes around different sets of geometries.
  • The attribute processor would only work on existing geometry, it couldn’t be used to create new geometry.

As an alternative, the team tried to find ways to handle the attributes as data directly in the node group level. Besides this, there was a pending design issue to be addressed: data abstraction from inside and outside the node groups. In other words, how to make sure that an asset is created and shared for re-usability and all the data it requires is still available once this is used by another object.

This proved to be more tricky than expected. And it is been discussed as a follow up from the workshop. You can check the current proposals here:

Update: There is a design proposal being formalized at the moment to address those problems.

Particles Nodes

Many existing solvers can work as a black box that receives geometry, extra settings, reads the current view layer colliders and force fields. The particles system however is a box full of surprises nodes instead.

Nothing definitive was proposed, but the 2020 design was revisited see if it would be compatible with the proposed integration with geometry nodes.

Example of particle simulation data-block – the rules / nodes are added by the artists.
  • Particle Simulations are solvers but they have their behavior defined by nodes.
  • There are three different node types: Events, Condition Gates and Actions:
    • Events – On Init, On Collision, On Age
    • Condition Gates – If attribute > x, If colliding, And, Or, …
    • Actions – Set Gravity, Keep Distance, Set Forces, Kill Particles.
  • Similar to Geometry-Nodes, each Action node can either:
    • Add or remove a row to the spreadsheet (i.e., create new points).
    • Add or remove a column to the spreadsheet (i.e., create a new attribute).
    • Edit a cell/row/column (i.e., set particle position).

Physics Prototype

As part of the Blender 3.0 architecture the simulation system will work independently from the animation playback. For this the physics clock needs to be detached from the animation clock.

To address this we will have a prototype to test how this can work both in the UI and the back-end. The scope of this was not covered during the workshop.

Related articles:

Source: Blender