Baking Simulations — Bake simulations and manage cache files - Blender

SECTION 1

Historical Context & Motivation

Physics simulation in 3D computer graphics has always faced a fundamental tension between computational cost and creative control. Early visual effects studios in the 1990s ran cloth, fluid, and particle simulations that could take hours or even days to compute, yet a single parameter tweak would invalidate the entire result and require a full recalculation. The concept of baking — pre-computing simulation data and writing it to disk as a persistent cache — arose from the practical need to separate the expensive solve phase from the iterative compositing and rendering phases of production.

Blender's simulation infrastructure has evolved significantly since its open-source release, incorporating increasingly sophisticated caching systems that mirror those found in proprietary packages like Houdini and Maya. Understanding this evolution helps contextualize why baking is not merely a convenience feature but a critical part of any simulation-based production pipeline.

2000 • Early Particle Systems

Blender 2.0 introduced basic particle emitters with no persistent caching. Every playback recomputed the simulation from scratch, making complex effects impractical for animation.

2008 • Smoke & Fluid Baking

Blender 2.48 added volumetric smoke simulation and improved fluid baking to disk. Smoke used .bphys point caches, while the fluid solver (Elbeem) wrote its own binary cache format — enabling artists to store solved frames and scrub timelines freely. OpenVDB did not yet exist at this time; it was publicly released by DreamWorks in 2012.

2013 • Unified Physics Panel

Blender 2.66 consolidated cloth, soft body, and rigid body simulations under a shared physics properties panel, standardizing the bake workflow across simulation types.

2020 • Mantaflow Integration

Blender 2.82 replaced the legacy fluid solver with Mantaflow, introducing modular cache management with separate data, mesh, and particle cache layers for smoke, fire, and liquid simulations. This release also brought full OpenVDB (.vdb) support for volumetric caches.

2023 • Geometry Nodes & Simulation Zones

Blender 3.6 introduced simulation zones in Geometry Nodes, extending baking concepts to procedural node-based systems and enabling entirely new cache paradigms for custom solvers.

The central question this lesson addresses is both practical and conceptual: how does one transform a volatile, frame-dependent physics calculation into a stable, portable dataset that can be reliably rendered, shared across a team, and archived for future iterations? The answer lies in mastering the bake-and-cache workflow — a workflow that governs every simulation type in Blender.

SECTION 2

Core Principles & Definitions

Before diving into specific workflows, it is essential to establish a shared vocabulary and understand the foundational ideas that underpin simulation baking in Blender. Every simulation system in the software — whether it handles cloth draping over a character, rigid bodies colliding in a destruction sequence, or fluid pouring into a glass — relies on the same core loop: a solver steps through time, computing forces and positions frame by frame, and the results are either held temporarily in memory or permanently committed to disk as a cache.

Simulation Solve

The computational process where Blender's physics engine evaluates forces, constraints, and collisions at each frame. This is the most time-intensive phase and produces raw per-frame state data.

Baking

The act of committing the solved simulation data to a persistent store — either in the .blend file's internal memory or as external files on disk. Once baked, the simulation can be played back without re-solving.

Cache Files

The on-disk data containers holding baked simulation results. Formats vary by simulation type: point caches (.bphys) for particles, OpenVDB (.vdb) for volumetrics, and Alembic (.abc) for mesh sequences.

Cache Invalidation

When a parameter that affects the simulation is changed after baking, the cache becomes invalid. Blender flags stale caches, requiring the artist to free the bake and re-solve to reflect new settings.

Frame Range & Resolution

Every bake is bounded by a start and end frame and may be influenced by a resolution divisor (for fluids) or substep count (for cloth/particles) that controls the temporal and spatial fidelity of the cache.

✦

KEY TAKEAWAY

Think of baking as rendering your physics. Just as you render an image sequence to avoid re-computing lighting every time you review a shot, baking a simulation writes out the solved motion data so you can scrub, composite, and render without waiting for the solver. The cache file is to the simulation what the EXR file is to the render — a frozen snapshot of expensive computation.

