Graphics Reference
In-Depth Information
Computing
f
jk
is a once-per-scene operation. Once the matrix
F
is known, we
can vary the lighting conditions (the vector
e
) and then recompute the emitted
radiance at each patch center (the vector
b
) quite quickly.
Once we know the vector
b
, how do we create a final image, given a cam-
era specification? We can create a scene consisting of rectangular patches, where
patch
j
has value
B
j
, and then rasterize the scene from the point of view of the cam-
era. Instead of computing the lighting at each pixel, we use the value stored for
the surface shown at that pixel: if that pixel shows patch
j
, we store the value
π
B
j
at that pixel. The resultant radiance image is a radiosity rendering of the scene.
This, however, is rarely done as described; such a radiosity rendering looks
very “blocky,” while we know from experience that totally Lambertian envi-
ronments tend to have very smoothly varying radiance. Instead of rendering
the computed radiance values directly, we usually
interpolate
them between
patch centers, using some technique like bilinear interpolation, or even some
higher-order interpolation. This is closely analogous to the approach discussed
in Section 31.4, in which we solved an equation on the integers and then inter-
polated to guess a solution on the whole real line. In this case, we've found a
piecewise-constant function (represented by the vector
b
) that satisfies our dis-
cretized approximation of the rendering equation, but we're displaying a
different
function, one that's
not
piecewise constant.
What we've done is to take the space
V
of
all
possible surface radiance
fields, and consider only a subset
W
of it, consisting of those that are piecewise
constant on our patches. We've approximated the equation and found a solution
to this in
W
; we've then transformed this solution (by linear interpolation) into a
different
subspace
D
consisting of all piecewise-linear radiance fields. If
D
and
W
are “similar enough,” then this is somewhat justified (see Figure 31.14).
V
D
W
Figure 31.14: Schematically, the
space V of all surface-radiance
fields contains a subspace W
of piecewise constant fields, and
another subspace D of piecewise
linear fields. There's a map from
W to D defined by linear interpo-
lation.
One way to address this apparent contradiction is to not assume that the radi-
ance is piecewise constant, and instead assume it's piecewise linear, or piecewise
quadratic, and do the corresponding computations. Cohen and Wallace [CWH93]
describe this in detail.
The computation of form factors is the messiest part of the radiosity algo-
rithm. One approach is to render the entire scene, with a rasterizing renderer, five
times, projecting onto the five faces of a
hemicube,
(the top half of a cube as
shown in Figure 31.15). Rather than storing a radiance value at each pixel, you
store the
index k
of the face visible at that pixel. You can precompute the pro-
jected solid angle for each “pixel” of a hemicube face once and for all; to compute
the projected solid angle subtended by face
k
, you simply sum these pixel con-
tributions over all pixels storing index
k
. For this to be effective, the hemicube
images must have high enough resolution that a typical patch projects to hun-
dreds of hemicube “pixels”; as scene complexity grows (or as we reduce the patch
size to make the “constant radiance on each patch” assumption more correct), this
requires hemicube images with increasingly higher resolution.
k
C
C
j
j
Figure 31.15: We project the
scene onto a hemicube around
P; since patch k is visible from
P through the pixel shown, the
hemicube
In solving the radiosity equation, Equation 31.46, some approximation tech-
niques do not use every entry of
F
; it therefore makes sense to compute entries of
F
on the fly sometimes, perhaps caching them as you do so. Various approaches
to this are described in great detail by Cohen and Wallace [CWH93].
Before we leave the topic of radiosity, we should mention four more things.
First, in our development, we assumed that patches were completely mutually
visible; the hemicube approach to computing form factors removes this require-
ment. On the other hand, the hemicube approach
does
assume that the solid angle
image
at
that
pixel
stores the value k.
