# 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);
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?

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.