Should a transform class store a matrix or seperate position/rotation/scale values?

Question

I'm creating a transform class to make storing the transform of individual objects in a scene easier, but I'm unsure on how to do it.

I could create one like this:

class Transform
{
public:
    //...

private:
    Matrix4f matrix;
};

• Easy to concatenate
• Easy to perform operations on (since the matrix functions already exist)
• Can store certain information such as the camera projection
• Difficult to get the individual values such as the position of the object
• Performing operations in the wrong order can lead to unexpected results (rotate/translate/rotate results in a very different transform than rotate/rotate/translate)
• Lots of memory usage (64 bytes of data for a single-precision transform)

Or like this:

class Transform
{
public:
    //...

private:
    Vector3f position;
    Quaternionf rotation;
    Vector3f scale;
};

• Very easy to extract individual values
• Very easy to change individual values
• Because the position, rotation, and scale are independent from one-another, there is no "correct" order for rotate/translate/scale
• Smaller, being only 40 bytes for single-precision
• Cannot store anything beyond position/rotation/scale
• Performing operations which require information stores in more than one value (such as strafing, which changes the position but depends on the rotation) are much more difficult to implement

I'm not entirely sure how most game engines deal with this. Which implementation should I go with?

Answer 1

Store the components and compute the matrix on-demand when you need it.

Storing the matrix itself is inferior if you're ever going to be manipulating the transformation in any interesting or useful way, because floating point error can creep into the matrix after repeated successive mutations (such as rotations). This can result in a matrix that doesn't do what it logically should, such as a matrix that is the result of nothing but rotation operations applying a non-uniform scale because of the accumulation error.

Many of your other "pros" for the matrix approach aren't really that big of a deal, or sort of come out in the wash (it's pretty trivial to do operations on vectors and quaternions as well, for example).