0
\$\begingroup\$

I have an object (cube) in the scene and I want it to continuously rotate on its only local X axis but suddenly while rotating on X axis its Y and Z axis rotation value goes 180 degrees for some frames, but it looks fine in the game view. Please help me to get out of this problem. It is also noted that this problem doesn't occur while rotating only on Y or Z axis. Code:-

    void Update () {
         transform.Rotate(new Vector3(1,0,0), 
         Space.Self);
    }

enter image description here

\$\endgroup\$

1 Answer 1

5
\$\begingroup\$

The thing to remember about Euler angles is that they're a fiction the engine generates on demand for our sake. They're not the ground truth of how rotation is stored inside the engine (that uses quaternions), and they're arguably not a natural description of the reality of 3D rotation itself.

Every 3D orientation can be represented by an infinite number of different Euler angle triples - just add or subtract a multiple of 360 on any axis for instance. Or combine rotations on different axes: {x: 180, y: 180, z: 0} is equivalent to {x: 0, y: 0, z: 180}

So when you ask Unity to translate the current orientation into Euler angles, it has to pick one standard version of those infinite possibilities to return, and that means there will be discontinuities somewhere - eg. wrapping from {89.5, 0, 0} to {89.5, 180, 180} instead of {90.5, 0, 0}. There's simply no way to write a function mapping orientations to angles that doesn't have a wrap-around anywhere.

The good news is that these still represent the orientation you expected to have, just written in a different way - like when a friend gives someone directions to a place that's different than the route you'd have chosen, but still gets them where they intended to go. ;)

This can cause trouble when we have code that's looking for specific Euler angle values, but the more robust solution there is to not write code that looks for specific Euler angle values. (Sorry, I know that sounds glib, but after answering gamedev questions here for a few years, I've found that code that does checks or math on Euler angles almost never does what its author intended for all cases that can arise in gameplay - Euler angles are very good at misleading gamedev intuition)

If you're experiencing a specific bug due to this wrapping behaviour, try asking how to solve the gameplay consequences of that bug - including the relevant code that's reading these Euler angle values - and we may be able to recommend a more robust way to phrase that code.

\$\endgroup\$
4
  • \$\begingroup\$ Thank you @DMGregory, what I was guessing is true. Its like holding same ear with either hand... I got the point and I changed my approach accordingly \$\endgroup\$ Commented Nov 22, 2018 at 13:12
  • \$\begingroup\$ The quaternion has a hidden value, via the complex plane, that determines the output angle. Not some mysterious "library pick". Imagine each point on the unit sphere having a direction associated(complex value), that direction points to the resultant vector. \$\endgroup\$
    – agone
    Commented Nov 14, 2023 at 3:23
  • \$\begingroup\$ This is a poor answer since it does not express nor describe Gimbol Lock or the reasons in terms of axis alignment. It is a decent answer for the Unity implementation limitations. \$\endgroup\$
    – agone
    Commented Nov 14, 2023 at 3:37
  • \$\begingroup\$ As I mentioned to you previously, if you'd like to post an answer demonstrating how apply this complex plane interpretation to use this to solve the problem, please feel free to do so. The question is not about gimbal lock, which is why I did not mention it. \$\endgroup\$
    – DMGregory
    Commented Nov 14, 2023 at 3:38

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .