...
The scene is designed to procedurally generate a number of area lights floating on top of a "city".
- Only diffuse reflectors. The original test scene had a diffuse+specular surface but that generated a considerable amount of additional noise in Arnold. Since we want to concentrate on light sampling here, we decided to go for a simpler setup.
- We will disable any adaptive sampling so to make sure we have very close ray-counts.
- We will use only direct lighting to estimate the geometric area light contribution. In the statistics files for each renderer, one can see that we have only one path length.
- The light sources contain about 80K triangles.
- All Renders are done in Maya 2016.
The Renderers
| Arnold | RenderMan/RIS | 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 |
...
We are interested to find out about:
- The quality of the geo light samples drawn by each renderer. How fast do we converge to ground truth by increasing the number of samples ?
- Performance. How fast is the sampler to produce an image of a given quality ?
...
Arnold — For light samples, Arnold uses effective sample counts that are proportional – within a constant – to the square of the user specified value. As we will see, this makes sense from a UI standpoint since the variance follows the inverse of the same rule in the case of Arnold. This makes the light samples slider linear in term of perceived noise. In the Arnold tables below, we will specify the effective samples per pixel along with the user samples. Those effective samples are gather from Arnold's diagnostics files.
RenderMan/RIS – In Arnold and 3Delight, light samples are the single "go to" parameter to control image quality when only direct lighting is considered. In RenderMan/RIS, we had to match light sample count with BxDF sample count to achieve acceptable quality and satisfactory convergence rates. Using light samples only – or BxDF samples only – produced slowly convergent renders. In RenderMan/RIS result data, "N samples" means N samples for both light and BxDF. We did all the test tests with the "advanced (mode 4)" light sampler — other since other samplers did not provide acceptable results for this test case. The samples used by the renderer are the ones entered in the UI and are not squared as in Arnold. Note that we used the path tracer with one bounce instead if of the "direct lighting" algorithm for one of the images because of a crash (quality and speed did not differ seem suffer although there were some minor differences).
3Delight – We have only one control for the general quality of the render. In the case of direct lighting, 3Delight "understands" that samples are best used for light sampling and that's what it does. As tests will show, those samples have a linear impact on perceived noise levels. Note that 3Delight doesn't care how many geo lights there are in the scenes : one sampling parameter acts on all lights adaptively. This is not the case with RenderMan/RIS and Arnold, where user intervention is necessary with each added geo light. The test scene contains only one geo light to simplify comparison
Results
| The following graph gives a good idea on the convergence rate of the different light samplers. |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| The following graph shows the time required to achieve a certain quality. From user's perspective, this is an important quantity. |
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| The following graph shows how much time it takes to build the acceleration data structure depending on sample/ray count. |
|
...