3D mathematics, game programming



This question is best answered with a story given in the book ‘3D Math Primer for graphics and games development’ by Fletcher Dunn and Ian Parberry. The story goes that there are two cities, ignorant of each other and having their own coordinate system to map the different areas within the city. In the first city, the inhabitants do not care or have any knowledge of the coordinate system used in the second city and vice versa. They each have their own coordinate system and live their blissful day to day lives. But one day, the state engineer is tasked with building a road between the two cities. This creates a dilemma: the coordinate systems used by the cities (maybe with the origins at the city centers) is not adequate for the engineer. He needs a larger frame of reference, encompassing the two cities within it. He needs a new coordinate space.

The 3D models we see rendered in games are generally created using  3D modeling packages. For example, if I use the open source software ‘Blender’ to draw a 3D model that I will use in my game, say for example a Spherical spaceship, then in my modeling package the origin of the model will be in the center of the sphere, denoting (0, 0, 0). But when I import this model to my game, I need this model placed in reference to ‘something’ that represents the whole virtual world of the game. This ‘something’ is the world coordinate space. With regards to multiple coordinate spaces and computer games, three coordinate spaces are vitally important and need to be understood clearly: Object space, World space, and Camera space.

Object space is what I was describing above when I mentioned that the origin of the model is at the center of the spherical spaceship. Object space refers to the coordinate frame that the object is embodied and described in. World space is the global coordinate space, where everything of interest to the game in a graphical sense will reside. Finally, camera space is your view into the game world: The origin in camera space represents the point where the camera is stationed (your screen viewport) and where the view frustum begins. Camera space is the frame of reference relative to this 3D origin. Note that camera space can be treated as a ‘special object space’ where the object in question is the camera through which you view the game, and all the game constructs are referenced relative to this camera object space.


Objects in the world space of a game are rarely rigid objects. One example of a rigid object would be a model of a barrel. But even this object weaves a complicated path through world space when tumbling down a flight of stairs (based on the physics that is coded). Now think of a model of a Robot with a large number of abilities. Let’s assume for the moment that the robot has pincers that open and close in the Y-Z plane of world space, and a circular saw that is spinning in the X-Z plane of world space, and the robot is traveling along the Z-axis in world space (assume the robot is traveling away from our field of view, towards the horizon). The programmer trying to implement this behavior of the robot in only world space context is going to have a very hard time! This is because, the movements of the robot in world space is complicated when we look at the movement collectively. Add to this that the robotic pincers can move around, and the circular saw can change orientation, and you have a very complicated movement pattern in world space that the programmer would find hard to implement. This is why we need nested coordinate spaces.

Think of nested coordinate spaces as parent – child coordinate space nodes in the structure of a graph or tree. In the example of the robot, the object space of the robot is the parent space. The object spaces of the pincers and the circular saw can be child spaces of the robots object space, and the pincer blade object space can be a child space of the pincers object space. In this manner, if a given object space and object is responsible for the movement of the connected child coordinate space nodes, implementing complicated movements in world space becomes very much less complicated to the programmer. This reduction in complexity is due to the nested coordinate spaces of the object and constituent parts of the object, and the responsibility of each node in controlling the individual movements of the child nodes, which collectively results in the complicated movement we observe in world space.


Hopefully the reader has a clear understanding of object space and world space by now. I like to think of object space and world space as two parallel universes, and traveling between these two universes is the idea of transformation between object and world space. What I would like to focus on here, is the space between these universes of object space and world space, or the intermediate transition stage between the two universes, which is known as ‘inertial space’. The idea of inertial space would be more clear by referring the image shown below

inertial space

Inertial space has the same origin as that of object space, but the primary axes are aligned to the world space primary axes. How does inertial space help in transforming an object from object space to world space? Inertial space makes it easy by providing a two step process:first we transform from object space to inertial space by simple rotation. In this operation, the X and Y axes of the object space above, coincide with the X and Y axes of the inertial space, and the robots alignment becomes upright. Second, we move the location of the inertial space origin to coincide with the origin of world space, and this operation is known as translation. In this two step process, which is easy to think about individually, we have transformed the object from object space to world space, via the intermediary inertial space.

In the next post, we will look at an important concept and construct vital to game programming: Vectors.