I see the problem. But its hard to say anything without seeing the source of it....
Your rotate function (in the first post) looks ok, but i think it has 2 flaws.
1. You are actualy storing the current rotation in the node (as X, Y, Z in the rotation vector) and conveting it back and forth with the get/setRotation. Better store it as matrix somewhere else and update it with the new values.
2. Converting the matrix to (evil) eulers to set the rotation of the node is a bit of a waste. Internaly it becomes a matrix again. The problem is there is no other way by default. So what I did once was implementing a ISceneNode::setRotation() that takes a matrix as argument. It's not that complicated and a bit more effective.
Well, these 2 points might not solve your problem (maybe they do I dunno)
If you mean source code I would not mind to shove it to you (send by email) but I dont know if it would help much since code I was posting do all the rotation work. If you think you may look at source code just give me your email adress...
1. -that is right but then I would need to normalize matrix from time to time and there is no function for that in Irrlicht ...I would need to write it myself.
2. -I know that engine use matrices to do rotation / camera /perspective work, problem is that only function to rotate node is setRotation() which accept eulers. So I would need to change Irrlicht source code ...which would be very efective but thats what I wanted to avoid since I am more modeler than coder.
...if you don't mind I would like to look in to your setRotation() function using matrix as input
...anyway, I am thankful that you don't mind wasting your time with my problem jox...
Nah, it's no waste of time. Sometimes solving other peoples problems is kinda relaxing and lets me see my own problems/bugs clearer or from another perspective. And I'm alwas learning something myself. So it possibly helps us both.
You're right with the normalisation. But then you should maybe store the current rotation in a separate vector3df. Because with every rotation you are using the result of getRotationDegrees() which is an evil function (matrix to euler is of gimbal lock problematic nature) and falsifying the values.
To set the rotation via matrix you can use the setTransformationMatrix() function I once posted:
Ok I was looking at your post an little bit at ISceneNode.h code. So if I understand it right getRelativeTransformation() function is returning matrix which is used by engine to make transformation of scenenode ...right?
...thats interesting I will try that.
To store rotation in vector3df would not make diference I think since it store rotation in euler angles and would be practicaly same like geting rotation from node directly since you get data in vector3df anyway.
arras wrote:To store rotation in vector3df would not make diference I think since it store rotation in euler angles and would be practicaly same like geting rotation from node directly since you get data in vector3df anyway.
Yes and no. In this case more no than yes though...
You are getting the rotation from the node. But what you set to the node then is not clean rotation angles but the result of getRotationDegrees() which is a dirty result. And in the next round you are working with this result. This result is especially dirty (not predictable in its single X Y Z values) if gimbal lock occurs. And your phenomenon has a gimbal lock taste. I could really imagine that this is the source of your problem. But doesn't need to. I'm not sure. Send me the source of SFTest and I will have a look (have you received my address?).
...OK I see what you mean, but I would need to update vector3df each time I would change rotation from getRotationDegrees() so it would be dirthy again.
-get rotation from vector3df
-change it to matrix4
-create second martix4 with rotation to add
-multiply both
-get eulers from result matrix4
-store it in vector3df
-rotate node with vector3df
hmm true... ok, but actually it should work anyway, even with dirty values. Because you are not using the single X Y Z values separately, but use them all together to setup a matrix...
I got some news. I'm not sure if these are good or bad news. You decide. Your source works just fine! I compiled it in Visual Studio 6.0 and the phenomenon does not show up. Rotation works just fine! Unlike your exe file.
This makes me think that your dll is messy. Maybe my implementation of getRotationDegrees() is not built in there correctly somehow. At least the error is not in your code...
I apoligize if getRotationDegrees() wasn't working correctly for you guys. I posted the code to that function a long time ago and perhaps it has limitations that are causing these errors. I used it to help update rotation every frame in my flight sim Reisender (before quaternions were in Irrlicht ) I just tested it with v0.6 and it still works for me and has worked for others in the past. hopefully it will still work for me when your fix is applied in 0.7
\\get rotation of the node
vector3df rot node->getRotation();
\\create a clean matrix and set the rotation
matrix4 currentmat;
currentmat.setRotationDegrees(rot);
\\create a clean matrix that contains our desired relative rotation in degrees e.g. if i wanted to rotate 1 degree on my relative y-axis, deltaR would be vector3df (0,1,0) and is set by keyboard input.
matrix4 relmat;
relmat.setRotationDegrees(deltaR);
\\multiply the matrices to apply the relative rotation (relative matrix must be the 2nd term)
matrix4 resmat;
resmat=currentmat*relmat;
\\get rotation of our final matrix
vector3df newrot=resmat.getRotationDegrees();
\\apply our new rotation to the node
node->setRotation(newrot);
I also use the "currentmat" to modify all sorts of relative vectors that are used in the sim using currentmat.transformVect().
Not directly. I'm waiting until some sort of Level of Detail is implemented for terrains. I'm researching other things about making simulatators that I'll bring back to this project at some point.
Ok, Arras. Believe it or not, I got the solution! I was recompiling my Irrlicht.dll with Chevs old code. And guess what happend to your app... yes, you're right!
Maybe you were compiling it right, but there is another Irlicht.dll somewhere in your path? On the other hand the one you sent me had the bad code too... Try to put in some debug print message (cerr << "something bla") in my getRotationDegrees() function so that you see it's really this one that's used. I don't know. What I know is that the old getRotationDegrees() code is sabotaging your rotation...
@Chev: No problem. Your code is almost ok. It's just messy in certain situations (like Arras' case (and mine too)). You probably read my post with the fix and the code comments, didn't you?
I dunno)
