Graphics Reference
In-Depth Information
of rotation. In each case, rather than using virtual-sphere or arcball rotations,
the
x
- and
y
-coordinates of this mouse displacement from its initial click deter-
mine, respectively, rotation about the world “up” vector (usually
y
) and about the
camera's “right” vector (i.e., the vector pointing to the right in the film plane).
Full-screen-width horizontal motion corresponds to 360
◦
rotation about the up
vector; full-screen-height motion corresponds to 180
◦
rotation about the right
vector, although this rotation is clamped to prevent ever arriving at a straight-up
or straight-down view. The rotations are implemented sequentially: first a rotation
about the up vector, then about the right vector.
The focus dot also serves as a focus for further interactions: Clicking and releasing
on the focus dot moves the camera to an oblique view of the underlying object,
seen from slightly above the object. A click and drag up and to the right saves the
current view into a draggable icon that can later be clicked to restore the view.
Dragging down and to the right temporarily scales the focus sphere by enlarging
its radius to the drag distance; upon release, the camera dollies inward until this
enlarged sphere fills the view, at which point the focus sphere returns to its normal
size. This allows the user to easily specify a region of interest. A drag in any other
direction aborts the gesture.
Unicam presents the user with very easy access to the most common camera oper-
ations. By having many of the gestures start at the current cursor location, it takes
greatest advantage of Fitts' Law. By associating actions with a direct-manipulation
“feel” (translation by dragging feels as if you are dragging the world with the cur-
sor, and dollying by vertical motion feels like you're moving along a train track
toward its vanishing point), the designers make the operations easy to use and
remember.
On the other hand, there are no affordances in the system. There's nothing that
tells you that the view's border area can be used for rotation, or that its center
can be used for translation. For an often-used feature like camera control, this is
probably appropriate. Through constant use, the user will rapidly memorize its
features. For controls that are used less often, some visual representation would
be appropriate.
We've seen two object-rotation interfaces and a camera-control interface. Many
games provide camera controls that simply let you look left or right (by fixed
increments) or up and down (by fixed increments), often controlled by keyboard
keys. Architecture walkthrough programs let the user move through a building, by
typically constraining the eye height to something near 1.8m, and prevent motion
that passes through walls, etc. Which interface is best? The answer is that among
well-designed interfaces (e.g., ones that pay attention to matters of affordance and
Fitts' Law), the best choice almost always depends on context. In an architec-
ture walkthrough application, the camera-control interface should restrict the eye
height and prevent passing through walls; in a CAD/CAM system for designing
