Page History

The goal here is to compare 3Delight's OSL rendering core with other renderers using C++ for shading   (namely Arnold and RenderMan/RIS) using C++ for shading. Since all renderers are quite different, we will try to get to a most common denominator, in terms of setup, to be able to compare apples to apples. We want to know: can we go as fast, in OSL, as highly optimized C++ ray-tracer ? How does OSL compare to our optimized RSL SIMD just-in-time compiler ?

In this particular case, we will be constructing an artificial test scene that simulates foliage.  Rendering foliage is a good stress test for many reasons:

• Many shader evaluations, including for transmission rays. No "opaque" object tricks are possible because leaves are usually modeled using cutouts. Shader evaluation efficiency is important.
• Many short ray probes necessitate a good integration and coordination between shading system and space partitioner.
• Any bottlenecks in the ray tracer tend to be amplified and adversely affect performance.

The Scene

The scene is designed in such a way as to put all the contenders in an even playing field and get meaningful performance numbers. For example:

• We will just use diffuse reflectors.
• We will disable any adaptive sampling so to make sure we have very close ray-counts.
• We will use only one diffuse bounce. This will circumvent some complex variables from the equation (Russian roulette and other tricks of the trade).  When looking at the statistics, all renders have a path length of 3.
• The scene is easy to load, setup and render. It is available for all tested renderers.

• All renders are done in Maya 2015 Extension 1.

Image ModifiedThe scene looks quite ugly in the viewport: just a large collection of rectangles generated using PaintEffects.

Image ModifiedThe render looks slightly better. Squares are transformed into circles using a cutout.
The scene is lit by two large area lights from each side.  

The cutout is done using a Maya Ramp.
In Arnold it is connected to "opacity", in RenderMan to "presence" and in 3Delight to "transparency" !
(3Delight shown here) 

The Renderers

	Arnold	RenderMan/RIS	3Delight OSL	3Delight RSL
Version	Image Modified	Image Modified	Image Modified	Image Modified
Technology	Unidirectional path tracer.	Using unidirectional path tracer. Other options are available but not useful for this test.	Unidirectional path tracer.	Undirectional path tracer
Shaders	C++	C++	OSL	RSL

The Methodology

We will be testing the wall clock time for all renderers. Every renderer will be run 3 times in succession and the average time will be taken. We make sure that nothing is running on the machine so not to slow down the poor renderers. The render is launched from Maya 2015 Extension 1. We are using a mid level Linux machine for our tests :

% lscpu

Architecture:          x86_64
CPU op-mode(s):        32-bit, 64-bit
Byte Order:            Little Endian
CPU(s):                16
On-line CPU(s) list:   0-15
Thread(s) per core:    2
Core(s) per socket:    4
Socket(s):             2
Vendor ID:             GenuineIntel
CPU family:            6
Model:                 26
Stepping:              5
CPU MHz:               2395.000
BogoMIPS:              4787.24
Virtualization:        VT-x
L1d cache:             32K
L1i cache:             32K
L2 cache:              256K
L3 cache:              8192K

% free -m

             total       used       free     shared    buffers     cached
Mem:         11984       8139       3844          0        151       4728
-/+ buffers/cache:       3259       8725
Swap:            0          0          0

The Setup

Each renderer uses a different sampling strategy and how rays are distributed between each sampled component.  We selected a setup that produces nearly the same number of rays in all renderers. Look wise, it was easy to obtain very similar renders between Arnold and 3Delight. We had to boost area light contributions in order to get a similar lighting in RenderMan/RIS.

More details:

• We use non-normalized area lights. This is because 3Delight OSL doesn't support normalized lights yet. 
• There is a slight difference in tint between Arnold and 3Delight. We think it's due to differences in color management between the two renderers
• RenderMan/RIS area lights sources had to be set with higher intensity. We are unsure why. 
• RenderMan/RIS has very different diffuse lighting component. Again, we are unsure why. One hint might be how the shading normals are treated 

The Results

_{* Taking into account the total number of traced rays}

Multi-Light Rendering Performance Test using 3Delight OSL

3Delight's multi-light feature allows you separate lighting components per light or per sets of lights. It is a subset of the LPE feature, in OSL parlance. Multi-light rendering is enabled in the Image Layers section of the OSL render pass; just select the RGBA layer and select the two area lights. This test evaluates the performance degradation when using this feature.

Select the two area lights to split the RGBA into two additional outputs (one for each area light)

In the snapshot of 3Delight Display below, you can see the resulting beauty (top left) and the two area lights 

Render time is almost identical, 34 seconds for the entire render.

Conclusion

• 3Delight's OSL-based path-tracer provides outstanding performance results. Building a rendering core around the OSL shading system, as opposed to just "integrating" OSL in the renderer, seems to have given 3Delight a good performance advantage.
• Multi Light in 3Delight doesn't have a perceptible adverse effect in this test (although from experience, rendering much more Multi Light AOVs, one can expect a 1-3% penalty).  
• This particular test shows the limitations of RSL shaders and the limitations of the JIT architecture they use.

Resources

Here are the links to reproduce the tests on your system.

3Delight packages used for testing: