Radiance ambient and penumbra test v2.0

Mark J. Stock


Both ambient accuracy and penumbral smoothness are qualities that make a raytraced image appear more realistic. We tested Radiance's rpict renderer, with some specific parameters set, to determine the optimal settings to achieve smooth gradations in the ambient calculation and smooth-appearing penumbras.

Because the scenes that we are interested in rendering are composed of very large numbers of primitives, both near the observer and far away, and as a result, the compiled octree commonly fills up all available RAM (1 GB on my machine); Greg Ward suggested that I set rpict's -aa (ambient accuracy) parameter to zero. This forces an ambient calculation to be made for every intersection of a view ray with a surface (with a few minor exceptions, such as mirrors), instead of computing and caching all of the ambient points. Note that the scene used for these tests in no way fills up available RAM, and a high-quality image can be created in less time using ambient caching.

In addition, because of the inability of simply using the -ds (direct sampling) parameter alone to create smooth penumbras (we have it set at 0.1), we also set the -dj (direct jitter) parameter rather high (0.6).

Thanks to suggestions from the Radiance-Online list, I changed the pixel sample -ps parameter from the Radiance-standard 4 to 1, thus sending a view ray into every image pixel. Renderings took a little longer with this parameter set as such, but the penumbras now appear much better for lower oversampling multipliers. To see the results from the -ps 4 tests, click here.

With these parameters set, we rendered a scene of a modified Sierpinski gasket with a single area light and no sky dome while varying the following parameters:

Ultimately, we decided to filter all images down to 256x256 pixels using pfilt with the -r 0.7 option and save them as PNG files. We based that smoothing radius on some of our previous work.

The rpict statement used is the following:

rpict -vp 3.6 2 1.5 -vd -3.6 -2 -1.1 -vh 25 -vv 25 -ps 1 -ds 0.1 -dj 0.6 -aa 0 -ab N -ad N -x N -y N scene.oct

Of additional importance is the use of rpict's default values for the following parameters:

-pj 0.67 -pt 0.05 -aw 0 -as 0
The perl script used to make the images in this table is called renderall.pl, and the source files are in this directory.

NOTE: The Radiance distribution was compiled with the -DMC option, which enables true Monte-Carlo sampling of specular highlights, penumbras, and the like. This causes no repeatable change in render times.

NOTE: All reported CPU times are from an Athlon XP 2000 processor in a system with 1 GB RAM.

Using -ab 1

-ad 4 -ad 16 -ad 64 -ad 256
1x final resolution
0m1.360s, 44519 bytes

0m3.940s, 41738 bytes

0m22.810s, 37804 bytes

1m10.120s, 36406 bytes
2x final resolution
0m5.460s, 40406 bytes

0m15.780s, 37150 bytes

1m30.950s, 33799 bytes

4m39.110s, 32805 bytes
3x final resolution
0m12.220s, 37332 bytes

0m35.330s, 34375 bytes

3m25.220s, 33799 bytes

10m28.280s, 30451 bytes
4x final resolution
0m21.830s, 35207 bytes

1m2.900s, 32452 bytes

6m5.380s, 29878 bytes

18m36.590s, 28983 bytes
6x final resolution
0m48.930s, 32650 bytes

2m21.350s, 30269 bytes

13m38.770s, 28058 bytes

41m50.730s, 27391 bytes
8x final resolution
1m26.690s, 31005 bytes

4m10.910s, 28863 bytes

24m17.530s, 26929 bytes

74m30.980s, 26363 bytes
12x final resolution
3m15.640s, 29178 bytes

9m24.930s, 27282 bytes

54m33.880s, 25573 bytes

167m13.340s, 25184 bytes

Using -ab 2

-ad 4 -ad 16 -ad 64 -ad 256
1x final resolution
0m2.280s, 47169 bytes

0m17.720s, 43045 bytes

3m47.160s, 38187 bytes

45m27.320s, 36587 bytes
2x final resolution
0m9.050s, 41856 bytes

1m11.010s, 37643 bytes

15m13.030s, 33808 bytes

181m39.810s, 32624 bytes
3x final resolution
0m20.300s, 38146 bytes

2m39.980s, 34594 bytes

34m6.890s, 31255 bytes

