Chapter 10ThreeDimensional Graphics Realistic RenderingM. Firebaugh© Wm. C. Brown Communications, Inc. 
The simple shading model of Phong achieves considerable success with realism in rendered scenes by incorporating several principles of optics into a heuristic shading algorithm. This success suggests that the closer we can approximate the physics of light, the better results we can expect from our illumination algorithms. The present chapter outlines three significant approaches for achieving visual realism. The first two are based on optics and energy conservation and overcome many of the problems of the simple shading model to produce images of striking realism. The third approach emphasizes the importance of shading and texture in visual realism. These three approaches define the state of the art in realistic rendering.
The approach based on physical optics is called ray tracing. Ray tracing appears intuitively to be the natural approach to rendering a physical scene. This technique solves many of the problems encountered or overlooked in the simple shading model, the most obvious being the correct handling of refraction by transparent objects. At its most basic level, ray tracing can be considered as the Phong shading model incremented by the possibility of multiple specular reflections and Snell's law of refraction. By the nature of the approach, ray tracing is the ultimate image space hidden surface removal algorithm. Yet, by introducing multiple specular reflections, we lose one of the simplifying assumptions of earlier chaptersthat back face removal should be the first step of any rendering program. Since back faces can indeed be visible through reflection, they cannot be eliminated automatically.
The second approach, one that effectively complements ray tracing, is the radiosity algorithm. With a basis in thermodynamics, radiosity algorithms are founded on the solid principle of energy conservation. Radiosity is the ultimate object space illumination model. It can be considered as a macroscopic model in contrast to the microscopic ray tracing model. Each surface of a scene is consideredcorrectlyas the source of light illuminating every other surface. As such, the radiosity algorithm is a global illumination model and is independent of the particular viewpoint. Using the physical basis of energy conservation, the radiosity approach has solved difficult effects such as color bleeding, which have defeated previous algorithms.
The third approach extends the simple shading model with sophisticated
generalized shaders and mapping techniques. By efficient simulation of
the optical effects of reflections and shadows, the RenderManô approach
achieves remarkable visual realism and is becoming a de facto standard
interface for describing and rendering 3D images. The design criteria,
algorithms, interface standard, and output of RenderMan are presented
in detail.
The first recursive formulation of the ray tracing algorithm was proposed
by Whitted in 1980. A detailed discussion of the subject, including many
refinements and extensions, is given by Glassner.
The concept of ray tracing is based on our understanding of the physics
of light emission, transmission, refraction, reflection, and absorption.
The basic idea is illustrated in Figure 10.1.
Forward ray tracing. Millions of rays are emitted by the light source L, and one particular ray is shown as reflecting off the larger sphere and striking the center of projection (eye point) through pixel P.
Light is emitted by the source, L, and travels in all directions, illuminating the world coordinate scene. The scene can be composed of transparent, translucent, and opaque objects of varying degree of reflectivity. One particular ray can strike the larger sphere, illuminating it, and be reflected toward the eye along a ray which intersects the screen at pixel P. The color and shading of pixel P is determined by the light emanating from the intersection point of the ray with the closest surface to P in the scene being viewed in this case, the larger sphere.
While such a model can correctly simulate the behavior of real light rays, a moment's reflection quickly indicates the fatal flaw in any forward ray tracing algorithm. In order to correctly determine the intensity of every pixel on the screen, such an enormous number of rays would have to be generated at L and propagated through the world scene that the largest supercomputer would bog down. Thus, forward ray tracing is completely impractical from a computational point of view.
We are rescued from this computational morass by the optics principle
of reciprocity. Reciprocity states that all ray diagrams in optics
are equally valid if all ray directions are reversed. This leads us to
the more tractable algorithm of backward ray tracing.
Backward ray tracing is the same as forward ray tracing, but with all ray
directions reversed. This is illustrated in Figure 10.2.
Backward ray tracing. Rays originating at the COP pass through each pixel, P, of the image and continue until they strike the nearest surface or exit the view volume. Upon striking the surface the ray's shading is determined by a combination of a shading model applied to the surface plus possible spectral reflection and refraction effects.
Note the tremendous computational advantage of backward ray tracing
over forward ray tracing. To correctly shade an n ¥
m pixel screen using backward ray tracing requires only n
¥ m primary rays rather
than the untold billions of rays which would be necessary to generate a
wellresolved image using forward ray tracing.
Secondary reflection and refraction processes.
Incident ray 1 can be partially reflected (2) and partially refracted (3) at the first surface intersection. A partial set of subsequent reflected and refracted rays is shown. Since each ray leaving a surface is capable, in general, of generating a reflected and refracted ray upon intersecting the next surface, the process becomes a natural candidate for a recursive algorithm.
Figure 10.3 illustrates a number of important concepts involved in backward ray tracing (henceforth called just ray tracing). First, back face removal is not allowed for ray tracing algorithms since the back face of object A may both refract a ray transmitted through A and may itself be reflected by object B. Secondly, the reciprocity principle helps us interpret the ray diagram in the following manner. Ray 1 can be considered as the shading model color of the front surface summed with a possible incident ray 2 which reflects along 1 plus a possible refracted ray 3 which bends at the surface along 1. Ray 3, in turn, can be considered as the sum of a reflected ray 4 plus an incident refracted ray 7, and so on.
This process can be continued for all secondary rays until any of several trivial conditions apply. These conditions include:
The ray strikes a light source (or comes close).
The ray's intensity becomes diminished below a certain threshold.
The ray becomes trapped by internal reflection (in transparent objects).
The ray exits the world scene.
The reader can sense that we are setting ourselves up for a recursive
solution to the ray tracing problem. This is indeed the case, and we turn
next to an elegant recursive algorithm for ray tracing.
Note that the nodes of the binary tree correspond to interactions at
a surface and result in both a geometric process (spawning of two new rays)
and the summation of information returned by these rays with the results
of a shading model applied to that point on the surface. These two essential
components of the recursive ray tracing algorithm are illustrated in Figure
10.5.
Recursive traversal of binary ray tree. Computing the raytracing diagram of Figure 10.3 corresponds to the fivelevel recursive traversal of the binary tree shown here. The branches correspond to rays shot out and information flowing back to the node. The symbol at each node indicates that the shading model color of that surface is added to the information carried back by the transmitted and reflected rays. The depth (or ply) of the traversal is indicated by the Age column.


