First steps for a game camera

The first version of a camera tracking a target on screen could be a fixed offset from the center of the target with the camera looking straight along the offset.

This is really all there is to get started and it is time to think about the next steps. This is a few questions to ask about the game before deciding on a direction for the camera that will influence level layout, art detail, how far sounds need to be heard and much more.

There are a lot of considerations when framing multiple targets at once but to reduce the scope this post will focus on game cameras with a single target. This post does not contain anything new, it is intended as a checklist to get started with a game camera.

Different camera distances

Any artistic qualities for framing subject would require a far longer post so instead I will resort to suggest defining some metrics at this point;

Intersection of three planes

Three plane intersections can make framing shapes on a screen trivial, along with many other applications. While useful for prototyping, I don’t tend to use three plane intersection in final products as there are a lot of things working together.

There are several cases where three planes do not meet in a single point, but there is a simple test for that. For most intersection applications with camera space I have not encountered this but it is worth keeping in mind.

Intersection of three planes

Unsurprisingly the solution is similar to finding a point along the line of a two plane intersection:

P = (d1(n2 ✕ n3) + d2(n3 ✕ n1) + d3(n1 ✕ n2)) / (n1 ᐧ (n2 ✕ n3))

Intersection of two non-parallel planes

Plane intersections can solve a number of camera framing optimization problems and is an easy way to for example find the rays along the corners of the view frustum given the screen edge planes.

Any line that lies on a plane is perpendicular to its normal, so the only line that is shared between both is perpendicular to both normals, or the cross product of the normals:

D = n1 ✕ n2

If the planes are parallel the cross product will be zero since there will be no intersection. This is a rare case when dealing with camera space but worth keeping in mind.

Two parallel planes will not intersect and two non-parallel planes will intersect in a line.

If any point of the line is already known, for example the intersection of any two camera frustum planes will intersect with the camera position, this is all that is needed.

If no point along the intersection is known there are a few more steps.

Constructing the camera frustum planes

The camera frustum is defined by the orientation and field of view of the camera and looks like a pyramid with the peak located at the camera and everything inside is visible on the screen.

Each edge of the the screen can be represented by a plane and in addition the near and far distances cap the frustum. Creating planes of the surface of the frustum is not the only way to represent it but it is convenient for many tests and placements.

A typical camera frustum with plane normals pointing outwards.

Before jumping in to formulas the value of field of view needs to be described.
The most common way to describe field of view in games is an angle between the top and bottom or between the left and right side of the screen, and most math uses the half field of view.

Plane definition

At this point I will add a few posts about basic geometry. This is needed to back up future posts without weighing them down inlining the math. Here is a basic review of planes.

Planes are commonly used for camera logic and are easy to work with as long as the basics are clear.

Line segment intersecting with a plane.

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.

Finding 2D points

I am going to post some basic geometry solutions that I will reference in future posts. These are solutions I've used in several games for a variety of cameras.

Some problems with game cameras can be solved by projecting points into a horizontal plane, and here are planar line intersection and constructing a circle from three points.



Intersection of two lines in a plane

Given two lines, L0 and L1

L0 = P0 + s D0

L1 = P1 +  t D1

Find a point along both lines s and t where L0 and L1 intersects.

P0 + s D0 = P1 + t D1

An intersection between two lines in the plane is a point.