Rendering – Page 5 – blender base camp

Time is money! That's a very old statement at this point but it will always be accurate. As a 3D artist, you can spend as much time waiting for a scene to render as you spent actually creating the scene in Blender if you don't have the right settings for your render. Below are the main 9 methods that you can use to reduce the amount of time it takes your scene to render in cycles, there are other methods, but these have the most notable impact... Use The Graphics Card Reduce Your Sample Count Reduce Your Base Resolution Increase Your Tile Size (For Cycles Not Cycles X) Enable Image Denoising Disable Caustics Lower The Number Of Light Bounces Reduce The Number Of Polygons In The Scene Bake Your Lighting And Textures These are some of the quicker methods of reducing your render times for both images and animations in Blender. Now we will guide you through each of these methods and also how effective they can be. What Render Times Can I Expect Without Changing The Settings? To start off we need to establish a baseline for a render, which means we are going to have to create a scene and render that scene with all of the default settings. But why water time creating a new scene when we can just use one of Blender's own benchmark scenes instead. For the sake of far testing, we need to make sure that we use the exact same scene for every method that we use, to get an idea of each method's true effectiveness. So for this test, I will be using the barbershop scene that you can download straight from the Blender website here. Your base render times will be determined by the scene that you create and it's level of complexity, and the hardware used to render the scene. The Barbershop Benchmark Note: There will be users of Blender who are using the Cycles X version of the engine and those who are still using the original Cycles engine. Render times between those two tend to vary a fair bit, and while many of the methods below apply to both versions, a couple of these do not. We will therefore be rendering with both engines on the same tests for comparison. What Hardware Am I Using For The Test? We have a few computers here but I decided that it would be of most benefit if we choose a setup that was representative of what most artists could afford or wish to use, as the purpose here is to learn what you can do to reduce the time of your renders, and not how fast we can make a render on an ultra-powerful rig. Below are the hardware specs of the PC being used for the test: CPU - Intel I7 7700 RAM - 16GB 2133Mhz GPU - Nvidia RTX 2070 SSD - Samsung Evo 870 Power Supply - 750 Watts If you believe that your rig is more powerful, then you will likely see a significant reduction in render times, but our focus will be on changing the settings in Blender to minimize our times rather than changing up the hardware. We are using Blender version 3.0 beta for our render tests with the original cycles engine. We will also be using an experimental branch for Cycles X. When Cycles X is fully released we will update this article to see if any improvements have been made. The Base Test For the 1st render, we avoided changing most of the settings in Blender, making it as unoptimized as possible. The only changes we made were to set the resolution to a full 1080p, and make sure that we were using the CPU to start off with. The location of where to send your render in the output makes no difference at all. Our render time for the benchmark scene is listed below Render Time Unoptimized - 24M 37.41S So we now have our baseline for how long it takes for Blender to render the scene, we can move on to applying each of our methods for reducing the render times. For each method, we will be running two test renders of our scene. Method one is going to apply that method alone and none of the others, with the exception of enabling the GPU which needs to be enabled to apply a few of the other methods. In the second test, we will stack all the methods that we cover together, and see just how far we can go to reducing the render time of our scene. Switching To The GPU The first method that you should consider using is to switch your render device from your CPU to your GPU. In the large majority of cases, the GPU will be able to perform rendering workloads much more effectively than the CPU, provided the settings are optimized for the GPU, which we will see shortly. Before you can switch over to the GPU you must 1st make sure that Blender can locate the hardware in your machine. Go to EDIT > PREFERENCES > SYSTEM and the 1st setting that you will see in the window that pops up will be for your Cycles render devices. Cycles Render Devices It will most likely be set to none, so you will want to change to one of the other three options based on which GPU you are using. If you are using an AMD graphics card, then you will want to select the OpenCL option and then select the GPU from the list below. If you are using an OLDER Nvidia graphics card, such as the 1000 series or older, then you will need to select the CUDA option. If you are using the NEWER Nvidia graphics, such as an RTX 2060 or 3080, then you can select either CUDA or Optix as your render device method. While you can select either CUDA or Optix for certain graphics cards, we recommend Optix as it is normally the faster of the two. Once you have selected your render device you will then need to close the popup window as the settings will be saved automatically. Then go to the render tab in your properties panel and change the device from CPU to GPU Compute. Our render times are listed below: Enable The GPU Cycles X- 4M 57.72S Using The Old Version Of Cycles - 2H 4M 32S Analysis Straight away we can see that there is a massive difference between the old and new versions of the cycles engine. But more importantly, the old cycles engine seems to have taken a lot longer than even the CPU to render. Keep in mind that besides changing to the GPU we have not changed any of the parameters for the render, and so there is one setting in particular that is causing this two-hour render time that is around 5 times longer than the CPU. Cycles X though shows us that we can reduce render times significantly by changing to our GPU for rendering. While old cycles increases the render time by 5X with the current settings, Cycles X decreases the time by 5X. Increasing Your Tile Size This is the 1st real method that we will be testing for increasing our render speed for our GPU. However, this test is exclusive to the old version of cycles. Both the CPU and GPU render with a user-defined tile system, where the computer renders a section of the image fully before moving onto another section, or tile, until all of the tiles have been successfully rendered. This tile system has been replaced in newer Blender versions with Cycles X for a more streamlined full render approach, where the entire image is being rendered at the same time. This change does not only apply to GPU rendering but too CPU rendering as well. The tile method allows the user to define how much of the image should be rendered for each core used. For a CPU that has multiple cores but not as much horsepower, a lower tile size will render faster but multiple tiles will be rendered at once. For example, my 8 core CPU renders 8 tiles at once, while a 64 core AMD Threadripper can render 64 cores at once. The GPU on the other hand will only render a single tile at a time but can offer a lot more processing power to that tile. This is the reason why the last test using the GPU resulted in a substantial increase in the render times. The GPU was rendering a 16* 16-pixel tile size every time, which accounted for such a small area of the render. To change the pixel tile size, you will need to go to the render tab in the properties panel, which is also where many of the other methods are located as well, and locate the tab labeled 'Performance'. Then you will look for a subcategory that should have the label 'Tiles', which you can open up and begin changing the size of the tiles on both the X and Y-axis. For this, we will render the scene 3 times. We know that really small tile sizes will take forever so the first test will be much larger, at 128 pixels for each axis. Then for the second test, we will double the size on both axis to 256 pixels before doubling again for the third test to 512 pixels on both the X and Y-axis. Our render times are listed below: Increasing Your Tile Size To 128*128 - 18M 25.73S 256 Pixel Tile Size Render - 19M 52.82S 512 Pixel Tile Size Render - 20M 09.29 Analysis Before starting the test we could hypothesize that rendering speed would be able to increase the more we increased the tile size since we would be rendering a larger portion of the image at any one time, however, that is not necessarily the case here. While increasing the tile size from 16 pixels to 128 pixels does represent a dramatic improvement, the 256 test indicates that there is a limit to how high the tile size should go. In this case, there is a lot of information to process in this scene, and so we can only go so far with our tile size until we reach the max threshold of what our GPU can do. Once we get past 128 pixels in size we can see that the render times actually begin to increase again rather than decrease, although nowhere near to the extent of the smaller values. Does this apply to every scene? In a sense it does, but a simple scene with only a few objects may benefit more from a 512 pixel render than a 128 pixel one. So this should be used as a guide to selecting the right tile size for your scene and your graphics card. Note: Because the tile size is only applicable to the old version of cycles, and because the render time is so poor without the tile size being increased, all further methods tested on the older version of cycles will use the tile size of 128 pixels. Reducing The Sample Count The most sure-fire method of reducing your render times using Cycles is to lower your sample count. In order to process an image for rendering the software needs to 'pass through' the information and whatever data it finds, it uses to construct the image. This is what we call a sample, and every time we pass through our data we are sampling it for our image. This means two things, that increasing the samples will increase the quality of the final image, and that an increase in samples also means an increase in render time. By reducing the number of samples that we want to be used for the render, we can easily reduce the amount of time it takes to complete the process since samples occur consecutively one after another and not at the same time, each sample takes a period of time to complete. The drawback though is this can also affect the quality of the image if we go too low, so we need to find a good mix of the two. To lower the number of samples, go to the render tab in the properties panel and you will find a section labeled as 'Samples'. The setting that we will be looking to change is the render samples option, which is set to 250. We will perform 6 test renders in total, and 3 for each version of the engine. Test 1 will render at 125 samples, half of the original value. Test 2 will render at 50 samples, and the third test at 10 samples. 250 Samples 125 Samples 50 Samples 10 Samples Our render times are listed below: Cycles (Old Version) 125 Samples - 9M 38.31S 50 Samples - 4M 11.57S 10 Samples - 1M 22.77S Cycles X 125 Samples - 3M 06.28S 50 Samples - 1M 34.15S 10 Samples - 44.59S Analysis From the results we can see that the reduction of samples plays a huge role in the speed of our renders, however, we can also see a clear degradation in image quality as our target sample count is reduced. Images become much noisier the lower we go and if the image is not what we envisioned then regardless of how long the render takes its all a waster of time. Even at 125 samples, we see examples across the screen that indicate a reduction of overall clarity. If only there was a way to get rid of all the noise so that we could render at a lower sample count without losing any quality? Oh, wait there is a way! This is the same for both versions of the Cycles engine, where the number of samples produces similar image quality on both sides. An interesting side point here is that Cycles X is 3 times faster than old Cycles at 125 samples, while it is less than 2X at 10 samples. This suggests that Cycles X performs better with higher sample counts. Enable Image Denoising Introduced in various forms over the past few years denoising is a post-processing effect where artificial intelligence is used to improve the quality of an image. It originally appeared as a node in Blenders compositor but you can now have it as a setting that you can enable before you start rendering. Image denoising in itself actually increases the render time slightly, as it is an added part of the process that takes place after the samples have been calculated. But it is so effective at what it does that you could use it to substantially lower your sample count and still get great quality images. The amount of time that you can potentially save by combining image denoising with a low sample count far outweighs the time added by the denoising process. To enable denoising, you will find the option in the samples section of the render tab and find the label for Denoising. Enable the render setting and choose the method you want to use for your denoiser. Open Image Denoiser will use the CPU for denoising. Optix can be used for compatible GPUs and the NLM denoiser is available for all GPUs to use. Depending on your hardware the performance of these different methods may differ but the result is negligible in most cases, so we will be using the NLM since that is the most accessible option since the other two are based on hardware brands (Intel and Nvidia). For the test, we will run at 250 samples, 125 samples, 50 samples, and then 10 samples and compare the results to when the denoiser was not used. 250 Sample 125 Samples 50 Samples 10 Samples Our render times are listed below: Cycles: 250 Samples - 18M 03.45S 125 Samples - 9M 11.51S 50 Samples - 3M 54.62S 10 Samples - 1M 04.74S Cycles X: 250 Samples - 5M 09.89S 125 Samples - 2M 47.41S 50 Samples - 1M 30.93S 10 Samples - 54.87S Analysis So the important thing to determine is not the time it takes to render at each sample count, but whether or not the quality of the image is still usable, as, without denoising, even 125 samples would not be recommended for this benchmark scene because of the noise degradation. If we take a look at the times, we will see that for Cycles X render times have actually improved from when we rendered with the same settings but without using the denoiser, but not by an awful lot. this is surprising because we are adding an additional step to the rendering process, but we think there may be some render caching in the background going on to help make repeated renders slightly faster. What is more interesting is the overall quality of the images, as even the 10 sample image looks so much cleaner now even compared to the original 125 sample render. However, if you were to take a close look at the side of the cash register you will notice that the denoising is not perfect, and while for do get a cleaner image we also lose some of the finer details. You would always have to experiment with your sample count to find a good balance, but for this scene, 50-75 samples are probably good enough with denoising on, as we retain more detail. Reducing The Base Resolution If the resolution does not need to be anything specific, then lowering the resolution is another guaranteed way of lower your render times. After all, we are rendering information on a pixel-by-pixel basis, so the fewer pixels there are, to begin with, the faster it will go. Of course, reducing the resolution can reduce the image clarity when scaled up for viewing, but this will be nowhere near as obvious as reducing the sample count without denoising. To lower the base resolution, we need to go to the output tab in the properties panel. You will see straight away that we can adjust the render settings. Just above the values, you will see an icon of a few button points with lines, this is the button for a preset menu that allows the user to quickly swap between stored resolutions. We will be performing two tests here, as there are two ways to lower the resolution. For the first test, we will use the preset menu to set the resolution to a 720p output. For the second test we will reset the resolution back to 1080p, but this time we will reduce the percentage value just below the resolution to 50%. Our render times are listed below: Cycles Reducing The Resolution To 720p - 8M 19.37S Reducing The Resolution To 50% Of 1080p - 4M 54.15S Combining 720p Render With Other Methods - 1M 55.18S Cycles X Reducing The Resolution To 720p - 2M 18.87S Reducing The Resolution To 50% of 1080p - 1M 30.61 Combing 720p Render With Other Methods - 1M 01.56S Analysis At 720p resolution, we see the render time drop by around 60% from the original GPU render with the same default settings. 50% of 1080p is even better because it is a lower resolution than 720p. when we use the % slider, we are reducing the size on each axis, which means 50% on the X and 50% on the Y. Halving both axis is not halving the total resolution, it's actually a quarter of the original value. Think of it this way, 10 x 10 is equal to 100, correct? If we half each number we get 5 x 5, and that equals 25, one-quarter of a hundred. Its easy to get confused with how the percentage slider works because of this. Using denoising and lowering samples we were able to get our 720p to render to complete faster than our 540p render (50% of 1080p) while maintaining a higher resolution and better overall quality. Lowering the base resolution of your render has a significant effect on the render times because there are fewer pixels to render. Before deciding on this method though think about what your render is going to be used for. If you plan to sell the image it may not do so well if it is too low a resolution. If you are just adding it to your portfolio then it becomes a more viable option as you don't always need 4K rendered images to prove your skills as an artist. Where it becomes very useful is in animations. For animation you render one image per frame, meaning the more frames you have the longer the render. Unless you need to be at a higher resolution, lowering it down to 720p is a great balance between time rendered and quality. We recommend not going below 720p for a render unless you have specific guidelines that you need to meet, for example, a YouTube Thumbnail may need to be a lower resolution. Disable Caustics What are caustics? Well, caustics are an effect that is created when light is either reflected or passes through transmissive objects such as glass. There are two types of caustics that you need to know about, the first of which is refractive caustics and the second is reflective caustics. Refractive caustics is the effect passing through a glass object and passes over to the other side. the light does not go straight through but undergoes a process of refraction which involves the change of direction a beam of light undergoes when it passes from one medium to another. If you have a light source on one side of the glass object, then it will create a shadow on the other side, like any other type of object. However, look at the shadow and who may see a smaller area where light is hitting the surface. This is refractive caustics in action. We have an article on what the index of refraction is in Blender and how you can control this effect and effectively control your refractive caustics behavior. You can check out the article here. Reflective caustics is the effect of light that has been reflected off the surface of a glass or glass-like object. If that light then bounces off a second surface, like a wall, then you may even see a rainbow effect on that surface, due to how the waveforms of the light are affected when bouncing off the glass. By default our test scene already has these options switched off, so we are going to see what happens if we were to turn these options on. Caustics can be found by going to Properties > Light Paths > Caustics and then ticking the checkboxes for both reflective and refractive caustics. We have also set up a second test for this method, as we believe that turning on caustics is unlikely to make a significant change to our barbershop scene. So for the second test, we will be using the scene in the image below, which has several objects using glass-like materials. Caustics Turned On Caustics Turned Off You can see in the first image the effect refractive caustics have within the shadow of each of the glass objects, and by comparison how it looks when caustics are turned off in the second image. We also set the sample count much higher for this one, as caustics are heavy contributors to adding noise or 'fireflies' to the scene and more samples are needed to calculate it. The sample count is set to 1000 for more images and denoising is kept off. The resolution is full 1080p with no other changes from the defaults. Our render times are listed below: Cycles (Old) Enable Caustics Barbershop - 19M 37.13S (18M 48.33S Disabled) Enable Caustics Glass Scene - 7M 07.91S Disable Caustics Glass Scene - 4M 15.56S Cycles X Enable Caustics Barbershop - 5M 07.44S (5M 01.04S Disabled) Enable Caustics Glass Scene - 2M 16.93S Disable Caustics Glass Scene - 1M 50.86S Analysis In the barbershop scene, for cycles X, we saw a marginal increase of around 10 seconds when we decided to enable caustics for our barbershop scene. However, this can just about fall in the margin of error as no two renders will be finished at the exact same time even if they were identical in terms of their render settings. To make sure this was having an actual effect we decided on a last-minute retest of the scene with the caustics disabled and recorded a time of 5:01 for the render, about 6 seconds faster. So this does suggest that caustics plays a small role in render times. However, this was not the whole story as our glass scene demonstrated a larger gap between the 2 renders despite the fact that it was an easier scene to complete. We see a 16-second increase in this specific scene when caustics are enabled. This is by no means a revelation but does suggest that caustics can have a significant effect depending on the scene. This is the key point, as methods like reducing samples and resolution will have a certain impact across all renders, other effects like caustics are dependant on the scene itself. If no caustics are generated in the render, then having the option enabled won't make much difference. For the old version of cycles enabling caustics in the barbershop scene did represent a significant increase in render time, more so than on X. But the test scene is much more interesting, as we go from 7 minutes plus when caustics are active, to just 4:15 when they are disabled. So for the old version of cycles, caustics can hot much harder, while it has less of an impact with Cycles X. Lower The Number Of Light Bounces Perhaps the most important factor of all in a decent render is how the scene is going to be lighted. In Blender we can use light objects to create the lighting in our scene. When we render, light rays are sent out across the scene as a means of calculating the data. Every time the light hits the surface of an object, it reflects back out at a different angle and keeps going until it hits another object, then another, and then another, and so on. In the real world, this occurs an infinite number of times until all light has been absorbed. But in a 3D scene, each light bounce adds more processing to the render, so we don't want an infinite number of light bounces in our render. Fortunately, we can limit the number of times that the light will bounce off the surface of our objects by going to Properties > Render > Light Paths and then change the total number of light bounces as well as the number of bounces applied to diffuse, glossy, transmission and transparent bounces. For our benchmark scene, the number of bounces is already set to a very low value, 2 total bounces for each type of reflection, with the exception of the transparent reflection, which is set to 16. therefore we are actually going to reverse the testing and increase the number of light bounces on this occasion and then compare to the original time how much has been added on. We will also test setting the transparent value to become lower than 16, for example, either 4 or 8 and test what happens if we reduce the number of light bounces down to 1. Our render times are listed below: Cycles (Old): Base Time With Two Light Bounces - 18M 20.50S Decrease Transparent Bounces To 8 - 18M 11.49S Decrease Transparent Bounces To 4 - 18M 09.86S Decrease Total Bounce Value To 1 - 16M 55.11S Increase Bounces To 5 - 19M 08.98S Cycles X: Base Time With Two Light Bounces - 4M 52.57 Decrease Transparent Bounces To 8 - 4M 51.19S Decrease Transparent Bounces To 4 - 4M 55.82S Decrease Total Bounce Value To 1 - 4M 25.76S Increase Bounces To 5 - 5M 15.87S Best Settings Together - 57.77S Analysis The impact that this will have on your render times is dependant on the types of materials that are being used in your scene. There are for example a few transparent objects in the barbershop scene, such as the cobwebs on the roof, but they take up a very small portion of the scene and so render times are not really affected. If you look at the images for each test however you will see that lowering the transparent bounce value does affect the appearance of the cobwebs and the other objects that use transparency. Reducing the total light bounces to 1 does have a small impact on the render times in this scene, down 27 seconds from the base time with two light bounces. If you were to analyze the render for this test, you will notice that the room is ever so slightly harder and a couple of the glossy surfaces are no longer reflecting the environment. A good middle ground here would be to have the glossy value kept at 2 with the other values reduced to 1. On the other hand, increasing the light bounces to 5 saw a similar change in the opposite direction, increasing the render time to over the 5-minute mark. This demonstrates that the value set for light bounces can affect a scene, but not to the same extent as reducing the sample count, and again, sacrifices will be made when pushing the values too low. When bringing together our best settings for resolution, samples, light bounces, etc we get below the 1-minute mark at just 57 seconds, that's four and a half minutes faster than just rendering on the GPU without changing the settings on Cycles X. Reduce The Number Of Polygons In Your Scene More effective in highly detailed scenes, this method involves reducing either the total number of objects in your scene or lowering the triangle count of the existing objects can reduce the render time of your image. An object's data is calculated as a part of the render, so if it is not there, it is not calculated, and the total processing time needed is reduced. Since we don't want to reduce the number of objects in our scene, we can test a few methods for reducing the polycount of some of our objects, One method is to introduce the decimate modifier, which is a fast way of dramatically reducing the amount of geometry an object has. It will destroy your topology, and going too low can eliminate the detail very fast, but as we are only using the scene for render the goal will be to get that count as low as we can without losing any real details In many cases though the decimate modifier may not be required, if a subdivision surface modifier is already in effect, then lowering the count on that modifier will be just as effective. To avoid making any permanent changes to the scene here, and just to make things a bot easier, we created a second save for this test named reduce poly, and then apply the modifier to the objects in our scene. Without applying the modifier, we need to check how many triangles that we currently have in our scene, which we can view in the bottom bar of the interface which gives us all the information we need. At 8,348,423 triangles, there is probably more geometry here than most of the scenes that you will create, so lets see how much this impacts out render times. To keep our objects as close to their original shape as possible we will be using the unsubdivide method with an iteration value of 1, and reducing the render value of any object to 1. Our render times are listed below: Old Cycles - Reduce The Number Of Triangles To 7.2 million - 17M 52.33S Combine With The Other Methods - 1M 33.04S Cycles X - Reduce The Number Of Triangles To 7.2 million - 4M 40.22S Combine With The Other Methods - 54.98S Analysis This was a scene that had ALOT of objects and as a result was the longest one to test as there were over 1000 objects in the scene, with most of them being mesh objects. We managed to get the number down to around 7.2 million triangles without significantly altering the look of the scene or removing any objects. The results show a small decrease in render times to around 4 minutes and 40 seconds on Cycles X. This indicates that the geometry does play a part in render times but other factors, like the lighting and materials, will play a larger role. When combined with other methods, we reached a low of just under 55 seconds for the scene. Baking Your Lighting And Textures Every time that you decide to click on that render button, Blender has to calculate all of the data in your scene and produce an image of that scene based on the location of the main camera. This data includes the effect lighting has on textures, shadows being cast, ambient occlusion, etc. What if there was a way to reduce the amount of information that Blender needed to calculate for each render, besides the already covered method of lowering the geometry count. That method does in fact exist and is referred to as baking. When you bake information it stores that data and applies it as a permanent effect in your scene. For example, if you have an object that is casting a shadow on the floor, and you move the object, then the shadow will move as well. One of the main requirements for baking is that the mesh objects must have a UV map. This presents a problem with the benchmark scene as a lot of the objects in this scene do not have UV maps. So to conduct the test we will first create UV maps for as many objects as possible in the scene. To enable baking, go to Properties > Render > Bake and setting what type of bake that you want, followed by what you want to influences your bake. There are many bake types but to get a good idea of how effective it can be we set the bake type too combined, which bakes everything in the scene. Also, note that baking works on the objects that are selected and will ignore any that are not selected. So make sure to select all of the objects that you want to bake. If you attempt to bake any objects that do not have a UV map then you will get an error message pop up at the bottom of your screen. Our render times are listed below: Old Cycles Baking Your Lighting And Your Textures - 16M 08.48S Combine With The Other Methods - 1M 29.07S Cycles X Baking Your Lighting And Your Textures - 3M 55.98S Combine With The Other Methods - 52.57S Analysis We managed to reduce our render times by a decent amount by baking our settings, however, in this instance, the amount of time it took to set up the objects and then bake them was far longer than the time it took to complete the render. So is it worth using this method? Most scenes will not be as detailed as the benchmark scene, and you will be able to add UV maps to the objects as you create them, which will save a lot of time. The baking process itself can take up to a few minutes to complete for higher detailed scenes, and so there is not as much point to baking if your render is only going to take a few minutes anyway. Where this method becomes invaluable is in animations. The amount of time it takes to set up and bake the scene remains the same, but now you have to render an image for each frame of the animation, which dramatically increases the projected time. If a single frame takes 4:45 to render without baking, and 3:55 after baking, then you save 50 seconds per frame. If the animation is 120 frames in length, then you will be saving approximately 100 minutes in your render times. Be careful, however, as you don't want to bake any objects that will be animated in any way. Make sure to restrict baking for static background objects only. When We Put Everything Together To make things a bit clearer we have taken the data that we gathered from each of our test renders and stored it all in two easy-to-view tables. Note that for the old cycles we kept the tile size at 128 pixels for each of the remaining tests, therefore any % drops are based on that tile size. The first is for the old version of cycles and the second is for cycles X... MethodRender Time % Of Time Saved Final Render Time And % ReducedEnable The Graphics Card 2H 4M 32S -490%-Increase The Tile Size 18M 25.73S 27% 18M 25.73S (27%)Reduce The Number Of Samples 4M 11.57S 77% 4M 11.57S (77%) Reduce The Base Resolution 8M 19.37S 55%1M 55.18 (88%)Enable Noise Reduction 18M 03.45S 2% 1M 54.62S (88%)Disable Caustics 18M 48.33S 4%1M 53.99 (89%)Lower The Number Of Light Bounces 16M 55.11S 8% 1M 37.32S (90%)Reducing The Number Of Polygons in your Scene 17M 52.33S 3% 1M 33.04S (91%)Baking Your Scene 16M 08.48S 13% 1M 29.07S (91%)Render Times For Old Cycles (Recommended Settings Used/Tile Size 128*) MethodRender Time% Of Time SavedFinal Render Time And % ReducedEnable The Graphics Card4M 57.72SN/A4M 57.72SIncrease The Tile SizeN/AN/AN/AReduce The Number Of Samples1M 34.15S68%1M 34.15S (68%)Enable Noise Reduction5M 09.89SN/A1M 30.93S (69%)Reduce The Base Resolution2M 18.87S53%1M 01.56S (79%)Disable Caustics5M 01.04S2%*1M 01.56S (79%)Lower the Number Of Light Bounces4M 25.76S10%57.77 (80%)Reducing The Number Of Polygons In Your Scene4M 40.22S5%54.98S (81%)Baking Your Scene3M 55.98S20%52.57S (81%)Render Times For Cycles X (Recommended Settings Used) *Compared To Test When Caustics Were Switched On, time falls within the margin of error for render (2%). So as you can see there are a host of methods that you can use to substantially reduce the render times of your scenes, and this applies to both single images as well as full animations. Compared to the base CPU render, both versions of Cycles can other much greater rendering performance and really reduce the times, but keep in mind that for every advantage gained, there is always something lost. Reducing the sample count will create noise, and enabling denoising may reduce detail. Disabling caustics takes away an aspect of realism, while baking shadows means you can't edit your scene as easily after the render. Always keep in mind what each setting does, and if it is necessary for your specific project. For Cycles X, we can see that we managed to reduce the render time for our image by an impressive 81%. We could have gone lower, but this a test to combine the different methods for reducing render times without compromising the images final result. For the old version of Cycles, the savings are even greater at 91%, although the final render time is still over 50% longer than with cycles X. What Settings Do I Use? That will depend on the project, but to give you an idea I will always use denoising unless detail is the most important thing. I will use a lower sample count for animations more than I will for single renders. Resolution-wise, I like my scenes to be 4K, so that bumps up the render times a lot. For animations though, I will always go for a 720p res unless it is a requirement to go higher. Even with the right settings, a one-minute animation at 30 frames a second will take a long time to render. It's rare that you will have a scene that uses caustics, or where the use of caustics is obvious in that scene, so I will have them turned off most of the time, and only switch them on if the scene requires them. The poly count of individual models is effective enough to change the way the surface reacts to light, so I will use the level of detail I think is necessary for my scene. In most cases, reducing the geometry does not have enough of an impact on render times to be reduced so that the render speed can increase. Baking is a common method for improving performance in both rendering and in-game design. If you have a mid to high detailed scene that is complete and you have no plans to edit, used the baking tools to lower your baking times. As such, I often do bake my textures, lighting, and shadows for a heavy render, but it is always the last thing that I do and I will create a second save for it in case I change my mind later. Are There Other Methods Of Reducing Render Times? It may surprise you to learn that the nine methods listed above are not the only ways that you can reduce your render times. There are numerous other means of reducing the amount of time you have to wait for your scene to finish. We will list them below but keep in mind that these are more situational and their effectiveness is dependant on the type of scene you create. Clamp Lighting Use Portals For Indoor Scenes Adaptive Subdivision Surface Remove Volumetrics Lower Strand Count For Hair Particles Remove Alpha Channels Use Object Instancing Here Are Some Other Articles That You May Be Interested In Thanks for reading through the article, we hope it helped cover some of your questions. Below we have a list of additional articles on blender base camp that we think you might be interested in. How To Apply An Image Texture To An Object? How To Isolate A Single Object In My Scene For Editing? How To Make Your Background Transparent In Your Renders? Can I Make Money Using Blender To Make Art And Sell Digital Products? How To Remove All The Overlays In The 3D Viewport?