Two phases of binary tree traversal. On the left, a ray incident on the surface spawns two new rays, transmitted ray, T, and reflected ray, R. On the right, information carried back by these rays is summed with the local color and passed back up the tree.
Rays leaving the scene without intersecting a surface return I(l)
= black and terminate the traversal down that branch. A retired ray stops
spawning new rays and returns either black or the shading model color of
the next surface it intersects, depending on the algorithm chosen. These
concepts form the basis for the recursive ray tracing algorithm.
The following outline of a simple recursive algorithm is due to Watt.
var
intersectionpoint,reflecteddirection,transmitteddirection:vectors; localcolor,reflectedcolor,transmittedcolor:colors;
begin
if depth > maxdepth
then color:=black;
else
begin
{Intersect ray with all objects and find intersection point if any) that is closest to start of ray}
if {no intersection}
then color:=backgroundcolor
else
begin
localcolor:={contribution of local color model at intersectionpoint}
{calculate direction of reflected ray}
RayTrace(intersectionpoint,reflecteddirection, depth+1, reflected color);
{Calculate direction of transmitted ray}
RayTrace(intersection point, transmitted direction,depth+1, transmittedcolor);
Combine(color,localcolor,local weight, reflectedcolor, reflected weight,transmitted color, transmittedweight);
end
end
end {RayTrace}
Thus, as Glassner suggests in the introductory quotation, the concept
of ray tracing is simple, and the recursive formulation provides an elegant
implementation algorithm. However, as with many great ideas, ray tracing
is easier said than done. Consider first the problems of geometry.
Two practical problems which must be solved by ray tracing algorithms are computationally efficient models for reflection and refraction, and efficient algorithms for computing the ray intersection of the nearest face. Consider the first problem.
Recall from Chapter 9 that the law of mirror reflection and Snell's law of refraction can be written:
qi = qr (Mirror reflection) [10.1] n1 sin q1 = n2 sin q2 [10.2](Snell's law of refraction)
Given an incident ray, I, making an angle, qi, with the normal to the surface, N, Equation 10.1 tells us how to compute the angle, qr, that the reflected ray, R, makes with the normal. However, rather than work with a reflected angle, it is much more convenient to compute the R vector directly.
Using a vector diagram like Figure 9.7, one observes that the two light vectors in mirror reflection have components parallel to the surface which are continuous and components perpendicular to the surface which are reversed.
Thus, we can write:
I = I + I^, R = R + R^ [10.3] but
I = R, I^ = R^ [10.4] so R = I  2 I^ and, since I^ = (I·N) N [10.5] we get R = I  2 (I·N )N [10.6]
This is readily computed by a dot product and vector addition.
The task in refraction is to express the refracted (transmitted) ray, T, in terms of the two vectors, I and N, while incorporating Snell's law. A ray, I, in medium 1 with index of refraction, n1, making an angle q1 with the normal, N, will be bent along T at an angle q2 in medium 2 with index of refraction n2. First, we define the relative index of refraction, n, as:
Next, we can express both the incident and refracted rays in terms of unit vectors parallel and perpendicular to the surface:
Assuming N is a normalized (unit) vector, we can express u and u^ as:I = u sin q1 + u^ cos q1 [10.8] and R = u sin q2 + u^ cos q2 [10.9]
u^ = N
Substituting 10.7 and 10.10 into 10.9 gives:
Substituting 10.12 and 10.14 into 10.11 gives a vector expression for R:
For reasons we shall return to shortly, the intersection of a ray with
a sphere is of great importance in ray tracing. Consider the following
simple algorithm by Hultquist for computing the intersection of a ray and
a sphere. For the plane containing the ray unit vector, V,
the ray origin, E, and the center of the sphere, O, as shown
in Figure 10.6, we can write the algorithm for the intersection point,
P.
Intersection point, P, in terms of points E, O, and ray unit vector, V.
From Figure 10.6, we get the following algebraic relationships:
In terms of the ray origin, E, and two vectors, V and EO,
the algorithm for intersection point, P, can be written:
The simplicity of the above algorithm explains, in part, why the featured objects in so many raytraced scenes are spheres. Since the polyhedral representation is so widespread in computer graphics, however, we should also present an algorithm for the intersection point of a ray with a polygon. At the most abstract level, this algorithm can be stated as a two step process:
1. Compute the intersection point, Pi, of the ray with the plane containing the polygon.
2. Test to see if Pi is contained within the polygon.
We assume that the polygon is defined as a triangle with vertices V1, V2, and V3 as shown in Figure 10.7. Planar polygons with n vertices in which n > 3 can readily be reduced to n  2 triangles to which the algorithm is applied. A quadrilateral, for instance, can readily be split along either diagonal into two triangles.
Geometry for raypolygon intersection computation.
A more refined version of the algorithm follows.
Ray tracing algorithms based on the algorithms described above have achieved remarkable realism in rendering synthetic scenes. However, they suffer from various shortcomings which limit the visual realism possible with this technique. Among these are:
Ray tracing algorithms still rely on simplifications of the Phong shading model for such terms as ambient lighting. Real illumination involves every incremental area of a scene serving as a source of illumination for every other incremental area in the scene. This produces effects such as "color bleeding" in which a given colored surface affects the color of nearby surfaces.
Ray tracing is built on the abstraction of light as mathematical rays and ignores the wavelike properties of light such as diffraction and dispersion. Thus, raytraced images show reflected, refracted, and shadow outlines as infinitely sharp. Since diffraction limits the sharpness of real images, ray tracing still fails the test of model authenticity.
Ray tracing algorithms work in image space and as such are local illumination
models. By this, we mean that changing the viewpoint requires recomputing
the raytraced image from scratch. The raytraced image is completely dependent
on the position of observer and screen in relation to the world scene and
thus does not qualify as a global illumination model.
In an ideal ray tracing program, the rendering time should depend only on the desired image resolution and be independent of the complexity of the scene. In practice, each ray must be tested for intersection with each object of the scene and the list of resulting intersections sorted to identify the surface nearest the ray's origin. The problem of intersection calculation is made even more complex because of the fact that secondary and older rays can originate anywhere in the viewing volume. It is estimated that up to ninetyfive percent of the time to render a raytraced image is spent in computing the intersections of rays with objects. It is not surprising that much of the research on ray tracing involves techniques for speeding up this process.
Various extensions have been introduced to improve the performance of
ray tracing algorithms and minimize the limitations listed above. These
include:
Several of the failings of ray tracing algorithms are overcome by taking an even more fundamental approach based on the thermodynamic principle of the conservation of energy. Thermal engineers use this principle to develop methods for predicting the flux of radiant (heat) energy within enclosures. This approach, called the radiosity method, yields rendered images which are so realistic that it is difficult to distinguish them from photographs of real scenes. This success can be interpreted as the natural result of an accurate simulation of the global illumination environment.
The radiosity solution of the global illumination problem was invented
at Cornell University by Michael Cohen, Donald Greenberg, and their colleagues.
While its algorithmic complexity and computational costs have slowed widespread
acceptance, the radiosity algorithms are now available commercially, most
notably on HewlettPackard graphics systems.
Energy is conserved at each point on a surface. That is, the light energy incident upon a surface and generated in the surface must be balanced by the light energy emitted from the surface or absorbed by the surface in the form of heat.
Each point on a surface serves as a source of light for illuminating every other surface element in the scene within its line of sight (and even possibly hidden elements through reflection).
A quick inspection of indoor environments indicates that a major portion of light "doing the illumination" is diffuse rather than spectral in origin. Based on this fact and to simplify the algorithm, the original formulation of the radiosity approach ignores spectral reflections and assumes perfect Lambertian diffuse reflection only.
We can capture the two principles of energy balance by the radiosity relationship:
Radiosity(i) = Emission(i) + Reflectivity(i) Ú Radiosity(j) x Formfactor(i,j)
where
Emission(i) = Ei = The rate of light energy emitted from a surface. The source of this light energy is the conversion of other forms of energy, e.g. electricity. The units are the same as those of radiosity.
Reflectivity(i) = ri = The fraction of incident light which is reflected back into the environment. It is a dimensionless ratio.
Formfactor(i,j) = Fij = The fraction of light energy leaving surface j which strikes surfacei.
Integral(env) = Integral over the environment in which element i exists.
Written symbolically in terms of a finite number of elements, N,
this becomes:
Since there are N patches in the scene, all illuminating each
other, this is equivalent to N equations in N unknowns, and
can be written:
The mathematical formulation of the radiosity technique expressed in
Equation 10.32 is elegant but deceptively simple. Consider some of the
"details" which must be addressed in any practical radiosity algorithm.
Let's consider some of these problems in more detail.
Assuming planar patches Ai and Aj
with dimensions within an order of magnitude of the distances separating
them, it is necessary to integrate the effects of differential areas, DAi
and DAj on
each other. Cohen and Greenberg write the differential formfactor as:
This formfactor is normalized to give a value of one for the limiting case
where patch Aj becomes a hemisphere of radius r centered
at DAi.
In order to compute the effect of the whole patch Aj
on the differential element, DAi,
we integrate over Aj.
The final nonobscured formfactor is defined as the area average of the
differential formfactor given by [10.37]. Thus,
This is the formal, mathematical expression for the formfactor. It does
not, however, solve the hidden surface problem. We can resolve this problem
by inserting a switching function, HID, into [10.38] to give:
While this expression for the formfactor formally includes a hidden surface
function, it does not specify how HID is to be computed. This is
the subject we consider next.
It has been shown that the formfactor calculation [10.38] is equivalent
to a series of projections. Nusselt used a hemisphere of unit radius with
center at dAi to compute the formfactor for patch
Aj as shown in Figure 10.9. Note that the projection
of the patch onto the hemisphere, A¢,
correctly accounts for the cos fj
and r2 term, and the projection of A¢
onto the Ai surface, called A?,
corrects for the cos fi
term.
Since the area of the hemisphere projected onto Ai
isp, the formfactor is given by the ratio of A"
to p:
The interesting result of the projective technique is that the result is independent of the shape of the projective surface. Cohen and Greenberg used this property to propose a hemicube scheme for computing the formfactor and extend the technique to solve the hidden surface problem. This technique is illustrated in Figure 10.10.
In the hemicube approach, a cube is centered about dAi
with the top plane of the cube parallel with the surface element, dAi.
The patch Aj, whose formfactor is to be computed, is projected onto the
hemicube in a fashion identical to the projection used in Figure 10.9.
The surface of the hemicube is subdivided into N ¥
N square "pixels," where N is typically in the range 50  100 (N is shown
as 8 in Figure 10.10). The hemicube has a unit height and a coordinate
system with the origin at dAi, zaxis coincident with
Ni and x and yaxes parallel to the edges
of the cube. The incremental contribution of each shaded pixel of area
DA and coordinates (x,y,z)
to the formfactor can be shown to be:
If, in Figure 10.10, the projected patch, A¢,
encloses R pixels, the final formfactor for patch Aj
illuminating Ai is given by the sum of all pixel contributions:
The advantage of the hemicube approach is that it is fairly straightforward
to incorporate a hidden surface algorithm to eliminate the contribution
of those patches which are shielded by other objects. Note that the
ith row of the formfactor matrix, F, is
generated by constructing a hemicube about dAi and
computing Equation 10.44 for all other patches, Aj.
When more than one Aj patch shades a given pixel,
a depth sort determines which is the closest. The incremental formfactor
contribution from the closest patch is summed into [10.44] and the rest
are discarded. This technique is completely analogous to the zbuffer algorithm
for hidden surface removal described previously.
Thus, the hemicube approach is useful for solving both the formfactor computation and the hidden surface problem.
Upon solution of the radiosity equation, the radiosity, Bi, of each patch is known. Because of the finite size and different geometries of each patch, each Bi will be different in general, even for adjacent patches. In order to achieve continuous shading across patch boundaries, the patch intensity is assigned to each vertex and the Gouraud interpolation algorithm applied during projection.
As an authentic model, radiosity solves several previously unsolved problems including shadows with proper penumbrae and color bleeding. But perhaps the most attractive feature of the radiosity model is its global nature in object space. That is, as an accurate solution for surface illumination, the radiosity method is completely viewpoint independent. Once the radiosity solution is obtained, images from a given viewpoint are readily rendered by the projective techniques already discussed. The image projection task is far less computationally intensive than the task of obtaining the radiosity solution. Although the radiosity solution can take minutes (or even hours), images of the scene can be rendered in fractions of a second. The computing power of most workstations is adequate for real time image computation as the observer "walks through" the scene described by the radiosity solution.
It does this by starting with the brightest source or emitting patch, bounding it with a hemicube, and shooting light through the pixels of the hemicube to illuminate all of the N1 other patches. The brightest source is the patch with the largest BiAi product corresponding to the greatest total light energy emission. The resulting radiosities of the newly illuminated N1 patches are then scanned for the brightest source and the process repeated. Light from this patch is projected through its hemicube to illuminate all other patches, including the original brightest patch. After the first two brightest patches have been fired, the third brightest patch is shot, and the process continues until the image converges to a stable illumination balance. Convergence is easily detected visually by noting subsequent iterations of the cycle produces no detectable change in the appearance of the scene.
Note that progressive radiosity fundamentally reverses the direction we visualize light moving as it achieves an equilibrium distribution. This direction reversal is analogous to the distinction between forward and backward ray tracing. In the full radiosity matrix formalism we compute the radiosity of patch i by gathering the light emitted by all the other j patches. The contribution to patch i's radiosity from patch j's light is (see [10.31]):
By inverting the process, progressive radiosity assumes i becomes a source, shooting light towards other j patches. The question then is: What is the radiosity, Bj, of each patch due to the present brightest patch, Bi? That is, we need to express Bj in terms of Bi.Bi = ri Bj Fij [10.45]
We know both rj and Bi but not Fji. Rather than marching out to each of the j patches and building a hemicube about them to compute Fji, it would save effort to use our existing hemicube designed to compute Fij and relate the two terms using symmetry principles. From the symmetry of the integrand in [10.37] it is clear that we can write:Bj = rj Bi Fji [10.46]
Fij Ai = Fji Aj [10.47]
The radiosity Bj due to Bi can then be written:
As a final note before presenting the progressive radiosity algorithm, it is possible (and in fact, likely) that a given patch i, which was one of the early patches shot, will receive enough additional radiosity, DBi, from subsequent shots that the stored energy, AiDBi, will exceed the unshot energy of any other patch. In that case, DBi is shot again and set to zero. The following algorithm uses DB to refer to unshot radiosity.Bj = rj Bi Fij( Ai/ Aj ) [10.48]
repeat{select patch i with greatest stored energy}
for j = 1 to N  1 do
begin
{compute Fij relating i to each j patch}
DBij = rj DBi Fij Ai/Aj .
DBj = DBj + DBij
Bj = Bj + DBij
end
DBi = 0
until image is good enough
There are several significant features of the progressive radiosity extension. Most important is the property that a complete image can be rendered after the first cycle of refinement. That is, the illumination balance, after the brightest patch is shot, corresponds to that achieved with the simple shading model using a single, distributed source. By displaying the image after each cycle, the user can monitor the computation and interactively control the level of refinement according to the task requirements.
The visual effect of observing progressive refinement is both instructive and intuitively satisfying. One first sees a somewhat dimly lit scene with harsh shadows. With the second cycle, the illumination level rises significantly, and the shadows begin filling in as an additional source clicks on and an effective ambient component appears. With each successive cycle, the illumination level grows by successively smaller increments until the change is undetectable. At that point, the user declares the image "good enough" and halts the process. Greenberg has demonstrated scenes in which visual convergence occurs in 2530 shots, and he states that 98 percent of the energy is accounted for after one hundred shots.
To accelerate the process, an artificial ambient term can be introduced for the first few cycles to "excite" patches occluded from the brightest patches. As the process converges, the artificial ambient term is gradually turned down and eliminated altogether for the final cycles.
The heart of the ray tracing formfactor (RTFF) algorithm consists of two clever tricks. First, the RTFF algorithm's primary task is to determine the radiosity at the vertices of each of the illuminated j patches. Since Gouraud interpolation requires the patch shading intensity at each of its vertices in any case, this is a useful shortcut. The second concept of the RTFF algorithm is to compute the formfactor itself by summing the differential formfactors of individual sampling rays from the vertex of j back to the source at i. Since f1, f2, and r are known exactly for each of the sampling rays, Equation 10.36 specifies the incremental formfactor contribution of each ray.
The only remaining issue in the RTFF algorithm is how to specify the rays from vertex j to the source patch, i. Here the algorithm exhibits another of its advantagesits flexibility. A fast, approximate radiosity solution can be obtained using a minimal number of sampling rays from vertex to source, e.g. one. More accuracy is achieved by increasing the number of sampling rays. Rays can be distributed over the source patch with either a regular pattern or distributed randomly. Stochastic processes serve as an effective antialiasing technique since the eye interprets random distributions of pixels as noise rather than structure in the image.
Wallace shows that formfactors computed with the RTFF algorithm converge rapidly to the analytic values as the number of rays increases from one to sixteen, at which point they are nearly identical. Using the RTFF algorithm Wallace was able to calculate a splendid view of the nave of Chartres cathedral in just under an hour on a HewlettPackard 9000 workstation. The scene model consisted of 9,916 polygons with 74,806 vertices and thirty stainedglass window light sources. The solution required 60 steps of progressive refinement and used 1.1 million rays.
The most obvious way to proceed in merging these two techniques is to note that radiosity provides an accurate solution to the diffuse light equilibrium (ambient light background) while totally ignoring specular effects of reflection and refraction. Ray tracing provides an accurate solution for specular reflection and refraction effects while approximating diffuse shading with a simple model based on an nonphysical ambient lighting term. This suggests a twopass process in which, first, the energy conservation principle of radiosity is used to establish the global balance of diffuse illumination, followed by a viewdependent raytracing process to determine specular reflection and refraction effects. After the first pass radiosity solution, the algorithm would shift to a recursive ray tracing mode and substitute the radiosity solution in place of the simple shading model when computing the diffuse shade at each intersection point.




This algorithm will improve the visual realism of rendered images over that possible by either technique used independently. However, this "linear superposition" of the radiosity and raytraced solution is still not complete. To understand the missing term, consider the four mechanisms in Figure 10.11 by which light from patch j reaches and is reemitted from patch i.
Note that radiosity algorithms assume only mechanism (a), and ray tracing algorithms account for both (b) and (d) involving specular reflections. However, neither algorithm takes process (c), diffuse scattering of spectrally reflected light, into account. So the linear superposition of these two algorithms would also neglect this effect.
Two of the earliest efforts to integrate elements of ray tracing and radiosity were the independent approaches of Immel and Kajiya. Immel et al have extended the basic radiosity method to include specular reflections. They accomplished this by computing the intensity distribution for every surface in the environment in terms of directional intensities for a number of discrete directions. The rendering process then consists of looking up the intensities pointing back to the eye and displaying them as the image. This approach preserves the advantages of a viewindependent solution while adding specular highlights to rendered images.
Kajiya has proposed a rendering equation that resembles the radiosity equation but which uses geometric optics rather than only diffuse assumptions for transforming light from sources to observer. To integrate the integral rendering equation he uses Monte Carlo (stochastic) ray tracing to sample the environment. He computes the diffuse component of surface intensity by randomly sending sampling rays from the intersection point throughout the environment. Thus, Kajiya showed that the ray tracing approach can be extended through stochastic processes to achieve a diffuse lighting component consistent with geometric optics.
Wallace et al have proposed an integration of ray tracing and radiosity that takes into account all four of the transfer mechanisms outlined in Figure 10.11. Basically, the Wallace algorithm introduces extra formfactors to the conventional radiosity algorithm that correspond to mirror reflections of patch k through reflective patch j to patch i as indicated in Figure 10.12.
Through the use of virtual patches the algorithm correctly takes into account all four of the transfer mechanisms of Figure 10.11.
As suggested earlier, the algorithm uses a twopass approach to calculate illumination. In the first pass (preprocess), all four transfer mechanisms are employed to compute the correct diffuse component. In the second pass (postprocess), the viewdependent speculartospecular and diffusetospecular mechanisms generate a specular component which is added to the diffuse component to produce the final image.
Using Kajiya's rendering equation, Sillion and Puech have proposed an extension of the Wallace twopass algorithm which removes the restriction limiting specular reflections to single plane mirrors. Their extended form factor, Fij, measures the energy leaving surface i and reaching surface element j after any number of specular reflections or refractions. This extends the radiosity solution to include multiple specular reflections (Wallace's algorithm computed only one) as well as refraction (transparent and translucent objects).
Sillion and Puech's algorithm closely follows the intuitive twopass algorithm introduced at the beginning of this section. In pass one, the extended radiosity solution (including all four mechanisms from Figure 10.11) provides a viewindependent illumination value for each patch in the scene. The second pass computes the directional distribution of light reaching the observer by a classical raytracing algorithm, simplified as follows:
This discussion, however, also indicates the limitations of the advanced realistic rendering techniques as tools for visualization available to the average designer/engineer/scientist. Among these limitations are:
In addition to these graphics functions built into the hardware of the system, the HP Personal VRX supports GKS, PHIGS, X Windows, and Motif industry graphics standards. It also supports CAD features such as sectioning, capping, interference checking, contour mapping, and deformation animation.
By building many of the rendering algorithms in firmware, HewlettPackard achieves high graphics processing speed. For instance, the HP Personal VRX can render 20,000 quadrilaterals, 50,000 triangles, or 270,000 vectors per second. This speed allows realtime "walk through" of scenes previously solved by the radiosity method.
The HP Personal VRX graphics workstation and similar workstations available
from other vendors are capable of solving the most sophisticated rendering
tasks facing large design, engineering, and image processing organizations.
However, the price puts them out of reach for smaller firms and educational
institutions on limited budgets. Does this mean that realistic rendering
is impossible for "the rest of us?"
 




