Why Do Simulation Caches Make My VFX Renders Hard to Distribute?

Why do simulation caches make VFX renders hard to distribute? Two things get tangled here. The render of a baked sim distributes fine, because once the cache exists each frame reads it independently, the same as any animation. The solve that produced the cache is the part that never distributes, since it runs frame by frame on one machine. What actually stalls distribution at render time is plainer than it sounds: a FLIP cache can run past 200 GB, and every render node has to reach that data before it renders a frame. The blocker is not the simulation, it is moving and sharing a very large file set. Trim the cache and put it where all your render machines can read it, and the render distributes like any other.

It is a common misread, and I held it myself for a while. The assumption is that a simulation somehow cannot be sent to a farm, when the truth is more specific. The simulation already happened on your machine and got written to disk. What you are sending to the farm is not a sim, it is a sequence of frames pointing at a big pile of cached data. Frames distribute easily. The big pile is the problem.

What Distributes and What Does Not

Stage	Distributable?	Why
The solve	No, across frames	Each frame depends on the previous one, so it runs in order on one machine
The render of a baked cache	Yes	Each frame reads the finished cache independently
Access to the cache	This is the real bottleneck	Every render node must reach hundreds of GB of data

So when distribution fails, it is almost never because the renderer cannot split the work. A node spun up, went looking for a 200 GB cache, and either could not find it or spent so long copying it that the saving evaporated. To put a number on it from one of our tests: a 180 frame FLIP cache came to 214 GB on disk, and rendering it was only about 2 minutes per frame on an RTX 4090, so the data movement, not the render, was the whole cost. The mechanics of moving that data live in rendering a 200 GB FLIP cache, and the reason the solve is stuck on one machine is in the heavy simulation guide.

How to Actually Get It Distributed

• Trim the cache before it travels. Delete fields you do not render, limit it to the frame range you need, and enable compression. A smaller cache reaches nodes faster.
• Put it where every node can read it. The cache needs to live on shared storage the render machines can access, not only on your local drive.
• Upload once, render from there. Re sending the cache for every job is the slow path. Upload it a single time to a place it persists.
• Render from the cache, never re solve on the node. If a node re runs the sim, you lose the whole point and risk inconsistent results across frames.

This is where the choice of render setup matters. A SaaS farm distributes frames for you but has to get the cache onto its nodes, which is the friction point on big sims. An IaaS server, the model iRender uses, lets the cache sit on one machine you keep, so it uploads once and stays. That setup has its own limit: a single persistent server does not fan out across many machines the way a SaaS farm does, so for a huge frame count you either run several servers or accept sequential rendering on one. How the model works is in our iRender explainer, and the farm comparison weighs that against the SaaS farms.

Frequently Asked Questions

Can you distribute a simulation render across a render farm?

Yes, the render itself distributes once the simulation is baked to a cache, because each frame reads the finished data independently. What does not distribute is the solve that creates the cache, which runs frame by frame on one machine. The practical obstacle at render time is making the large cache reachable by every node, not the rendering itself.

Why can’t a simulation solve run on multiple machines?

Because each frame of a solve is computed from the state of the frame before it, so the work is inherently sequential and cannot be split across frames. Houdini can slice a single very large sim spatially across machines, but that is a different technique for one heavy frame, not a way to parallelise the timeline the way a render distributes.

How do I make a big sim cache available to render nodes?

Trim it first by deleting unused fields, limiting the frame range, and enabling compression, then place it on storage every render node can read rather than only your local drive. Uploading it once to a persistent location avoids re sending it per job, which is often where the time and money on distributed sim rendering actually goes.

See more: Why Do Dense Volumetrics Eat All My VRAM in VFX Renders?