A critical distinction for production work is the difference between internal caching (data stored within the .blend file) and external caching (data written to a folder on disk). Internal caches are convenient for small simulations and personal projects because everything lives in one file. External caches, however, are essential for team workflows, large datasets, and render farms because they decouple the simulation data from the scene file, allowing multiple artists or machines to access the same cached result without transferring a bloated .blend.

SECTION 3

Visual Explanation — The Baking Pipeline

The following diagram illustrates the complete baking pipeline from simulation setup through cache management. Each stage represents a discrete step that you will encounter in Blender's Physics Properties panel, and the arrows indicate the directional flow of data — from solver to cache, and from cache to render engine.

The baking pipeline flows from left to right: Setup (define physics type and parameters), Solve (compute frame by frame), Bake (write to cache), and Playback/Render (read from cache). The Cache Management Zone shows the iterative loop of freeing, modifying, and re-baking that characterizes production work.

Notice that the pipeline is not purely linear. The Cache Management Zone introduces a feedback loop — a reality of production work where artists iterate repeatedly. When you change a collision object's position or alter the viscosity of a fluid, Blender marks the existing cache as stale. You must explicitly free the bake (delete the old cache data), adjust your parameters, and then re-bake. This deliberate invalidation model protects you from accidentally rendering with outdated simulation data — a mistake that in professional studios can waste hours of render-farm time.

SECTION 4

How Baking Works Under the Hood

While Blender abstracts much of the complexity behind a single "Bake" button, understanding the underlying mechanism deepens your ability to diagnose problems, optimize performance, and make informed decisions about cache strategies. At its core, baking is a serialization process — the solver's in-memory state is converted into a structured data format and written to storage.

The Frame Loop

When you click "Bake," Blender enters a sequential frame loop beginning at the cache's start frame and ending at the end frame. At each frame, the solver evaluates the physics equations for that timestep, considering all forces, collisions, and constraints. Crucially, simulations are temporally dependent — frame 50 cannot be computed without first solving frames 1 through 49, because each frame's state depends on the previous frame's result. This is why you cannot bake arbitrary frame ranges out of order, and why a partial cache break at frame 100 invalidates everything after it.

TEMPORAL DEPENDENCY

S(t) = f( S(t−1), F(t), Δt )

Where S(t) is the simulation state at frame t, S(t−1) is the previous frame's state, F(t) represents all forces acting at time t, and Δt is the timestep. This recursive dependency means baking must proceed sequentially.

Cache Size Estimation

For production planning, estimating cache size is important. The total disk footprint of a baked simulation depends on the amount of data per frame multiplied by the number of frames. For particle systems, each particle stores position (3 floats × 4 bytes), velocity (3 × 4 bytes), and additional attributes, while fluid simulations store full 3D voxel grids whose size scales with the cube of the resolution divisor.

CACHE SIZE — PARTICLES

Cache ≈ N × D × F

Where N is the number of particles, D is the data per particle per frame (typically 24–48 bytes), and F is the total number of frames.

CACHE SIZE — FLUID VOLUMES (DENSE UPPER BOUND)

Cache ≈ R³ × C × B × F

Where R is the effective voxel resolution per axis, C is the number of data channels (density, velocity, temperature, etc.), B is bytes per value (typically 4 for float32), and F is the frame count. Note the cubic scaling: doubling resolution increases cache size by roughly 8×. This formula assumes a dense voxel grid and therefore represents a worst-case upper bound. Mantaflow's OpenVDB caches use sparse voxel storage, meaning voxels in empty regions of the domain are not written to disk — actual file sizes can be substantially smaller than this estimate, especially when the fluid or smoke occupies only a fraction of the bounding volume.

⚠

Production Warning

A fluid simulation at resolution 256 with 5 data channels across 250 frames could produce up to roughly 80 GB of cache data if the entire domain were filled with fluid (dense storage). In practice, Mantaflow writes OpenVDB sparse caches, so simulations with large empty regions will consume significantly less disk space than this dense estimate. Always estimate using the dense formula as a safe upper bound, verify actual sizes after a short test bake, and ensure your storage can handle the worst case. Use the resolution divisor to create low-res preview bakes before committing to final resolution.