410m22.290s, 30117 bytes
4x final resolution
0m36.130s, 35878 bytes

4m44.400s, 32651 bytes

60m48.460s, 29513 bytes
6x final resolution
1m20.980s, 33081 bytes

10m41.270s, 30186 bytes

136m30.290s, 27701 bytes
8x final resolution
2m24.390s, 31263 bytes

18m58.690s, 28712 bytes

244m32.980s, 26315 bytes
12x final resolution
5m24.010s, 29200 bytes

42m34.800s, 26918 bytes

544m40.140s, 24981 bytes


As is readily apparent, smooth penumbras require high oversampling. Less oversampling would be required for smoother appearance of both penumbras and normal surfaces, but that would lower the overall level of detail in the image, a comprise we chose not to make.

The effect of changing the ambient bounce setting was somewhat predictable. Noticeable differences exist in the shadow regions between otherwise-equivalent images when the parameters is changed from 1 to 2. Much less difference is seen as the parameter is raised to 3, definitely not enough difference to warrant the increase in render time. This parameter was not the main focus of this test, though. It was mainly used to try to affect the influence of -ad on the images.

The effect of the -ad is surely the most interesting result from this test. At 1x resolution, obviously, the low sampling used for the -ad=4 and 16 cases causes clear speckling of the final image; while -ad 64 and -ad=256 create images with very smooth intensity gradations. Obviously, if penumbras were not called for, one would need no more than 3x oversampling and -ad of 64.

It would be important to note that the PNG file size seems to be a fairly good rating of the overall quality of the image. Any images with file sizes less than 32000 appear to be very high quality, while file sizes under 30000 appear nearly perfect. We shall use this system as a quality parameter later.

Notice that when oversampling is doubled (1x to 2x, or 3x to 6x), four times as many view rays are shot through each pixel window, making the primary contribution of ambient rays equivalent to the next level tested (-ad 4 becomes -ad 16, etc.), but the render time for these "equivalent" renderings strongly favors the one with higher oversampling and less ambient divisions! This is more evident for the cases with more ambient bounces, so let's start with one ambient bounce, and look at the numbers:

-ab 1

Oversampling -ad CPU time file size
1x 256 1m10.120s 36406
2x 64 1m30.950s 33799
4x 16 1m2.900s 32452
8x 4 1m26.690 31005

As you can see, the render times are roughly equivalent, as would be expected with only one ambient bounce allowed. Additionally, the file sizes decrease significantly, likely due to both a smoother penumbral shadow and smoother intensity gradients on the faces. We found that these files also appeared smoother and more attractive.

When we look at images rendered with two ambient bounces, we should expect some differences. Whereas the first bounce should shoot an equivalent number of rays into the hemisphere, the second bounce should shoot fewer rays as -ad goes down. Theoretically, this should lead to decreased rendering times and reduced image quality.

-ab 2

Oversampling -ad CPU time file size
1x 256 45m27.320s 36587
2x 64 15m13.030s 33808
4x 16 4m40.400s 32651
8x 4 2m24.390s 31263

Instead, what we see is sublinear decrease in render times (meaning that the reduced weight of the second bounce rays allows more at -ad 64 to be ignored), and an increase in image quality (though, again, that could be caused by the smoother penumbras). The effect of this method is to create a system by which we can force more ambient rays per pixel at the first bounce (where their visual effect is greater), and fewer for the second bounce and beyond (where visual effect is calculable, but less important).


For the renderings we desire---with huge geometries, smooth penumbral shadows, and proper ambient lighting---we recommend -ab 2 to capture enough interreflection to be interesting; oversampling of 6 or more to smooth the penumbras, and -ad 4 or 8, whichever turns out to provide sufficient smoothness on surfaces for available rendering time.

As an example, the image linked from the thumbnail above is cropped from a 4000x4000 pixel image, which came from a 16000x16000 pixel original. The scene is composed of 531441 cubes, or about 3.2 million primitives. It was rendered with default Radiance options (including -ps 4), except for -ab 2 -aa 0 -ad 8. It took 16.247 hours to render. I can't even begin to calculate how long this scene would take to render using ambient value caching.

Mark J. Stock, Aerospace Engineering, The University of Michigan
page created: 2003-09-30, last modified: 2003-10-02