[no bug] with Quaternion and Matrix to euler angle

[CuteAlien]

Actually you don't have to do that. Any parent-rotation will mess this up (so 60° angle also works). I suspect the reason is that you calculate the rotation around an axis in the global coordinate system and then multiplicate it with a rotation in the local coordinate system of the shoulder. But sitting on this already for an hour without being able to fix it. I thought I just would have to bring the axis to rotate around into the local coordinate system of the shoulder, but either I'm doing something wrong or that's not it. Anyway - so far doesn't look yet like an Irrlicht bug - thought no promises, maybe one shows up.

[thanhle]

When parent doing the rotate. Children should update all their abs transform matrices. Else we have to call updateallchildren() or something like that.

Note the ralative transformation matrices of the children are still the same.
In theory, the only thing to rotate to the new ball position is a relative rotation of dx,dy,dz angle.
Which is equivalent to the multiple of two transform quaternion. (previousRelativeAngleQuaternion*DeltaQuaternion.). As you can see the deltaquaternion is calculate using the axis angle method.

Similarly we can multiply two transform matrix to achieve the same thing. toEuler at the moment doesn't return the correct result when parent y-angle is > 90 or less than <-90, as I stated previously.

I'll look deeply into this when I have time

thanks
thanh

[CuteAlien]

I think the reason you have to call updateallchildren() instead of this happening automatically is because that stuff can be called too often otherwise and is really slow. At some point the engine has decide between comfort and still being usable for realtime 3D. That's one of those I think (note I didn't write it - but looks like that from the source code).

But I have the feeling I was hunting another problem than the one you tried to show. I thought this example tried to show that the rotation of the elbow doesn't go toward the target point (which you seemed to try to do). Which as I explained probably can't work as the rotation axis is in global coordinates and then multiplied with a rotation in a local coordinate system.

But - now from the your last post I guess - you wanted me to look at anglexx and compare it to the other result instead? Hehe - I kicked those 2 lines out because they didn't seem to do anything in this code. Once in a while an additional comment when doing examples helps ;-)

[thanhle]

Hi CutetieAlien,
I want you to hunt the bug with child doesn't return the correct euler angles when the parent y-angle is > 90 or < -90 degree.


Regards
thanh

[CuteAlien]

Still looks correct to me. You get different angles for anglexx and q2.getMatrix().getRotationDegrees() - but as far as I can see so far they still describe the same transformation.
So if you use the resulting transformation for example like that:

Code: Select all

 
core::matrix4 m1;
core::matrix4 m2(q2.getMatrix());
m1.setRotationDegrees(anglexx);
 
core::vector3df v1a(1,0,0);
core::vector3df v2a(0,1,0);
core::vector3df v3a(0,0,1);
core::vector3df v1b(1,0,0);
core::vector3df v2b(0,1,0);
core::vector3df v3b(0,0,1);
 
m1.transformVect(v1a);
m1.transformVect(v2a);
m1.transformVect(v3a);
m2.transformVect(v1b);
m2.transformVect(v2b);
m2.transformVect(v3b);
 

Then in the end the vXa and vXb vectors have again the same results.

[thanhle]

I think I solve the problem. But logically it doesn't seem right.
Because I already use two absolute positions to calculate the relative change in angle between them . The result should just be previous transform*relative transform instead of below.

Code: Select all

while (device->run())
        {
 
 
            vector3df rot = node->getRotation();
            rot.Y += 0.10f;
            node->setRotation(rot);
            node->updateAbsolutePosition();
            ((IBoneSceneNode *)*node->getChildren().begin())->updateAbsolutePositionOfAllChildren();
 
    
            base->setRotation(vector3df(0, 0, 0));
    
            ((irr::scene::IBoneSceneNode *) base->getParent())->updateAbsolutePositionOfAllChildren();
 
            vector3df basePos = base->getAbsolutePosition();
            vector3df target = vNode->getAbsolutePosition();
            vector3df endEffPos = endEffector->getAbsolutePosition();
            vector3df p1 = endEffPos - basePos;
            vector3df p2 = target - basePos;
            p1.normalize();
            p2.normalize();
            vector3df axis = p1.crossProduct(p2);
            axis.normalize();
 
            float dot = p1.dotProduct(p2);
            float angle = acosf(dot);
 
            matrix4 tran, ivtran;
            node->getAbsoluteTransformation().getInverse(ivtran);
            
            if (abs(angle) > 0.0001)
            {
 
                matrix4 change;
                change.makeIdentity();
                change.setRotationAxisRadians(angle, axis);
                change = ivtran*change*base->getAbsoluteTransformation();
 
                vector3df  anglex = change.getRotationDegrees();
                base->setRotation(anglex);
                base->updateAbsolutePosition();
                ((irr::scene::IBoneSceneNode *) base->getParent())->updateAbsolutePositionOfAllChildren();
 
            
            }
 
            driver->beginScene(true, true, SColor(255, 100, 101, 140));
            smgr->drawAll();
 
            SMaterial someMaterial;
            someMaterial.Lighting = false;
            driver->setMaterial(someMaterial);
            driver->setTransform(video::ETS_WORLD, core::IdentityMatrix);
            driver->draw3DLine(base->getAbsolutePosition(), target);
 
            driver->endScene();
        }
 

