Rotation Matrix

[DarkWood_Neo]

everybody know that in games if the player moves and rotares the player model-position (rotation) and the camera-position (rotation) aren't change. the whole world moves and rotares.

the funktion maybe should look like this:

Code: Select all

inline TransRot(ISceneNode *node, vector3df trans, vector3df rot_0, vector3df rot)
{
matrix4 temp;
vector3df pos;
temp = node->getRelativeTransformation();
temp.makeIdentity();
temp.setRotationRadians(rot_0);
temp.setTranslation(trans);
temp.transformVect(node->getPosition(), pos);
node->setPosition(pos);
node->setRotation(rot);
};

but it doesn't work! has anyone a function or an idea how the function works?

[Boogle]

Well actually I believe that is incorrect. The player and camera position/rotation do move/rotate in the 3d world. The world doesn't change. It makes more sense to move 2 objects around, rather then x (where x is likely huge).

[DarkWood_Neo]

you are absolutly wrong. i don't know if you ever programmed a 3d game, but if you ever did you KNOW that the player an the camera can't be move, because if you rotare the playermodel you can't change the position of x-axe if the player presses the "go-forward-button"...........

[Boogle]

Perhaps you should read the source of the FPS Camera Scene Node.. (CCameraFPSSceneNode.cpp). Particularily the animate() method. Also, check out the example programs that come with version 0.4. They compile with 0.4.2 after some minor modifications (change DT_DIRECTX8 to EDT_DIRECTX8, etc).

[SuryIII_guest]

In todays 3D API's (DX) the rendering is performed by translation the objects matrix from world space to camera space so actually the camera is not moving or rotate at all ...it just sits there in the world's origin and looks along Z axis , every object has has it's 4x4 matrix wich stores their rotation , translation , scaling values for every axis..so when you "move" an object you actually change it's translation values from it's matrix.

This's is faster than moving the camera and the objects in 3d space and finding their relative translation ,rotation and scaling and make the calculation to determine how exactly this particular object should be rendered according it's current relational translation,rotation,scaling to the camera wich in this case has it's own rotation,translation,rotation values.

Then again i might be wrong

[keless]

SuryIII_guest is right. in OGL or DX, you set up your projection matrix, and leave it that way. things like gluLookAt where you give the 'camera' a position and target simply format the MODELVIEW matrix so that objects put thru it are translated infront of the static camera relative to the 'position/direction' you set.

As far as IrrLicht engine goes-- you dont need to worry about this. It is hidden inside of the engine rendering code. You can feel free to change the camera position and direction, because just like gluLookAt, it is NOT reformating the Projection matrix each time, it is actually formating the Modelview Matrix-- which means you ARE transforming the world around the camera, without even realizing it.

So DarkWood_Neo, you dont need a function like that if you're using normal camera code. Or are you the person who is trying to write their own FPS camera?

[Boogle]

Ah well there we go.. I didn't know how it worked in DirectX, just Irrlicht