SECTION 5

Detailed Breakdown — Cache Types & Management

Different simulation systems in Blender produce different types of cache data, and understanding these distinctions is critical for managing disk space, organizing project directories, and collaborating with other artists or departments. The following diagram provides a classification of cache types organized by simulation category.

This taxonomy diagram organizes Blender's cache types into three families: Point Cache (.bphys) for particle and deformable simulations, Volume Cache (.vdb) for gas and liquid domains, and Mesh Cache (.abc) for geometry export. The bottom panel shows the four primary cache management operations available in Blender.

Cache Directory Structure

When you set an external cache path, Blender creates a folder structure that organizes cache files by object name and simulation type. A well-organized cache directory is essential for team workflows. A typical Mantaflow fluid bake generates three sub-caches within the domain's folder: data (the volumetric simulation data), mesh (the generated liquid mesh), and particles (spray, foam, and bubble secondary particles). Each sub-cache must be baked independently, and they must share the same frame range to remain synchronized. Failure to bake all three results in partial or invisible fluid renders — a common pitfall for artists new to Mantaflow.

Simulation Type	Cache Format	Typical Size / Frame	Key Notes
Cloth / Soft Body	`.bphys`	50 KB – 2 MB	Stores vertex positions per frame; size scales with mesh density
Particle Emitter	`.bphys`	100 KB – 10 MB	Linear scaling with particle count; velocity & rotation optional
Rigid Body	`.bphys` or keyframes	Minimal (~5 KB)	Can bake to F-curves for editing in Graph Editor
Smoke / Fire	`.vdb`	10 MB – 500 MB	Cubic scaling with resolution; use adaptive domain to reduce
Liquid (Mantaflow)	`.vdb` + `.obj/.bobj.gz`	50 MB – 2 GB	Separate data, mesh, and particle bakes required
Geometry Nodes Sim	Internal or `.blend`	Variable	New system (Blender 3.6+); bake via Simulation Zone panel

Cache format and size comparison across Blender simulation types

SECTION 6

Worked Example — Baking a Cloth Simulation

Let us walk through a complete baking workflow for a common visual arts scenario: a fabric curtain affected by wind, draped over a collision object. This example covers the full cycle from setup through cache management and demonstrates the decisions you will make in any baking workflow.

Baking a Wind-Driven Curtain Cloth Simulation

1
Step 1 — Prepare the Scene

Create a subdivided plane (at least 50 × 50 subdivisions) to serve as the curtain mesh. Position a passive collision object (a rod or sphere) behind it. Add a Cloth physics modifier to the plane via Properties Panel → Physics → Cloth. Set the preset to "Silk" for lightweight draping behavior. Add a Collision modifier to the rod/sphere object.

Scene contains one cloth object and one collision object, both with physics modifiers applied.
2
Step 2 — Configure Simulation Parameters

Under the Cloth settings, adjust Quality Steps to 8. This setting controls the number of solver substeps computed per frame — higher values increase constraint accuracy and simulation stability, which is especially useful for stiff fabrics or tight collision contact, though it also increases bake time. Enable a Force Field — Wind (Add → Force Field → Wind) and set its strength to 5. In the Cloth Cache panel, set the frame range to match your animation: Start = 1, End = 250.

Simulation is configured with silk preset, 8 quality steps, wind force at strength 5, and frame range 1–250.
3
Step 3 — Preview Bake (Optional but Recommended)

Before committing to a full bake, play the animation in the viewport (press Spacebar or Alt+A). Blender will compute the cloth simulation in real-time (or as fast as it can) and store the result in a temporary memory cache. This preview cache is volatile — it vanishes if you change any physics parameter. Use this step to verify the general motion looks correct before investing time in a full bake.

Temporary memory cache created; curtain drapes and billows as expected in viewport playback.
4
Step 4 — Set External Cache Path

