Camera Debug Drawing

It seems natural that one of the more useful ways to debug the camera is the ability to see what the camera is looking at and where it came from. I usually render a variety of paths and frustums and more to help diagnose a large set of common problems.

This is a re-imagining of camera debug drawing in a recent game which contains a number of different visualizations:

Camera drawn as the frustum up to the near plane, player, player path, framing cylinder, camera path and extended field of view as red lines.

One additional requirement is the ability to view the camera status from a different perspective and ideally while the rest of the game is in a frozen state. I prefer to be able to go into this state using nothing but the game controller so I can easily investigate issues on other machines when I get called over to look at something.

Some engines handle seeing the game camera from a different perspective by letting you move around in the scene in one window while playing the game in another. This is fine but it means you can’t really dig in to what happened when the game is tested on a target different from the development computer.

Here is list of visualizations I tend to implement in games.

Camera path

Line segments showing frame to frame movement for the camera, optionally colored for speed (length of movement per frame). A quick glance at the camera path can tell you if the camera unintentionally clipped through some geometry or where a hitch occurred.

Near frustum

A solid frustum rendered from the camera point to the the intersection of the view frustum and the near plane is very useful for thinking about camera collision.

Mid range frustum

For a little bit more information about what is around the edges of the screen drawing lines along the corners of the screen in world space can help placing the camera and field of view in the scene.

Target path

A majority of the camera hitches I’ve experienced are due to unexpected movement of the target. Correlating target position with camera behavior can help resolve a large number of issues.

Target shape

I often describe the camera target as not just the character but various points related to the target including a look-ahead position. Using these points I construct a cylinder that fits the view.

Camera path perpendicular change

In addition to the camera path it can be useful to see how much the camera velocity changes. Coloring the path can show the forward acceleration but the perpendicular acceleration Ap between three points P0, P1 and P2 can be found by calculating the segments S0 = (P1 - P0) and S1 = (P2 - P1) and removing the projection of S1 on S0 from S1:

Ap = S1 - (S1 ᐧ S0 / S0 ᐧ S0) S0

Simply draw the line from P1 to P1+Ap for each point in the camera path.

Camera orientation

Drawing a lines from the camera position some distance in front of camera for a number of frames back can help identify questionable camera rotation. Drawing the lines all the way to the target can help detect stuttering.

Collision response

Showing the normals at the contact points where the view intersected with collision is useful for determining ways to soften the collision response. What is relevant to draw depends on the approach used for handling view collision which is a topic for another post.