Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.


It is not uncommon for production scenes to rely heavily on geo area lights. In this test we will compare Geo Light geo light sampling technology in 3Delight OSL, Arnold and RenderMan/RIS. 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. 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 raymeaningful  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 lenghtlength.
  • The light sources contain about 80K triangles.
  • All Renders are done in Maya 2016.

The Renderers

Info

RenderMan/RIS 21 is about to be released with new sampling technology. We will complete the test as soon as the renderer is available.




ArnoldRenderMan/RIS3Delight OSL
Version

Image Added

Image Added


Image Added

TechnologyUnidirectional path tracer.Using unidirectional path tracer. Other options are available but not useful for this test.Unidirectional path tracer.
ShadersC++C++OSL

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 ?
  • How do the algorithms scale with more complex area light geometry ?

We will start by creating a "ground truth" image for each renderer (this image is ; an image generated by using a very large amount of samples so there is no more apparent noise). We . Although it is normal for images generated by each renderer to vary slightly, encouragingly, images produced by both 3Delight and Arnold are almost exactly the same.  We will then render several images with varying amount of samples and measure the RMSE between these images and the ground truth for each renderer. Timings and statistics will be taken collected at each rendererrender. 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 About Sampling Parameters

Arnold

3Delight

RenderMan

Results - RMSE

Arnold

 

Info

Admittedly, those are not standard settings for any useful render. The goal here is to isolate one algorithm in order to understand its behaviour. Understanding an algorithm can shed light on its strengths and weaknesses and allows us to draw interesting conclusions for the more general case.





ArnoldRenderMan/RIS3Delight OSL
General Parameters

Image Added

Image Added

Image Added

Geo Light Parameters

Image Added

Image Added

Image Added


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 gathered from Arnold's diagnostics files.

RenderMan/RIS – While in Arnold the light samples effectively control image quality when only direct lighting is needed, in RenderMan/RIS, we had to match light samples count with BxDF samples count to achieve acceptable quality and satisfactory convergence rates. Using light samples only, or BxDF samples only, produced noisy renders.  In the RenderMan/RIS results below, "N samples" means N samples for both light and BxDF.   We did all the tests with the "advanced (mode 4)" light sampler since it produced the best results. 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 to suffer although there were some minor differences in the render). 

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

Chart
width800
domainAxisUpperBound300
titleRMSE vs. RAYS
typexyLine
yLabelRMSE
domainAxisLowerBound0
xLabelMillion Rays



Rays2.453.134.517.2712.7823.845.8890.1
3Delight0.09331420.06582660.04412480.02904390.01855750.01175660.00752546

0.00449892



Rays0.6783.2610.816.9443.4173.6694.5
Arnold
Samples2 (1.23)4 (4.91)8 (19.64)16 (78.56)32 (314.29)64 (1257.18)ImageImage Removed

Image Removed

Image Removed

Image Removed

Image Removed

Image Removed

Time1s2s6s21s1:218:12Shadow Rays0.678 M

3.26 M

10.8 M43.4 M173.6 M694.5 MRMSE
0.156990.1001150.05017870.03963990.02425150.01174130.00693426

...



Rays
Samples
1.472.94
48163264128256Image

Image Removed

Image Removed

Image Removed

Image Removed

Image Removed

Image Removed

Image Removed

Image Removed

Time5.72s8s12.82 s22.18 s40.92 s86.91165.69 s302.98Shadow Rays2.45 M

3.13 M

4.51 M7.27 M12.78 M23.8 M45.88 M90.1 M
5.8811.721.147.0294.14376.3751.3
RenderMan/RIS0.1511250.1214870.09536490.07281480.05206060.03738760.02653880.01381480.00854045



The following graph shows the time required to achieve a certain quality. From user's perspective, this is an important quantity.

Chart
width800
titleRMSE vs. TIME
typexyLine
yLabelRMSE
xLabelTime (seconds)
Time5.247.1811.2120.6835.8669.48134.18265.05
3Delight
RMSESamples
0.09331420.06582660.04412480.02904390.01855750.01175660.00752546

0.00449892

RenderMan

Time12
4
6
8
9
32
21
64
81
256
492
512
Arnold
1024Image

Image Removed

Image Removed

Image Removed

Image Removed

Image Removed

Image Removed

Image Removed

Image Removed

Image Removed

0.156990.1001150.05017870.03963990.02425150.01174130.00693426
Time6.
74s
747.
23s
237.
99s
999.
42s
4218.
51s
5129.40
1:38RMSE
98.08
3:15.776:23.39Rays

1.47 M

2.94 M

5.88 M

11.7 M

47.02 M94.14 M376.3 M751.3 M1499 M
383.39
RenderMan/RIS
0.1511250.1214870.09536490.07281480.0373876


0.02653880.01381480.00854045
0.00396

...

The following graph shows how much time it takes to build the acceleration data structure depending on sample/ray count.

