Currently, one of our primary goals for Geometry Nodes is to get to a point where we can build high level and easy to use node group assets for physics simulations. Our general approach was described briefly last year. The goal of this document is to go into a bit more detail.
For the examples below I’ll use a particle simulation because it’s the easiest, but the same applies to many other simulation types like hair, cloth and fluids.
Two Different Views
There are two different ways to look at a particle simulation:
- Declarative view: Describe the intended behavior of the particles by combining various existing behaviors like emitters, forces, colliders, surface attachment and more.
- Imperative view: Describe the computation steps to simulate the particles. Such steps are for example “integrate forces”, “update positions”, “find collision points”, etc.
Both are totally valid views at a particle simulation, but depending on what you’re trying to achieve exactly, one view is more practical than the other. Most particle simulations can be described using a combination of various behaviors in which case the declarative view is more practical, but when you’re building a particle system from scratch or have custom needs, the imperative approach works better because it has more flexibility at the cost of dealing with low-level details.
Current State
Geometry Nodes is already quite decent at building particle systems using the imperative approach. Obviously, there are various missing built-in features to really be able to tackle any kind of simulation, but the overall structure is there.
Building particle systems using the declarative approach by combining a set of behaviors is much harder, because it requires creating node groups that describe a certain behavior which are passed to a “solver” which performs the actual computations in the right order.
Goal
We are working towards various core features (bundles, closures, lists) that together will allow building declarative systems. The image below shows how individual behaviors could be encapsulated by node groups. All behaviors have the same type which allows easily combining them to form higher level behaviors. Also note that the order in which they are passed to the particle solver is largely irrelevant.
This approach to building particle solvers allows someone to focus on building the actual solver that exposes a specific interface while anyone else can just build and combine behaviors for that solver without worrying too much about how it works internally.
Since all behavior node groups have a very similar structure (various inputs, one behavior output), we can also build a higher level UI for managing them. For example, if the Particle Solver node group is used as modifier, the UI could look like in the following mockup. Note that each panel corresponds to one behavior and that an arbitrary number of behaviors can be added. The individual behaviors would be node group assets coming from an asset library.
Of course one always has more flexibility in the node editor, but this kind of UI should be capable of solving the most common needs without requiring the node editor at all.
Lastly, this approach of using declarative systems also simplifies creating add-ons that have a custom high level UI for some node tree. That’s because it’s way easier to write code that merges a few behaviors together automatically, than it is to edit potentially deeply nested node groups.
Beyond Simulations
As mentioned, this behavior-based approach works well for all kinds of physics simulations. However, using declarative systems also makes sense in other cases where the user thinks more about the what and not the how.
One example for such a system is Line Art. A potential Line Art node is supposed to generate curves based on various features (e.g. silhouette, non-occluded edges and intersections). Here again, the user does not really care about how the curves are computed exactly, but only what kind of curves are expected. One could build node groups describing the different kind of curves, pass these to the Line Art node which then outputs all the requested curves.
Something similar could be done for landscape generation, where behaviors encapsulate terrain features or asset scattering rules.
There is always a bit of a trade-off when choosing between the imperative and declarative approach, but for high level tools used by potentially millions of people, the declarative approach is often better because it significantly reduces the cognitive load at the cost of a little less flexibility.
How do Bundles and Closures fit in?
Bundles and closures are currently an experimental feature. They have many interesting uses on their own, but the primary reason for why we are working on them is to allow building these declarative systems.
You can check out the pull request for more details, but in short a Bundle allows passing multiple values along using a single link and a Closure allows passing around functions that can be evaluated anywhere.
Each individual behavior will generally be encapsulated as a bundle. The exact structure of that bundle is determined by the solver that uses the behavior. For example, a very basic mesh particle emitter could look like in the image below. Note that the Type in the bundle will be used by the solver to figure out what kind of behavior this is. The solver will call the Emit callback to actually create the new particles. The inputs and outputs of the callback are also determined by the particle solver.
Closures are a fundamental feature to make this whole system work, while at the same time being a fairly niche feature that most people will not have to know about. Most people will just use systems that heavily rely on closures under the hood to be able to provide a good high level user interface.
Feedback can be posted in the corresponding forum thread.
