Planning Brief // Render Time EstimateA render time estimate is usually wrong because it is based on one frame, while frames in a sequence cost very
Planning Brief // Render Time Estimate
A render time estimate is usually wrong because it is based on one frame, while frames in a sequence cost very different amounts.
- Sample Three Frames: Time a light, an average and a heavy frame instead of frame one.
- Weight the Average: Multiply each sample by how many frames of that type exist; in the worked example below this turns a 12.5 hour guess into about 46 hours.
- Add Overhead: Loading, denoising, writing and re-renders add time; 10 to 15 percent is a placeholder until you measure your own.
- Plan Capacity Early: If one machine cannot make the deadline, decide on extra machines at planning time. See our render farm ranking.
A render time estimate is usually too low because people time frame one, see a short number and multiply it by the frame count. Frame one is often among the cheapest frames in a shot. The method below replaces that guess with a weighted estimate you can defend to a client.
Why is a render time estimate based on one frame wrong?
Frames in a sequence differ in cost. Close-ups with heavy reflections, volumetrics and large simulations can take several times longer than calm frames, and if they cluster in one part of the shot a flat average hides them. The table lists the usual reasons estimates miss.
| Why estimates miss | The fix |
|---|---|
| Tested on one calm frame | Sample a light, an average and a heavy frame |
| Heavy frames cluster in one section | Weight the average by how many frames fall in each group |
| Fixed overhead forgotten (scene load, denoise, file write) | Add a per-frame overhead on top of render time |
| Multi-GPU or multi-machine scaling assumed perfect | Use measured scaling, not a clean multiple |
| Failed frames and restarts ignored | Add a contingency for re-rendering |
How do you estimate render time for a sequence?
Render three sample frames, count how many frames resemble each, calculate a weighted total, then add overhead. Follow these steps:
- Render the lightest frame, a typical mid-sequence frame and the heaviest frame at final settings.
- Count roughly how many frames fall into each of the three groups.
- Multiply each sample time by its frame count and add the three results.
- Add per-frame overhead for loading, denoising and writing. If you have not measured it, use 10 to 15 percent as a placeholder.
- Add a contingency for failed frames, then divide by the number of machines for wall-clock time.
The 10 to 15 percent figure is a rule of thumb, not a measured value; time your own scene load and file write from the render log to replace it.
Worked example: 500 frames
Take a 500-frame shot where 100 frames are light at 1.5 minutes, 280 are average at 4 minutes and 120 are heavy at 10 minutes. These numbers are illustrative, not measurements.
| Group | Frames | Minutes each | Total minutes |
|---|---|---|---|
| Light | 100 | 1.5 | 150 |
| Average | 280 | 4 | 1,120 |
| Heavy | 120 | 10 | 1,200 |
| Sum | 500 | 2,470 (about 41.2 hours) |
A flat estimate from frame one (1.5 minutes x 500) gives 750 minutes, or 12.5 hours. The weighted total is 2,470 minutes. Adding 12 percent overhead gives about 46.1 hours on one machine. Spread evenly over 8 machines, that is about 5.8 hours of ideal wall-clock time, before upload, start-up and uneven frame distribution.
Does more GPUs mean proportionally less render time?
Not exactly. Sending different frames to different machines scales closely because the frames are independent, but fixed per-frame costs such as scene loading do not shrink, and the last few long frames can leave machines idle. Several GPUs working on one frame scale less cleanly. This is our reasoning from how the work is divided; measure scaling on your own scene before promising a deadline. Puget Systems’ December 2025 study found that short scenes dominated by per-frame setup overhead gained little from faster GPUs, which is why fixed costs belong in your estimate (Rendering Benchmarks vs Reality). If a proper estimate says one machine will not make it, add capacity at planning time. Our overnight render recovery guide and animation render crash guide cover failures that blow estimates, and the top 10 render farms ranking compares ways to add machines.
FAQ
Why is my render time estimate always too low?
Most estimates are built from one calm frame, but heavy frames can take several times longer. Sample a light, an average and a heavy frame, weight them by how many frames of each kind you have, then add time for loading, denoising, writing and failed frames.
How do I estimate render time for a sequence?
Render the lightest, a typical and the heaviest frame. Count roughly how many frames fall in each group, compute a weighted total, add per-frame overhead and a contingency, and divide by the number of machines for wall-clock time.
Does adding more GPUs cut render time in proportion?
Not always. Splitting different frames across machines scales closely, while fixed per-frame costs such as scene loading, upload and start-up do not shrink. Several GPUs on a single frame scale less cleanly.
COMMENTS