Graphics Reference
In-Depth Information
The testing will vary with the situation: If the design abstracts something about
human perception, then the test may involve user studies; if the design abstracts
something physical (“We can safely model small ocean waves with sinusoids”),
then the test may be quantitative.
Barzel [Bar92] argues that most physical models for computer graphics come
in three parts: the physical model itself, a mathematical model, and a numeri-
cal model. (As an example, the physical model might be that ocean waves are
represented by vertical displacements of the water's surface, and their motion is
governed solely by the forces arising from differences in nearby heights [rather
than by wind, for example]; the mathematical model might be that these displace-
ments are represented by time-dependent functions defined at integer points in
some coordinate grid on the ocean's surface, with intermediate values being inter-
polated; and the computational model might be that the water's state one moment
in the future can be determined from its state now by approximating all deriva-
tives with “finite differences” and then solving a linearized version of the resultant
equations.) Including this separation in your programs can help you debug them.
This means, however, that during debugging, you must remember your model and
its level of abstraction and the limitations these impose on your intended results.
(In our example, the physical model itself says that you cannot hope to see break-
ing waves, while the mathematical model says that you cannot hope to see details
of the water's surface at a scale smaller than the coordinate grid.) Within computer
science, this is very unusual: In most other areas of computer science, you've got
either a computational model or a machine model, and this single model provides
your foundation. In graphics, we have physical, mathematical, numerical, compu-
tational, and perceptual models, all interacting with one another.
In both 2D and 3D graphics, it's critically important to consider the eventual
goal of your work, which is usually
communication
in some form, and usually
communication to a human. This end goal influences many things that we do,
and should influence everything. (This is just a restatement of the “form follows
function” dictum, as valuable in graphics as it is anywhere else.) As a simple
example, consider how we treat light, which is just a kind of electromagnetic radi-
ation: Because humans can only detect certain frequencies of light with their eyes,
we usually don't worry about simulating radio waves or X-rays in graphics, even
though the light emitted by conventional lamps (and the sun) includes many ener-
gies outside the visible spectrum. Hence, a limitation of the visual system becomes
a computational savings for our programs. Similarly, because the eye's sensitivity
to light energy is approximately logarithmic, we build our display hardware (to a
first approximation) so that equal differences in pixel values correspond to equal
ratios
of displayed light energy.
T
HE VISUAL SYSTEM IMPACT PRINCIPLE
:
Consider the impact of
the
human visual system on your problem and its models.
As another example, even in 2D display graphics there are perceptual issues
to consider: The limits of human visual acuity tell us that the things we display
must be of a certain size to be perceptually meaningful; at the same time, the
limits of human motor control tell us that interaction must be designed in ways
that fit those limits. We cannot ask a user to click on a sequence of pixels in a
