Graphics Reference
In-Depth Information
Of course, we'll take many chapters to resolve the theoretical and practical
issues raised here. Since graphics is an active field, some issues will not be thor-
oughly resolved even by the end of the topic. In the spirit of servicing both prin-
ciples and practice, we present some ideas first with pseudocode and mathematics
and then second in actual compilable code. Although minimal, that code follows
reasonable software engineering practices, such as data abstraction, to stay true
to the feel of a real renderer. If you create your own programs from these pieces
(which you should) and add the minor elements that are left as exercises, then you
will have three working renderers at the end of the chapter. Those will serve as a
scalable code base for your implementation of other algorithms presented in this
book.
The three renderers we build will be simple enough to let you quickly under-
stand and implement them in one or two programming sessions each. By the end
of the chapter, we'll clean them up and generalize the designs. This generality
will allow us to incorporate changes for representing complex scenes and the data
structures necessary for scaling performance to render those scenes.
We assume that throughout the subsequent rendering chapters you are imple-
menting each technique as an extension to one of the renderers that began in this
chapter. As you do, we recommend that you adopt two good software engineering
practices.
1. Make a copy of the renderer before changing it (this copy becomes the
reference renderer
).
2. Compare the image result after a change to the preceding, reference result.
Techniques that enhance performance should generally not reduce image qual-
ity. Techniques that enhance simulation accuracy should produce noticeable and
measurable improvements. By comparing the “before” and “after” rendering per-
formance and image quality, you can verify that your changes were implemented
correctly.
Comparison begins right in this chapter. We'll consider three rendering strate-
gies here, but all should generate identical results. We'll also generalize each
strategy's implementation once we've sketched it out. When debugging your
own implementations of these, consider how incorrectly mismatched results
between programs indicate potential underlying program errors. This is yet
another instance of the Visual Debugging principle.
We start with a high-level design in this section. We'll then pause to address the
practical issues of our programming infrastructure before reducing that high-level
design to the specific sampling strategies.
Light that enters the camera and is measured arrives from points on surfaces in the
scene that either scattered or emitted the light. Those points lie along the rays that
we choose to sample for our measurement. Specifically, the points casting light
into the camera are the intersections in the scene of rays, whose origins are points
on the image plane, that passed through the camera's aperture.
