Graphics Reference
In-Depth Information
transformation is part of the scene graph in exactly the same way that the transfor-
mations on objects are. In more basic terms, if we want to see the left-hand side
of a box, we can either rotate the box to the right or move our eyes to the left. It's
not very difficult to adapt the trackball or arcball interface to act on the scene as a
whole rather than on a particular object, and thus achieve this effect. For a square
viewport, we simply draw a manipulator sphere that touches all four sides of the
viewpoint, thus giving maximal precision in control of the camera. Unfortunately,
when we do so we find it's not very satisfactory: The camera keeps tilting away
from “upright,” and while being able to make a single object tilt is convenient,
having a tilted camera is so rarely what's wanted that it's a constant annoyance.
This is a situation where context (the traditional human experience of having the
vertical almost always be “up” in our view of the world) should influence design.
Furthermore, camera control involves more than just the orientation of the
camera: You may wish to look somewhere else (at some other object), or get closer
to the object you're looking at. For the first of these
(panning),
there's a fairly
natural interaction: You can click on the object you want to look at and drag it to
the center of the screen. If it's off-screen, multiple panning steps may be needed.
Of course, you need to do something to indicate that you're panning rather than
rotating; that is, you need a notion of “mode.” For the second
(dollying),
there's
no obvious interaction, even once you've established you're in dollying mode.
Unicam [ZF99] is a camera-manipulation mechanism that allows for control-
ling the three rotational degrees of freedom and the three translational degrees of
freedom in a virtual camera with a single integrated system. Other features com-
mon to virtual cameras (clipping, plane distances, view angle, and film-plane rota-
tions for view-camera effects) are so rarely adjusted that they are not included, just
as we omitted image rotation in our photo-manipulation application. The imple-
mentation is so very similar to that of the other manipulators we've described that
we'll simply describe how the interface feels to the user. Unicam can actually be
used for both perspective and orthographic cameras, but we'll only describe the
more common perspective camera case here.
Because Unicam is designed for applications in which camera control is a fre-
quent operation (e.g., solid modeling), a single mouse button is entirely allocated
to it: All camera operations are performed by click and drag with this one mouse
button. This reduces the transition time and effort when the user wants to switch
between camera operations and other application operations controlled by other
mouse buttons.
With Unicam, the viewing window is divided into two regions (see Fig-
ure 21.9): an inner rectangle in which interactions determine camera translations
and a border where they determine rotations.
Figure 21.9: In the blue inner
rectangle, mouse motions induce
camera translations. In the pink
border
Unicam maintains a notion of a
hit point,
a place that represents the location
of the user's focus of attention. Typically, this is the scene point under the cursor
(i.e., the first point hit by tracing a ray from the eye through the cursor point on
the film plane into the scene). In the event that this ray hits nothing in the scene,
the hit point is the projection of the
previous
hit point onto this ray.
region,
mouse
motions
determine rotations.
A click and drag in the translation area is initially classified as “horizontal” or
“vertical” by examining the first few pixels of motion. (The authors suggest about
1% of the screen width as a reasonable distance to use in determining primary
