🔒 Locked

Engine design & Matrixes

Started by Mort Aug 20, 2006 at 12:09 PM 7 replies 1.2k views

Original Post

Aug 20, 2006 at 12:09 PM

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 ?

Evil Steve

Aug 20, 2006 at 12:58 PM

Quote:
Original post by Mort
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 ?

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.

matches81

Aug 20, 2006 at 1:04 PM

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.

JasonBlochowiak

Aug 20, 2006 at 6:41 PM

Quote:
Original post by matches81
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.

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.

circlesoft

Aug 21, 2006 at 3:07 PM

Quote:
Original post by JasonBlochowiak
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.

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

GraphicsBas

Aug 21, 2006 at 3:13 PM

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

Specchum

Aug 21, 2006 at 11:43 PM

[pedantic mode]
Shouldn't this thread be in the Game Programming section?

[/pedantic mode]

Armand

Aug 22, 2006 at 12:21 AM

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.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.