Moving objects

There's no reason why you can't use an at/right/up system to update objects. I'm using that system for my soccer game I'm writing. You will also be able to incrementally yaw/roll/pitch the object without fear of the Gimbal Lock provided you incrementally rotate the object's matrix about the object's up/at/right vectors. The only downside is that you'll need to orthonormalise the object's matrix every hundred frames or so as the floating point inaccuracies will build up over time.

Skizz

Thanks for the reply Skizz.

How do you build the world matrix?


Derek

The world matrix is defined as:

-           -| Rx Ry Rz 0|| Ux Uy Uz 0|| Ax Ay Az 0|| Px Py Pz 1|-           -

Where the right vector is (Rx Ry Rz) and so on, P is the position vector.

That is a row major matrix, which DX uses. You can also transpose it to form a column major version which is what OpenGL uses.

I prefer the row major version because you can access the components easier:

Vector *at = (Vector *) ((float *) matrix) + 8);

Using C++ you can make the above neater by doing the following:

class Matrix{public:    Vector &GetAt (void) {return at;}    // and so onprivate:    Vector right; float r0c3;    Vector up; float r1c3;    Vector at; float r2c3;    Vector pos; float r3c3;};

Skizz

Thanks Skizz. I'm moving now. :)


Derek

Yep. It's most likely you're using 3Ds or simular modeler and your exporter has it's forward axis backwards.

My DirectX (quest) exporter has it's forward backwards as well. Rather than fix it or recode my own exporter, I just build my models facing backwards [lol]. How lazy is that?

The only other alternatives are to rotate all of every model's vertices 180 degrees on the Y axis when you load it, or simply multiply all of your matrices by a 180 y rotation. Both can cause problems when working with skeletal meshes.

Thanks for the reply.

The models I'm using are out of the DX9 SDK.


Derek