All the ways to render faster in Blender / Cycles

· By Richard

Of all the things you can be doing with your computer, 3D rendering is not the fastest ship in the fleet ;D

Most of the time it's dreadfully slow. If you need a lot of samples it can be like watching paint dry.

Let's look for ways to make it a bit faster.

In this article I'll list 35 different ways you can speed up rendering in Blender. I will be updating this article with new ways I find and remove anything that becomes irrelevant.

You will pay some price for most of these optimizations, so it's a balancing act. But if you're aware of the trade offs, you can weigh up the pros and cons, and make a good decision.

You won't need to do all 35 things, picking one, or a handful of them might be enough to safe significant time.

Render Farms

Trade offs:

• Costs money
• Your scene needs to work on other computers, so you need to pack assets / bake simulations

If you look at a render task as taking some amount of "Compute Work" W . And your "Compute Power" P is a value for being able to do some amount of that work per second. Then the time t it takes a render to complete is:

t = W / P

So if we want to reduce the time t, we could reduce W. That means less "render work". If you render less frames, at a lower resolution, or with less samples, yeah you reduce render time. But if you want to render without compromising quality, increasing compute power P is the other option.

If you double compute power, you half the render time (in theory). So if you render on 2 identical computers instead of 1, you will need about half the time.

Rendering on two computers goes twice as fast. Rendering on 200 computers goes (up to) 200 times as fast. The challenge is making sure the computers are all doing something productive.. Fortunately, for 3D rendering this is pretty easy. Especially if you have enough frames to give every computer something to work on.

If we look at rendering from first principles. It makes a lot of sense to simply increase compute power. This is the "brute force" approach. The cost: literally money, for the hardware / energy.

Adaptive Samples / Noise Threshold

Trade offs:

• More parameters to tune than only "Samples"

This one is almost a no-brainer:

Using the samples that Cycles takes more intelligently. More samples for the pixels that need more to become noise free.

The only trade of that instead of only the samples setting, you now have more knobs to tune. But it's not that bad.  And there are ways to let Blender choose some sensible defaults if you don't want to tune them yourself.

Cycles is able to measure the noise per pixel, and give it a numerical value. If the noise of a pixel drops below this the noise threshold, Cycles will stop taking samples for this pixel. Over time, less and less pixels will have to be sampled, resulting in a faster render.

Light Path Bounces

Reducing the number of bounces can reduce time per sample. This reduces the amount of samples needed for a noise free image.

You have to be aware that this will reduce Global Illumination, so it reduces realism.

Eevee

Trade offs:

• Less realistic
• More work to set up combining Eevee and Cycles together

Sometimes you don't need the photorealism of Cycles, and you can get away with simple shading.

For example, if you're rendering a scene in many render passes. Some of those passes might have an excessive amount of noise. Rendering this pass with Eevee and compositing it back into the shot could save you a bunch of render time.

Denoising

Trade offs:

• Can lead to loss of detail / blurryness / artefacts

The idea of rendering with an engine like Cycles is that you start with a noisy image, and over time it will get cleaner.

So the more time you give Cycles, the more samples it can take, the closer you get to the "perfect noise free image".

Instead of giving Cycles all this time (that you want to save) you can get the image to a point of looking almost good enough. From there, you can let a Denoising algorithm take it to the next level.

Blender has a few denoising options built in, either in the render settings or as a Node in the Compositor.

Using a denoiser well is about finding the right balance between:

• how much work to give to Cycles
• how much denoising to leave for the denoiser

Light Groups

Trade offs:

• Takes more time to set up
• Requires compositing
• Leads to larger files

If you want to save time on re-rendering, this is a good tool to use.

You can place all objects that illuminate light into separate groups.

This way Blender can create render passes for each light group, and in post you can mix these together..

This opens up some interesting doors:

• Being able to tweak the brightness of certain light groups
• Being able to change the color of certain light groups

All physically accurate, and without re-rendering the image.

AI Upscaling

Trade offs:

• Requires an external AI tool
• Loss of detail
• Might add jittering artefacts in animations

With AI tools, it's possible to upscale images or video to 2x or even more. This is not a magic bullet because the AI has to come up with non-existent detail. But if the extra detail is "predictable" enough, it can work really well.

Rendering at 50% is up to 4x faster, because it's only 25% of the amount of pixels.

So if you feed in a 2x upscale algorithm your 50% resolution frames, it will spit out the frames at 100% resolution. If you have access to a good upscaler, this is definitely worth a try.

Denoising at 200% (or more) Resolution

Trade offs:

• Extra setup work in the compositor and extra scenes

Instead of halving the resolution, this strategy is about rendering at double the resolution.

This takes about 4x longer, so why the heck would you do this?

Yep, it's slower, but you can counteract this by lowering the Cycles samples to 25%. This should get you back to about the same render time.

Doubling the resolution turns every pixel into 4 pixels. But by giving each pixel 25% of the samples, you use the same number of total samples in the entire render.

The benefit of this, is that you will have a more noisy image, but there is more information available. The denoiser has more "noise" to work with so it can be more effective.

