3D Render Time Calculator
Work out how long a render takes, when it finishes and what the machine hours cost.
Frames, time per frame and machines, in your browser
Work out how long a render takes, when it finishes and what the machine hours cost.
Frames, time per frame and machines, in your browser
Give this render time calculator three numbers, the frames you have to render, how long one frame takes and how many machines you can point at the job, and it answers the question you actually asked: how long until it is finished, and at what time of day that happens.
The schedule bar shows the render running from now to the finish with the nights shaded, so an overnight batch render reads at a glance rather than as arithmetic. Each machine gets its own lane, which is where you can see that the split is rarely even.
Nothing is uploaded and nothing is stored. It is arithmetic, done in your browser, and it works for a single still just as well as for a 3,000 frame sequence.
These two get mixed up constantly, and they answer different questions.
Render hours, sometimes called node hours or machine hours, are frames multiplied by the time one frame takes. That figure does not change when you add machines. It is what a render farm invoices you for, and it is the honest measure of how heavy a scene is.
Wall clock time is how long you wait. It is the render hours divided across the machines you have, so it halves when you double the fleet. Both are on this page: the big number is the wall clock, and the render hours sit in the results with the rest.
One detail matters more than it looks: frames do not split in half. Put 250 frames on 3 machines and one machine takes 84 while the others take 83, so the job ends when the busiest machine ends. This calculator uses that ceiling everywhere, which is why the frames per machine row and the time always agree with each other.
Most people know their shot as seconds rather than as a frame count, so switch the panel to Duration and enter the length and the frame rate instead. Ten seconds at 25 fps is 250 frames, twelve seconds at 24 fps is 288, and the frame count is filled in for you.
That also makes this an animation frame calculator when you need one. Type the seconds, read the frames, and use the number for your output range, your naming padding or your quote.
Rendering a single still is the same calculation with one frame, and the interesting result becomes the cost row rather than the schedule.
Distributed rendering scales close to linearly, because every frame is independent and no machine needs to wait for another. That is the assumption behind the machines field, and for straightforward frame based jobs it holds up well.
Where it stops holding up is worth knowing before you trust a number. Each machine loads the scene and pulls textures before it renders its first frame, so very short per frame times get eaten by that overhead. Simulation caches, motion blur passes that depend on neighbouring frames, and denoising across a sequence all break frame independence. A busy farm also queues you, and queue time is wall clock time even though nobody is rendering.
If your per frame time is under a minute or so, add a little padding to it rather than treating the result as exact. The calculator will not invent that overhead for you, because only you know your farm.
Enter what you pay per machine hour and the cost appears alongside the schedule, both as a total and per frame. Because cost follows render hours and not wall clock time, splitting the same job across more machines finishes sooner for the same money, which is the whole argument for a render farm.
Cloud and commercial farms use different pricing units, so convert to a per machine hour figure before typing it in. Some price per node hour directly, some price per GHz hour or per OctaneBench point, and a few sell credits that map to an hourly rate. Your own workstation has a rate too if you want one: electricity plus whatever you consider the hardware to be worth per hour.
Per frame cost is the number to quote from. It survives a change of scope, so if the edit grows by 40 frames you already know what that costs. If you also price printed work, the Printing Ink Calculator does the same job for ink.
Render times for 3D graphics vary enormously and there is no universal answer, but there are useful ranges. A simple product shot on a modern GPU renders in seconds. A lit interior at 4K with global illumination and a few bounces commonly lands between two and twenty minutes a frame. Heavy VFX work with volumetrics, depth of field and dense geometry runs into hours per frame, and feature film frames have historically been measured in tens of hours.
The way to turn that into your number is to render one representative frame, not a title card and not the emptiest shot in the sequence. Pick a middle frame with the effects that make the shot expensive, time it, and enter that here.
Two habits keep the estimate honest. Test at final resolution and final sample count, because render time does not scale linearly with either, and time a frame that includes any motion blur or hair, since those are usually the frames that hurt. If you are comparing GPU against CPU, or Cycles against Eevee, time one frame in each and run the numbers twice.
Engines behave differently but the arithmetic does not care. Cycles, Arnold, V-Ray, Redshift, Octane, Karma and Eevee all give you a per frame time, and Blender, Maya, Cinema 4D, 3ds Max and Houdini all report one in their render log. That figure is the only thing this page needs from your software.
Multiply the number of frames by the time a single frame takes, then divide by the number of machines rendering. That gives the wall clock time, whether you write it as render time or as rendertime. This page does it for you, rounds the frame split the way a real queue does, and tells you the finishing time rather than only a duration.
Take the per frame time from a test render and multiply it by the frame count. Ten seconds of animation at 24 fps is 240 frames, so at 5 minutes a frame that is 20 hours on one machine and 5 hours on four. The honest way to answer it for your own shot is to render one representative frame and enter that time above.
The meaning is simple. Render hours, also written as node hours or machine hours, are the total machine time a job consumes: frames multiplied by time per frame. Ten machines each working for one hour is ten render hours, not one. Farms bill in this unit, which is why it does not fall when you add machines.
Enter your frames and your per frame time, then raise the machine count until the finishing line reads the morning you want, which is the quickest way to find the number of machines needed. Because the finish is given as a time of day and not only as a duration, you can see straight away whether the job clears the night or runs into your first meeting.
Cost is render hours multiplied by your rate per machine hour. Put your rate in the price field and both the total and the per frame cost appear. Compare quotes by converting whatever unit a farm sells in, node hours, GHz hours or credits, into a single hourly figure first.
Yes, and for any other renderer. Blender prints the time for each frame in the render window and in the console, so use that as your time per frame. The same applies to Maya, Cinema 4D, 3ds Max and Houdini, whichever engine sits underneath them.
Yes. Set the frames to 1 and the calculator reports the time and the cost of that one render. It is the quickest way to price a still, or to see what a change in sample count is doing to a shot.
No. It counts rendering only, so add your own allowance for scene loading, asset upload and waiting in a farm queue. Those are real and they are wall clock time, but they depend on your pipeline rather than on your frames.
No. The whole calculation runs in your browser, nothing is uploaded, and nothing is saved when you close the tab.