Cameras and View Space

If our CameraPosition is $(0, 0)$, our world space and view space are identical, so effectively no transformation happens. As such, our scene would look like this:

However, if we imagined a real camera positioned at $(0, 0)$ in our world, this is not exactly what we'd expect the camera to see. We currently have the view space defined as below, where the origin is indeed the location of the camera, but the camera can only see things to its top right:

Instead, we want the camera to sees things "in front" of it. We can represent this as a rectangle positioned such that the camera is in the center of it. Or, equivalently, a view space where the origin represents the center:

The size of this rectangle is determined by the camera's field of view. For now, we'll keep things simple and make our field of view the same size as our world space - a 1400 x 600 rectangle.

To transform our objects from world space to the definition of view space that includes the origin change, our ToViewSpace() function needs to be slightly expanded. Visually, we can imagine one way of achieving our goal would be moving our camera down and to the left by half of our rectangle's height and width:

But again, our camera doesn't really move in view space - it's position is always $(0, 0)$. So instead, we replicate the effect by moving our objects by the same amount but in the opposite direction - up and to the right.

In view space, we move objects right by increasing their x position, and up by increasing their y position:

1// ...
2
3class Scene {
4// ...
5private:
6  Vec2 ToViewSpace(const Vec2& Pos) const {
7    return {
8      (Pos.x - CameraPosition.x) + WorldSpaceWidth / 2,
9      (Pos.y - CameraPosition.y) + WorldSpaceHeight / 2
10    };
11  }
12  // ...
13};

We should now see the view we'd expect from a camera positioned at $(0, 0)$ in the world space:

We can reposition our camera to the center of the world space to get our original perspective back, but now calculated using a fully implemented view space transformation:

1// ...
2
3class Scene {
4// ...
5private:
6  // ...
7  float WorldSpaceWidth{1400};
8  float WorldSpaceHeight{600};
9  Vec2 CameraPosition{
10    WorldSpaceWidth / 2, WorldSpaceHeight / 2
11  };
12};

Advanced: Orthographic and Perspective Projection

This example of representing the camera's field of view as a simple rectangle is called an orthographic projection. It is commonly used in 2D scenes as, by their nature, our scenes have no depth. Depth would be a third dimension and, in 3D scenes, it is typically labelled $z$.

In 3D scenes, creating a realistic camera is more complex. The third dimension means we have more complex movement and rotations to model, but depth itself adds complexity. Depth creates the illusion that objects, and the spaces between objects, appear smaller the further away they are from the camera.

Creating this effect involves the field of view being modeled as a frustum - a volume that grows in size as the distance from the camera increases:

Image Source: Jakob Killian

The process of mapping the objects in this three-dimensional view space to a two-dimensional space, such as screen space, is called perspective projection.

Let's update our scene to give players control of the camera. Our scene is already receiving events through it's HandleEvent() functions. We can examine the events flowing through our scene to detect if the player has pressed one of their arrow keys.

If they have, we can update our camera's position. Remember, our camera and other objects are now positioned in world space, meaning increasing y now corresponds to moving up:

1// ...
2
3class Scene {
4public:
5  // ...
6  void HandleEvent(SDL_Event& E) {
7    if (E.type == SDL_EVENT_KEY_DOWN) {
8      switch (E.key.key) {
9        case SDLK_LEFT:
10          CameraPosition.x -= 20;
11          break;
12        case SDLK_RIGHT:
13          CameraPosition.x += 20;
14          break;
15        case SDLK_UP:
16          CameraPosition.y += 20;
17          break;
18        case SDLK_DOWN:
19          CameraPosition.y -= 20;
20          break;
21      }
22    }
23
24    for (GameObject& Object : Objects) {
25      Object.HandleEvent(E);
26    }
27  }
28  // ...
29};

In many games, the camera is attached to some other object in the scene, often the character that the player is controlling. We can replicate this in a few ways. The most direct is to simply examine the player character's position, and set the camera's position accordingly.

1CameraPosition = Player.Position;

In cases like this, we should be mindful of when our objects are being updated in each iteration of our game loop. To prevent our camera lagging one frame behind the player, we should set the camera's position after the player's position has been updated for the next frame, but before we start rendering that frame.

In our case, our player can't move yet, but a good time in general to perform the update would be after our player-controlled character ticks, but before the scene renders. We'll assume the GameObject that the player is controlling is the first in the scene's Objects array:

Our camera should now center its view on the player character. Remember that the player's Position denotes the top-left corner of their image, so our object's rendered appearance will appear slightly lower and to the right of their actual Position:

Let's update our HandleEvent() so that arrow keys move the player instead of the camera:

1// ...
2
3class Scene {
4public:
5  // ...
6  void HandleEvent(SDL_Event& E) {
7    if (E.type == SDL_EVENT_KEY_DOWN) {
8      switch (E.key.key) {
9        case SDLK_LEFT:
10          Objects[0].Position.x -= 20;
11          break;
12        case SDLK_RIGHT:
13          Objects[0].Position.x += 20;
14          break;
15        case SDLK_UP:
16          Objects[0].Position.y += 20;
17          break;
18        case SDLK_DOWN:
19          Objects[0].Position.y -= 20;
20          break;
21      }
22    }
23    // ...
24  }
25  // ...
26};

The player can now move their character around the scene. And, because the camera is attached to the player's character, the camera will indirectly move too:

Typically, we don't want the camera to match the character's position exactly. Most games want to apply some offset to the positioning, such that the scene is framed in a way that looks better.

Below, our camera still follows the player character, but is positioned 600 units to the right, and 100 units higher:

1// ...
2
3class Scene {
4public:
5  // ...
6  void Render(SDL_Surface* Surface) {
7    CameraPosition = Objects[0].Position
8      + Vec2{600, 100};
9    SDL_GetSurfaceClipRect(Surface, &Viewport);
10    for (GameObject& Object : Objects) {
11      Object.Render(Surface);
12    }
13  }
14  // ...
15};

This returns us to our original composition, where our dwarf is currently positioned at $(100, 200)$, and our camera is attached to the dwarf but with a $(600, 100)$ offset. Adding these, we get a final camera position of $(700, 300)$, which is at centre of our simple world:

Our updated Scene and GameObject classes are available below:

We've walked through a basic world space view space screen space example in these lessons, but larger projects typically include some additional spaces. These spaces are configured to solve specific problems in a complex pipeline. Three common examples are below:

Local Space

Alternative names for this include model space or object space. It is the coordinate system relative to a single object. For example, when an artist is creating a 3D model, that is done in a software package where the model is the only thing in the scene. This means the model's vertices are positioned relative to an origin $(0,0,0)$ that typically near center of the model.

When a level designer takes that model and positions it in the overall world, we need a mechanism to move the vertices of the model into that new position. To handle this, each model in the world gets its own transformation process to convert those local space coordinates to world space coordinates based on the model's position, scale, and rotation in the larger world.

Clip Space

Additional spaces are often added between the view space and screen space steps. Clip Space is the result of applying a projection (like the orthographic projection we simulated) to the view space.

In this space, geometry that falls outside the viewing volume (frustum) is "clipped" (discarded or trimmed) because it won't be visible on the screen. This serves as an optimization step in the pipeline to ensure we're not processing geometry that can't possibly be visible to the camera.

Normalized Device Coordinates (NDC)

After clip space, coordinates are typically converted into normalized device coordinates (NDC). This is a standardized coordinate system where the visible part of the screen maps to a specific range, typically from $-1$ to $1$ on the $x$ and $y$ axes.

This creates an environment that is very similar to screen space, but independent of the actual screen resolution. This standardization simplifies any work we need to do right before displaying the final image. For example, we know the point at $(0, 0)$ in NDC is always the center of the screen, and $(-1, -1)$ is always a corner, regardless of the final viewport size.

The final transformation in the pipeline simply maps this normalized range to the actual pixel coordinates of the player's window (screen space).

In this lesson, we've explored the techniques involved in creating a 2D camera system that can be controlled directly or attached to a game character. Key takeaways:

• Camera systems use coordinate space transformations to create the illusion of movement through the game world.
• Converting between world space and view space requires understanding the camera's position and field of view.
• In 2D games, cameras typically use orthographic projections which represent a simple rectangular view.
• Camera positioning can be manually controlled or automatically attached to follow characters.
• Applying offsets to attached cameras allows for better visual composition of game scenes.
• Coordinate transformations should happen in the correct order: world space view space screen space.

In the next lesson, we'll move away from manual calculations and see how linear algebra can generalize and simplify these transformations.