Instant Radiosity

Mark Schmelzenbach CS684: Radiosity Final Project: Instant Radiosity

For the final project, I chose to implement the radiosity solution method outlined in SIGGRAPH 1997 paper entitled "Instant Radiosity." This paper was written by Alexander Keller of the Universistat Kaiserslautern. His web page can be reached here.

The idea of this paper is similar to that of the Monte Carlo path tracer written for homework 1. However, instead of using a ray tracer as the sampling method, the OpenGL image buffer is used. Several images are rendered using OpenGL, and are composited in the accumulation buffer. This method converges fairly rapidly to the radiosity solution--without having to evaluate any form factors or generate meshes. In addition, since the program uses OpenGL, it can leverage existing hardware accelerators dramatically decreasing computation time.

Significant advantages:

Can use OpenGL hardware to decrease rendering time
Computed solution can be displayed directly
Low memory requirements, since it works in image space rather than creating matrix elements
Algorithm can be extended to allow specular surfaces
Radience contribution from textures is directly computed

Disadvantages:

View dependent (although Keller does present a method of generating walk-throughs in the paper)
This method is not terribly accurate, it generates nice pictures, but should not be used for predictive results.
Final output quality is dependant on hardware capabilities. For instance, the accumulation buffer needs to be fairly deep to allow large numbers of images to be composited.
Doesn't work as well on scenes lit primarily by indirect lighting. Since it uses a quasi-random walk to distribute photons, several hundred frames may be required to get photons to arrive where they are needed.

For a full description of the algorithm, see the original paper.... However, here is a (very) brief overview. At runtime, a number of photons are selected from the lightsources to be cast into the scene. In addition, the mean reflectivity r of the scene is calculated. Initially there are N photons. For each photon, the scene is rendered, placing a point light source at the origin of the photon. Then, rN of these photons are cast into the scene in a method similar to that in homework 1. When a photon hits a surface, it is attenuated by the diffuse component of that surface. Then the scene is rendered again, with the point lightsource appropriately moved. r²N of the original points continue on to a second bounce. The process is repeated until all of the paths are complete. In essence, this algorithm is generating an increasingly accurate approximation of the average radiance for every point in the scene with the rendering pass.

For a graphical explanation, click here.

The snapshots below were generated under Linux, using Mesa, a very nice (and free) OpenGL emulator. I used a scene very similar to that in the paper, but reduced the polygon count by removing a few chairs. I also turned one of the walls red, so that the color bleeding effect is demonstrated. The models were taken from some earlier work by our very own Peter Shirley.
The shadows were generated using BSP trees from a library by A T Cambell, III, written at University of Texas. These routines are software based, and so do not dramatically improve when run on OpenGL hardware. Using a package like Mark Kilgard's real-time shadows would probably yield a nice speed improvement. (However, Kilgard's method relies on version 1.2 of GLU, which is not emulated in Mesa. In interests of convient development, I opted for the slower shadow volume approach). All the pictures below were rendered with a r value of 0.57

Using software emulation of OpenGL hardware had the added benefit that the acculumation buffer is deep and accurate. On some boards (notably some of the cheap PC graphics accelerators), this is not the case. A bit-depth of 8-12 bits is shallow enough to cause artifacting when compositing images. This means that there can be an arbitrary upper bound on the number of images that can be composited depending on the implementation of the accumulation buffer. This could pose a signifcant problem in scenes lit primarily by indirect lighting, since rendering these scenes requires a large number of inital photons.

This method presents a promising radiosity previewer. If nice looking images are all that is desired, than this method provides good results -- particularly if there is a lot of direct lighting in the scene. One the other hand, if the goal is to produce a predictive model, such as for accurate stage lighting or other architechural needs, then this would not be a good choice for the end result. Even then, instant radiosity could be used for quick initial design and layout. Once the basic model has been completed, more accurate solution methods could be used for fine tuning.

And now, with out any further ado... some pictures!

This picture used 32 photons, compositing about 70 separate scenes

This picture traced 64 photons, compositing about 150 images

This picture is traced 128 photons, compositing about 300 images

And no radiosity page would be complete without the Cornell box... this was traced using 64 photons.