Reversed Normal

I have been investigating solutions for real-time global illumination over the past few weeks, and thought I might share some of my thoughts on a potential approach to this problem.

To create a global illumination effect for static geometry and lights is relatively easy. One must simply bake the lighting information into a series of light maps which are then multiplied into the scene when rendered in game. The lighting rigs can be as complicated as you like, and can leverage whatever cool features your DCC tool has, provided the lights and the geometry in the scene never change.

Dynamic geometry presents a bit of a problem. Light maps won’t do because when the object moves from it’s baking position, the values from the map are no longer valid. Though some global illumination effects can look passable even when not accurate (ambient occlusion, for example), in most cases, this is unacceptable. The most common solution for achieving low-frequency global illumination effects on dynamic objects is to approximate the environment’s lighting using spherical harmonic approximation, a technique similar to Fourier signal approximation.

My approach would combine these two methods to produce a flexible global illumination solution. Static geometry would the lit with light maps as described above. To light dynamic objects, the artist would place a series of ‘light probes’ in the scene, which are accurately calculated during the offline backing stage and approximated using low-order spherical harmonics for us in-game. For any given dynamic object, the closest few probes would be averaged based on distance. The resulting set of spherical harmonic coefficients would be used to compute the final global illumination term. This would probably be done per-vertex. The averaging of probes could be accomplished in a threaded manner on the CPU, perhaps during the scene culling stage before rendering.  A similar technique was used in Killzone’s rendering engine.

Regardless of the final form your global illumination data takes when used in-game, you still need to be able to calculate it in the first place. Many real-time GI implementations I’ve seen have used proprietary renderers created specifically for the job. While writing a renderer would be cool for didactic reasons, reinventing the wheel is never a good idea. I propose that by using some cool shaders and Renderman’s point cloud API, any Renderman-compliant renderer (many of which are free) could be used to bake global illumination data for real-time use.

In order to render light maps for static geometry in a scene, we need to trick Renderman into rendering lighting information to texture. While Renderman has a nice set of functions for baking 3D data, there are no such functions for baking the results of a shader to a 2D texture. To accomplish this, we need to draw each object in UV space while shading the object in world space. Check out this writeup from the LA Pixar Users Group for more information. Another approach would be to bake the information to a point cloud using the s and t parameters instead of the micropolygon’s position. The point cloud could then be turned into a texture using an external application.

Creating the spherical harmonic data for dynamic objects in the scene is a little more involved. As mentioned previously, the scene author would hand place a series of ‘light probes’ in the scene. Each probe, simply a point with a special shader attached, would sample the lighting around its position over a unit sphere and bake the result to a point cloud. An external application would then create an approximation of the lighting function using the samples and project it into spherical harmonic coefficients for use in-game.

I’m going to do a little more reading on this, and post more details later. In the mean time, marvel at the cool chart I made!