This initial milestone of the Everything Nodes Project will focus on geometry nodes, more specifically particle scattering for set dressing.
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.
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.
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.
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.
In this example the callbacks are represented as vertical lines, while the geometry dataflow is horizontal.
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.
Main Design Concepts
Modifiers are blackboxes with geometry as the main input and output. External dependencies are possible on ID level.
New object types are introduced to handle new primitive types.
- Point cloud
- 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.
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.
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
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
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.
Historical Design Documents
- Particle Workshop - September 2020
- Everything Nodes
- Initial Functions System
- Mesh Type Requirements
- Breaking up the Modifier Stack
- Simulation Architecture Proposal
- Simulation Framework - First Steps
- Node Interface Framework
- Representing Particle Systems with Nodes
- Particle System Code Architecture
- Updated Particle Nodes UI
- Updated Particle Nodes UI 2
- Particle Nodes Core Concepts
- Unified Simulation System Proposal
- Function System