## Effect of Blender decimate ratios on bidir render times

Post your tests, experiments and unfinished renderings here.

### Effect of Blender decimate ratios on bidir render times

I love LuxRender's bidirectional renderer for its caustics, but of course it is quite slow. I wondered whether reducing the level of mesh detail would provide any significant reduction in render times, and what the trade-off would be in terms of render quality. I searched the LuxRender forum, the BlenderArtists forum and I did a general online search but I couldn't find any information on this issue, so I decided to check for myself.

To test, I used a detailed mesh I have created with LuxRender's Glass2 material in LuxBlend with lux-opencl_linux64_18-12-2017 in Blender 2.79. The mesh contains a flower-symbol displacement on each of the large outside surfaces (but not on the inside surface, which is mostly flat). I'm not an experienced modeller, so to retain all of the smooth details I wanted I ended up with a mesh containing nearly 800,000 vertices, all in quads. (I don't know if other people use meshes with that much detail, but it sounds excessive to me.) I then added a soft cloud noise displacment modifier to provide small surface variations across the whole mesh, because I wanted to have some naturalistic irregularities in the glass.

To reduce the number of elements in the render mesh, I added a Decimate modifier, using the Collapse type.

I then performed the renders in Blender via a python script using LuxCore API bidirectional render engine type. I used Decimate Collapse ratios of 0.0010, 0.0100, 0.1000 and 1.000 (ie. no decimation). Each of these renders was done at Halt Samples values of 100 and 2000.

Note: I was using the cpulimit utility to limit Blender to 75% of the cpu cycles. This was in order to prevent my long-suffering cpu from running hot during the renders. It adds to the render times, but it keeps my cpu temp oscillating from about 45ᵒC to 60ᵒC instead of being constantly over 70ᵒC here in Brisbane's subtropical summer.

Code: Select all
                            Render Time (h:mm:ss)Collapse ratio        100 samples     2000 samples 0.0010                 0:00:55         0:11:37 0.0100                 0:00:56         0:11:53 0.1000                 0:00:56         0:12:16 1.0000                 0:00:38         0:12:29

Conclusion: Reducing the level of detail in the mesh does provides a small reduction in the render times for longer renders. In my case, however, it did cause a noticeable reduction in the quality of the rendered image. Based on this, I won't be placing a lot of importance on reducing the mesh detail for prominent objects in this type of scene. The main problem I encounter with highly detailed meshes is that they may reduce the responsiveness of Blender's UI.

P.S. I won't upload the .blend file because it is a whopping 160 megabytes.

Ratio 0.0010 @ 100 samples = 0:00:55

Ratio 0.0100 @ 100 samples = 0:00:56

Ratio 0.1000 @ 100 samples = 0:00:56

Ratio 1.0000 (no decimation) @ 100 samples = 0:00:38

Ratio 0.0010 @ 2000 samples = 0:11:37

Ratio 0.0100 @ 2000 samples = 0:11:53

Ratio 0.1000 @ 2000 samples = 0:12:16

Ratio 1.000 (no decimation) @ 2000 samples = 0:12:29
Philstix

Posts: 36
Joined: Tue Sep 23, 2014 5:30 pm

### Re: Effect of Blender decimate ratios on bidir render times

Philstix wrote:Conclusion: Reducing the level of detail in the mesh does provides a small reduction in the render times for longer renders. In my case, however, it did cause a noticeable reduction in the quality of the rendered image. Based on this, I won't be placing a lot of importance on reducing the mesh detail for prominent objects in this type of scene.

From a theoretical point of view, ray tracing has an O(log n) complexity with the number of triangles. This means, for instance, you have to increase the number of triangles by 4 to double the rendering time. So, yes, more triangles you have and more efficient it is. This is the major theoretical winning point of ray tracing over rasterization (OpenGL, DirectX, Vulkan, etc. rendering). Rasterization has usually an O(n) complexity: double the triangles to render and you double the rendering time.

Nowadays, rendering times are more driven by materials complexity and noise than just triangle count.