An alternative solution is to use ray-casting hysteresis, that is, statistical information of the ray cast results gathered over multiple updates. From this history, it is possible to generate a probability graph of likely ray collisions and to reduce the actual amount of ray casts per update. The probability graph is then used to determine the influence applied to camera motion. For example, according to the position of the ray cast relative to the camera, we can deduce that lateral or vertical motion of the camera is probably necessary to avoid a future collision if the ray is prevented from reaching its target.

The results of the ray casts can then be used to dictate potential camera motion in a variety of ways. First, a weight or influence factor for each ray cast can be applied depending on the success of the ray cast. Thus, rays not reaching the target cause the camera to move in a direction away from their position.

An alternate method often used is to cast rays from the target object back toward the camera. The results of these ray casts are utilized in a similar manner. If a ray is cut short then once again it influences the movement of the camera. The degree of influence is often based on the proximity of the collision point to the origin of the ray cast, or sometimes simply a pre-defined weighting factor depending on the particular ray cast direction.

One of the problems with ray casting is that the determination of whether the ray intersects with the environment (or indeed, other game objects) is often computationally expensive. Additionally, it is often necessary to apply property information to the collision surfaces.

This information may be used to determine if a collision or ray intersection is actually valid. It is common that the game camera may ignore a significant portion of the environment if these filters are set appropriately. This is typically performed by a simple masking operation of desirable properties against the set of properties applied to the surface.

Technical

A typical implementation of simple ray casts would use a fixed arrangement of source positions around the proposed position of the camera, with the rays extending toward the target object. Care must be taken to ensure the arrangement does not intersect with world geometry.

Often the ray positions are arranged in a grid or other symmetric shape. Each ray is given an influence factor that may be applied horizontally, vertically, or both. If the ray cast fails to reach the future position of the target object, the influence is applied to the desired camera position. The influence may even be calculated according to its position relative to the target.

For all ray casts
If ray cast successful
No influence applied
If ray cast fails
Scale influence factor by distance of ray cast collision from target
Add influence to desired camera position
End

Once the total influence has been calculated, the camera will move toward the desired position plus this influence. Note that the influence may be calculated differently in each axis, if so desired.

Volume projection

Rather than simple rays, this technique projects a volume through the world from the camera position toward its target position. This volume is typically an extruded sphere (sometimes referred to as a capsule); for simplicity and performance, it may be either rectangular or cylindrical. Performance improvements can be gained by simulating the volume using several ray casts around the perimeter of the volume.

As with other collision determination techniques it is important to filter out any unimportant objects or geometry from the potential collision set. Bounds checking of axis-aligned bounding boxes or similar techniques may be applied to initially cull objects.

Volume projection is often used to determine if the camera would fit within confined spaces, or when determining a new potential position relative to an object (e.g., after a jump cut). It may also be used to ensure that camera motion is valid by projecting a motion volume from the current position to the desired position.

Sphere/cylinder collisions

The camera is often considered a sphere for collision purposes. This is partly because sphere collisions are relatively straightforward, but perhaps also because spheres are likely to slide along collision surfaces. The radius of the collision sphere should be slightly larger than the distance of the view frustum's near plane from the camera, thus preventing interpenetration of the camera with render geometry.

This is only true, however, if the collision geometry of objects or the environment extend beyond that of the render geometry. Note that this distance is also dependent upon the horizontal field of view. Ideally, the collision volume encompasses all four vertices of the frustum at the near plane.

Alternatively, the camera collision volume may be considered as a simple vertical axis-aligned cylinder. In environments where the camera will not move close to horizontal surfaces such as floors or ceilings, this approximation should provide equal functionality to a sphere at a reduced performance cost. The same caveats apply regarding the near-plane distance, and vertical collision must take into account the elevation of the camera, which might change how geometry would interpenetrate the near plane.

In the case of first person cameras, no collision volume or testing may actually be necessary since the camera should be completely contained within the collision bounds of the player character (it would also be somewhat disconcerting if the camera was prevented from moving and the player was not).

However, it is still necessary to ensure the collision bounds of the player are larger than the near-plane distance to avoid the same manner of rendering artifacts as those prevalent in third person cameras. Interpenetration of the near plane is still possible if there are game elements (such as game AI objects) that do not test for collision against the player, or that have render geometry protruding from their collision volume.

Dynamic path finding

Real-time or dynamic path finding has obvious similarities to solutions used for AI object navigation of the game world. However, path finding for cameras is more stringent than AI path finding -- aesthetic constraints play a large part. The underlying idea is that precomputed information is available that defines the volumes of space available for motion through the world. The data structure used to represent these volumes can vary but usually includes methods to traverse the volumes through connectivity information (which may also be directional in nature).

Traditional search algorithms such as A* or Dijkstra's Algorithm (as described in many AI or computer science text books) may be used to determine the most efficient path through the volumes, given weighting values that dictate the desirability of a particular path. The desirability determination for camera motion is likely to be quite different from that of an AI object, however.

Once a path has been generated, the camera will follow the path until it reaches the desired position or the movement is interrupted by a new request. Usually this occurs when the path is recomputed on a regular basis, to account for player motion or environmental changes and so forth. Often the path searching occurs at two levels. The high-level solution determines the overall motion of the camera between volumes, combined with a low-level solution to avoid game objects, proximity to collision geometry, and so forth.

The difference between this solution and ones used for AI is that the latter tend to deal with longer paths of motion along surfaces (though sometimes flying or jumping), whereas cameras are normally relatively close to their target positions. In the case of cameras, the path information is used more for collision avoidance rather than a complete motion path. Longer motion paths such as those used during non-interactive cinematic sequences are most often pre-defined and do not require any type of navigation logic to be applied.