In the Cache section of the Cloth physics panel, check External if you want to write .bphys files to disk (recommended for any scene you plan to render on a farm or share). Set the cache path to a project-relative directory, for example: //cache/cloth_curtain/. The // prefix tells Blender to use a path relative to the saved .blend file location.

Cache directory set to //cache/cloth_curtain/; external caching enabled.
5
Step 5 — Execute the Bake

Click the Bake button in the Cache panel. Blender will begin the sequential frame loop, displaying a progress bar. For a 50 × 50 mesh with 8 quality steps over 250 frames, expect approximately 2–5 minutes depending on hardware. Once complete, the cache directory will contain 250 .bphys files (one per frame). The "Bake" button changes to "Free Bake," indicating that the simulation data is now locked.

250 .bphys cache files written to disk. Simulation is baked and locked.
6
Step 6 — Iterate (If Needed)

If the result is not satisfactory — perhaps the wind is too strong — click Free Bake to delete the cached files and unlock the simulation parameters. Adjust the wind strength from 5 to 3, then click Bake again. Each iteration follows this free → modify → re-bake cycle. This is the cache management loop shown in the pipeline diagram.

Old cache freed; parameters adjusted; new bake initiated with updated settings.

💡

Pro Tip: Versioning Caches

Before freeing a bake you are happy with, consider renaming or copying the cache folder (e.g., cloth_curtain_v02). Blender does not version caches automatically, so manual backups are your safety net. In team environments, use a naming convention like projectname_simtype_objectname_v## to keep caches organized.

SECTION 7

Strengths, Limitations & Comparisons

Baking is not without tradeoffs. Understanding when to bake, when to rely on live preview caches, and when to use alternative approaches like Alembic export or bake-to-keyframes requires weighing several factors including disk space, iteration speed, portability, and render-farm compatibility.

Factor	Baked Cache (Disk)	Live Memory Cache
Persistence	Survives .blend reload, Blender restarts, and system reboots	Lost on file close, parameter change, or Blender crash
Render Farm Support	Fully supported — farm nodes read cache files without re-solving	Not supported — each node would re-solve independently, producing inconsistent results
Disk Usage	Can be very large (GB–TB for fluids)	Zero disk usage; stored in RAM
Iteration Speed	Slow — full re-bake required for parameter changes	Faster for quick prototyping — just play the timeline
Portability	Can be shared independently of the .blend file	Embedded in the session; not transferable
Timeline Scrubbing	Instant random-access to any baked frame	Only forward playback; backward scrub resets to frame 1

Comparison: Baked disk cache vs. live memory cache

🎯

WHEN TO BAKE

A useful rule of thumb: prototype with live cache, commit with baked cache. Use the memory cache during the exploratory phase when you are adjusting parameters frequently. Once the simulation looks right, bake to disk to lock the result. Think of it like sketching in pencil before inking — the sketch phase is fast and erasable, but you eventually need a permanent, reproducible version for the final piece.

Bake-to-Keyframes vs. Bake-to-Cache

Rigid body simulations offer a unique option: Bake to Keyframes (found under Object → Rigid Body → Bake to Keyframes). Instead of writing cache files, this converts the simulation into traditional location and rotation keyframes on each object's F-curves. The advantage is that you can then manually edit the motion in the Graph Editor — nudging a bouncing box's final resting position, for instance. The disadvantage is that the simulation's physical accuracy is lost once you begin editing individual curves, and the approach does not scale well to scenes with hundreds of rigid bodies.

SECTION 8

Connections to Advanced Workflows

The baking concepts covered thus far form the foundation for more advanced simulation workflows that you will encounter as you progress in visual effects production. Two major areas extend naturally from this lesson: Geometry Nodes simulation zones and cross-application cache pipelines.

