When creating Blender projects, one of the most frustrating parts of the process is rendering. Yes, that grueling, slow process watching tiles appear one by one. Obviously, we try to get this done as quickly as possible, but sometimes the shortcuts used affect our images in subtle, but undesirable ways. And when you use Blendergrid to render faster, optimizing your scene can also help lower the costs, so many opt for using the same kinds of shortcuts to lower CPU usage on our servers, yet the effects of these workarounds still remain. So today we're going to talk a little about the things to watch out for when optimizing your scenes for rendering.
1 - Using Too Few Light Bounces
One of the more well-known tricks for shortening render times is reducing the number of light bounces that Cycles is allowed to use. Light bounces are the foundation of raytracing render engines, each bounce is considered as a change in a ray's direction, caused by whatever 3d surface it happens to hit. This bouncing is more commonly known as Indirect lighting or global illumination and is what allows shadows to be partially lit, despite not being in the direct view of the light.
Rendered with 12 light bounces
Rendered with 1 light bounce
The problem with using a small number of these light bounces is that it almost defeats the purpose of having any bounces. Because in the physical world, there are an unlimited number of light bounces, going in every possible direction. The only way one can attempt to fake those bounces is to have a fairly large number of them, or else, the shadows will most certainly be darker than the same scene in the physical world. By default, Blender is set to have a maximum of 12 light bounces, and this is plenty for the majority of renderings, and perhaps overkill for most scenes without a need for the effects of full GI. For most renders, one can usually set the maximum to 4-6 bounces, and be totally fine, but be careful going any lower that that.
2 - Low Clamp Values
Using clamping is the common trick for reducing render noise and fireflies (Pixels that have unusually high brightness values). In case you aren't sure what clamping is, clamping is limiting the high brightness values of an image. Usually, this value is set to clamp out-of-range/bright samples that are overly bright, down to the clamp value.
The original raw rendering
The overly clamped render
(notice the dull highlights)
The main use of this is to clamp samples down to more reasonable values so that fireflies and bright noise aren't so noticeable. The only problem with this method of noise control is that if clamp values are set too low, the highlights of an image can be darkened, given an image a subdued and low-contrast look. So when you're changing clamp values, make sure to watch the highlights of your image for changes, or else you could end up with some unwanted changes to your image. The trade of of course is, you must set the clamp value low enough to help with noise reduction, but not to hinder highlights too much. One workaround to overcome this is to allow the highlights to be darkened, and fix them later in post-processing.
For more detailed info on Clamping, I highly recommend you check out this article by HJ Hornbeck.
3 - Baked Lighting
Baked lighting is one of the most common optimization methods for games and real-time graphics. More recently, however, with the arrival of baking support in the Cycles render engine, baking has found its way into being used for animations into speed up frame render times in Blender. This technique can be useful, but there are once again a few things to watch out for.
Notice the static feel of the model and lack of Specular reflections
The primary problem with light baking is that additional information outside of lighting is baked. Such as reflections, specular highlights, and all other dynamic properties of materials are "hard coded" into the scene. This means that when objects or cameras in the scene are moved, the materials no longer interact with their environment. So essentially, any animation using full material baking will have an element of non-photorealism.
Note: While full material baking is not recommended, map baking, such as ambient occlusion mapping, can help speed up render times in some engines. Unfortunately, by default, Cycles takes advantage of few of these workarounds.
4 - Using Material Hacks
Material hacks are commonly sought after trick to keeping render times low, the problem is, there are very few tricks for Cycles materials because Cycles is an unbiased render engine and the ones that do exist usually end up affecting the visual quality of images. So I would encourage avoiding looking for the magic speed button of materials, for unbiased render engines rarely have such features in comparison to biased engines (Such as Blender Internal) which have the flexibility to offer render "cheats" in favor of speed.
Left, a typical glass material. Right, a "hacked" glass made from glossy and transparent shaders
5 - Model Optimizations
What I would venture to say is the most misused method of optimization is mesh optimization. Meaning, keeping the polygon count down by either using low levels of subdivisions or by using decimation tools. The common idea is that a less dense mesh will render faster; and while this is true to a point, it has very little to do with rendering and more to do with memory. A dense mesh has almost zero effect upon the CPU or GPU in terms of rendering a tile. Instead, the BVH build process is restricted.
The edges of a model can clearly reveal their low poly nature
The BVH build process relies heavily upon memory and if you have low amounts of memory it can take a very long time. But the truth is, if you have at least 4 to 8gb of memory in you PC, you should be able to render just about any scene you throw at it as long as you don't have an insane amount of unneeded polygons. So instead of spending lots of time optimizing models, make sure you don't have any insanely dense models and move on.
6 - Extreme Denoising
Denoising is often considered the last attempt at removing noise from an image before publishing. There are quite a few types of denoising, with even more denoising programs and a few of them are actually pretty good. But no matter what denoising method you use, it's always going to be a work around, because denoising always comes with a dark side.
The original noisy render out of Blender
The de-noised version (Note the blurry artifacts at the back)
This "dark side" I'm talking about is the artifacts that are left behind from most denoising algorithms. The smoothed, but kind of sloppy looking digital kind of artifacts, to be precise. What you should be looking for while denoising is not the lack of noise, but the sweet spot between noise and the smoothing artifacts of the algorithm. Admittedly, it's a hard spot to find, but as long as you use denoising subtlety, you should be on track to an ok result.
7 - Rendering Locally
First, yes this is a shameless plug for our services here at Blendergrid, but second, this is a valid point to consider. Rendering on your home computer may be easier, and possibly cheaper, but it all comes at a cost. Using a render farm has some major advantages over using a traditional rendering PC. Not only is farm rendering faster, but it also lengthens the lifetime of your home computer, and can even be cheaper, depending on how much PC parts, and electricity cost in your area.
So if you're looking for the ultimate rendering speedup, give Blendergrid a try! You might be surprised at how much time and money it will save you, without compromising quality.
That's it! I hope you enjoyed the article and learned a few things too. If you know about another speed-up trick that should be used with caution, feel free to share it below in the comments :)