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\$
3
\$\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.

| improve this answer | |
\$\endgroup\$
  • \$\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\$ – Javed Rehman Nov 22 '18 at 13:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.