Inspection is an approach to viewing where users can examine a scene as if it's a single object they are holding in their hand. For example, users may want to examine the model of a coffee mug the same way they would examine a real mug by holding it and turning it around.

The expected user model for inspection is that users are manipulating the scene, not the camera. From the users' perspective, all inspection controls appear to manipulate the scene (or object) while the camera remains stationary. For example:

Note that in both examples, users move the control (and pointer) in the direction they want the scene (or object) to move. To achieve this, the application moves the camera in the opposite direction of the control (and pointer).

Table 13-2 provides an overview of the different functions available in inspection.

Tumbling is the default viewing function for inspection. Users rotate a model of an object or a scene as if they were holding it in their hand. Users expect to be able to tumble the object in all three dimensions around the fixed look-at point. Tumbling doesn't change the location of the object in space.

The user controls tumbling by dragging with the left mouse button. The movement follows a virtual trackball imposed on the viewing window. The initial position of the pointer on this virtual trackball influences the tumbling behavior: If the user positions the pointer in the center of the viewing window (trackball) and drags horizontally (or vertically), the object tumbles around the y axis (or x axis). If the user positions the pointer in the center of the viewing window and drags out in any direction, the object tumbles around an axis perpendicular to the drag. If the user drags in a circle around the center of the virtual trackball, the object tumbles around the z axis. If the user drags beyond the limits of the trackball, the object continues to tumble until the user releases the mouse button.

Figure 13-2 illustrates tumbling from the implementation perspective. The camera (eyepoint) moves around the scene as though the camera were placed on the surface of a sphere. The look-at point remains stationary at the center of the sphere. The camera moves opposite to the direction of the rotation. Using the original camera position, the user can look into the pot but can't see much of the pot's outside surface. After the user has tumbled the bottom of the pot upwards, it's possible to see the pot's surface. To accomplish this rotation, the eyepoint (camera) moves down along the surface of the sphere and the look-at point remains stationary.

Dollying allows users to move a model of an object or a scene closer or farther away. Users move the object as if they were holding it in their hand. The user controls dollying by dragging while simultaneously pressing the left and middle mouse buttons during inspection. Dragging down in the viewing window moves the object closer; dragging up moves it farther away.

Figure 13-3 illustrates dollying from the implementation perspective. The look-at point and viewing direction are fixed. The camera (eyepoint) moves toward the look-at point along the viewing direction to move the object closer to the user. If the user wants to move the object further away, the camera would move away from the look-at point.

Dollying is different from zooming. In both cases the objects change in size in the viewing window. However, in contrast to dollying, zooming doesn't move the object closer or farther away from the user. Zooming instead allows users to change the viewing angle of the camera, the same way they would use a zoom lens on an actual camera. That is, as the user zooms out the viewing angle is increased so that the viewing area becomes larger and more of the scene is visible. This new larger viewing area is then mapped to the viewing window.

As shown in Figure 13-4, objects appear larger (or smaller) after zooming in (or out) even though the location of the camera hasn't changed. This is because the viewing angle changes but the size of the viewing window hasn't changed.

Panning allows users to move a model of an object or a scene up, down, left, or right in the viewing window. Users move the object as if they were holding it in their hand. The user controls panning by dragging while pressing the middle mouse button. The object moves in the direction of the drag; for example, dragging up in the viewing window moves the object up and dragging left moves the object left.

Figure 13-5 illustrates panning from the implementation perspective. The camera (eyepoint) moves in the plane perpendicular to the viewing direction. The camera moves opposite to the movement of the object. As shown in the figure, the camera moves right, which moves the scene to the left in the viewing window. The look-at point moves with the camera. The viewing direction is unchanged.

Seeking allows users to move an object in the scene into the center of the viewing window. In inspection, the user model is that the user is incrementally moving the object closer (see “Inspection Overview”). In navigation, the user model is that the user is incrementally moving closer to the object (see “Navigation Overview”).

For both inspection and navigation, the user controls seeking by clicking on the object (or part of the object) of interest. Clicking on the object centers the object (or part) in the viewing window and brings the object and user closer together. Each additional click on the same object (or part) brings the object and user still closer. Figure 13-6 shows a simple example of seeking to the door of a house. The first click on the door positions the door in the center of the viewing window and halves the distance between the door and the user. The second click halves the distance again.

Many applications need to reserve clicking with the left mouse button for a more critical or useful function (for example, activating a link or initiating object behavior). In those applications, allow users to first activate a seek tool, then click with the left mouse button in the scene to actually seek.

From the implementation perspective, seeking sets a new look-at point at the location of the user's click and moves the camera so that this new look-at point is at the center of the viewing window. The camera is also moved forward half the original distance between the camera and the object. Note that in the case of inspection, resetting the look-at point by seeking means that the camera tumbles around this new point after the seeking action.

Navigation is useful when users want to move through a world, for example, walk through a 3D model of a museum or an architectural model. In navigation, the user maneuvers through a fixed, immovable world by walking, flying, or another navigation mechanism.

The expected user model for navigation is that users are manipulating the camera. From the users' perspective, all navigation controls appear to manipulate the camera while the scene remains stationary. For example:

Note that in both examples, users move the control (and pointer) in the direction they want the camera to move.

Table 13-3 provides an overview of the different functions available in navigation.