Aspect	Traditional Physics Baking	Geometry Nodes Sim Zones
Solver	Built-in solvers (Mantaflow, Bullet, Cloth engine)	Custom node graphs — you design the solver logic
Cache Location	External disk (.bphys, .vdb) or internal	Baked into the .blend file; external bake in development
Bake Trigger	Dedicated "Bake" button in Physics panel	"Bake" button on the Simulation Zone node group in Sidebar
Flexibility	Fixed to predefined simulation types	Unlimited — any procedural effect can be frame-cached
Maturity	Stable, production-proven	Newer feature; API evolving with each Blender release

Traditional physics baking vs. Geometry Nodes simulation zones

The OpenVDB format deserves special mention as a bridge to cross-application workflows. Because OpenVDB is an open-source industry standard maintained by the Academy Software Foundation, smoke and fire caches baked in Blender can be imported directly into Houdini, Nuke, or any VDB-compatible renderer. Similarly, Alembic (.abc) serves as the universal mesh-cache format for exchanging animated geometry between Blender, Maya, Cinema 4D, and Unreal Engine. As a visual arts student, developing fluency with these interchange formats positions you to work effectively in multi-software studio environments.

ℹ

Looking Ahead

Future lessons will explore adaptive domain techniques for reducing fluid cache sizes, resumable baking strategies for long-running simulations, and distributed simulation where multiple machines collaborate on a single cache. Mastery of the fundamentals in this lesson is a prerequisite for all of these advanced topics.

SECTION 9

Practice Problems

The following problems test your understanding of simulation baking concepts, cache management, and production decision-making. Work through them in order; they progress from conceptual understanding to applied critical analysis.

Question 1: CONCEPTUAL

Explain why Blender's physics simulations are temporally dependent. What property of the simulation solver makes it impossible to bake frame 200 without first computing frames 1 through 199?

Show answer

Physics simulations are temporally dependent because each frame's state is a function of the previous frame's state — the solver applies forces, resolves collisions, and updates velocities incrementally. The state equation S(t) = f(S(t−1), F(t), Δt) makes this explicit: you cannot know where a cloth vertex is at frame 200 without tracing the entire chain of forces from the initial rest position. This is fundamentally different from procedural animation or keyframe interpolation, where any frame can be evaluated independently. The sequential dependency is why baking always proceeds frame-by-frame from start to end, and why modifying a parameter at any point invalidates all subsequent cached frames.

Question 2: BASIC CALCULATION

A particle emitter spawns 50,000 particles over 300 frames. Each particle stores position and velocity data (6 floats × 4 bytes = 24 bytes per particle per frame). Estimate the total cache size in megabytes if all particles are alive for the entire duration.

Show answer

Using the formula Cache ≈ N × D × F: Cache = 50,000 particles × 24 bytes × 300 frames = 360,000,000 bytes = 360 MB. In practice, particles may have additional attributes (rotation, size, age), which could increase this to 400–500 MB. Additionally, not all particles may be alive for the full 300 frames if they have limited lifetimes, which would reduce the total. This estimation helps you assess whether your project's storage can accommodate the bake before committing compute time.

Question 3: INTERMEDIATE

You are working on a Mantaflow liquid simulation with a resolution of 128. The art director asks you to double the resolution to 256. How does this change affect: (a) the per-frame cache size, (b) the total bake time (approximately), and (c) your storage requirements for a 200-frame simulation? What mitigation strategy could you use to manage the increased demands?

Show answer

(a) Per-frame cache size scales with R³ for a dense voxel grid, so doubling resolution from 128 to 256 increases the voxel count by a factor of 2³ = 8. If a single frame at resolution 128 was 50 MB under dense storage, at resolution 256 it would be approximately 400 MB at the same density. However, because Mantaflow uses OpenVDB sparse voxel caches, actual on-disk sizes depend on how much of the domain is occupied by fluid — frames where fluid fills only a small portion of the domain will be much smaller than the dense estimate. (b) Bake time also increases roughly 8× for the fluid solve computation itself, potentially more when mesh generation and secondary particles are included. (c) For 200 frames: the dense upper bound for the data cache alone would be up to 400 MB × 200 = 80 GB, plus mesh and particle sub-caches could bring the worst-case total to 100–150 GB; sparse VDB storage will typically yield a smaller actual footprint. The primary mitigation strategy is to use the adaptive domain feature, which shrinks the simulation volume to only the region where fluid is present rather than computing the entire bounding box. Additionally, you could bake a low-resolution (64) preview first, confirm the motion, and only commit to 256 for the final version.

