Does anyone else have this problem with Rotation on Y-Axis

[jox]

Your code syntax looks funny, are you using the C# wrapper or something?

[Fingers]

Yes this code is in c# ...

[jox]

I'm just guessing, but I think using getRotationDegrees on a scaled matrix might be a problem in itself. So maybe separate the rotation and scale of your object. (attach a scaled child node to the rotatin node).

Further getRotatinoDegrees is kind of an "evel" function. Also if you get the degrees with it and set it to a node, they will be made into a matrix again internaly, so this is a waste. Thats because I created a node->setTransformationMatrix() once (in some thread, and in irrlichtNX, C++ though).

Whatever you wanna achieve it should be possible without getRotationDegrees, and it would be more "professional" as well (cant find a better description now ).

Arras did struggle with this topic also for a while. I'm not sure how he solved it in detail in the end but he got it working in his space flight simulator thingy.

Hope this helps a bit!

jox

[Fingers]

I Found code in a thread http://irrlicht.sourceforge.net/phpBB2/ ... php?t=4680 started by arras, zeuss helped and the resulting functions from that thread, I've converted to c#, and they all work great except the Y Rotation if the object is scaled .....

But thanks for the help, at the moment I'm just scaling it to the right size in the 3d-editor, and then using it like that ...

Cheers

[jox]

You could also scale the mesh after loading it with the MeshManipulator (SceneManager->getMeshManipulator()). This is even better because the vertex normals are also scaled. (its independent from the scene node scale)

[Fingers]

I might try that when it becomes available in .NET

Thx

[jox]

It is like I was thinking: getRotationDegrees on a scaled matrix (non-pure-rotation-matrix) is evil, bad and nonono...

Imagine this code (sorry C++):

Code: Select all

matrix4 rotmat;

rotmat.setRotationDegrees(vector3df(20,20,20));

vector3df rotvec = rotmat.getRotationDegrees();

cerr << "X: " << rotvec.X << ", Y: " << rotvec.Y << ", Z: " << rotvec.Z << endl;

It'll print out:
X: 20, Y: 20, Z: 20
as you would expect.

Now:

Code: Select all

matrix4 rotmat, scalemat;

rotmat.setRotationDegrees(vector3df(20,20,20));

scalemat.setScale(vector3df(scale, scale, scale));
rotmat *= scalemat;

vector3df rotvec = rotmat.getRotationDegrees();

cerr << "X: " << rotvec.X << ", Y: " << rotvec.Y << ", Z: " << rotvec.Z << endl;

With scale=1 its:
X: 20, Y: 20, Z: 20

scale=2:
X: 20, Y: 43.1602, Z: 20

and with scale=3 you got the dilemma:
X: 0, Y: 1.#QNAN, Z: 12.904

You see it starts with the y rotation and then goes totally mad...

evil regards,
jox

[Fingers]

C++ Code is not a problem for me to read,

Wat you say makes sese, but I'm not to familiar of any other way to do the rotations, how would I accomplish that another way ??


Thx

[SuperElectric]

So, the problem is that matrix4 doesn't factor out the scale when calculating getRotationDegrees(). Shouldn't this be classified as a bug? This means that if one wants to find the absolute rotation of a node using myNode->getAbsoluteTransformation().getRotationDegrees(), one has to first make sure that there are no scales in the scene graph branch leading to myNode. This seems like a very brittle assumption to me.

My workaround right now is to go to the object being rendered and pre-scale it (as in, manually scaling its vertices) to the right size to avoid using any ISceneNode::setScale()s. With each vertex definition that I add "*= scale" to, I'm like, "this is dumb....this is dumb... this is dumb..."

[SuperElectric]

I posted this problem, and the necessary fixes to matrix4.h, in the bugs section:
http://irrlicht.sourceforge.net/phpBB2/ ... highlight=