Radiance ambient and penumbra test v2.0

Introduction

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:

• -ad (ambient divisions) This is how many sample rays are sent from each ambient point into the hemisphere to determine the indirect incident light. We used values of 4, 16, 64, and 256,
• -ab (ambient bounces) This is how many bounces indirect light is allowed in the ambient calculation. We varied this from 1 to 2 in order to change the ultimate number of indirect samples per pixel. Using a value of 3 didn't add enough to the final image to be considered in this test.
• -x -y (resolution) We rendered at resolution multiples of 1, 2, 3, 4, 6, 8, and 12, in order to determine when the jittering in the ambient calculation and penumbras was filtered smooth.

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

-pj 0.67 -pt 0.05 -aw 0 -as 0

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

Discussion

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:

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.

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

Conclusion

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.