Quaternions For Heavy Rotations

[Alpha Omega]

I am implementing some code that relies heavily on accurate rotations. Basically I need to copy a bounding volume onto a an irrlicht scene node and then whenever I rotate the irrlicht scene node I rotate the bounding volume by the same amount. The bounding volume is a rectangular and contains 8 points. I rotate the relative points by the same rotation matrix as the scene node using f32 vertex data points. However after many rotation calls the bounding volume seperates from the node.

Would I achieve more accurate rotations by using a Quaternion instead of the 3x3 matrix multiplication with a 3 column vector? Does irrlicht use quaternions or the more generic 3 column vector approach to handle rotations? I assume it uses the 3 column vector but would just like confirmation. Also how would using a quaternion for the bounding volume and using the 3 column vector for irrlicht affect the results? Maybe I should implement a quaternion approach for Irrlicht scene nodes as well?

[REDDemon]

isn't better calculate the rotation of the bounding volume and apply the same rotation to the scene node? or even better just pass to irrlicht scene node the same trasformation matrix computed in the phisics engine?

[Alpha Omega]

or even better just pass to irrlicht scene node the same trasformation matrix computed in the phisics engine?

I do this but it isnt accurate enough. Maybe if I use vector<f64> to hold the points but I dont want to do that to be a memory hog.

I believe it to be processor rounding error that is the problem but havent totally it ruled it in just yet.

[Alpha Omega]

Well anyway the current implentation is using irrlicht rotation matrices to do the rotations of the but I can not actually use the exact same matrix on the bounding volume because Irrlicht has everything in degrees (why?).

Anyway I have an angular velocity which is in radians and get a time step rotation to rotate the node by some amount. I use this code to rotate it...

Code: Select all

Matrix4<f32> m;
m.setRotationDegrees(node->getRotation());
CMatrix4<f32> n;
n.setRotationDegrees(rot*180.0f/PI);
m *= n;
node->setRotation(m.getRotationDegrees());
node->updateAbsolutePosition();

Pretty basic. However the problem could be that converting between the "real" rotation matrix that take "rot" as an argument is converted 4 times back and forth between radians and degrees because Irrlicht has no function to getRotationRadians() (why?).

But I cant rotate a single point by the m matrix because this would imply that a single point (or a difference between points has a starting rotation value. So to rotate all the verts of the cube I do this

Code: Select all

vector3df* RelEdges = new vector3df[8];
    getEdges(RelEdges);
    getRelativeCoordinates(RelEdges);
    
    for(int i=0;i<8;i++)
    {
      CMatrix4<f32> M;
      M = M.setRotationRadians(rot);
      f32 M2[4];
      M2[0] = RelEdges[i].X;
      M2[1] = RelEdges[i].Y;
      M2[2] = RelEdges[i].Z;
      M2[3] = 0;

      M.multiplyWith1x4Matrix(M2);
      RelEdges[i].X = M2[0];
      RelEdges[i].Y = M2[1];
      RelEdges[i].Z = M2[2];
    }

      setRelativeEdgesToAbsoluteCoordinates(RelEdges);

This works for a while... But not all the way. I use the matrix M in the second code to rotate the cube verts with the cube. What am I missing? It seems like the Irrlicht rotation system has a flaw with using degrees on default which makes working in radians very complicated.

It actually only seperates when I attempt to change its direction. I cant remember with I have to multiply by the transposed rotation matrix in this case or not...

Maybe I should read the bug reports once and a while....
http://irrlicht.sourceforge.net/phpBB2/ ... hp?t=42637

[REDDemon]

that's an inefficient approach. and as I were expected you are using 2 different transform matrices . you have "M" for edges and "m" for the scene node

and bounding box is evidently not transformed by the same amount of the scene node.

you must keep rotation and translation separed. (do all rotation and translations first, that's also faster than applying the rotation to the matrix and more accurate) than build your transform matrix .(a matrix is the same. indipendently if you build it with radians or degrees. you will have just a little difference caused by hardware approximations)

you don't need to extract the rotation again for rotate the point.
A suggestion is also to copy the irrlicht matrix class and remove degrees method replacing them with radians (less conversions, more speed, more accuracy) once you provide a matrix it will be the same.

instead of use

Code: Select all

node->setRotation(m.getRotationDegrees());

you must do something similiar to:

Code: Select all

node->setMatrix(m);

of course if you do that you have to mind a bit about the scale values. it is only a way to do that. have you also a separed code for translations?. maybe it is a good thing do translations and rotation in the same place. and build the roto/transl matrix once.

[pippy3]

If you're using irrlicht 1.7.1 there's a bug in the matrix class. Setting the rotation causes a miscalculation.

Either upgrade to the trunk or use doubles (f64) to calculate it.

[Alpha Omega]

instead of use

Code: Select all

node->setRotation(m.getRotationDegrees());

you must do something similiar to:

Code: Select all

node->setMatrix(m);

Im sorry but I do not recall a method for scene nodes such as this one. I understand the idea, instead of making seperate calls to position, rotation, and scale you can just apply one matrix. However I do not see this method in ISceneNode class. Are you saying to write one myself? That might be easier to optimize instead of using Irrlicht seperate commands.

If you're using irrlicht 1.7.1 there's a bug in the matrix class. Setting the rotation causes a miscalculation.

I am assuming you are refering to the current 1.7.2 dated back in 10/27/2010?

[REDDemon]

you can write your own method for that or just set up the matrix in the render method using the irrlicht drivers. anyway a custom scene node is probably the best solution. You can easy integrate it with the phisics and provide to the user a very simple interface