Overview
Hi everyone! This week I continued my journey into the fundamentals of computer graphics by learning about linear & affine transformations. However, before I dive into the things that I learned, I would like to celebrate that today is Programmer's Day 🥳! As part of the celebration, I'm sharing with you this free Fanatical bundle which I just discovered. The bundle includes 4 programming books in pdf & epub format. One of the books included in the bundle is Mathematics for Game Programming and Computer Graphics by Penny de Byl, which is one of the books I've been reading during my journey into the fundamentals of computer graphics. So definitely check out the bundle if you're interested in learning the things that I've learned!
Top 3 things I learned
Watch out for the order of your transformations!
Whenever you're calculating the matrix for a transformation that you want to apply to an object, you need to understand how the library you're using will process the matrix. Otherwise, you'll end up with a different transformation than the one that you expected.
For example, in OpenGL, the transformations are processed in reverse order. This means that if you want to translate, then rotate and then scale an object, in OpenGL you need to first scale, then rotate and finally translate. This is because the multiplication of a matrix with another matrix isn't commutative, which means that the final result will be different.
In a very particular example of translating, rotating & scaling an object, if you don't reverse the order of operations in OpenGL, the object won't appear on the screen:
This is the result of the matrix transformation if you don't reverse the order:
While this is the expected result of the transformation:
And the expected result on the screen:
Apollo 13, you're heading for gimbal lock...
Out of all the transformations that you can apply to an object, rotation is by far the most complex. This is because a lot of issues arise when you try to do rotations in a 3D space. One of the most common problems is called gimbal lock. This is basically when an entire dimension is lost because you make a 90° rotation in one of the axes and it gets aligned with another axis, which locks them. This was a very big problem during the mission of Apollo 13 to the Moon. Here's a diagram that will hopefully make it more clear:
The result of having a gimbal lock in a camera is that it starts to tip roll around the z-axis and it will eventually end upside down.
An approach to first-person cameras
In order to avoid having gimbal locks in first-person cameras, several restrictions are often placed. These restrictions include setting up the controller to rotate around the world's up axis and the camera's forward axis. Which means making switches between local/object & world space. The minimum and maximum angles of rotation for the y and z axes are also restricted to prevent the camera from going upside down. Here's an example of this implementation for a first-person camera:
This week's math concepts
Matrices & Linear Transformations
I learned that the difference between linear transformations and affine transformations is that the former doesn't include translations. This means that affine transformations need to be represented with 4x4 matrices.
I also learned about these 6 linear transformations:
Translation
Rotation
Scaling
Orthographic Projection
Reflection
Shearing
It was also noted that reflection and shearing are usually not used in 3D graphics and they aren't part of a typical graphics API.
More on Matrices
The determinant of a matrix is related to the change in size that results from transforming the matrix. This means that the absolute value is related to the change in area or volume, while the sign indicates if there is a reflection or projection. I learned that the inverse of a matrix allows us to compute the reverse/opposite of a transformation, which can be useful for undoing it. Besides, I also learned about 4x4 homogeneous matrices and how to calculate a perspective projection matrix.
Useful resources
This week, the resources focus mostly on further explanations of matrix concepts and calculators for some of their operations.
You can learn how to calculate determinants of large matrices in Math Insight.
You can make quick calculations of determinants with this online calculator.
You can learn more about matrix math in Math is Fun and Khan Academy.
You can multiply matrices with this matrix multiplication calculator.
What's next?
You can't possibly expect to solve all the rotational issues that arise in 3D computer graphics by just applying restrictions in the axes. Usually, a better approach for rotations involves the use of quaternions, which is an advanced math concept. This will be my focus for the next week. Meanwhile, I invite you to tell me if you already knew about the gimbal lock and if it has caused you any problems!
Top comments (4)
Hey Eric, nice article !
Ohhhhh yesss, but not in the way you imagine ! I'll tell you my story 😁
I was working on aeronautical domain, on a UAV camera control. Camera were attached under the UAV and was controlled with azimuth/site parameters. As expected, camera get stuck when looking vertically.
One of the dev noticed that I had implemented all the rotations using matrices, and saw in this wikipedia article (french version) that "The solution of the gimbals lock problem is to use quaternions". So he undertook to reimplement all the computations using quaternions... Yep, changing the code won't change the fact that the mechanical device IS a gimbal...
I regularly had this discussion that matrices don't cause gimbals lock all along my career. It's the way you structure your rotations that cause it. I ended up having an argument with the Wikipedia article author to rephrase its article in 2012, but the common misconception that matrices cause gimbal lock, and quaternion don't, is still widspread in developpers mind 🙁
Hi Thibaut, thanks for sharing your story! Just as you say I think it's important to understand the device that you're using (or trying to recreate in a 3D virtual world) before trying to implement solutions for gimbal lock. I agree with you that quaternions have this misconception of being the solution to gimbal lock and it's probably caused by not understanding completely how they work.
I have to admit that at the moment of writing this reply, I'm guilty of having such a misconception. Even though the books I'm reading have just mentioned at the moment that quaternions are another approach and are a possible solution and not necessarily the only solution! If I were to stop my learning journey right now (and I hadn't read your comment), I would stay with this misconception and just go right away to implementing quaternions thinking that they will always fix the problem. Thanks a lot for making the clarification that this won't be the case! Hopefully, the chapters that I'll be reading this week about quaternions will also mention this.
The thing to keep in mind is that, from a mathematical point of view, quaternions are "strict subset" of matrices. Everything a quaternion does, matrix can do. But matrices can do thing that are not possible with quaternions (like scaling, squishing, projection, ...).
Knowing this, I have to admit I was never that much interested in quaternions. I just don't like them and prefer using matrices for everything 😁
However, quaternions have 2 advantage compared to matrices:
Performances. Multipliying 2 quaternions require less operation than multiplying 2 matrices. But in practice, matrices multiplications are rarely the bottleneck in render engines nowadays, and matrices multiplication is so well optimized on hardware that I'm wondering which one is actually faster.
Numerical stabilities. Ok, one point for quaternions. Accumulating several rotations create less imprecision with quaternions than with matrix. That's why in robotics for ex., when lots of rotations are involved, it is preferable to use quaternions. In 3D, quaternions are translated to matrices anyway by the render engine.
This definitely helps! Thanks a lot for your comments!