How this instrument works
Total render time is the total workload -- the number of frames multiplied by how long each frame takes to render -- divided by however many render nodes are working on the job at once. A sequence that would take one machine days to finish can be split across a farm of workers so the wall-clock time drops in proportion to how many nodes are crunching frames in parallel.
This works because frame rendering is what computing calls an 'embarrassingly parallel' problem: each frame is calculated independently of every other frame, with no data dependency between them, so a queue manager can hand frame 1 to node A, frame 2 to node B, and so on with no coordination overhead built into the math. Doubling the worker count halves the total time, in the idealized case this instrument computes.
Real render farms rarely hit that idealized number exactly -- scene loading, license-checkout time, network transfer of textures and cached simulation data, and uneven per-frame complexity (a frame with heavy motion blur or global illumination samples more than a plain one) all eat into the theoretical speedup. Use this instrument for planning and quoting, then compare it against actual farm logs once a job has run.
- Enter Total frames to render -- the length of your sequence, e.g. 250 frames for just over 10 seconds at 24fps.
- Enter Render time per frame -- how long a single frame takes on one worker, from a test render or a previous job's logs.
- Enter Parallel render nodes/workers -- how many machines or render-farm slots will work the job simultaneously.
- Read Total render time in both seconds and hours beneath the inputs -- no manual division required.
Worked example -- 250 frames across 5 render nodes
Enter 250 total frames, 45 seconds of render time per frame, and 5 parallel render nodes. Total render time works out to (250 x 45) / 5 = 2250 seconds. Divided by 3600, that is 0.625 hours -- the full sequence finishes in 37.5 minutes when the workload is spread evenly across all five nodes, instead of the 187.5 minutes a single machine alone would need for the same 250 frames.
Questions
Why does doubling the number of render nodes halve the total time?
Because rendering is 'embarrassingly parallel' -- each frame is computed independently with no dependency on any other frame, so a queue manager can assign frames to idle nodes with essentially zero coordination cost. This instrument models that idealized case, where total time scales as workload divided by worker count; real farms usually land close to this but slightly behind it once overhead like scene loading and network transfer is factored in.
Does this calculator account for scene loading or network transfer time?
No -- it assumes render time per frame already reflects everything a single worker needs to produce one frame, and it ignores per-job overhead like initial scene caching, texture streaming, or license checkout. For a rough estimate, pad your 'time per frame' input upward to cover this, or compare the instrument's output against a real farm log once a similar job has run to calibrate the gap.
What should I enter if some frames render slower than others?
Use the average time per frame across a representative sample -- render a handful of frames from different points in the sequence (including any that involve heavy simulation, motion blur, or global illumination) and average their times. A single frame with unusually high complexity, like a hero shot with volumetrics, will skew the estimate if used alone; sampling several frames gives a more reliable average.
Is there a limit to how much adding more workers helps?
Yes, in practice. This calculator models an idealized world with unlimited, perfectly parallel speedup, but real farms hit diminishing returns from shared bottlenecks -- a limited render-license pool, a single asset server serving textures to every node, or network bandwidth saturating once enough machines pull data simultaneously. Past that point, adding nodes stops shortening the job proportionally.
How do I find my render time per frame before starting a full job?
Render a single representative frame (or a few, from different points in the sequence) on one worker and time it directly -- most render engines log per-frame render time automatically. Use a frame with typical complexity for your scene, not the simplest or most demanding one, so the estimate reflects the sequence as a whole rather than an outlier.