Source/Nodes/Modifier Nodes

< Source‎ | Nodes

Modifier Nodes

This initial milestone of the Everything Nodes Project will focus on geometry nodes, more specifically particle scattering for set dressing.

Nodes Modifier

A modifier to handle more complex interaction. The logic is built with a node graph, owned by the modifier.


Nodes Modifier inputs and outputs

The modifier input and output are explicit nodes that represent the flow of geometry in the modifier.


High level abstraction

Users should be able to use the system in a high level. Hand picked parameters are then exposed in the nodes.


The building blocks of the system are kept inside the main node groups, abstracted away but for advanced usage. Properties connected to the Modifier Input can be exposed in the modifier stack.

Nodes high abstract inspection.png


The high level nodes operate in a clear dataflow of geometry. For events there is a need for a different representation for its callbacks.


Often, the simulation effects require a different input and output geometry types. For example, a spray gets the nozzle as input, and output foam particles.

Geometry types.png

The icons in this image represent the data type output. It is still not clear whether this needs to be exposed in the user interface and how to do it.

Solver Node

The solver node requires new kind of input, the influences.

The geometry is passed to the solver as the initial points (for the particles solver). The solver reaches out to its influences that can:

  • Create or delete geometry
  • Update settings (e.g., color)
  • Execute operations on events such as on collision, on birth, on death.
Solver Node.png

In this example the callbacks are represented as vertical lines, while the geometry dataflow is horizontal.

Emitter Node

The emitter node generates geometry in the simulation. It can receive its own set of influences that will operate locally. For instance, an artist can setup gravity to only affect a sub-set of particles.

Emitter node.png

Main Design Concepts


Modifiers are blackboxes with geometry as the main input and output. External dependencies are possible on ID level.

Geometry Primitives

New object types are introduced to handle new primitive types.

  • Point cloud
  • Hair
  • Volume (already in Blender)

Those object types, as well as the mesh objects can be passed around in the nodetree via the "Geometry" socket. It is possible for the system to handle implicit conversion, but there are explicit settings required in some cases.

Nodes Modifier

A new kind of modifier that contains a nodetree to define what happens with the geometry. The nodetree can be shared across multiple modifiers. High level settings are exposed in the modifier stack.

Nodes Modifier Stack.png

Any of the existent modifiers can be ported to nodes, though they may need small adjustments in a per-case basis.

Geometry Node Editor

Edit the nodes for the modifiers happen in a new editor. The editor is context sensitive, showing the modifier node group of the active modifier of the active object.

Conversion vs Emission

  • Conversion tries to convert from different data types close to 1:1
  • Emission requires distribution functions + maps

Simulation Context

The simulation context is defined by the current view layer. If the simulation needs to be instanced in a different scene it has to be baked to preserve its original context.

Baking vs Caching

  • Baking overrides the modifier evaluation (has no dependencies)
  • Caching happens dynamically for playback performance

Interaction and physics

  • Physics needs its own clock, detached from animation playback
  • There is no concept of (absolute) “frames” inside a simulation


An important part of the pipeline is to assign attributes to the geometry to be change how the geometry looks and behave.

There are two kinds of attributes:

  • built-in attributes.
  • user defined attributes.

Built-in attributes are reserved names that nodes expect to operate on. For example, the instancer node expects point clouds to have position, rotation and scale attributes.

User defined attributes are created either in the source data (e.g., mesh), such as UV maps, or on-the-fly in the node tree.

Naming: Built-in attributes use snake case, while user defined attributes are initialized as "PascalCase", but can be renamed later to anything (unicodes, space, lowercase).

Abbreviation: In both cases abbreviations are to be avoided. If they eventually happen, should be lower case for the built-in attributes. For user defined attributes they can be decided on a per-case basis.

Built-in attributes:

  • density
  • position
  • radius
  • rotation
  • scale
  • temperature

Historical Design Documents