3D Render Time, Cost and Machines Calculator
Enter the number of frames, the average time to render one frame, and how many machines (or GPUs) are working on the job. This calculator returns the total render time, the projected finish time, the render farm cost, and the electricity bill for the job. Switch modes to solve for machines needed or maximum frame time instead. Results update as you type.
How the render time formula works
The core formula is: total render time = (time per frame x total frames) / number of machines. When you distribute a job across multiple render nodes, each node handles a share of the frames in parallel, so the wall-clock time drops proportionally (ignoring queuing and I/O overhead). For example, rendering 1,800 frames at 5 minutes each on a single machine would take 9,000 minutes, or about 6.25 days. Split that across 4 nodes and it falls to roughly 37.5 hours. The calculator also solves the formula in reverse: given a deadline and a known per-frame time, it tells you the minimum number of machines you need. Or, given a deadline and a fixed machine count, it tells you the maximum per-frame budget to meet it.
Render farm cost and electricity estimation
Cloud render farm pricing is typically billed per machine-hour or per GHz-hour, so total cost scales with both the number of nodes and the wall-clock render duration: farm cost = hourly rate x nodes x render hours. Electricity draws from a similar formula: energy (kWh) = power per machine (kW) x nodes x hours. A workstation GPU such as an RTX 4090 draws around 450 W under load; a dual-CPU render server can draw 300-600 W. Multiply the total kWh by your local rate to get the electricity bill. At US residential rates of about $0.13/kWh, a 24-hour, 4-node job with 300 W per node consumes roughly 28.8 kWh and costs about $3.74 in electricity alone, before the machine rental cost.
Tips to reduce render time
Render time is determined by scene complexity, sampling rates, light paths and output resolution - not just hardware. Common optimisations include: reducing path-tracing samples for background objects (adaptive sampling); using render layers so that only changed objects re-render between versions; baking static lighting and global illumination into textures; lowering subdivision levels for distant geometry; and using denoising (OIDN, OptiX or equivalent) to reach an acceptable quality at a fraction of the samples. Switching from CPU to GPU rendering can cut per-frame times by 5-20x on scenes that fit into VRAM. For deadline-critical work, cloud burst rendering lets you temporarily scale to dozens or hundreds of nodes.
Understanding the machine-count and max-frame-time modes
The "machines needed" mode answers: given a fixed deadline, a known per-frame time and a frame count, how many nodes do I need? The result is always rounded up to a whole number because you cannot use a fraction of a machine. The "max time per frame" mode answers the complementary question: given a deadline and a fixed machine count, what is the slowest each frame can be before the job misses the deadline? This is useful when you are profiling a scene and need to know whether a particular render setting is too slow before committing to a full farm run. Both modes include the same cost and electricity estimates as the standard mode.
Typical render times by project type
| Project type | Frames (typical) | Avg time per frame | Single-machine total |
|---|---|---|---|
| Short promo (15 s, 30 fps) | 450 | 1-3 min | 8-23 hours |
| 60-second spot (30 fps) | 1,800 | 2-5 min | 1-6 days |
| Architectural walkthrough (90 s) | 2,160 | 5-20 min | 8-30 days |
| TV episode VFX shots | 5,000-20,000 | 1-10 min | 3-140 days |
| Feature film (2 hr, 24 fps) | 172,800 | 5-30 min | 0.8-3.6 years |
| Product render turntable (360 frames) | 360 | 3-10 min | 18-60 hours |
| Game cinematic (2 min, 60 fps) | 7,200 | 2-8 min | 1-4 weeks |
Approximate single-frame render times on a modern workstation. Distributed farms scale these down linearly with node count.
Frequently asked questions
How accurate is this render time estimate?
The estimate is only as accurate as the "time per frame" input. Render times vary significantly between frames due to camera angle, depth of field, motion blur and the amount of visible geometry. For the most reliable estimate, run a test render on a few representative frames - a close-up hero shot, a wide establishing shot and a complex action frame - and use the average. Add a 10-20% buffer for scene loading, output writing, queuing delays and inevitable retries.
What counts as one "machine" for farm rendering?
On most render farms, one "machine" means one compute node - which could be a multi-core CPU server, a single GPU, or a cloud instance. Some farms price by GPU rather than by machine. If your farm prices per GPU and you have 4 GPUs on one machine, enter 4 for the machine count. The calculator treats all nodes as identical and fully parallel; in practice, larger scenes may have I/O bottlenecks that reduce effective parallelism.
Why does render time not scale perfectly with more machines?
In theory, doubling the nodes halves the render time. In practice, overhead from scene loading, network file I/O, job distribution, and queuing contention means you get diminishing returns beyond a certain point. This is known as Amdahl's law: if even 5% of the job is serial, no amount of parallelism can speed it up more than 20x. The calculator uses the ideal linear formula; subtract 10-20% from the estimate for real-world efficiency losses on large farm runs.
How do I estimate the time per frame for my scene?
Render 3-5 representative frames (not just the first frame, which may be unusually fast if it lacks complex lighting or particles) and record each time. Use the average or, for a safer estimate, the 90th percentile (the slowest of the batch). If you are still in pre-production, you can use the reference table on this page as a ballpark, then refine it once you have a test render.
Does the formula apply to GPU and CPU rendering equally?
Yes - the formula is engine-agnostic. Whether you are using Blender Cycles, Arnold, V-Ray, Redshift, Octane or any other renderer, the math is the same: total time = frames x time-per-frame / nodes. The only difference is the per-frame time input, which will be much lower for GPU-accelerated engines on scenes that fit in VRAM.
How is electricity cost calculated?
Energy consumed (kWh) = power per machine (W / 1000) x number of nodes x render duration (hours). Electricity cost = energy (kWh) x your rate (USD/kWh). The default power figure of 300 W is typical for a mid-range render workstation. For a dedicated GPU node (RTX 4090) use 450 W; for a cloud CPU instance, 150-250 W is more typical. Check your hardware specifications for the rated TDP under full load.
What frame rate should I use to work out animation length?
Film and cinema projects use 24 fps. Television broadcast in North America is 29.97 fps, commonly rounded to 30 fps. UK and European broadcast is 25 fps. High-frame-rate gaming cinematics may use 60 fps. The animation length shown in this calculator assumes 24 fps; to calculate length at a different rate, divide your frame count by the actual frame rate.