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 ? How does OSL compare to ours 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 modelled 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.
...
- We will just use diffuse reflectors. We don't want complexe complex 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 complex variables from the equation (Russian roulettes roulette 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.
...
| Arnold | RenderMan/RIS | 3Delight OSL | 3Delight RSL | |
|---|---|---|---|---|
| Version |
|
|  
|
|
| Technology | Unidirectional path tracer. | Using unidirectional path tracer. Other options are available but not useful for this test. | Unidirectional path tracer. | Undirectional path tracer |
| RSShaders | C++ | C++ | OSL | RSL |
...
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:
...
2015 Extension 1. We are using a mid level Linux machine for our tests :
% lscpu
| Code Block |
|---|
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
| Code Block |
|---|
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
| Common | Arnold | RenderMan/RIS | 3Delight OSL | 3Delight RSL | |
|---|---|---|---|---|---|
| Version |
|
|
|
|
|
| Remarks | Area lights have 1 sample each. | Min Samples = Max Samples. |
|---|
Arnold in terms of ray counts. | Only shading samples to set for sampling BRDFs. 3Delight OSL takes care of the rest. |
The Results
| 3Delight OSL | Arnold | RenderMan/RIS | |
|---|---|---|---|
| Image |
|
|
|
| Total number of rays | 28.5 Millions | 31.6 Millions | 30.9 Millions |
| Time on Linux | 33 seconds | 50 seconds | 74 seconds |
| Compared to 3Delight OSL * | -- | 1.36 times slower | 2.07 times slower |
* 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. Performance penalty is almost nil.
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
Here are the links to reproduce the tests on your system.
| Arnold | 3Delight OSL & RSL | RenderMan/RIS | |
|---|---|---|---|
| Maya Scene (ASCII) | disks_arnold.ma | disks_3delight.ma | |
| Statistics | stats_arnold.1.txt | stats_3delight.txt | |
| EXR images (linear) |
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 the two area lights
Render time is almost identical, 64 seconds for the render, meaning that LP
...