# Engine design & Matrixes

## Recommended Posts

I created a 3D engine some years ago and have been improving on it on and off during the last years. A while ago I ran into a problem with my engine design that made me consider whether my engine design was flawed. My engine contains a collection of 3D objects, each of these objects contain 3 matrices: The translation, rotation, and scaling matrix. The complete transformation is always calculated in the order: Translation * rotation * scaling. Because each 3D object always uses these 3 matrixes, it limits my flexibility of calculating new matrixes. For instance it is not be possible to insert another matrix into the transformation calculation, if I needed to. I have tried to replace my 3 matrices with one combined transformation matrix, however with only one matrix I am no longer able to retrieve reliable position, angles and scaling parameters from my objects because these parameters have been combined into one matrix (For example: Rotation and scaling both occur on the _11, _22 and _33 positions of the 4x4 matrix). This is where I would like to draw from your experiences: How many matrixes do you maintain in each 3D element in your 3D engine and why ?

##### Share on other sites
Quote:
 Original post by MortThis is where I would like to draw from your experiences: How many matrixes do you maintain in each 3D element in your 3D engine and why ?
As far as the engine code is concerned: One - the transformation matrix.

Each game object can have as many matrices as it wants, and it just updates the transform matrix, which the game engine uses. The point is, the engine object and game object are seperated.

##### Share on other sites
in my "engine" every 3D object contains one matrix, which contains the complete transformation. Furthermore I store position and scale factors as 3D vectors and rotation, currently as a 3D vector, too, but might change that to quaternions as soon as I´ve looked into them.
If either position, rotation or scale factors are changed I update the transformation matrix as soon as it is needed, for example when rendering the next frame.

##### Share on other sites
Quote:
 Original post by matches81in my "engine" every 3D object contains one matrix, which contains the complete transformation. Furthermore I store position and scale factors as 3D vectors and rotation, currently as a 3D vector, too, but might change that to quaternions as soon as I´ve looked into them.If either position, rotation or scale factors are changed I update the transformation matrix as soon as it is needed, for example when rendering the next frame.

Yep, that's what I do, except I'm using quats for rotation. This is also easier for dealing with things like game/physics synchronization, because the physics engines (at least all of them that I've seen) tend to prefer the separate components.

##### Share on other sites
Quote:
 Original post by JasonBlochowiakYep, that's what I do, except I'm using quats for rotation. This is also easier for dealing with things like game/physics synchronization, because the physics engines (at least all of them that I've seen) tend to prefer the separate components.

Yea, this is the right idea. Quaternions are preferable because they are easy to interpolate (this is why animation & physics middleware commonly use them).

##### Share on other sites
My engine does not store transformations for each object. In the scenegraph I have a node called Transform. It stores a quaternion as rotation and vectors for scale and position. Its easy to calculate a transformation world matrix from that information. The matrix is then also cached so i dont need to recalculate if the Transform is the same in the next frame.

This methode alows me to do a lot less calculation in the scene per frame.

GBS

##### Share on other sites
[pedantic mode]
Shouldn't this thread be in the Game Programming section?

[/pedantic mode]

##### Share on other sites
Personaly,
I'd knock out a small class and call it a transform.

class transform{  protected:    Vector3 m_translate;    Matrix33 m_rotate;    Vector4 m_scale;  public:    inline void toMatrix44(Matrix44 * outMat)     {      // fast conversion code    }    // standard gets and sets    inline void set(X);    inline X get(void);

Most of this should be clear. Except may be scale.
The W in the m_scale should be for uniform scale, and normaly should be 1.
But its handy to have a uniform that dosn't stomp on the non uniform.

My 2cents anyway.

##### Share on other sites
in my engine, this is where a scenegraph comes into play:

i have a scenegraph that stores all kinds of matrices and positions, the engine "collects" them in the tree.

ROOT
|
transformation_matrix(1)
|
scale_matrix(1)
|
CAR_OBJECT
| |
| |
| transformation_matrix(2)
| |
| scale_matrix(2)-----------
| | |
| TIRE_FRONT_LEFT TIRE_FRONT_RIGHT
|
transformation_matrix(3)
|
scale_matrix(3)-----------
| |
TIRE_BACK_LEFT TIRE_BACK_RIGHT

(mabe the tires at the back are bigger then the fron ones...)
now to get the final transformation matrix of the front right tire (they are relative in the graph), you multiply it "up the tree":
transformation_matrix(2) * transformation_matrix(1) * view_matrix * projection_matrix

if you now need more matrices for an object, you can just add them into the tree.

and with the scale matrix (and if you store your positions relatively), you can even generate your position data like this.
this means, if the chassis of the car gets larger, the tires will still be at the correct position (the distance between them will grow).

## Create an account or sign in to comment

You need to be a member in order to leave a comment

## Create an account

Sign up for a new account in our community. It's easy!

Register a new account

• ## Partner Spotlight

• ### Forum Statistics

• Total Topics
627662
• Total Posts
2978506

• 9
• 10
• 12
• 22
• 13