Render engine speed comparison

in my 14 years as a 3d artist i've witnessed countless forum debates over which rendering engine is the fastest and not one credible study that actually compares them so for my own curiosity more than anything i decided to make this video the top path traces head to head see which one's the fastest not realizing of course that this is a mammoth task that would take two years to complete as a research assistant and i learned precisely why nobody's done a video on this but by the end of this video you'll learn the answer to that age-old question of which rendering engine is the fastest and also why answering it isn't easy if you click this video i assume you care about speed so you'll probably like polygon polygon is a library of architectural textures and models that help you build beautiful buildings and exteriors faster with add-ons for all major software and render engines you'll spend less time clicking and more time making art use it with your 3d software of choice by signing up at polygon.com or by clicking the link in the description and before we get to those juicy graphs showing which render engine is fastest at what i need to explain how and why we tested them first of all let's make one thing absolutely clear speed does matter it's not only responsible for what the render farm bills you but often the quality of the artwork because if you're constantly waiting for noise to resolve you'll be afforded less creative decisions in an 8 hour workday than somebody using a faster engine which makes speed just about one of the most important traits of any engine but when you look into it you immediately face the question of optimization how can you test engines fairly when an expert could always optimize the settings to be faster but the crucial part of that question is expert which most artists are not engine settings are an obstacle we learn reluctantly in order to create our image not only that but optimization is a time consuming app itself it requires a b testing to see if that one optimization improves speed and at what cost to quality and doing this for the hundreds of variables in a scene can take days if not weeks which is why even large studios with dedicated teams don't bother trying to optimize everything so i believe a fair test isn't which engine could be the fastest but which engine will be the fastest most of the time i.e we use default settings but there are two settings we changed light bounces and light clamping both alter the speed and quality significantly and since each engine has different defaults it wouldn't be fair to compare drastically different images with each other so we set them to the same value we also turned off caustics since its practical uses are less common and it drastically increases time another difficult setting was samples because there's actually no standard on what a sample is and since getting a clean image is the point of rendering longer this is kind of important now you'd think that you could eyeball them to be close but we quickly discovered that two people will often disagree on which feels noisier we discovered a workable solution though with the peak signal-to-noise ratio this image analysis script compares an image with a ground truth clean image and then produces a noise score this was time consuming but it let us get consistent noise matching across each engine part of the test was also to see the visual differences between each engine which by default you can't do since each engine has its own color pipeline so we stripped away any tone mapping and grading and instead fed it through the same filmic color transform this gave us a naked view of each render before any grading was applied and for v-ray corona and redshift we tested them twice once with the standard brute force gi then again with secondary solvers which if you didn't know subdivide the scene into chunks and then calculate light values for those individual chunks it then combines it with a fast gi pass to average out to the final result it's not practical for all production cases but when it works it can reduce render times by a whopping 92 percent with no difference in quality so i'll show the timings for both of those but use the fastest time for ranking for each engine we conducted four tests a light bounce test subsurface scattering test an environment volume test and an all-rounder test some engines work only on gpu others only cpu and others that do both and since we're using a new 3090 gpu but a much older i7 cpu it wouldn't be fair to compare the speeds so we kept the timing separate between categories and in case you weren't aware not all engines work in every software so we rendered cycles cycles x e cycles octane and lux core in blender then we exported an exact replica of the scene to 3ds max for rendering in redshift v-ray corona and arnold and in every case we use the recommended material shader and lam type as research from forums so that's why this video took longer to finish than i ever would have imagined but if you appreciate the effort hit like and subscribe to help more people find it anyway let's begin test number one the classic cornell box basic geometry with diffuse shaders lit by an area lamp it's simple but it shows how quickly an engine can perform the most basic of light calculations in the gpu category the results were very close the winner was octane followed closely by e-cycles and redshift basically tying then v-ray then cycles then cycles x and lagging way behind was lux core and if you're wondering why cycles x is slower here remember that for starters it's in early alpha stage of development but also the developers claim that you'll see the biggest performance increases in complex scenes as you'll see later on now in the cpu rendering category v-ray took the win at 37 seconds followed closely by corona then you need to wait seven times as long to see cycles and then you need to wake three times longer than that to see arnold but before you make any conclusions here remember that this is the fastest of tests and therefore it has the highest margin of error test number two subsurface scattering this is the test you'd care about if you do character animation since it simulates light scattering through skin in our test we used a simple statue model with an sss random walk and gloss shader and a standard three-point lighting setup there were some pretty big differences in the visual look but they could be matched more closely by an expert what we're really looking at is how quickly it clears up that noise in the gpu category the fastest was surprisingly e-cycles then redshift cycles x and octane basically tying for third then v-ray in cycles tying for fifth and lux core in last place and interestingly this was one test whereby cycles was fastest not in its optics calculation but in its cuda calculation now in the cpu tests v-ray really stood out over its competitors being almost four times faster than second place which was arnold then we had corona cycles x and then cycles also in simple scenes like this secondary solvers made little to no difference to the render times as it's really only when there's lots of surfaces receiving bounce light that you get the benefits of secondary solvers test number three environment volumetrics this is honestly the test i care about most since fog and smoke add so much beauty to environments we tested this on the classic classroom benchmark scene that you can download from blender.org with a few modifications we took out all the lighting and materials and instead replaced it with a mid-grade diffuse shader for everything and four area lamps pointing down at the windows and then we finally added in a large volume scatter cube over everything in the gpu timings redshift surprised us by being more than four times as fast as second place which was v-ray then we had e-cycles and much further behind that was cycles then lux core and then finally octane cycles x was not tested here because at the time of recording at least volumetrics is not yet supported in the cpu category corona took the win by a wide margin followed by v-ray then arnold and then cycles scored the absolute worst at more than 10 times that of first place so blender users it's not just you cycles is unreasonably slow at volume metrics worse so in the cpu but not so great in gpu either so i'm eager to see how cycles x performs here because as i explained in my forest cabin tutorial the volumetrics added a lot to the beauty of the scene but because of the insane hit to the performance i couldn't use it for the final animation all right final test the all-rounder if you only care about one of them this is it unlike the other test this represents a much more typical scene with multiple challenges it's got indoor and outdoor areas textured areas subsurface scattering glass high poly objects multiple ies lamps and hdr lighting while the previous tests reveal specific strengths and weaknesses i consider this ranking to be the one that really counts when choosing an engine it's also the best test to compare visual quality with out-of-the-box settings to me it demonstrates why corona is so beloved by archbis artists because it looks amazing the glass pops the ground reflects the way it should the marble looks milky the lighting feels hot everything just looks gorgeous now an expert of any of these engines could probably tweak the settings to be comparable but again that requires time and expertise best bang for your buck in terms of beauty i think corona takes the win but let's talk timings in the gpu category the winner of the big all-rounder test was v-ray beating out all the other engines by a considerable margin then we had cycles x nice very promising then e cycles followed closely by redshift then cycles then octane and then lux core lagged way way way behind in the cpu test v-ray took the win again with corona taking almost four times as long then arnold more than twice that and finally cycles in last place by a considerable margin so that's the final graph hats off to chaos group huh for taking the win in both categories and also the second place in cpu and if you're looking at these timings and you're thinking that you could improve them with better settings you're right there is no doubt in my mind that an experienced octane artist couldn't reach the same speed as v-ray but at the same time inexperienced v-ray artists could also reduce their times further so remember that these are the base speeds that you should expect before they are all reduced further through optimization and while i'm fairly confident in the timings i'm also aware of its faults while the peak signal to noise ratio is the gold standard for comparing noise two people could still disagree on which image feels noisier one reason for this is brightness the engine's color grading or your monitor's brightness could change how noisy something looks another is inconsistent noise as different parts of the image could be noisier than the rest and while the script will evaluate the entire image your eye may be drawn to certain areas more depending on the composition and the final reason is that each engine has a different noise pattern to me the noise in redshift and v-ray feels more lumpy than the rest but does that mean i'd render more or less samples i honestly don't know as artists we just tend to increase or decrease samples depending on how it feels that said we've spent hours looking at these images up close and to us they look similar enough but considering the differences in perception i'd say there's still a twenty to thirty percent margin of error so where the times are close you can just assume they're tying for the same position to me what the tests reveal most are the strengths and weaknesses of each engine every engine struggle with volumetrics except redshift and corona their weaknesses oddly enough were complexity cycles x has few weaknesses so far but we'll see once it supports volumetrics and lux core look i don't know i guess it kind of struggles with everything but subsurface scattering the least i've included a link to my website where you can see all the images and spreadsheets if you want to dig into the data more but why you may ask was caustics not tested well currently each engine processes caustics in such wildly different ways that there's really no point in comparing the timings i'm confident that in the next five years as path traces become real time we'll see volumetrics and caustics becoming the next area of focus but for now it's a pretty nice feature that few people use to understand why caustics is such a difficult problem to solve i've brought in someone a little more experienced hey there andrew this is dr karo jonah ifahir from two minute papers big fan of your donuts so why is rendering caustics so slow and difficult well it is because the classic path tracing algorithm that nearly everyone uses randomly shoots millions and millions of light rays from the camera and bounces them across the scene and unfortunately very few of these random rays end up hitting caustics and hence it takes a long long time to get a smooth image there are two effective ways to address this problem the hard way and the easy way the hard way is systematically finding these regions that contain caustics and trying to process them directly there are great research papers on how to do that but it still requires more complex rendering algorithms but there is also the easy way the easy way is shooting photons around from the light sources filling the surfaces of the scene and building a database with those photons then whenever we encounter the hostics we look at nearby photons in this database for clues this is what photomapping does it works really well but it has a drawback however we still need a large database of photons or else our caustics will get blurry due to the lack of information and excessive averaging hope this helped what a time to be alive thanks dr carroll and guys if you want to learn about the emerging technologies that make our industry i highly recommend checking out his channel so caustics can be on or off and while we wanted to include it in our tests it would have taken too long to get the results to match so we turned it off the only engine that looked good with default settings was corona you just hit a checkbox and it works provided though you're okay with quadrupling your render times because nothing is free and you can find more tests like this in my this week in 3d newsletter it's a short weekly email of three to five discoveries that i make each week could be a cool tutorial a promising looking technology or just a collection of free resources that i find the newsletter is free and you can sign up in the link below and if you want to speed up the construction of your scene sign up for polygon we spend hours creating high quality textures and models so you can spend your time doing what you do best which is making art sign up by clicking the link in the description special thanks to these rendering engines for giving us licenses to test with and also answering our pesky questions also thanks to my research assistant whose first job on this channel was learning the quirks of nine different rendering engines over the course of two years that's it hit subscribe if you want to stay in the loop of 3d with artist interviews tutorials breakdowns and more i'll see in the next video

Channel: Blender Guru

Views: 462,534

Keywords: render engine, speed, cycles, cycles x, redshift, vray, arnold, corona

Id: myg-VbapLno

Length: 15min 35sec (935 seconds)

Published: Wed Jul 07 2021

Reddit Comments

[u/L10-1N]

Really good to see “normal” testing, not tweaking until it’s right, but what works best

[u/Grilled-Burrito]

Nice!!

[u/OurOnlyWayForward]

Smh have you seen the eevee engine it’s a lot faster

[u/zacharyjordan23]

When seeing his face, did his voice pop into your guy’s heads too?

[u/GeorgeMcCrate]

When I read the title I thought you tested different engines while you were high on speed.

[u/Bob-Chaos]

Appreciate the dedication man

[u/AlexT05_QC]

Very interesting

[u/zacharyjordan23]

Omg it’s the blender guru IRL !!!