The basic rendering technique of REYES combines the zbuffer algorithm operating on micropolygons with shading models that have capabilities of texture mapping. Each object is turned into micropolygons as it is read in. A small primitive object can be diced directly into micropolygons, while a larger object may be split into smaller primitive objects or patches which are subsequently diced into micropolygons. The resulting micropolygons are shaded, sampled, and compared to values currently in the zbuffer. Since only one object is processed at a time, the amount of data necessary at any time is minimized, and the scene can contain arbitrarily many objects.
With this background the reader can better understand the overview of the REYES algorithm offered by Cook et al.
The advantages of the REYES algorithm include very effective antialiasing through stochastic sampling, high speed achieved through locality and the simplicity of micropolygons, and a rendering time linearly proportional to the scene complexity (model size). In addition, because of the flexibility of the REYES architecture, the authors were able to extend it easily to include the following features:
Features provided by RenderMan are summarized below:
The second mode involves coupling an independent modeling program with RenderMan. In this CAD modeling mode, the user creates the model using the design tools available on 3D CAD systems and exports the model in a RIB format file. RenderMan is then called to render the RIB file.
#include <ri.h>
render(nframes) /*Basic program using the RenderMan Interface*/
int nframes;
{
int frame;RiBegin(); /*Options may now be set */
/* IMAGE OPTION SECTION*/
RiDisplay(Ö);
RiFormat(Ö);
Ö
/* CAMERA OPTION SECTION*/
RiClipping(Ö);
RiDepthOfField(Ö);
RiProjection("perspective", Rl_NULL); /* The current trans*/
/* formation is cleared so the camera can be specified.*/
RiRotate(Ö); /* These transformations address RiTranslate(Ö); /* the worldtocamera */
Ö /*transformation controlling placement and orientation of the camera.*/
for(frame = 1; frame <= nframes; frame++) {
RiFrameBegin( frame );
/* FRAMEDEPENDENT OPTION SECTION*/
/* Can still set framedependent options, camera xforms*/
RiWorldBegin()./* SCENE DESCRIPTION SECTION*/
/* The camera xform is now set; options are frozen*/
/* and rendering may begin. We are in world space.*/
RiAttributeBegin(); /* Begin a distinct object*/
RiColor(Ö);/* Attributes fit in here.*/ RiSurface(Ö);
RiTransformBegin();
RiTranslate(...);/* Objectpositioning*/ /* commands */
RiRotate(...);Ö
RiSphere(...);
RiPolygon(...);
RiPatch(...);
RiTransformEnd();
RiAttributeEnd();/* Restore the parent's attributes.*/
/* Otherobjects, otherspaces*/
RiWorldEnd();/* The scene is complete. The image is ren*/
/* dered and all scene data is discarded. Other /*scenes may now be declared with other world blocks. */
RiFrameEnd(); /* Options are restored.*/
}
RiEnd();
}
Next, we show a working RenderMan program with the image it generates
in Figure 10.16.
##RenderMan RIBStructure 1.1##Scene "Table_Cube"
##Frames 1
version 3.03
projection "perspective" "fov" [30.800]
clipping 5.750 113.764
worldbegin
light "distantlight" 1 "intensity" [1.000]"from" [0 0 0]"to" [0.346 0.621 0.703]
light "distantlight" 2 "intensity" [0.250]"from" [0 0 0]"to" [0.400 0.750 0.530]
attributebegin
attribute "identifier" "name" "World"
scale 1.000 1.000 1.000
translate 0.163 0.290 8.575
rotate 0.000 0 1 0
rotate 0.000 1 0 0
rotate 0.000 0 0 1
scale 0.729 0.729 0.729
attributebegin
attribute "identifier" "name" "Object1"
translate 0.262 1.027 1.155
rotate 319.200 0 1 0
rotate 22.100 1 0 0
rotate 19.000 0 0 1
scale 1.138 1.138 1.138
attributebegin
attribute "identifier" "shadinggroup" "Object1shade"
color [0.539 0.312 0.186]
opacity [1.000 1.000 1.000]
surface "wood" "Ks" [0.937] "Kd" [1.000] "Ka" [1.000] "roughness" [0.250] "grain" [10.000] "swirl" [0.000]
sides 1
polygon "P"[0.000 0.000 1.000 0.694 0.056 1.000 0.694 0.056 1.000 0.002 0.000 1.000 ]
polygon "P"[0.002 0.000 1.000 0.694 0.056 1.000 0.694 0.056 1.000 0.002 0.000 1.000 ]
polygon "P"[0.002 0.000 1.000 0.694 0.056 1.000 0.694 0.056 1.000 0.000 0.000 1.000 ]
polygon "P"[0.000 0.000 1.000 0.694 0.056 1.000 0.694 0.056 1.000 0.000 0.000 1.000 ]
polygon "P"[0.694 0.056 1.000 0.694 0.056 1.028 0.694 0.056 1.028 0.694 0.056 1.000 ]
polygon "P"[0.694 0.056 1.000 0.694 0.056 1.028 0.694 0.056 1.028 0.694 0.056 1.000 ]
polygon "P"[0.694 0.056 1.000 0.694 0.056 1.028 0.694 0.056 1.028 0.694 0.056 1.000 ]
polygon "P"[0.694 0.056 1.000 0.694 0.056 1.028 0.694 0.056 1.028 0.694 0.056 1.000 ]
gpolygon [4] "P"[0.694 0.056 1.028 0.694 0.056 1.028 0.694 0.056 1.028 0.694 0.056 1.028]
attributeend
attributebegin
attribute "identifier" "name" "Object4"
translate 0.021 0.458 0.012
rotate 180.000 0 1 0
rotate 0.400 1 0 0
rotate 89.700 0 0 1
scale 0.669 0.669 0.669
attributebegin
attribute "identifier" "shadinggroup" "Object4shade"
color [0.871 0.020 0.800]
opacity [1.000 1.000 1.000]
surface "metal" "Ks" [1.000] "Ka" [0.809] "roughness" [1.000]
sides 1
gpolygon [4] "P"[0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599]
polygon "P"[0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599 ]
polygon "P"[0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599 ]
polygon "P"[0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599 ]
polygon "P"[0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599 ]
gpolygon [4] "P"[0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599 0.599]
attributeend
attributeend
attributeend
attributeend
worldend
Image of scene Table_Cube rendered with RenderMan program. The metallic finish of the cube and the wood grain are produced by the metal and wood shaders (Object 1 and Object 4 of the program, respectively).
Note that the programming mode gives the user the maximum flexibility and control over the quality of the rendered image. It is a relatively simple matter to add two more cubes to the scene and change the shaders and opacity as follows:
/* TABLE*/surface "wood" "Ks" [0.937] "Kd" [1.000] "Ka" [1.000] "roughness" [0.250] "grain" [10.000] "swirl" [2.530]
/* LEFT CUBE */
color [0.581 0.720 1.000]
surface "metal" "Ks" [1.000] "Ka" [1.000] "roughness" [0.500]
/* CENTERCUBE */
opacity [0.500 0.500 0.500]
surface "plastic" "Ks" [0.875] "Kd" [0.869] "Ka" [0.802] "roughness" [0.250]
/* RIGHT CUBE */
color [0.809 0.089 0.112]
surface "stippled" "Ks" [1.000] "Kd" [1.000] "Ka" [0.809] "roughness" [0.250] "grainsize" [0.031] "stippling" [1.000]
These programming changes produce the changes in appearance of objects in the scene shown in Figure 10.17.
Finally, keeping the model's geometry identical with that of Figure 10.17, the following changes in shaders produce the image of Figure 10.18.
/* TABLE*/
color [0.934 0.748 0.694]
surface "carpet" "Kd" [0.600] "Ka" [0.848] "nap" [2.000] "scuff" [2.000]
/* LEFT CUBE */
surface "rmarble" "Ks" [1.000] "Kd" [0.950] "Ka" [0.875] "roughness" [0.000] "veining" [8.000] "specularcolor" [1.000]
/* CENTERCUBE */
opacity [1.000 1.000 1.000]
surface "spatter" "Ks" [0.875] "Kd" [0.869] "Ka" [0.822] "roughness" [0.250] "specksize" [0.480] "sizes" [5.000]
/* RIGHT CUBE */
color [0.697 0.363 0.108]
surface "wood" "Ks" [0.950] "Kd" [0.882] "Ka" [0.776] "roughness" [0.250] "grain" [10.000] "swirl" [0.625]
Effects of changes in RenderMan shaders.
The price the user pays for this programming flexibility is the effort involved in tediously "hand crafting" each scene and image.
In practical design environments, the preferred mode is to create the model with a CAD package and submit the model to RenderMan as a RIB file. Many CAD systems support the rapid, intuitive design of 3D objects. Therefore, they provide the natural user interface for designing models for realistic rendering. From the designer's point of view, RenderMan can be considered the final pass for processing the user's design.
In Figure 10.19, the scene generated using CAD
modeler, Swivel 3D Professional, is shown. The process of building
the model is discussed in the chapter on design. The model itself required
about onehalf hour to construct by a reasonably skilled designer. Swivel
3D Professional is one of a growing number of design and modeling programs
that support the RenderMan RIB format. So, for instance, to select
the shader to use for a particular object, the object is selected and the
Select Color menu opens a shader submenu. Selecting a particular
shader opens additional submenus from which the particular shader parameter
values are selected. The windows providing parameter selection are shown
in Figure 10.21.
Additional texture mapping changes by RenderMan.
CAD model designed with Swivel 3D. Note that the polygonal basis for the model is quite apparent. To add interest and realism, we have invoked the shadow and antialiasing rendering features of the modeler.
RenderMan image of model shown in Figure 10.19. In the model, the pedestal has been set to marble and the glass has been set toplasticwith the top half given a transparency of 0.5 and the bottom part a transparency of 0.75. The floor surface is generated by the carpet shader.
After the surface attributes were set by the interactive menu selection outlined in Figure 10.21, the RIB file corresponding to this model was generated and submitted to RenderMan for image generation. The results are shown in Figure 10.20.
The increase in visual realism achievable by surface mapping is obvious in Figure 10.20. In particular, the marble pedestal and carpeted floor surface improve the realism of the scene, and the transparency of the glass conveys a convincing (if nonphysical) image. The shaders and their attributes were set very simply using the series of hierarchical windows presented in Figure 10.21.
Figure 10.21Material shader windows for setting RenderMan parameters. Clicking on the palette icon and the object to be shaded causes the shader icon palette summary to open (a). Double clicking the right icon opens the menu, (b). Clicking the Material Shader button opens the Shaders menu, (c). After selecting a shader, the Shader Values button is clicked and its attributes set with the valuators, (d). Swivel 3D automatically incorporates these attributes into the RIB file it exports for RenderMan. 


