2022-03-10 Nodes & Physics Workshop

Nodes & Physics Workshop

During the week of March 6 to 10 there was a Geometry Nodes / Physics at the Blender HQ. The focus of the workshop was to clear the way for Simulation Nodes and Physics.


  • Dalai Felinto
  • Jacques Luckes
  • Lukas Tönne

Now that Lukas started working in Amsterdam, the plan is to leverage that by focusing on the parts of the project that requires a lot of design iteration with the artist (such as real-time physics).

Simulation Nodes

  • 3.6 initial release milestone added to #103032, they are:
    • Simulation starts on scene start frame (no pre-rolling).
    • Get sockets and anonymous attributes to work
    • Store simulation on disk (see #105251)
    • Bake simulation using render settings (i.e., the “is viewport” node will return false)
    • Design document for when to free dynamic cache:
      • It should free whenever the user expects it to.
      • But it needs to be clearly defined on paper first.
    • Dynamic cache (the cache created automatically when playbacking the animation).
    • Simulation (and loop) background color.
    • Documentation.
  • What happens next will be decided once this is merged in main.
  • Design for the “Simulation Disk Cache Format” #105251.

Real-time (physics) clock

The discussions narrowed down the MVP, the User Interface and the scope of the features.

  • The main topic was about cache and controlling the playback (and pause/reset) of the simulation.
  • Design:
    • Settings (sub-steps, attach/detach from animation timeline) are on the scene level.
    • Initially support only simulation nodes (not mantaflow, rigidbodies, cloth).
    • When rendering or baking, the real-time clock maps to the animation clock.
    • Option (in timeline) to detach simulation from timeline.
    • If detached we can control the simulation indepedently of animation playback.
    • Example of control: play/pause/stop/reset.
  • Follow-up:
    • Design on where the play/pause buttons are.


  • Cancel geometry-nodes execution
    • Sometimes the user may tweak a parameter leading to a very slow calculation.
    • One idea was to support users to cancel this execution.
    • This has a few implications and complications.
    • Instead we will support ctrl+z a way to immediatelly undo.
    • This should work even if the heavy operation may still be in progress.
  • Simulation background name
    • So far the background connecting the simulation nodes were been referred as region.
      • e.g., “Simulation Region”, “Loop Region”
      • Region is already something else in Blender, so we tried to come up with a different name.
    • We decided on “zone” (simulation zone).

Attribute editing

  • There is no need for an exclusive editor until 4.0 (use mesh/curve edit mode for now)
  • For 3.6 having node-based operators with access to active attribute is enough.
  • For 4.0 we can try to have the initial MVP for Attribute Edit mode:
    • Selection tools
    • At least vertex, edge and face domains
    • Set attribute operators
    • Attribute overlay
    • Transform attributes (G: offset values; S: scale values)
    • Assign ID (e.g., Face is of type Door)
  • A future milestone would be to support Technical Painting
    • Vertex paint obsolete/removed
    • Weight paint exclusive for rigging

Node operator design

  • Real-case examples:
    • Smooth operator
  • Initial constraints:
    • Consider to support only Selection
    • Design should account for more inputs
    • The main discussion was between allowing or not nesting the mapping
  • Findings:
    • There were two main scenarios considered:
      • I. Mapping as part of the node-tree
        • The operator specific inputs are available as regular nodes
        • The operator inputs always show up in the node-group as inputs
        • Those inputs fallback to the same original inputs (e.g., selection)
      • II. Explicit separation between mapping and operation (logic)
        • Allow a node-tree to have different maps, for different usages
        • The mapping itself is not nestable

Really like that talk about cashing/baking for simulation!
Hope I’m not too ignorant on this topic, but I always believed that because bakes created in blender can only be used in blender, there is no point in creating new unique file formats for different types of bakes, and store every frame as a different file, etc… I really don’t want blender to create files in my computer that i didn’t specifically ask for.
If possible, the cleanest way to go is to make them datablocks in .blend files.
By the users choice (Simulation node properties, N panel), bakes could either be held in the same .blend file as the user is currently working in (Though that is not always a good idea), or saved in an external .blend file (Specific location set in N panel), from which they are then read from and linked in.

Of course, all bakes could also be imported through File > Appen/Link.


@FreeMind There are a couple of problems with storing baked simulation state in standalone .blend files:

  • Parts of the simulation state often remain the same over multiple frames, it shouldn’t be necessary to store the same data multiple times. This is especially bad in common case where people create trails using simulation nodes.
  • Not all simulation state maps easily to data blocks. It works fine for an individual mesh or so, but less so for instances or single values that could be simulated as well.
  • The .blend file format is not really optimized to be read from disk in real-time.

But can bakes be packed in the current .blend file instead of linked to an external one?
The next best thing is to create one specific new file format for blender geometry bakes, if the user wants to keep them externally. One for each bake, or one for multiple bakes. Not one for every frame!