Model's rotation and translation

[galf]

Hi,

Environment: windows 7 64 bit, c++ visual studio 2012, no clr.

I want to implement rotation and translation on a model using R (matrix 3x3) and T (vector 1x3) that I get from
a framework that uses irrlicht.

* I noticed I can use the set position option for the translation but in the rotation it seems the api "gives" me
only yaw-pitch-roll option (while I prefer quaternion or rotation matrix to avoid the ypr inconsistency and gimbel lock).

* In one of my tests I used the cam node api to do the transformation. it worked of course fro one model but when I added several models this method failed.

A quick look at irrlicht's ISceneNode shows that there is a transformation matrix in irrlicht but it's inaccessible (there is getRelativeTransformation but no set).

should I add to ISceneNode a set method and compile irrlicht?
I would like a better solution...does anyone know an alternative?

Thanks

[mongoose7]

Look in the matrix class to see if there is a function to get a 'rotation' from a matrix. Something like m.getRotation?

You shouldn't be looking at the absolute transformation, but at the local transformation.

[galf]

Thanks for the reply!

You shouldn't be looking at the absolute transformation, but at the local transformation.

I'm not sure what you mean by that... do you refer to the RelativeTranslation,RelativeRotation,RelativeScale in ISceneNode?
if you are, RelativeRotation is a yaw pitch roll represntation (what i want to avoid).

If you refer to the core::matrix4 rotation api, the way to create rotation in there is by yaw,pitch roll as well.

The following example comes to handle this by injecting quaternion to the implementation:
http://staraban.com/en/adding-quaternio ... ht-engine/

if I did not understand you correctly can you upload an example that demonstrate what you mean?

It seems that perhaps IDummyTransformationSceneNode inheritance may do the trick...

Of course I would prefer to use the irrlicht api if it will "give" me a possibility to rotate with rotation matrix or quaternion,
Do you know such way?

[mongoose7]

I am talking only of "applying" the transformation. Yes, Irrlicht uses a vector of angles. All that you need to do is take *your* representation and *convert* it to Irrlicht's. There is no gimbal lock when transferring transformations. You seem to think the 3-angle representation creates problems. It doesn't. It is only when you manipulate the representation that problems arise. So, if you have a quaternion implementation, and you manipulate this quaternion implementation and, frame by frame, convert the quaternion into the 3-angle representation, you get a faithful representation of the transformation. Any quaternion can be converted to three angles and back to the same quaternion. It is simply a matter of representation.

[AReichl]

The function "getRelativeTransformationMatrix" returns a reference to the current relative transformation matrix.
So it should be possible to change it.

[CuteAlien]

Internally Irrlicht indeed keeps euler angles and updates it's matrix from those. ISceneNode::getRelativeTransformation is just a convenient function.

You can use IDummyTransformationSceneNode which works indeed with a matrix, but it means that you have to add one additional transformation to each node using that, so I don't recommend it as long as you have other options.

Irrlicht's quaternion class has conversion function to matrix and to euler. You probably need toEuler in this case.

[galf]

Thank you all for the replies, I entered here to publish my solution and I see CuteAlien and AReichl has already revealed it.

As they said , I Implemented ISceneNode::getRelativeTransformation in a IDummyTransformationSceneNode using my transformation,
and then injected it as a parent node to my ISceneNode.
I don't see why it's a problem adding another transformation to my tree, it is exactly what I want to achieve ,
And in the IDummyTransformationSceneNode I can make sure this node will not add additional complexities.

referring to the Euler-angle representation, my first solution was transferring the representations.
my implementation was not complete because I noticed a singular use-case that remind me the gimbel-lock,
Here it is:

Code: Select all

 
irr::core::vector3df GetYawPitchRollFromRotationMat(const cv::Matx33f& rotationMat)
{
    float sinyrot = rotationMat(2,0);
    float angley = asinf(sinyrot);
    float cosyrot = cosf(angley);
 
        //Singular case 
    if (cosyrot == 0)
    {
        return  irr::core::vector3df(0,0,0);
    }
 
    float negsinx = (rotationMat(2,1)/cosyrot);
    if(negsinx > 1) negsinx = 1;
    if(negsinx < -1) negsinx = -1;
    float anglex = -asin(negsinx);
    float cosz = rotationMat(2,2)/cosyrot;
    if (cosz > 1) cosz = 1;
    if (cosz < -1) cosz = -1;
    float anglez = acos(cosz);
    return irr::core::vector3df((anglex*360/2*PI_F),(angley*360/2*PI_F),(anglez*360/2*PI_F));
}
 

Anyway, I use mpu6050 (inertial motion unit) to control my models rotation. The Euler-Angle representation is problematic when I need
to change heading (a problem that do not occur in other representations). it's shown nicely in this (very interesting by the way) google talk in minute 38:43:

https://www.youtube.com/watch?v=C7JQ7Rpwn2k

[CuteAlien]

Adding another transformation is fine. Just adds some calculations, so if you have lots of objects at some point it will become noticable (but unless we're talking about thousands of objects you don't have to care).