# Problem with rotation around axis

if(transform.up == Vector3.up) {
g.localRotation = Quaternion.Euler(new Vector3(0f, 90f * GD.rot, 0f));

``````		} else if(transform.up == Vector3.down) {
g.localRotation = Quaternion.Euler(new Vector3(180f, 90f * GD.rot, 0f));

} else if(transform.up == Vector3.right) {
g.localRotation = Quaternion.Euler(new Vector3(90f * GD.rot, 0f, -90f));

} else if(transform.up == Vector3.left) {
g.localRotation = Quaternion.Euler(new Vector3(90f * GD.rot, 0f, 90f));

} else if(transform.up == Vector3.forward) {
g.localRotation = Quaternion.Euler(new Vector3(90f,  0f, 90f * GD.rot));

} else if(transform.up == Vector3.back) {
g.localRotation = Quaternion.Euler(new Vector3(-90f, 0f, 90f * GD.rot));

}
``````

So, I want to rotate object g in the direction my object is pointing (one of 6 basic ones) with it’s “up”. At this point everything is fine. Also I want to rotate it around its local “y” (90f x GD.rot) and its still all fine with first 4 sections, but 5th and 6th works wrong. My 90f x GD.rot used in the “z” slot rotates the object around “y” axis instead of “z” (“y” is also rotating it around “y”) and Im really confused whats wrong, maybe its a 5.4b problem, or something?

This seems like a needlessly complicated solution to a very simple problem.

What you’re encountering is Unity’s order of operations when converting Quaternion rotations to Euler angles. Specifically, they are processed by the Z rotation, followed by X, followed by Y.

Therefore, on your last pair of examples, rather than rotating by 90f or -90f, followed by (90f * GD.rot), you’re instead doing it the opposite way. Then, if you move that to the Y-axis rotation instead, it’s done in the opposite order. By coincidence, you wind up with the same rotation.

But, again, this seems like quite an overwhelming solution to a reasonably simple problem.

From the looks of it, you should be able to build this rotation like this instead:

``````g.rotation = Quaternion.AngleAxis(90f * GD.rot, Vector3.up);
``````

In other words, rather than trying to set the local rotation to counteract the parent’s(?) rotation, you could set the global rotation instead and cut out the middle man.

That said, if you’re dead set on modifying the local rotation, you will instead need to break the rotation apart into two stages to make it foolproof. First, you can set the current local rotation to the inverse of the main rotation (i.e. your 90f and -90f), then apply the secondary rotation of (90f * GD.rot).

``````g.localRotation = Quaternion.Inverse(transform.rotation) * Quaternion.Euler(0, 90f * GD.rot, 0);
// or...
g.localRotation = Quaternion.Inverse(transform.rotation) * Quaternion.AngleAxis(90f * GD.rot, Vector3.up);
``````

Either way, it can simplified into a single process rather than a 6-part, strictly cardinal-direction-based if statement.

Edit: For what it’s worth, once you break the rotation process apart into multiple stages to avoid running into issues with the order of operations, you’ll always wind up with the same results; one rotation to undo the parent’s rotation will result in the following rotation being axis-aligned with global coordinates, so the second rotation would always be able to be the same.