All,
The issue is that combine rotators works most of the time, but it fails sporadically when pitch = 90 degrees. This can be replicated by the above condition and combining the rotator with minor changes - you will see objects changing their rotation massively. I’m still trying to find reliable workarounds.
Best wishes,
Al
This sounds like gimbal lock; it’s an issue inherent to Euler rotation sets rather than a problem/bug in Unreal.
The best way to avoid it is to use maintain your rotation data and perform your calculations with Quaternions.
If you want to work with degrees (or radians) it’s generally a good idea to store the values as independent floats to perform your calculations along specific axes, convert those into individul single-axis quats, and then combine those quats to find your final rotation.
Many thanks for the reply.
Gimbal lock is a physical issue rather than logical. It happens in real life because the gimbals have obviously limitations to torque and angular momentum, so if it gets locked you can’t reconfigure the gimbals fast enough to do the desired rotation.
This has been used as an excuse for logical rotation manipulation, but is really unfounded. Any rotation position can be represented by the three angles, and the calculations happen between frames without physical limitations. You can visualise that by watching in real time the angles as the object moves along all axes - they go all over the place because they are being reconfigured to represent the desired rotation. I hope that makes sense.
Now, it is a bug because some reconfiguration sets fail and give wrong results, completely inverting the object from time to time for example. Even if that was physical, it would never be an outcome of Gimbal lock.
The solution of doing through Euler rotation is neat, however I was hoping to be able to do a pure blueprint project, to avoid the hassle of compiling the whole thing in a mac. I’m looking for a different workaround then, so wondered if anyone has found one that can be done through blueprints.
As a side note, I think this issue might become a showstopper very quickly for VR.
Many thanks all for the help.
Al
I recommend to use Quaternions (FQuats). Not an easy thing to master, but would solve 99% of rotation problems You’ll ever face.
And, that’s not a bug. It’s a design flaw. Move the thread please.
Oh, and THE best video on the topic: Euler (gimbal lock) Explained - YouTube
Thanks for correcting the terminology. Design flaw it is then, I suppose.
Am I correct in understanding that Unreal isn’t able to do rotation properly without C++ coding?
Best wishes,
Al
Um. Not sure. There are Quat nodes in BP. But iirc users struggled with real working implementation. Maybe just lack of math knowledge, don’t know.
“Gimbal lock is a physical issue rather than logical. It happens in real life because the gimbals have obviously limitations to torque and angular momentum, so if it gets locked you can’t reconfigure the gimbals fast enough to do the desired rotation.”
With all respect, it sounds like you don’t understand what gimbal lock is, or why it happens.
“This has been used as an excuse for logical rotation manipulation, but is really unfounded.”
It’s not an excuse, it’s reality. It’s a fundamental flaw in Euler rotations. It’s why programmers have been going to the trouble of using rotation matrices and quaternions for decades. Nobody has been making their lives more difficult just for pretend.
“Any rotation position can be represented by the three angles, and the calculations happen between frames without physical limitations.”
Yes, but a single Euler rotation can also represent multiple, different real-world orientations. This is a logical problem.
“they go all over the place because they are being reconfigured to represent the desired rotation. I hope that makes sense.”
It absolutely makes sense. It’s called gimbal lock.
“Now, it is a bug because some reconfiguration sets fail and give wrong results, completely inverting the object from time to time for example.”
Because two axes become aligned and the different positions (inverting etc.) are all valid interpretations of that individual Euler set. The system has no way of knowing what the “correct” orientation is, because they are all correct. Thus, it goes “all over the place”.
“Even if that was physical, it would never be an outcome of Gimbal lock.”
It’s a perfect description of the behavior expected from gimbal lock.
“The solution of doing through Euler rotation is neat, however I was hoping to be able to do a pure blueprint project”
The solution is to not use Eulers.
If there’s any design flaw here, it’s that BP don’t have a better way to use quaternions.
Ok, thanks. I’ll insist because either we get passed the point that there is a flaw or no one will ever fix it. Just bear with me and I’ll try to clarify with the specific thing I’m trying to do.
Imagine a Gimbal mechanism in the “locked” position (gimbals 1 and 3 sharing the z axis, 1 being the outer and 3 is the inner). Let’s say you want to tilt the component by 5 degrees along x: it is not possible through a continuous movement of the gimbals because there is no gimbal that is not perpendicular to the x axis. This is a problem if it was a physical mechanism in real life, because to get to the rotation you want you need to move more than one gimbal, which causes unintended tilts on axes you didn’t plan to rotate.
My problem is not the above, as what I’m trying to do shouldn’t be affected by gimbal lock. What I am doing is taking an object and using combine rotators to get to a rotation that is a few degrees off along one axis. Instantly - no interpolations, so all calculations and “gimbal turns” if you will happen between frames. Therefore, there is no reason the software can’t find the right gimbal configuration to give me the right rotation, and as a matter of fact it does most of the time. In a few situations though it fails: adding just a couple degrees returns an absurd rotation in 1 out of 10 frames roughly, in specific positions. I’m not saying it tilts slightly to the wrong place from time - I’m saying it completely messes up the rotation with a massive pop, which can’t be explained by gimbal lock. The point you made that a single Euler rotation can represent multiple orientations is not true (if I tell you to move your arm 45 degrees up and 30 to the left, and twist it 10 degrees anti clock wise, there is really only one orientation your arm will be) - perhaps you meant something else?
I hope that makes sense. If not, I’ll send through a project file and video to demonstrate the issue.
Again, I appreciate the help.
Al
Gimbal lock is not a physical phenomenon.
“I’m not saying it tilts slightly to the wrong place from time - I’m saying it completely messes up the rotation with a massive pop, which can’t be explained by gimbal lock.”
It’s gimbal lock.
“The point you made that a single Euler rotation can represent multiple orientations is not true (if I tell you to move your arm 45 degrees up and 30 to the left, and twist it 10 degrees anti clock wise, there is really only one orientation your arm will be) - perhaps you meant something else?”
No, a single Euler set can represent multiple orientations.
With your example “45 degrees up and 30 to the left, and twist it 10 degrees anti clock wise” the resulting Euler set is, presumably, (45, 30, -10). But what if you rotate 10 anti-clockwise, 30 left, and then 45 up? That’s a totally different orientation. But the resulting Euler set is (45, 30, -10). What if you do 30 left, then 45 up, then -10; again, the Euler set is (45, 30, -10). That’s three different orientations all with the same Euler set; I could go on, there are more.
In fact, your example isn’t a Euler set; it’s three, ordered, angle and axis movements.
Frankly, you don’t know what you’re talking about. All video games occur in virtual environments; they aren’t bound to real-world constraints. And yet, game programmers have been battling gimbal lock and avoiding it (and other euler problems) by working with quaternions for decades. Read up on what gimbal lock actual is, and why people use quaternions. It has nothing to do with torque or physical mechanisms; it’s a problem inherent to the Euler system.
You have your answer, provided three times from two different people, and it’s not a bug in Unreal. You just refuse to accept it.