ofNode setOrientation, consider this...

advanced
#1

Consider this code:

  
    ofQuaternion rotX, rotY;  
    rotX.makeRotate(-35, 1, 0, 0);  
    rotZ.makeRotate( 45, 0, 1, 0);  
    cam.setOrientation(rotX * rotY);  
    ofLogVerbose(ofToString(cam.getOrientationEuler()));

The output is:

  
[verbose] 0, 45, -35

Just as expected…
Now this code:

  
    cam.setOrientation(ofVec3f(0, 45, -35));  
    ofLogVerbose(ofToString(cam.getOrientationEuler()));

The output is:

  
[verbose] -23.9275, 50.6773, 26.341

This is not as expected. Is this a bug or am I missing something?

#2

Not sure why, but inside ofNode’s setOrientation using a ofVec3f, it sets the y axis, then x axis, then z axis

  
//----------------------------------------  
void ofNode::setOrientation(const ofVec3f& eulerAngles) {  
	setOrientation(ofQuaternion(eulerAngles.y, ofVec3f(0, 1, 0), eulerAngles.x, ofVec3f(1, 0, 0), eulerAngles.z, ofVec3f(0, 0, 1)));  
}

This happens to do with the order of operations.
You can get the same result as rotX * rotY if you you set the x, then y, then z, which is the same order of operations as your multiplication of rotX * rotY

  
setOrientation( ofQuaternion(-35, ofVec3f(1,0,0), 45, ofVec3f(0,1,0), 0, ofVec3f(0,0,1)) );

If you multiply rotY * rotX instead of rotX * rotY, then you get

  
-23.9275, 50.6773, 26.341

(in the example code provided, not sure where rotZ is defined.)

#3

yeah sorry it was a typo of mine, rotZ should be rotY.

I had noticed the different order of axis calculation. But I’m not sure yet if it is a bug or correct.

#4

this seems to me as a bug, but fixing it might break a lot of things.
I tend to avoid as much as I can using Euler Angles. Quaternions are so much easier to handle and transform and don’t suffer from gimbal lock.

#5

So true, but in my mind I find eulers so much easier to visualise and grasp. In my current I case I’m receiving euler angles which I need to mimic. Quaternions are definitely better but so are matrices.