Geo Light Sampling Stress Test

It is not uncommon for production scenes to rely heavily on geo area lights. In this test we will compare geo light sampling technology in 3Delight OSL, Arnold and RenderMan. We will use a test with a geometric area light that is composed of a relatively large number of faces. The test, although limited, should allow us to find the convergence rate of each algorithm as well as general performance.

The Scene

The test scene allows for procedural generation of floating area lights using the "Tubes Per Step" PaintEffects attribute.

The scene is designed to procedurally generate a number of area lights floating on top of a "city".  

• Only diffuse reflectors.
• 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

Methodology

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 ?

We will start by creating a "ground truth" image for each renderer (encouragingly, images produced by both 3Delight and Arnold are almost exactly the same). This image is generated by using a very large amount of samples so there is no more apparent noise. We will then render several images with varying amount of samples and measure the RMSE between these images and ground truth. Timings and statistics will be collected at each render. Having this data will allow us to draw a conclusion about the convergence rate and general performance.

The Setup

We use a 1x1 pixel sample in all renderers. Adaptivity is disabled as well as all additional bounces. In Arnold, the light samples are attributes of the geometry. In RenderMan/RIS the light samples are attributes of a custom shape. In 3Delight, the light attributes are on Maya's area light. 

Notes

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 tests with the "advanced (mode 4)" light sampler 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 of the "direct lighting" algorithm for one of the images because of a crash (quality and speed did not  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.

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.

Arnold

*TTFP = Time to first pixel.

Samples (effective)	2 (1.23)	4 (4.91)	8 (19.64)	10 (30)	16 (78.56)	32 (314.29)	64 (1257.18)
Image
Time	1	2	6	9	21	81	492
TTFP*	0	0.35	1.2	2.0	3.2	11	41
Shadow Rays	0.678 M	3.26 M	10.8 M	16.94 M	43.4 M	173.6 M	694.5 M
RMSE	0.15699	0.100115	0.0501787	0.0396399	0.0242515	0.0117413	0.00693426

3Delight

RenderMan/RIS

Conclusions

• 3Delight generates light samples that are algorithmically better than both Arnold and RenderMan. In short, for x effective samples:

1. 1. 3Delight Variance ~ 1/x
   2. Arnold Variance ~ 1/sqrt(x)
   3. RenderMan/RIS Variance ~ 1/sqrt(x) (but could be slightly worse, needs more tests)
   
   

• 3Delight is slower to generate these samples. For draft renders (high variance), Arnold is fastest. For final renders (low variance) 3Delight becomes increasingly faster with increasing samples.
• Both Arnold and RenderMan/RIS produce biased images at low sample counts. More specifically: images are darker. 3Delight manages to keep the same energy overall independently of sample counts.
• Arnold, 3Delight and RenderMan/RIS rely on acceleration data structures to sample the geometric area lights. In Arnold and RenderMan, the algorithmic complexity to build those data structures is tied – linearly, as the graph shows –  to the number of samples (as well as the complexity of the light). In 3Delight, only to the complexity of the light matters (time to first pixel for 3Delight was 2-3 seconds no matter how many samples there are).  
  
  
  

Resources