Question 4: APPLIED

You are preparing a scene with a cloth curtain, a rigid body chandelier, and a smoke simulation for a short film. The scene must render on a farm of 20 machines. Describe your complete cache management strategy: which simulations do you bake, in what order, where do you store the caches, and how do you ensure the farm nodes can access them?

Show answer

First, establish a shared network directory accessible to all 20 render nodes (e.g., a NAS or shared drive). Set all external cache paths to this shared location using project-relative paths, converting to absolute paths if the .blend file itself lives on the shared drive. Bake in dependency order: (1) Rigid body chandelier first, since it may act as a collision object for cloth; (2) Cloth curtain second, so it can respond to the chandelier's motion; (3) Smoke simulation last, since it may be influenced by the curtain's motion or may need to respect the chandelier as an obstacle. Each bake should use clearly named cache folders (e.g., //cache/rigidbody_chandelier/, //cache/cloth_curtain/, //cache/smoke_room/). After baking, verify that all cache files are readable from a test farm node before submitting the render job. Avoid internal caches entirely — farm nodes opening the .blend will not have access to session memory. Finally, lock the .blend's physics parameters (or save a dedicated render version) to prevent accidental cache invalidation.

Question 5: CRITICAL THINKING

Blender's Geometry Nodes simulation zones (introduced in 3.6) allow users to build custom simulation logic that can also be baked. Compare and contrast this approach with the traditional physics baking system in terms of artistic flexibility, cache portability, and potential risks. Under what circumstances might a visual arts student prefer one system over the other?

Show answer

The traditional physics system offers battle-tested solvers for well-defined phenomena (cloth, fluids, rigid bodies) with established cache formats (.bphys, .vdb) that are portable across applications. Its limitation is rigidity — you cannot easily create novel physical behaviors outside the predefined solver categories. Geometry Nodes simulation zones, by contrast, offer virtually unlimited flexibility: any attribute can be iteratively modified across frames, enabling custom growth systems, flocking behaviors, or abstract procedural animations that have no equivalent in the physics panel. However, this flexibility comes with risks: the Geo Nodes bake system stores data internally in the .blend file (external baking support is still maturing), making large simulations impractical for team workflows. Additionally, the custom solver logic lacks the physical accuracy guarantees of dedicated engines like Mantaflow or Bullet. A visual arts student should prefer traditional baking when the simulation matches a known physical phenomenon and production portability matters, and should prefer Geometry Nodes when the effect is artistically driven, non-physical, or requires procedural control that the built-in solvers cannot provide. In many productions, both systems are used in tandem.

SUMMARY

Lesson Summary

Summary

Baking is the process of committing a Blender simulation's solved state to persistent cache files, eliminating the need for re-computation during playback and rendering. The three primary cache formats — .bphys for point-based simulations like cloth and particles, .vdb (OpenVDB) for volumetric smoke and fluid data, and .abc (Alembic) for mesh sequence exchange — each serve distinct roles in a production pipeline. Simulations are temporally dependent, meaning every frame relies on the previous frame's state, which is why baking always proceeds sequentially and why parameter changes invalidate downstream cached frames.

Effective cache management involves choosing between internal and external cache directories, estimating storage requirements (especially for fluid simulations where cache size scales with the cube of resolution as a dense upper bound, with Mantaflow's sparse OpenVDB storage often yielding smaller actual sizes), and following an iterative free → modify → re-bake cycle. For render-farm workflows, always bake to external disk caches on a shared network path. As Blender evolves, Geometry Nodes simulation zones extend baking concepts to custom procedural solvers, opening new creative possibilities while the traditional physics baking system remains the production standard for physically based effects.