|
|
 |
 |  | | | | |  | |||
 | ||||||
          |  |  | ||||
|
The Full Spectrum Warrior Camera System Collision Avoidance and Cuts The FSW camera system uses various techniques to avoid collisions and to prevent obstruction of the view. Normal View Collisions The camera attempts to avoid collisions with the environment
by casting several rays from the look-at point towards the general vicinity
of the camera. Each ray is cast to points that have the same altitude
(y value) as the camera. This creates an arc of an inverted cone of rays
over the look-at object (see Figure 4 and Figure 5).
Each ray has a weight that determines how strongly it affects the view radius. The rays nearest the camera affect the view radius 100%. The view radius will never exceed the length of these rays. Rays further from the center have progressively smaller effect on the view radius. The farthest rays have a very weak effect. The calculated view radius is used to generate the target point for the motion system, which smoothly interpolates the position, preventing jarring motion. Fly-By Collision Avoidance Another algorithm helps the camera avoid walls when it is performing a "fly-by" between distant points. This algorithm also casts rays from the look-at point, a single ray to the left and a single ray to the right (see Figure 6). Note that the ray casts may not be horizontal, as they originate at the height (y-position) of the look-at point and end at the height of the camera. When a ray intersects a wall, it applies a small sideways
acceleration to the camera, nudging it away from the wall. The size of
the side acceleration is proportional to the distance from the look-at
point to the intersection.
Look-At Avoidance A "look-at avoidance" algorithm prevents
the camera from passing too close to the look-at point, which would otherwise
result in rapid and disorienting camera pan. This algorithm analyzes the
distance from the look-at point and the approach velocity. If the camera
is in danger of passing too close to the look-at point, its target velocity
is modified by reducing its magnitude and moving the vector away from
the line between the camera and the look-at point.
Although look-at avoidance is an important consideration for many camera systems, its solution is game dependent. Rather than delving into a detailed discussion of the calculations used by the FSW algorithm (which is beyond the scope of this paper), the following summarizes some important things to consider when working on this problem. First, determine if look-at avoidance is necessary. In general, look-at avoidance is most problematic during fly-bys. If your system cuts between viewing positions, then look-at avoidance may be a moot point. Even when your system has fly-bys, look-at avoidance may not be an issue if the camera always flies straight towards objects, since it does not need to pass to the opposite side of viewed objects. When the camera motion controller has lag, it is possible that moving objects may catch up to the camera in certain circumstances, requiring a different type of look-at avoidance. This problem can usually be avoided in games like FSW, since the camera is attached to human characters whose maximum speed is a quick run. However, this can become a serious issue in games with fast moving vehicles. A potential solution for this particular problem is to apply a repulsive force from the look-at point to the camera. The force grows in inverse proportion to the distance between the camera and the look-at. If your system does need look-at avoidance, consider what general approach you want to use. The FSW system modifies the camera velocity, but there are other solutions. Your camera can maintain its orientation, fly past the viewed object, then turn to face it, preventing rapid-pan problems. Or, you might be able to move the camera's target position so that the camera no longer needs to pass beyond the viewed object. Whatever your solution, it is important to take the environment into consideration, since look-at avoidance changes the camera position which may unintentionally cause the camera to intercept environmental geometry. Camera Cuts In cases when the destination is on the other side of a wall or obstacle, the camera cuts past the obstruction. When this situation arises, the camera animates as it would for a fly-by. It pivots in place (if necessary) to face towards the new look-at point. Then, it begins to fly forward until it is close to an intervening obstacle (usually a wall). The camera cuts to an unobstructed point and continues its fly-by. The camera also performs a cut instead of a fly-by whenever the destination is beyond a certain distance. This prevents overly lengthy fly-bys which would interrupt gameplay. Characters And Tagged Objects In FSW, the camera does not collide with characters. Any character that obstructs the view becomes translucent. Additionally, environmental objects can be tagged so that the camera does not collide with them. This is generally used for thin objects, such as telephone poles. Debugging and Tuning Aids FSW has over 100 parameters that affect the camera system. Many of these parameters require tuning by a designer or programmer. With such a large number of parameters, it can be difficult to predict how a change in a value will affect the camera system. Indeed, it can even be difficult to comprehend exactly what a value represents and what it is intended to change. In order to facilitate the tuning process, FSW has debug displays that graphically display aspects of the camera system. Most of the displays indicate ray casts through the environment. The rays used for collision probing are displayed. Rays that intersect the environment are displayed in a different color from those that do not. The raycasts for the autolook system are also displayed. An additional debug feature that is very useful is the ability to view the scene from any camera. This allows examining the dynamics of a camera by viewing it from another perspective. This is especially useful for examining raycasts, since raycasts often originate near or behind the eye point, where they are difficult or impossible to see from the normal perspective. It can also be useful to view the camera's motion from an alternate perspective, which can elucidate the source of motion glitches. The camera system timescale can also be altered to allow closer examination of glitches. Sometimes a slow-motion examination will reveal details that are not visible at normal speed. Other Considerations Gameplay Recording And Playback FSW can record and playback game sessions. This is done by recording the input stream and a minimal amount of other critical information (such as timestamps). To re-create the original gameplay the game is started and the original input stream is fed back into the system. In order for this type of playback system to function properly, the gameplay components must be repeatable, behaving identically during a replay as during the original recorded session. However, the user can view from different angles in replay, which means that the camera will not be at the same position as it was during the original session. This could disrupt playback, since the camera affects the operation of UI components (e.g., the movement cursor operates relative to the main camera). This problem is solved by adding special replay cameras that function only during replays (they are inactive during normal gameplay). The original gameplay cameras repeat their same behaviors during replay even when the user is not viewing them. Field Of View (FOV) As with many features of a game camera system, the field of view (FOV) affects both aesthetics and usability. Note that, in the following, FOV is measured horizontally (the vertical FOV is determined by the aspect ratio of the screen). In FSW, the typical gameplay FOV is 80 degrees wide. This is wider than in many games (it seems that 60 degrees is the "unwritten standard"). However, the wider FOV provides a better view of the actions and situations in the game, which is helpful in a game like FSW where the user must evaluate and plan strategies involving a large portion of the play area while viewing from a close third-person perspective. An even wider FOV might have been useful, but after 80 degrees, the distorted perspective is too unnerving for most players. FSW changes the FOV in two situations: (1) The player can zoom the camera to get a closer view of enemies. The result is a reduced FOV, (2) FOV is changed during cinematics, again to provide a zoom effect. Limitations of the System and Potential Improvements So now you've learned about the best parts of the FSW camera system. Unfortunately, like all things, it is not perfect. Here are some of the limitations of the FSW camera system and what has been done about them (if anything). The biggest limitation of the FSW camera system is that the main camera can temporarily clip through walls in certain situations. These problems are always temporary--the camera never gets "hung up" on geometry. The situation is fairly rare, and usually occurs only during a fly-by. It would be nice to fix for aesthetics, but there is the risk of introducing worse problems in the process. In the end, we have decided to live with the issue. A second limitation of the system is that it does not provide a good playing perspective in tight spaces. This is not a major concern for FSW, since tight spaces have been avoided by design for a multitude of reasons unrelated to the camera system. Although the main camera satisfied the requirements of the gameplay camera system, it is also very complex. Part of its complexity is due to serving more than one purpose in the game. It handles the user-controlled pan/tilt operation, fly-by functionality, plus a portion of the cinematics system. Splitting the main camera along those functional lines to create multiple cameras would simplify code and, more importantly, would simplify the tuning process. Recommendations
Future Directions
References Bobick, Nick, "Rotating Objects Using Quaternions", Game Developer Magazine, April 1998 Drucker, Steven M., Zeltzer, David, "Intelligent Camera Control in a Virtual Environment", Proceedings of Graphics Interface '94 Hawkins, Brian, "Creating an Event-Driven Cinematic Camera" (two parts), Game Developer Magazine, October/November 2002 He, Li-wei, Cohen, Michael F., and Salesin, David H., "The Virtual Cinematographer: A Paradigm for Automatic Real-Time Camera Control and Directing", SIGGRAPH 96 Proceedings, pp 217-224. Rabin, Steve, "Classic Super Mario 64 Third-Person Control and Animation", Game Programming Gems II, Charles River Media, 2001 Treglia II, Dante, "Camera Control Techniques", Game Programming Gems, Charles River Media, 2000 ______________________________________________________
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
Introduction
GDC
2004 Feature 
