# pouët.net

## Matrix transformations x Quaternion & Position vector

category: code [glöplog]

Hey!

I've been writing a graphic engine for a while and now I finally understood the need of a quaternion to solve the Gimbal Lock problem. For now, I am only applying this for my camera. But what about the 3D objects? Do I need it for all the classes of them (dynamic, static, physics)?

In my engine, all the spatial transformation so far was implemented by using matrices. Both the Object3D class and the scenegraph (a tree struct) walking uses matrices (adding them together for the object group transformation).

OK, so my question here is: I am looking for the best design possible for the engine. Should I change the transformation representation from matrix to a quaternion (rotation) and a vec3 (translation)? Is it the best way to do it?

Since I am taking my first steps with it, I would appreciate some insight for something further from my engine reality, preventing a possible problem in the future.

Well, that's all :)

P.S.: If you don't post any pony, I promise I will open another pony thread only for you and your little pony friends. ;)
added on the 2013-07-12 04:56:26 by Danguafer
First, a bit of vocabulary
(quaternion, vector) represents a 'similarity' aka a rotation followed by translation

I tend to prefer a vector+quaternion approach rather than a 4x4 matrix for 3d representations. Said quickly, it's more robust and don't bite me after I spent months in the project. I speak from a numerical computation background, I'm just casual amateur at computer graphics.

1) a 3x3 or a 4x4 matrix represents any linear transformations. It includes rotations, translation if you 4x4, and scaling... but it can represents lots of other transformation I really don't care and really don't want to happen, like shearing. Using a vector+quaternion, I represent only similarities and can represent only them.
2) vector+quaternion use the minimal amount of variable to represent a similarity. If you happen to have lots of object around, it's nice. Not sure it's relevant for many use cases :p
3) less problems due to floating point precision issues.
a) When combining similarities stored as 4x4 matrices, you might end-up with something which is not a similarity (happens with a deep scene graph for example) : object that shrinks mysteriously, etc.
b) When combining similarities stored as quaternion+vector, you end-up with something which is a similarity (see point 1)). Thus, floating point precision issues will give a slightly off position and rotation, but no weird thing happening.
4) easier to invert vector/quaternion than a matrix. You can invert a matrix, but it's hard to make it numerically robust... if you combine transformations, it might bite you.
Quote:
the need of a quaternion to solve the Gimbal Lock

Just a nitpick there. The Gimbal Lock problem is not solved by quaternions themselves but _maintaining a state_, then occasionally renormalize current quaternion. You could do it with rotation matrices and reorthonormalization.
added on the 2013-07-12 16:49:58 by ponce
marmakoide, thanks for the tips :)

Canopy, I am just trying to save my time by having a portable and reusable code. Time passes, I am getting old and I don't feel with time for rewriting things over and over again. I will release a demo using it asap. :)

Quote:
The Gimbal Lock problem is not solved by quaternions themselves but _maintaining a state_, then occasionally renormalize current quaternion.

ponce, I couldn't understand what you said. I realized that my quaternion rotations are always being made on an absolute axes.
added on the 2013-07-12 20:43:21 by Danguafer
I'm not an expert on this, but what Ponce said reminded me of how I solved this in my own simple 3d engine a long time ago. Instead of storing the rotation state of your objects as only a set of three (or four) rotation angles, you store it as a set of orthonormal vectors (i.e. a rotation matrix). When you rotate your object, instead of adding to the angles ("angle = angle + step;") you rotate the object's own rotation matrix and re-normalize it to prevent accumulating rounding errors. No gimbal lock, and no quaternions needed.
added on the 2013-07-13 13:58:06 by yzi
I meant, re-orthonormalize it.
added on the 2013-07-13 14:10:34 by yzi
Quote:

Canopy, I am just trying to save my time by having a portable and reusable code. Time passes, I am getting old and I don't feel with time for rewriting things over and over again. I will release a demo using it asap. :)

I've been doing the same, the article helped me change my focus and decide what's really important. As it helped me change my thinking in a good way I thought I'd share.

I've stopped thinking about an "engine" and more about code that helps me get the job done more efficiently as far as reuse (including start-up time for new projects) without compromising performance.

:)
added on the 2013-07-15 11:33:54 by Canopy