ofNode setOrientation, consider this...

Consider this code:

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

The output is:

[verbose] 0, 45, -35  

Just as expected…
Now this code:

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

The output is:

[verbose] -23.9275, 50.6773, 26.341  

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

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.)

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.

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.

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.