Another gimbal lock thread hooray!

Quaternions, eulers don't you just HATE maths? it wastes so much of my time that could be spent making video games.

Heres how I'm animating each axis & it would look right if it didnt spaz out with this fantastic gimbal lock thing unity does:

Code (CSharp):

1.  
2. rot = deltaTime / freq * 2 * Mathf.PI+ phase;
3. result = amp * Mathf.Sin(rot);
4. newRotation = new Vector3(result, newRotation.y, newRotation.z);
5.  

So i've tried looking through the hundreds of threads with similar rotation issues because this man trap seems to punch more than me in the nuts but i can't find the right code snippet to make it not freak out at certain angles.

If anyone is charitable enough to throw me a bone please paste some code/pseudo code because I will never understand quaternions so please don't try

 

Gimbal locking is not so much an Unity thing. It's a general heading, pitch, roll thing. Which is the way a rotation is stored in euler angles. Luckily, Unity stores the rotation as a quaternion internally, so that prevents gimbal locking. Setting the rotation through euler angles introduces gimbal locking again, so that won't work.

Instead, you could directly use the quaternion representation, but that does introduce some fairly exotic math.

The other way, is to just use Transform.Rotate, which is also free of gimbal locking.

Code (csharp):

1.  
2. rot = deltaTime / freq * 2 * Mathf.PI+ phase;
3. rot = amp * Mathf.Sin(rot);
4. transform.Rotate(Vector3.up, rot - rotOld);
5. rotOld = rot;
6.  

 

Advancing a rotation so that it results in a new rotation isn't as hard as you think. Imagine your top-down object is rotated to some degree, and you want to rotate it some more. To do that, you simply multiply your new rotation delta on top of the current rotation:

transform.localRotation *= newDeltaRotation;

It works the same in 3D with all axes. Additionally, you can rotate around all axes in just one step.

 

@jvo3dc: Thanks for that - I'm sure your right but i can't seem to apply it to my case - can't store previous rotation for each object, trying to use current rotation & i still have gimbal locking.

@blizzy - Thats does seem like the more likely solution for my needs (and its what i thought i was doing).

 

Math is my favorite part of game development.

 

Do you need fully-free motion, like a space flight sim? Or could you solve the problem by parenting different axes of rotation in a tree, such as yaw --> roll --> pitch, as one might do for airplane (or roll --> pitch --> yaw), assuming the airplane maintains "normal" flight attitudes and doesn't get into aerobatics.

I've generally found a lot of success with parenting separate transforms to break the rotations explicitly apart, like for an articulated arm, or an enemy appendage that swipes at you for instance.

If all else fails, get one of those little magnetic boxes that go under the bumper and put a spare key in it and you'll never be locked out of your gimbal again.

 

Just wanted to bookend the thread by saying i've got what i wanted but i couldn't tell you how it works. My approach was to think stricktly in terms of rotation speed on each axis & stay away from 'rotation' or eulers & stick with 'rotate' (ugh, very descriptive).

thanks for the replies they were all high quality - i'd shop here again.

 

Don't feel bad. I have bent several brain cells permanently trying to figure out rotation in 3D game space. Fortunately I can still walk in a straight line. Mostly.