Opps! Now these is a twisting issue with the joint even set base each loop rotation to 0. Need to find out why.

Regards
thanh

[CuteAlien]

I think I solve the problem. But logically it doesn't seem right.
Because I already use two absolute positions to calculate the relative change in angle between them . The result should just be previous transform*relative transform instead of below.

Not yet checked your new code, but in the old code I think the problem wasn't the angle - that seemed correct. But the axis around which the angle rotated, that was in the wrong coordinate system. But I didn't manage to fix it, so I suppose I'm also still missing something.

[thanhle]

I think it is a good idea in the future to allowing directly set the node to quaternion or transformation matrice, since there is already a get matrix function.

For skeletal animation or parent child node, maybe have function to allow for applying relative transform on the specific node.

This is actually faster than conversion between matrix to angles and then set.

Is Luke still alive? : ). It is faster for him to improve these thing. Else I can try to hack into those, when the time is right. But my program style is not right : ), as I don't follow standard.

Regards
thanh

[CuteAlien]

It's an idea that has been floating around a few times already. But don't expect it to be a quick hack when you want to do it right.
IDummyTransformationSceneNode did go in this direction - allowing to add nodes which work directly with matrices. But adding another transformation on top of each node using it. Name is a little strange (IMatrixTransformationSceneNode would be better imho), but we could certainly add another IQuaternionTransformationSceneNode like that.

Better solution would be a node with a template parameter for the type it really uses (maybe the easiest solution without breaking everything while being fast at the same time). Yet another solution would be a node that uses all 3 types (euler, quaterion, matrix) - but only updates the others on read functions (ugly, so forget about that). Generally modern engine try to get transformations completely out of such classes and into arrays instead. So instead through virtual functions they can access all scene-transformations in a single cache-friendly array. Not sure if this can be done in Irrlicht without breaking the interface completely (aka having a new engine really).

Haven't seen Luke for a while, I don't think he has coded anything for Irrlicht in the few years I've been part of the engine team. Thought he did show up in IRC occassionally.

[thanhle]

I think it's good to do one thing at a time. Maybe adding matrix first. Since it is already there through the get function. Maybe just add a few functions that implement the set transform matrice.
setTransform() <-- set local transform matrix. Relative to parent assume rotation and translation are at 0's.
setRelativeTransform() <-- set local relative transform matrix. Basically existing local transform matrix multiply to a new one. //Can be very useful if I do axis rotation.
setAbsoluteTransform()

I think it shouldn't take to long too add those functions as it would not break anything.

I thought there is already one implementation if you search google, I saw it a while back. Maybe that was a quaternion implementation.

Regards
thanh

[CuteAlien]

Just adding a matrix additionally is the solution I like least. Because then it's no longer obvious where the data is kept - in the eulers or the matrix. So either one is constantly out of date or you have to do all operations twice to keep them both up-to-date. The IDummyTransformationSceneNode does something like that - it ignores eulers and adds a matrix additionally. It confused the hell out of me when I run into it the first time (setRotation, getRotation suddenly no longer working as expected). But at least it's in an own class and not in ISceneNode directly. Code is harder to understand when the access functions depend on which other functions of a class you called. In short - this is not a good idea.

[thanhle]

I agree, but changes are necessary to improve an engine.

Regards,
thanh

[CuteAlien]

Well, I mentioned 2 alternatives. One using template parameters, the other ... don't know yet how to build that, but basically trying to get transformations into arrays. Those take more work. Which is why no-one did it so far. We can only improve as much as we have programming time.

Can we consider this bug as closed or do you still think there is something wrong in the conversion to eulers?

[thanhle]

There are many ways to implement this.

Anyway, you can close this. I know where the bug in the Engine on this issue now.

I need someway to implement this so that we never need the inverse transform. Inverse is use in the wrong purpose here. Logically, it should be just simple forward matrix multiplication.

Regards
thanh