Workshop from June 22 to 25 2021 in Amsterdam.
Participants: Dalai Felinto, Jacques Lucke.
Special Participants: Andy Goralczyk, Brecht Van Lommel, Pablo Vazquez, SimonThommes, Ton Roosendaal.
- Particle Nodes
- Attribute Processor
- Bonus: Page node
- Heap/stack attributes namespace
- Bonus: Selection/tagging
- Detached physics prototype requirements/specs.
- Nodes 3.0 targets
- Final compact nodes
- New node UI proposal
- Expression nodes.
(Proposal refuted, see v2.0 below)
“It is like compositor but for physics”.
- The physics context is the view layer - all visible collections interact among each other.
- The order of simulation is handled on the scene level by controlling which view layer is evaluated first.
- Each view layer with a single physics solver.
- Collections can be enabled/disabled in different view layers to exclude them from the simulation being baked.
Outcomes of the presentation:
- This system wouldn’t allow an asset to be brought over with all its simulation data (e.g., character with simulated cape) (because view layer is not a datablock).
- This can fit in a VFX pipeline, where the process is more linear and deal with the entire scene.
- However for simple asset-centric simulations (e.g., clothes, water fountain, character hair) it makes it complicated to connect the different simulation systems.
- It is also tricky to play a simulation that involves multiple solvers and tweak one of them, if the setting is in the view layer level.
New design round, presented to Brecht and Simon. To be presented to Ton Thursday 10:00 CEST after attributes processor.
- The solvers will be integrated in the pipeline in the Geometry Nodes level.
- Each solver node gets the geometry in and out, so it can be transformed with further nodes or even connected to a different solver.
- Solvers are ID blocks, which can be re-used in different geometry-nodes nodetrees. That means you can have multiple geometries interacting with each other in the same solver.
- In a View Layer level users can inspect (read-only) the dependency between the different solver systems and eventual circular dependencies. Their order is defined in the geometry-node trees though.
- Most of the solvers can be treated as a blackbox where objects get in and out.
- Colliders (and other solver specific settings) are defined on the object level.
- Particle Simulations are solvers that have their behaviour set with nodes.
- There are three different node types:
- On Init, On Collision, On Age
- Condition Gates
- If attribute > x, If colliding, And, Or, …
- Set Gravity, Keep Distance, Set Forces, Kill Particles.
- Similar to Geometry-Nodes, each Action node can either:
- Add a row to the spreadsheet (i.e., create new points).
- Add a column to the spreadsheet (i.e., create a new attribute).
- Edit a cell/row/column (i.e., set particle material).
- A solver can be baked into caches.
- In a similar way the nodetree can be frozen (stored in a cache), edited, and continue with more nodes.
- Both concepts are interchangeable, where we can get a node that reads from a cache (vdb, alembic, …) that can work the same way as if I had a solver node connected to the tree.
- Freezing can be for a “frame” too, not necessarily for the entire sequence.
The attribute processor discussion faced a few problems:
- The compact node is an issue for regular nodes as well, and attribute processor makes this problem even worse.
- Restricting “column” operations to happen only inside attribute processor.
- Attribute only nodes outside the attribute processor are not always intuitive and still require a lot of temporary attributes.
Design to be discussed on on Friday.
What if users could pass attributes around directly?
- Initial discussions about Solvers.
- Presented Solvers discussion, to no consensus.
- Elaborated solvers proposal 2.0, presented to part of the team.
- Prepared attributes processor presentation.
- Presented solvers 2.0, everyone was happy with it.
- Attribute processor discussion didn’t get consensus.
- Further discussions about alternatives (passing columns - list of attributes) directly in the node tree, without needing attribute processors.
- Passing attributes directly between nodes seems to be a consensus.
- The remaining design to be explored is whether this is done with Get/Set nodes that take strings OR as part of the node group Input/Output directly.
- Either way there should be ways to have no hard-coded strings in a nodetree.