Sign in to follow this  
Mort

Engine design & Matrixes

Recommended Posts

Mort    147
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 this post


Link to post
Share on other sites
Evil Steve    2017
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.

Share this post


Link to post
Share on other sites
matches81    474
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 this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
circlesoft    1178
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).

Share this post


Link to post
Share on other sites
GraphicsBas    129
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 this post


Link to post
Share on other sites
Armand    164
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 this post


Link to post
Share on other sites
Guest Anonymous Poster   
Guest Anonymous Poster
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).

Share this post


Link to post
Share on other sites

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

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this