Roaming (and turning) is the default viewing function for navigation. Users move through a fixed scene as if walking through it. While users are moving they expect to be able to turn to change the direction of the movement. Users control roaming by dragging with the left mouse button while the application is in view mode. Since users may sometimes want to turn without moving, dragging on the horizontal is interpreted differently than dragging in other directions as follows:

From the implementation perspective, the camera (eyepoint) moves forward or backward along the viewing direction in the same direction as the user's action; that is, as the user moves forward, the camera moves forward (see Figure 13-7). The viewing direction moves in the same direction that the user turns; that is, as the user turns left, the viewing direction rotates left. If the user indicates a wish to turn but not move (by dragging the pointer directly left or right on the horizontal), the viewing direction changes appropriately but the camera doesn't move forward or backward. The look-at point changes as the viewing direction changes.

Tilting allows users to look up and down to see an object higher or lower than their current viewing direction in the scene. Tilting doesn't move the user. To move toward an object in the new view, the user has to use roaming (see “Roaming”). To control tilting, the user simultaneously presses the left and middle mouse buttons and drags. Dragging up in the viewing window tilts the user's head up to look up in the scene; dragging down allows the user to look down.

From the implementation perspective, tilting changes the viewing direction in the same direction the user's head is tilted (see Figure 13-8). As the user looks up, the viewing direction moves up; looking down moves the viewing direction down. The location of the camera (eyepoint) doesn't change. The location of the look-at point changes as the viewing direction changes.

Sidling allows users to sidestep left and right in the scene or to “elevator” up and down in the scene. Sidling moves the user left, right, up and down in the plane perpendicular to the viewing direction; it doesn't move the user forward or back in the scene. The user controls sidling by dragging while pressing the middle mouse button. The user moves in the direction of the drag; for example, the user drags left in the viewing window to sidestep to the left. Dragging up moves the user up as if riding on an elevator.

Figure 13-9 illustrates sidling from the implementation perspective. The camera (eyepoint) moves in the plane perpendicular to the viewing direction. The camera moves in the same direction that the user wants to move. As the user sidesteps left, the camera moves left. If the user moves up, the camera also moves up. The orientation of the camera remains unchanged. The look-at point moves with the camera.

If an application supports editing, separate and explicit view and edit modes are highly recommended. This allows more flexibility in assigning functions to mouse and keyboard key combinations. In edit mode, mouse and keyboard input perform editing functions on selected objects and on the scene; in view mode, mouse and keyboard input perform viewing functions.

Users expect an obvious mechanism to switch modes, for example an item in a pull-down menu or a button on a tool palette that provides a variety of possible modes. In addition, users also expect to be able to switch modes using the <Esc> key (see “Using Modifier Keys in 3D Applications” in Chapter 12). Pressing this key takes the user to the next mode.

When they are editing, users expect to always have quick access to viewing with a view overlay. A view overlay is a temporary view mode that's available while the user holds down the <Alt> key (see “Using Modifier Keys in 3D Applications” in Chapter 12). As long as the <Alt> key remains pressed, mouse and keyboard input is temporarily interpreted as providing viewing input rather than editing input. Releasing the <Alt> key returns the application to standard editing operations. If the application is already in view mode when the user presses the <Alt> key, the <Alt> key is ignored.

A view overlay offers users quick access to temporary viewing but allows them to stay focused on the editing tasks at hand. This avoids forcing the user to make a heavyweight switch between edit and view modes. Although the view overlay is temporary, users still need to see the correct pointer shape feedback while accessing the viewing functions (for example, the roam pointer or tilt pointer). See “Pointer Shapes for 3D Functions” in Chapter 12.

Applications can optionally provide separate user interface controls to access viewing functions. In this approach, all mouse input is interpreted as editing input unless the user is using the mouse pointer to manipulate a viewing control.

Figure 13-10 shows an application window with viewing controls around the sides and the bottom of the window. Manipulating the thumbwheels or sliders with the mouse affects viewing: For example, dragging the thumbwheel in the lower right hand corner of the window dollies the camera, which changes the view but doesn't edit it. Using the mouse in the viewing area of the window performs editing actions: for example, clicking on the star selects that object for editing.

Another optional method of addressing the conflict between viewing and editing input is to assign all viewing actions to one dedicated input device, such as a spaceball. All input from the dedicated input device performs viewing functions; input from other devices performs editing functions. This approach provides more input bandwidth: Context switching between viewing and editing is handled by the choice of input device.

In the single-viewport model, only one view of the scene can be projected to the single viewport at any given time, even if there are multiple cameras in the scene. This is a serially multiplexed approach; different views are presented one after another in the same viewport and the user can switch among them.

By default, the viewport provides a perspective view of the scene. The view updates as the user selects different cameras.

Single-viewport viewing has these advantages:

In the multi-viewport model, two or more views of a scene are simultaneously available. Typically, there are four views: front, top, one side (typically the right), and perspective.

A view isn't necessarily bound to a particular camera. For each view, the user can choose which camera to use and what each camera views. For example, to view an object from the bottom that's currently visible from the front, the user can either find a camera that displays it from the bottom or tumble or roam to get that view.

Multi-viewport viewing has the advantage that it allows simultaneous views of different representations of data. Users can examine and edit data from different perspectives simultaneously and can edit and examine data across multiple views without having to switch views. This is important for editing complex objects or during scene composition. While performance can be worse with multiple views (because more windows must be updated during viewing operations), experienced users find multiple views useful because they can coordinate operations across multiple viewports to get more accurate feedback on the actions they are performing.