One of the most useful features of CAD systems is the library of parts and objects available to the designer. To design the more complex scene of Figure 10.22, we built the room (two walls and floor) and picture by modifying the basic cube primitive of Swivel 3D. Then the filing cabinet, table, chair, and serving tray were imported from an object library and positioned, using orthographic projections. Next, the colors and textures were selected with the menu windows shown in Figure 10.21. Finally, the export file type was set to RIB and the output file generated for input to RenderMan.
The process of designing a world model like that shown in Figure 10.22 takes less than an hour for a moderately skilled designer. It is important to note that the design occurs completely in 3D space, maintaining complete flexibility of object position, camera position, and projection type until the desired projected image is achieved. The complete 3D representation of the model, including camera position, directions of light sources, and surface shaders and parameters, is encoded in the RIB file exported to RenderMan. The RIB file is a standard text file of RenderMan language commands which can be edited with any standard word processor. The model shown in Figure 10.22 is represented by a 900 Kb RIB file.
There are several interesting features distinguishing the model image of Figure 10.22 and the rendered image of Figure 10.23. First is the obvious aliasing of straight edges of the model image. These may be suppressed by invoking an antialiasing option of the modeler as was done in Figure 10.17. Second is that surface shaders are merely attached to the surfaces in the RIB files generated by the modeler but are not used in generating the image produced by the modeler. The final feature of note is that shadowing of the model image is a rendering option of the modeler (invoked in Figure 10.17 but not in 10.22), but the results of shadowing are not transmitted through the RIB file.
Office scene produced with 3D CAD modeler, Swivel 3D. Surface attributes such as transparency of the glass table top and carpet texture have been tagged to the surfaces but not rendered by the modeler.
The RIB file is then rendered by Renderman, and several hours later the image shown in Figure 10.23 is complete. Rendering takes place in background mode, however, and the machine is available for other tasks during the process.
Several features of the RenderMan image enhance its visual realism as compared to the modeler image. First is the antialiasing which eliminates the prominent aliasing observable in Figure 10.22. Second is the improved realism of several of the surfaces produced by texture mapping shaders. The only shading controls available on the modeler are the relative values of ambient and specular light intensity. These values are passed through the RIB file to RenderMan which has, in addition, a rich repertoire of builtin shaders and the capability of userdefined shaders.
While the RenderMan image is more realistic than the plasticlike scene of the modeler, it still fails the test of photorealism. An examination of Figure 10.23 reveals these failings.
The specular surfaces of the tea set fail to reflect objects in their environment which an accurate raytraced solution would have generated.
The chair, table, and file cabinet appear to be floating a few inches above the floor. This is a common artifact associated with the absence of a global solution such as that provided by radiosity. A global solution produces local shadows in regions where the objects contact the floor.
The rendered solution shown does not include shadows of any kind. The resulting flat and featureless image is a signature of the local shading model used by RenderMan.
RenderMan image of Figure 10.22 office scene model.
But surely, you must be thinking, RenderMan should be able to do better than this or it wouldn't be capable of producing the realistic visual effects in films like The Abyss. The solutions to these problems in realistic rendering are provided by two additional generalized texture maps. These are called environment maps and shadow maps.
Environment maps address the problem of interobject reflectionsan image of the filing cabinet which should be visible in the tea set. An environment map assumes a viewpoint near the middle of the reflective object and precomputes an image from that viewpoint. This image is then mapped onto the surface and added to the specular and ambient light emitted from the reflective surface.
Environment mapping is a relatively inexpensive technique for rendering highly reflective objects. It works well when the surfaces are fairly small compared to the distance to the objects being reflected and is less well suited to rendering highly convoluted surfaces that reflect themselves. It also suffers from the "hand crafting syndrome," that is, the user must select which objects will use environment maps and then call the appropriate routines for each object. This ad hoc approach contrasts sharply with the automatic and complete rendering which raytracing algorithms carry out on wellspecified scenes.
&nbs