// undine docs
Workflow
A typical Undine simulation follows a structured pipeline.
This chapter documents that pipeline at a high level so readers can understand where each reference page fits.
Panel order
The Undine panel is organized around the order most users follow while building a liquid shot.
Objects assigns scene roles, Actions runs and manages cached results, Sim Params controls solver behavior, Meshify creates renderable surfaces, and Other is reserved for supporting visual systems such as Whitewater FX.
| Panel | Primary task | Typical moment |
|---|---|---|
| Objects | Tag active Blender objects as Domain, Emitter, or Collider. | Scene setup |
| Actions | Set frame range, bake animated colliders, run simulation, review playback, and launch meshing. | Execution |
| Sim Params | Choose fluid presets and tune forces, numerics, pressure, density, particles, and viewport limits. | Look development and stability tuning |
| Meshify | Convert cached primary water particles into surface meshes with preset, quality, backend, and expert controls. | Final output |
| Other | Enable Whitewater FX, choose a secondary-particle preset, and tune visual emission budgets without changing the primary solve. | Project-specific visual utilities |
Simulation pipeline
1. Scene Configuration
The user defines the simulation domain and configures emitters and colliders in the Objects tab.
The Tagged in Scene counter gives immediate feedback about how many domains, emitters, and colliders are currently assigned.
2. Particle Generation
Emitters generate fluid particles that represent the simulated liquid.
3. Simulation Steps
Each simulation step executes a sequence of solver stages that update the particle state for each time step.
- Advection
- Boundary interaction
- Viscosity solving
- Pressure projection
- Particle redistribution
4. Surface Reconstruction
After simulation, cached particle data can be converted into a surface mesh through the Meshify pipeline.
This stage transforms the primary water particle distribution into a continuous surface that approximates the shape of the simulated liquid. Secondary whitewater particles are deliberately excluded from Meshify.
4b. Whitewater Review
When Whitewater FX is enabled, spray, foam, and bubbles can be previewed as separate colored point layers in Blender. These layers enrich impacts, wakes, and aerated areas without feeding forces or volume back into the solver.
The secondary cache is stored separately from the primary particle cache, so it can be reviewed or reloaded independently.
5. Review, store, or discard
The resulting mesh can be stored when the result is acceptable or discarded when the mesh build should be rejected.
Once stored, the mesh can be rendered using Blender's rendering engines.
Action-state workflow
The Actions tab changes as data becomes available. A clean scene starts with Run, Stop, and Cancel controls; after cached frames exist, a PLAYBACK block and Meshify command become available; during meshing, progress is shown as a triangle count and frame counter.
Common state transitions
- Run simulation -> playback cache appears.
- Playback cache -> MESHIFY SIMULATION becomes available.
- Meshify in progress -> STOP MESHIFY NOW becomes available.
- Meshify result pending -> Store and Discard become available.
- Clear playback -> cached preview frames are removed from the current panel state.
Pipeline Structure
Undine is designed around a modular simulation pipeline where each subsystem is responsible for a specific part of the simulation process.
Each stage performs a specific transformation of the simulation state rather than mixing unrelated responsibilities into a single step.
Maintainability
This staged architecture improves the maintainability of the codebase because each subsystem can evolve independently without destabilizing unrelated parts of the solver.
Targeted improvements
It also allows targeted improvements to individual stages without requiring structural changes to the entire pipeline.
Debugging and validation
Finally, it simplifies debugging and validation because each stage has a clearly defined responsibility within the simulation step.