Ray Tracing Stress Test

The goal here is to compare 3Delight's OSL rendering core with other renderers using C++  for shading  (namely Arnold and RenderMan RIS). 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 ?

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 modelled 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 don't want complexe BRDFs sampling to get in the way.
• 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 complexe variables from the equation (Russian roulettes and other tricks of the trade). 
• The scene is easy to load, setup and render. It is available for all tested renderers.

• All renders are done in Maya 2015.

  
  
  

  ---

  
  

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

The 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	3Delight OSL
Version
Technology	Unidirectional path tracer.	Using unidirectional path tracer. Other options are available but not useful for this test.	Unidirectional path tracer.
Shaders	C++	C++	OSL

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 machines so not to slow down the poor renderers. The render is launched from Maya. We have three test machines available:

The Setup

	Arnold	RenderMan	3Delight OSL
Screent Shot
Remarks		Min Samples = Max Samples Light Samples = 2, seems to give closer results to Arnold	Only shading samples to set for sampling BRDFs. 3Delight OSL takes care of the rest.

The Results

* Taking into account total number of rays traced but not CPU usage.

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).

Resources

Extra Test For 3Delight OSL

3Delight has a feature called multi-light. It let's you separate lighting components per light or per sets of lights. It is a subset of the LPE feature,  in OSL parlance. This extra test was done to see the performance degradation when using this feature. Setup is easy and can be enabled in the Image Layers section of the OSL render pass. Just select the RGBA layer and select the two area lights.

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 the two area lights 

Render time is almost identical, 64 seconds for the render, meaning that LP