Two years in the making, I set out to ambitiously answer the question that has plagued countless forum debates for years…what’s the best 3D render engine? As you’ll see, it’s not an easy question to answer…but I believe I have the answer.

This article will tell you everything you need to know about today’s top path tracing render engines, including Cycles X, Vray, Redshift, Luxcore, Arnold, Corona, Octane and E-Cycles - and which renderer is the fastest!

What is 3D rendering and what does a render engine do?

In the world of 3D, rendering is the process of taking your 3D scene/object and creating a 2D image or animation out of it.

Rendering is used to both share your scene outside of the modelling software you’re using (such as showing your visualization to a client), as well as constantly rendering while you work, so that you can refine your 3D project in real-time; otherwise, you’d have to constantly export details of your scene to see how it looks in the final render.

A render engine is what’s used to undertake this rendering process. There are a variety of render engines you can choose from, all ranging in performance, quality, speed and costs - which can make it hard to know which to use.

So, to help you on your quest, we’ve decided to compare the 8 main render engines and rank them for you, based on the most important factor, in our opinion - speed.

Why does speed matter in 3D rendering?

Not only does it affect how much the render farm bills you, but it also often affects the quality of the artwork. See, if you’re constantly waiting for noise to resolve, you’re wasting precious time that could be spent making creative choices to enhance the finished artwork…which basically makes speed one of the most important performance aspects of a render engine.

Why we didn’t optimize settings

If you’ve ever tried to optimize a scene, you’ll know how time consuming it is. Properly optimizing a scene could take days to test the before and after of each setting. But not only that, optimization itself is a highly technical skill - Pixar has an entire Lightspeed team that does just this. For this test, we didn’t want to know which engine could be the fastest but which engine would be the fastest, most of the time.

So here are the render engine setting we chose across the board to keep the testing fair:

Samples

There’s actually no standard to what a sample is. Since getting a clean image is the point of rendering longer, this is kind of important! You would think that you could eyeball them to be close, but we quickly realised that two people will often disagree on which ‘feels noisier’.

So, we found a solution through signal-to-noise ratios using an image analysis script that compares an image with a ground truth clean image, producing a noise score. Time consuming? Yes. But ultimately, allowed us to get a consistent noise match across each engine.

Color pipelines

Part of the test was to compare the visual differences of each rendered image, which by default you can’t do, since each engine has its own color pipeline. So we stripped away any tone mapping and grading, feeding it through the same filmic color transform. This gave us a naked view of each render, before any grading was applied.

The settings

In the name of a fair comparison, we chose to stick to default settings, with a few exceptions:

The first two settings we had to tweak were light bounces and light clamping. These two settings affect speed and quality significantly, and each render engine has different defaults for these values - since it would be unfair to compare such different images, we set them to the same values (Light Bounces: Uniform, Light Clamping: Off).
We also turned off the Caustics setting, since its practical uses are less common and it drastically increases time.

Brute Force GI and Secondary Solvers

While all path tracers have the ability to do a brute force GI calculation, only V-Ray, Corona and Redshift come with an extra secondary solver, which work by subdividing the scene into chunks, calculating light values for those chunks, and then combining it with a low sample brute force pass to average out the final result.

It’s not practical for all production cases, it can reduce render times by a whopping 92% with no difference in quality.

We’ve included timings for both options, but used the fastest results for the final rankings.