Graphics Reference
In-Depth Information
estimate each part separately. In some cases, direct
evaluation
rather than estima-
tion is possible (e.g., mirror reflection of direct light from area lights); removing
this component of the integrand makes the remaining scattered light a smoother
function of the outgoing direction and/or the scattering location, and thus allows
better stochastic estimation with fewer samples.
Certain classes of illumination and reflection are amenable to particular
approaches. For instance, it's very difficult to use Monte Carlo methods based on
ray tracing from the eye to render a scene that's lit by tiny luminaires: The chance
that a ray (primary or scattered) will hit the light is so small that the variance in
the radiance estimate ends up large. On the other hand, if we trace rays from the
luminaire to build up a photon map, it becomes easy to estimate the diffusely scat-
tered radiance from small sources, or even scattering along light paths of the form
LS
+
DE
. A dual situation is the rendering of area lights that are multiply scattered
by highly specular surfaces. It's very difficult to pick a point of such a light, and
a direction for emission, with the property that the resultant light path eventually
reaches the eye. Such a situation is far more amenable to ray tracing. To handle
both cases, you find you want to trace both from the eye and from luminaires,
and you're in the realm of bidirectional path tracing [LW93, Vea97]. Whether you
choose to glue paths together or use a density-estimation strategy like photon map-
ping depends on the classes of paths you encounter. In fact, it's natural to begin
thinking that for each possible path type, you might want to choose different ways
of working with those paths, and then combine the results at the end. Choosing
a reasonable way to combine the multiple sampling approaches (or, thinking in
the opposite direction, a reasonable way to break up the integrand or domain of
integration) leads quite naturally to methods similar to those used for Metropolis
light transport.
Broadly speaking, there's a whole collection of possible approaches that you
can take in building a rendering algorithm, and you can put the pieces together in
many different ways. Considerations of classes of phenomena that are important
to you (caustics, shadows) may make one method preferable over another. Con-
siderations of efficiency, either in the big-O running time of a procedure, or in
coherence of memory access or careful use of bandwidth, may also be an influ-
ence. Don't be constrained by what others have done: Evaluate the specific ren-
dering problem you need to solve, and then combine techniques as necessary to
optimize.
In Chapter 5 we discussed how very sensitive the human visual system can be to
certain kinds of artifacts in images. Renderers give you the opportunity to put that
sensitivity to work. Not only do they provide millions of parallel executions of
the same bit of code (typically one or more executions per image pixel), but it's
easy to construct scenes that have a natural coherence to them so that any anomaly
stands out.
Let's look at several examples to see how you can debug a renderer. Suppose
you're writing a path tracer, and you find that increasing the number of primary
rays causes the image to get dimmer, but does not improve the aliasing artifacts
around shadows. The dimming of the image suggests that you're dividing by the
number of primary rays, as you should, but that you're failing to accumulate radi-
