Graphics Reference
In-Depth Information
product may end up differing from a rotation by a large amount because of round-
off errors; the result can (and should!) surprise the user. A solution to this is to
accumulate the rotations and then, after perhaps ten are accumulated, reorthogo-
nalize the matrix with the Gram-Schmidt process.
Even with this reprojection onto the set of rotation matrices, the differential
form has another drawback. The exact same cursor click-and-drag sequence, exe-
cuted on two identical scenes, may produce different results. That's because the
mouse motion is sampled by the operating system, and depending on other loads
on the machine, the samples may not occur at exactly the same moments. Thus, the
two sequences of points used to produce the two sequences of rotations may dif-
fer slightly, and the final results will generally differ as well. This is not usually a
problem unless the load is rather high so that sampling occurs at a rate that fails to
accurately represent the cursor path. For example, if the cursor is moved in a small
circle over the course of a half-second, but only two position samples are taken
during that time, the results will be very different than if ten samples are taken.
In general, it's a bad idea to try to numerically integrate differentials, or
even very small differences, for the reasons given above. There are two excep-
tions. First, such an integral may be the only practical way to compute a value.
In studying light transport, for example, computing the light arriving at the eye
amounts to evaluating an integral, one for which the only known methods are
numerical (see Chapter 31). The second is where the summed quantity is known
to be an integer; in this case, roundoff errors, if they're known to be small, can be
removed by rounding. (For instance, if you sum four terms and get 3.000013, you
can safely assume that the value is 3.)
The arcball interface [Sho92] is exactly like that of the trackball, except that the
sphere rotates
twice
as far as the drag would suggest. That is to say, if you drag
from
A
to
B
, and they're 30
◦
apart on the sphere centered at
C
, the object will
rotate 60
◦
in the plane of
A
,
B
, and
C
.
This has several practical implications. First, even though we can only see
and click on the front half of the sphere, we can perform every possible rotation:
Dragging the nearest point to the contour rotates it all the way to the farthest point,
for instance. Second, dragging from
P
to
Q
, then
Q
to
R
, then
R
to
P
(where all
three are points on the sphere) results in no rotation at all.
In evaluating the arcball, much of what we said about the virtual sphere still
holds. If the interaction sphere is textured with some recognizable pattern, such
as a world map, then there is some surprise for the user who clicks and drags
London: During the drag, London slides out from under the cursor. With a trans-
parent sphere, this effect is largely invisible, however, and the interaction feels
quite natural. (If we were to implement a translation-by-dragging interface and
translated by twice the drag vector, it would almost certainly be disconcerting to
the user, however.)
Unicam
We now move on to the topic of manipulating the view of a scene. It's easy to
imagine that this is just the same as manipulating an object; after all, the camera
