Rotating TO certain angle while avoiding gimbal lock
Hello. I'm currently encountering gimbal lock issue in custom, in-game inspector that let you precisely set rotation of object, minus "precisely" part.
I can't use Rotate* methods, because they're rotating BY specific angle, which makes the tool useless for building levels for my game and while I try to use euler angles, the aforementioned gimbal lock occurs. I've looked through other solutions, but all require using Rotate* methods which as I said are useless to me as I need to set angles precisely.
You mean the player will be using the tool? Like you're reproducing a standard 3-wheel rotation tool? I think those always have gimbal lock, unless you limit them in some way.
If your idea for a solution avoids gimbal lock, than your code automatically will (unless it's wrong,) or the idea isn't what you though it was (which is possible -- this sort of thing is tricky.)
Answer by Dave-Carlile · Aug 29, 2015 at 10:39 PM
You should be able to set the rotations using the Quaternion class (specifically maybe Quaternion.AngleAxis) and assign it directly to the rotation
property.
Hm. Seems like step in the right direction. But I want to set rotation on that specific axis while preserving rotation that was on the other 2.
So let's say I have object that is rotated by 270 on X axis, 25 on Y axis and 0 on the Z axis. Now I want to set rotation on the Z axis while preserving rotation on the X/Y ones.
@darkhog in the simplest form you can do
transform.rotation = Quaternion.Euler(transform.eulerAngles.x, transform.eulerAngles.y, 90);
@Sarper Soher - except as I said, I can't use euler because of gimbal lock issues.
If AngleAxis isn't working for you, then what are you expecting to happen in terms of "preserving rotation on the other 2" axes?
@$$anonymous$$o $$anonymous$$haon - staying the same. $$anonymous$$g. I have rotation (23,24,20) Now I want to set rotation on Z axis to say, 45. Now it is (23,24,45).
Answer by mfitzer · Aug 24, 2018 at 05:19 PM
@darkhog To rotate a certain number of degrees on one axis while preserving the original rotation, you must take the original rotation * the rotation calculated by Quaternion.AngleAxis().
float degreesToRotate = 25f;
transform.rotation *= Quaternion.AngleAxis(degreesToRotate , transform.forward);
This will rotate 25 degrees around the z-axis while preserving the original rotation, so if the original rotation is (23f, 24f , 20f), the new rotation would be (23f, 24f , 45f).
darkhog's last visit was in June. The discussion you're answering to is from 2015. I find the thread fascinating in that it seems everyone's missing the point. Indeed, from the original inquiry, one easily changes a "BY" rotation method (as the OP called it) to an explicit setting (which is what he's in need of) by incorporating the existing angle(s), and using subtraction to choose the correct "BY" adjustment, and gimbal lock is actually an issue that probably doesn't impact the OP in the first place. When one is explicating the angles, there can't be "gimbal lock confusion", because by definition the explication is in charge of the angles. Put another way, gimbal lock has solutions, among them an arbitrary motion that removes the 'lock', which the explication of the angles itself does. There may have never been a real, difficult problem to solve in the first place.
@Jvene, thank you for the comment "may have never been a real, difficult problem to solve in the first place." It actually validates what I'm currently thinking. I went through the exercise of digging into the mathematics of Quaternions, only to find a lot of things I don't like about them. One issues with them, is they're not as universal as the internet portrays, I tested every permutation of XYZ order in both the creation of the quaternion and the rotation matrix, since the same equations from the rotation matrix are used to pull out the Euler angle. Only to find that, yes, order does matter both in Quaternion creation and extraction. Unity builds the Quaternion in YXZ order and builds its equivalent rotation matrix in ZXY order, with pitch (X actually, believe it or not) being pulled as the Arcsine angle (and the other two pulled by Arctangent). Euclideanspace.com briefly mentions a difference in how they're equations differed from NASA specs by ordering, and that's correct. It's why the code from Wikipedia and Euclideanspace fail with Unity, order matters. Secondarily, because the pitch angle is converted to a Quaternion by Cos(X/2) and Sin(X/2), you lose some information when converting, which is why it's tough to pull out the original Euler angle. You'll get at best 2 angles, one of whom is < 90 while the other > 90 and < 180, one will have the original roll/yaw while the other roll/yaw will be flipped 180 degrees either in a positive or negative direction. I got around this to a $$anonymous$$or degree by building my own Euler angle extraction function which builds a new quaternion with only the X, and check if the other angle is either 0 or +/-180, it works unless your original roll/yaw are close to +/-180 as is. In other words, it's a guessing game. Hence, I'm not a fan of Quaternions. I feel like a better solution that doesn't involve a theoretical "hypersphere" of rotation, but rather, more naturalistic motion, that, like you said, involves some arbitrary movement to get out of gimbal lock, treating each axis of rotation as a dependency chain of motion rather than independently, since there's an obvious dependency chain that I can clearly see now involved in Quaternion rotations as well. Quaternions aren't a magical unicorn panacea of rotational system technological utopia in other words, they're certainly not something transcendental in nature as much as the internets hype them up to be. It means thinking of the problem in more naturalistic terms and explicating perhaps changes in other axes as you are rotating.
The OP's Q was never clear, and probably a misunderstanding. But every day game-designers who have never seen a cosin are able to use quaternion builtins such as Lerp, RotateTowards, LookDirection ... to get nearly magic results.
Quaternions do come with some costs, and there are good reasons to question their wholesale employment. As Own-Reynolds pointed out, some of the built in methods to Unity's Quaternion class give considerable leverage, but the class is a slightly different subject that the mathematical foundation.
Indeed, quaternions were nearly forgotten for almost 100 years in part because there are common alternatives to their purposes. One key reason for their use in graphics, aside from the solution to gimbal lock, is that the same basic operations performed in linear algebra are completed in fewer machine instructions when using quaternions, if the operations don't depend on shearing (or skewing or scaling). There are situations where quaternions are generally simpler when a class is doing the algebra for us, especially where relative rotations are concerned. The primary given advantage, that of solving the gimbal lock problem, is curiously not so strong as one might initially think. We also exclusively use unit quaternions in graphics, because they are the ones appropriate toward the goal of rotations, but quaternions have mathematical uses outside this domain, which typical quaternion classes don't really provide, and for which most of us have little purpose.