So you can then denoise the image at 200% resolution. (this will also be 4x slower, but denoising doesn't take that long)

After denoising the image, you can average each group of 4 pixels back to one. Reducing any remaining noise significantly.

A downside of denoising is that it tends to blur/soften the image a little. With this strategy, in the final image, you won't notice this as much because the softening happened at 200% resolution.

If you try this and you get significantly better noise free renders, you can set the samples to even less than 25% and at that point you're saving render time.

Cycles X

Trade offs:

• Need to install a different Blender build

A custom version of Cycles that renders faster. It's available on the Blender market, and we are working on supporting it at Blendergrid as well.

More than one Blender Instance

Trade offs:

• Requires more RAM
• More work to set up

This is about utilizing the compute power you have as efficient as possible.

If one Blender instance is not able to take advantage of the full capacity CPU/GPU of your computer, running two instances of Blender might.

If you start rendering, and you look at the Activity monitor or whatever tool you use to monitor CPU / GPU usage. You might notice that the CPU usage goes up significantly but it's not quite hitting the 100% ceiling. If it's only hitting 80% on average, that means that in theory you could be rendering with 25% more compute power.

If you're rendering an animation, it's easy to let two Blender instances each render different frames in the sequence. And maybe now each instance is taking an average of 50% of the compute power. This means each frame is rendering a bit slower, but there are two frames being rendered simultaneously, so the net render speed is higher.

Fast GI approximation

Trade offs:

• Less realistic lighting (not physically accurate)
• Can cause artefacts

One of the things that makes Cycles renders look realistic is global illumination or indirect lighting. Everything that reflects or refracts light will contribute that light back to the scene.

A white object close to a red object will get some red tint because the red light bouncing off of the red object will affect it. That's pretty much the classic example of global illumination. Everything gets illuminated by everything.

So global illumination is cool. If you want realistic renders, you should use it. But it can sometimes be slower to render, and more noisy.

So Blender added a little trick where it can approximate this effect faster. Hence the name.

This is how you use it:

And this is what it looks like, with/without.

AI Frame Interpolation

Trade offs:

• Can lead to artefacts / loss of detail
• Requires an external AI tool

This is kinda like AI upscaling. With AI upscaling, AI is filling in the blanks between pixels in every frame. Upscaling in the spacial dimensions (x, y) of the image.

With AI frame interpolation, you can give the AI two frames. Say frame 1 and 3, and it will fill in the blanks (interpolate) to figure out what frame 2 would have looked like. Upscaling in the temporal dimension.

If this works well, it means you can render only your even (or uneven) frames.  This means you're halving the number of frames, and also halving your render time.

You can find a free tool that can do this at: nmkd.itch.io/flowframes 

Performance Settings

Optimize memory usage, preparation time, and sampling time to get the lowest average render time per frame.

TODO: Make a separate section for each Performance Setting.

Persistent Data

Use persistent data to save time initializing the next frame.

If you're rendering an animation, and every frame needs to load in a bunch of textures, this can save time.

With persistent data you will only need to load in these textures into memory on the first frame. After that it will be persisted. From the second frame onwards, it will save this loading time. If it took a few seconds to load in everything, you will save this on every frame starting from the second.

GPU vs CPU rendering

If you have a decent GPU in your computer, be sure to use it for rendering whenever possible. The fastest results can be achieved when you can let the CPU and GPU render together.

Polycount, subsurf, culling, simplify setting

Make sure you're not using too dense meshes. If it's not visible in the final image, you might be able to simplify the scene. Lower the polycount and save render time.

Disable Caustics if you can

If you don't need complex caustics, you can consider turning it off for faster noise free renders.

Portals

Use portals to guide the light paths into the right direction for tricky scenes.

Don't save in 100% compressed PNG

Saving 100% compressed PNG's can take a long time and it doesn't save you that much space. (show graph with saving time vs. file size)

Texture resolution

Show what texture resolution does to render time?

Ensure you are not using a huge resolution for your textures. At some point there is no advantage to using higher texture resolution.

Instances vs copies?

If you have a lot of duplicate objects in the scene, use instances vs full copies. This allows Blender to use the same mesh data in memory instead of a new copy for each object.

Adaptive subdivision

Be careful with adaptive subdivision as this can explode the polycount in the scene (and render time).

Especially if you've been running tests at lower resolutions. Setting the resolution to the final HQ can suddenly explode poly count while rendering.

Volumes tips

Volumetric rendering is expensive. If you're after a fog-like effect. Try to see if you can get away with compositing this using z-depth or a fog pass.

Motion blur

Motion blur can increase render time. Be sure you need it for your scene, and consider turning it off to save a lot of render time. There is always the option to add motion blur in post.

Render Region

Trade offs:

• Only works while testing, the production render still needs the full frame

Rendering only a part of your scene (render region) instead of the full frame for tests can save a lot of time during iterations.

Out-of-Core Rendering

If your scene is too large to fit into GPU memory, Blender supports out-of-core rendering, where some of the data is stored in RAM. Optimizing how this happens can lead to more efficient renders.

Baking Textures & Lighting

Trade offs:

• Requires baking upfront
• Less flexible (if you move an object, you have to re-bake the whole scene)

Baking lighting and textures (especially for static objects) can reduce real-time render time, as the baked data can be reused without recalculating light/shadow interactions.

If you have a scene with a complicated diffuse indirect lighting setup, but the objects don't move (only the camera), then this can save you a lot of render time.

Simplify Materials

Complex shaders can slow down renders, especially if you’re using a lot of procedural textures. Simplifying or baking materials can reduce render time.

(come up with a test case study .blend file)

Decrease Level of Detail

Decrease level of detail in distant objects. They don’t need the same polycount or material complexity as objects close to the camera.

This is another example of not doing work where it's not needed.

Camera culling

Use of HDRI Lighting

HDRI images can offer efficient lighting setups that reduce render time compared to complex lighting rigs.

Does it? Let's test it. Come up with a complex "lighting setup". Turn it into an .HDR panoramic render. Then use that as the only light source.

Optimizing Keyframe Interpolation

Test if this makes a difference in render time. Probably not?