Tutorials Motion

Why Your Render Takes Far Longer Than the Preview Suggested

Intermediate · ~15 min

Overview

Smooth playback in the viewport tells you the frames already in memory replay quickly. It tells you almost nothing about how long the frames take to make. A comp previewing at full rate and rendering overnight is not a fault, it is the normal relationship between a cache and a render. Understanding where the time goes turns most overnight renders into something shorter, and tells you when the answer is a different machine rather than a different setting.

What You Need

The project rendering slowly, and a note of how long it took
Your system monitor open during a render, watching processor, memory and disk
The render settings and the output format in front of you
Patience for one controlled test, because changing five things at once teaches nothing

Steps

Understand why the preview lied

A preview plays cached frames. Once a frame is computed, replaying it is a memory read, so a comp taking four seconds a frame to build plays back instantly on the second pass. A render computes every frame once, at full resolution, with every effect at final quality, and with none of the shortcuts the viewport takes. The two numbers were never measuring the same work.

Find the expensive layer by bisecting the comp

Render ten frames with everything enabled and note the time. Disable the top half of your layers and render the same ten frames. Repeat on whichever half stays slow. Four or five rounds finds the layer costing the time, and it is usually one rather than the whole comp. Guessing is slower than bisecting, because the expensive effect is rarely the one looking complicated.

Know which effects are expensive by nature

Some effects cost far more than others and no setting changes the ordering. Anything sampling many pixels per output pixel is slow: large blurs, glows, depth of field and motion blur. Anything analysing across time is slower still, including optical flow retiming, tracking and denoising, because a single frame needs its neighbours. Effects nested inside a precomp which is itself scaled get computed at the larger size, so the cost multiplies rather than adds.

Check whether you are waiting on the disk or the processor

Watch the system monitor through a render. A pinned processor with light disk activity means the comp is compute-bound and the fix is in the effects. Low processor use with heavy disk activity means you are waiting on media, and the fix is faster storage or proxies. Memory filling and then a sudden collapse in speed means the render started paging to disk, and reducing the number of simultaneous frames helps more than any effect change.

Render to a format costing you nothing to write

Rendering straight to a heavily compressed delivery format asks the machine to compute the frame and then compress it hard, on the same processor, for every frame. Render to an intermediate format such as ProRes or DNxHR, then transcode it to the delivery file in a second pass. The two passes together often finish sooner than the single pass, and a failure at frame 8000 costs you the transcode instead of the render.

Turn off what the render does not need

Guide layers, disabled-but-still-computed adjustment layers, effects on layers hidden behind others, and full-resolution precomps feeding a small on-screen element are all paid for at render time whether or not they reach the picture. Motion blur and depth of field on a layer nobody sees clearly cost the same as on a hero element. Audit what the frame needs before buying hardware.

Decide honestly whether the machine is the limit

After the audit, some comps are simply large. A heavy particle system with volumetric lighting at high resolution takes the time it takes. At this point the options are a longer wait, a lower delivery resolution, splitting the render across machines, or rendering in segments overnight. Recognising this point early beats spending three more evenings on settings.

Pro Tips

Time ten frames, not the whole comp. Every measurement in this process wants to be fast enough to repeat.
Render in segments and join them. A four-hour render failing at hour three costs the whole night. Eight half-hour segments cost you half an hour.
Check the frame the render is slowest on. A single frame with a heavy transition often accounts for a surprising share of a total.
Close the application and reopen it before a long render. Long sessions accumulate memory the software never reclaims, and the render inherits whatever is left.
A comp scaled up inside another comp computes at the larger size. Scaling down a precomp is free, scaling up is expensive, and the cost is invisible in the timeline.
Keep a note of render times per project. Knowing a job usually takes 40 minutes makes the evening it takes four hours a signal rather than a surprise.

Knowledge Base

What You'll Learn

The table below ranks where render time usually goes. The sections after it explain the cache, which is the single most common source of the surprise.

What costs render time, roughly in order

Cost	What	Why
Highest	Optical flow retiming, denoise, tracking	Each frame needs its neighbours analysed
High	Large blurs, glows, depth of field	Many input pixels sampled per output pixel
High	3D renders with global illumination	Light bounces computed per sample
Medium	Motion blur	The frame is rendered several times and combined
Medium	Nested precomps at larger scale	Computed at the bigger size, then reduced
Low	Colour correction, transforms, masks	One pass over the pixels
Varies	Writing the output file	Cheap to an intermediate, expensive to a delivery codec

Why a cache makes a slow comp feel fast

Every compositing and motion package keeps computed frames in memory and on disk. Scrub over a section once at a low preview resolution and the frames are stored. Play it again and the software replays stored pictures rather than rebuilding them.

Three things make the stored version cheaper than the real one. It was often computed at half or quarter resolution. Some effects run in a faster draft mode in the viewport. And it exists already, so the only cost is reading it back.

A render discards all three advantages. Full resolution, final quality, every frame computed once. So the honest preview of render time is timing ten uncached frames at full settings, which is why every measurement on this page starts there.

The two-pass render, and why it is usually faster

Rendering directly to a delivery codec makes one processor do two heavy jobs per frame, and the compression job cannot start until the frame is finished. Rendering to an intermediate codec writes bigger files and finishes each frame sooner, because the compression is light.

The second pass, transcoding the intermediate to the delivery file, is a job dedicated hardware encoders handle well and it runs without recomputing a single effect. Total wall-clock time usually drops. The intermediate also gives you a master to re-deliver from when someone asks for a different format next week, without going near the project again.

The cost is disk space, and intermediates are large. Treat them as temporary for a small job and as an archive worth keeping for a large one.

Where This Fits

This sits under Blender for Motion Graphics, the pillar for the motion and 3D side of the site. What Happens When You Hit Export covers what the machine is doing during those hours, and Proxy Editing covers the same trade of quality for speed applied to editing rather than rendering.

FAQ

Q: Why does my comp play smoothly and render for hours?
A: Playback replays frames already computed and stored, often at reduced resolution and draft quality. A render computes every frame once at full resolution and final quality. The two numbers measure different work, so a fast preview and a slow render are consistent with each other.

Q: Which effects slow a render the most?
A: Anything analysing across time is worst: optical flow retiming, denoising and tracking. Next are effects sampling many pixels per output pixel, such as large blurs, glows and depth of field. Colour work and transforms are cheap by comparison.

Q: Is it faster to render to ProRes and then convert?
A: Usually yes. Writing a light intermediate finishes each frame sooner, and the second pass compresses without recomputing any effects. You also get a master to re-deliver from later.

Q: Will more memory fix a slow render?
A: Only when memory is the constraint. Watch a render in your system monitor: if memory fills and speed then collapses, the machine is paging and more would help. A pinned processor with memory to spare points at the effects instead.