3D mathematics, game programming


The 3D coordinate system is a natural extension of the 2D cartesian coordinate system we are all familiar with and have studied. The cartesian coordinate system has an interesting history, first documented by the French mathematician Rene Descartes in around 1637. Early work in this time period dealt with only one or two axis coordinate systems, although later findings indicated that the mathematician Pierre de Fermat worked with a three axis (3D) system which was not published. The work done by these great men laid the basis for the great discoveries by Newton and Leibniz later on: the invention of the Calculus. But enough reflections on history, and back to the matter at hand…

We will be covering the following aspects in this first blog post dealing with 3D mathematics:

  • The 3D coordinate space
  • Left handed and right handed orientation
  • The need for multiple coordinate spaces (in games)


The 3D coordinate system consists of three lines or axes (singular form: axis), which are mutually perpendicular to each other, and form the abstract representation of the three dimensions that we humans are able to see. If we had the ability to sense or see in more than 3 dimensions, we would not be limited to the 3 axis system, though this limitation is absent in areas such as linear algebra where you can describe systems with any number of dimensions in an abstract sense. In real life, we see only in three dimensions, and will be our basis behind creating real life-like game environments and models.

The three axes are referred to as the X, Y, and Z axes. Any and every point in 3D space (relative to the axes) can be described in reference to these three axes. The point where the three axis lines intersect is known as the origin. The origin is to the 3D space, what the number zero is to the number line. A coordinate in 3D space is described by the length units projected on the X, Y, and Z axes respectively to reach that position, starting from the origin. Thus the position of the origin can be described as (0, 0, 0) and the point shown in the coordinate system below has the coordinates (x, y, z).


Left handed and right handed orientation is nothing more than a categorization of how the 3D axes can be aligned. If you take your left hand and extend the thumb, index, and third finger at right angles to each other, and hold your hand so that the thumb (positive x-axis) is pointing to your right, the index (positive y-axis) is pointing up, and the third finger (positive z-axis) is pointing towards the direction you are facing, then you have a left handed 3D coordinate system. If we do the same with our right hand, where the thumb, index, and third finger are the positive x, y, and z axes respectively, we have a right handed coordinate system. Notice that if you rotate the right handed orientation to match the x and y axis directions of the left handed system, only the positive z-axis changes direction. We could say that the difference between the orientations is that in a left handed system, the positive z-axis points away from us towards where we are facing, whereas in a right handed orientation, the positive z-axis points towards us. The figure below represents this fact.

image courtesy of http://viz.aset.psu.edu/

In the next post, we will learn about multiple (3D) coordinate spaces and nested coordinate space, and also how basic coordinate transformations can take place. Please leave any feedback on content, clarity of writing,  on what you think should be changed, or errata in general, and I will do my best to work on it.

3D mathematics, game design, game programming


Many a time I’ve heard statements like “Games programming? 3D graphics? that requires an awful lot of maths right? and graduate level math at that…” ….and therein onwards the interest dies off due to the pre-mis-conceptions about the role that mathematics will play in games development.

For a programmer/developer/software engineer, learning the concepts of 3D mathematics needed for developing games is not an impossible task (the math we use in 3D game programming is referred to as ‘3D math’ but is actually a composite collection of topics from different mathematical disciplines as we shall see shortly). Of course, there will be some due inherent complexity, as there should be with good reason, but we tackle complexity everyday in software engineering: software architecture and patterns, databases and database design, mastering specific technologies that we use to build systems with, web site user experience, all bring about their own inherent complexities, but we master them and control them in order to reach our objectives. In that regard, what is so different about 3D mathematics that we cannot master the complexity, understand it, and apply it? That being said, this may be a good time as any to elaborate on what 3D mathematics is made up of.

The math used in the rendering of 3D games is based on a sub-set of topics derived from the mathematical branches of linear algebra, (solid) geometry, real analysis, and higher algebra. In addition, any artificial intelligence used in game logic and physics simulations, employs real world physics and mathematics as well. But we are currently concerned with the mathematics needed for drawing and rendering 3D graphics for games, and that is what we will focus on at the moment, though we will discus all aspects of game programming, including AI, in later topics.

To this end, I will be creating a thread of posts in this blog that deal with 3D math topics in a linearly progressive fashion, including code examples showing their applications where possible. This is in order to show and  prove to the reader, that learning 3D mathematics is not the daunting task it is labeled to be, and also to pave the way for the game programming concepts and topics discussed in this blog that rely on mathematics. It is one of the most rewarding experiences, that when you are developing 3D computer games, you actually understand the mathematical concepts and principles behind what you are doing. For at that point, no aspect of the game is out of your control, as you know and understand exactly what is happening under the hood.


Agile estimation, Algorithm analysis, and Relativity…

No, Im not referring to Einsteins theory of relativity (though I can draw some parallel if I really think about it). Something I was reading in an algorithms/data structures book recently hit a profound note in my thinking, though we all have learnt and overlooked it at times. The topic was on analysis of algorithms using Big(O) notation, and the words that hit home were “relative rates of growth”. We all have learnt this before and understand the simple matter of comparing algorithms based on their growth rates. But when we think of comparing the relative rates of some functions, we are not talking about comparing the functions themselves anymore. For instance, say that f(n) = N^N and g(n) = 1000N. It does not make sense to say that f(n) < g(n), which will be true for all N less than or equal to 1000, but false for all N greater than 1000. Therefore, it is the growth rate of f(n) that is compared relative to the growth rate of g(n). In this context, it makes sense to say O(f(n)) > O(g(n)).

This made me jump track and think of Agile estimating. We estimate a base story and then estimate the remaining stories in the backlog relative to the base story value. There is no specific unit defined, but we call them story points. There is no specific time unit associated with the relative growth rate of an algorithm, or the relative complexity of a user story, but we use them in order to make some pretty important decisions in our work. We compare one algorithms complexity relative to another, and estimate task complexity relative to a another ‘known sized’ task. This makes me wonder, what else do we knowingly or unknowingly measure in relative terms in our day to day work?

There is little doubt that measuring something in relative terms produces more accurate results than say, labeling a specific time unit or complexity unit to a mathematical function or user story. It helps us measure and calculate things to large degree of accuracy, and has quite a number of similarities with relativity in physics in my opinion. One such similarity is the concept of a frame of reference: in algorithm analysis, a frame of reference could be the computer platform that the algorithm is run on, in agile estimation the definition is a bit fuzzier but could be the team size for example. You could come up with certain relative values in one frame of reference, and a completely different set of values in another, whether its relative story points, growth rates, or velocity (in physics). It’s interesting to see where this kind of thinking can lead us, and even more profoundly interesting would be to see the hint of a large as-of-yet undiscovered unified software theory of relativity, lurking under the bits and bytes out there waiting to be stumbled upon and discovered.