I see. We use language differently. I think of [1:0:0:1] being a point, not a vector.

You are correct. The W member is defined with a very specific meaning. It is the multiplier for any translation values, so 1 is full translation (a point), 0 removes all translation (a normal/direction), and any value between provides that much of the intended translation.

But in game programming speed is more important than sticking to standards so there are a plethora of optimizations that ignore the W component for vectors and easily allow people to falsely believe that the W component doesn’t matter or has no meaning.

His team should change the W to 0 in order to conform to standards. The way he describes it being used can only work properly if said optimizations (ignoring W completely because you know it is a normal, not a point) are in place. For example, multiplying <0, 0, 1, 1> with the object’s matrix only gives you the correct “the object is facing this way” result if W is ignored in the matrix multiply. If actual non-optimized matrix multiplication is applied, it would tell you with direction from the center of the world the model is, not the direction it is facing. Correct results could only come from a vector <0, 0, 1, 0>.

As an optimization hint to ChaseRLewis, if you wanted the direction the model is facing, it would be faster to just read the appropriate row or column (depending on whether you are row-major or column-major) straight out of the matrix instead of doing matrix multiplication. Apparently it is important to your team to be able to change which axis is up, right, and forward, so macros allow you to easily also assign indices that would allow you to read the appropriate rows/columns whenever you decide to change orientations.


As for the original question at hand, I would heavily suggest not embedding any orientation information directly in your “SceneObject” class, your “Actor”, or any other class than one named “Orientation”. You should definitely make a class whose role is nothing but managing orientations. It becomes reusable in many places and certainly helps keep your code clean, because you will soon discover that you need dirty flags and a lot of other hidden features to make it optimized.

I personally maintain a CVector3 position, CVector3 scale, and CVector3[3] rotation. Compared to using a quaternion, there is extra work involved in rotating things in some ways, but far less work involved in creating the final matrix (which you only do if the dirty flag is set). This is the method used in Halo and over the years it has a very good track record in my opinion. I have used it for many released games that have good performance even with lots of rotating objects, even on low-end devices such as iPhone 3GS.
Basically, there are only a few kinds of rotations that are more expensive than using quaternions (because a lot of rotations involve nothing more than a few dot products in this format). A lot of common rotations, such as rotating around a given axis, will be more expensive with quaternions. Using 3 vectors for rotation matches matrix layouts, so any rotation you can make with a rotation, say around a given axis, translates into nothing but a copy when you pass that translation matrix to the “Orientation” class.
Matrix math offers a lot of shortcuts, such as rotating around a world axis (for example the Z axis). Rotating around any random axis with quaternions is roughly the same speed as with matrices (or slower), and rotating around world axes is not as fast as with matrices thanks to it resolving to only a sin()/cos() pair or a single sincos() call.

This makes it the overall best way to go at the cost of a little extra memory.


L. Spiro