Chart
width800
domainAxisUpperBound300
title
RMSE
Time to First Pixel vs.
RAYS
Rays
typexyLine
yLabel
RMSE
Time to First Pixel (seconds)
domainAxisLowerBound0
rangeAxisUpperBound50
xLabelMillion Rays
Rays2.453.134.517.2712.7823.845.8890.1
3Delight
0.09331420.06582660.04412480.02904390.01855750.01175660.00752546
2222222

2

0.00449892

Rays0.6783.2610.843.4173.6694.5
Arnold0
.15699
0.
100115
35
0
1.
0501787
2
0
3.
0242515
2
0.01174130.00693426
1141
Rays1.472.945.8811.747.0294.14376.3751.3
RenderMan33.244.7915.551.297

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
Image Added



Image Added

Image Added

Image Added

Image Added

Image Added

Image Added

Time1 sec.2 sec.6 sec.9 sec.21 sec.81 sec.492 sec.
TTFP*0
.1511250.1214870.09536490.07281480.03738760.02653880.01381480.00854045

The following plot gives us a good idea the time required to achieve a certain quality. From the user perspective, this is an important quantity.

sec.0.35 sec.1.2 sec.2.0 sec.3.2 sec.11 sec.41 sec.
Shadow Rays0.678 M

3.26 M

10.8 M16.94 M43.4 M173.6 M694.5 M
RMSE0.156990.1001150.05017870.03963990.02425150.01174130.00693426

3Delight

Samples248163264128256
Image

Image Added

Image Added

Image Added

Image Added

Image Added

Image Added

Image Added

Image Added

Time5.24 sec.7.18 sec.11.21 sec.20.68 sec.35.86 sec.69.48 sec.134.18 sec.265.05 sec.
TTFP2 sec.2 sec.2 sec.2 sec.2 sec.2 sec.2 sec.2 sec.
Shadow Rays2.45 M

3.13 M

4.51 M7.27 M12.78 M23.8 M45.88 M90.1 M
RMSE
Chart
width600
titleRMSE vs. TIME
typexyLine
yLabelRMSE
xLabelTime
Time5.72s812.8222.1840.9286.91165.69302.983Delight
0.09331420.06582660.04412480.02904390.01855750.01175660.007525460.00449892



RenderMan/RIS


Time
Samples12
62181492Arnold0.156990.1001150.05017870.02425150.01174130.00693426
481632642565121024
Image

Image Added

Image Added

Image Added

Image Added

Image Added

Image Added

Image Added

Image Added

Image Added

Image Added

Time6.74 sec.7.23 sec.7.99 sec.9.42 sec.12.12 sec.18.51 sec.29.40 sec.98.08
383.39RenderMan0.1511250.1214870.09536490.07281480.03738760.02653880.01381480.00854045

Results - Scalability

For this test we will render 3 images that have a similar RMSE in all renderers but with a much higher area light count. We increase the Tube Per Step to 200 (10 times more area lights) and re-time the results. 

...

sec.195.77 sec.6:23.39 min:sec.
TTFP3.1 sec.3.2 sec.4 sec.4.7 sec.6.7 sec.9 sec.15.5 sec.51.2 sec.

97 sec.



Rays

1.47 M

2.94 M

5.88 M

11.7 M

21.1M47.02 M94.14 M376.3 M751.3 M1499 M
RMSE0.1511250.1214870.09536490.07281480.05206060.03738760.02653880.01381480.008540450.00396



Conclusions

  • 3Delight generates light samples that are algorithmically better than better (in term of variance) than both Arnold and RenderMan. In short, for x effective samples:
    1. 3Delight Variance ~ 1/x
    2. Arnold Variance ~ 1/sqrt(x)
    3. RenderMan/RIS Variance ~ 1/sqrt(x) (possibly slightly worse but could be within a constant)

    Image Added
  • 3Delight is slower to generate these samples. Meaning that for For draft renders Arnold/PrMan will seem faster(high variance), Arnold is fastest. For final renders (low variance) 3Delight is fastest and becomes increasingly faster .
  • Using so much less samples also makes 3Delight faster when shading is more expensive
  • RenderMan seems to have difficulties in sampling.
  • Arnold has a solid albeit O(N^2) algorithm (vs O(N) in 3Delight)  and compensates to a certain degree with very fast light sampler.
  • When combining BRDFs, 3Delight is even less noisy. 
  • with increasing samples.
  • Arnold and RenderMan/RIS draw samples at about the same speed, but the quality of Arnold samples is better. 
  • 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/RIS, the algorithmic complexity to build those data structures is tied linearly to the number of samples (as well as the complexity of the light). In 3Delight, only the complexity of the light matters (time to first pixel for 3Delight was 2-3 seconds no matter how many samples there were).  



Resources



RenderMan/RISArnold3Delight
Images and Statsarnold.tar.gz3delight.tar.gz
Maya Scenemal_prman.mamal_3delight.ma
Remarks
The same scene works with both 3Delight and Arnold