Solution to the gimbal lock!!!
BlitzMax Forums/MiniB3D Module/Solution to the gimbal lock!!!
| ||
| Hi all! I discovered that there was some problems by recieving the global rotation coords from EntityPitch yaw roll, because of the gimbal lock. But why not just add all the parents rotation degrees together, and then you've got the global rotation coords? and then just MOD them to 360? |
| ||
| Because this is not correct. Adding all the angles together is matematically incorrect and doesn't lead to the expected result. If you were converting the rotations to matrices, and multiplying them, then you'd get the expected result. But merely adding the angles won't do it. |
| ||
| i've made a test against Blitz3D, and it is correct! if you've got an entity with a parent, and that parent has got a parent too, then look here: + Entity : Local Pitch = 90 |-+ Entity : Local Pitch = 90 <-- Here the child is at 180 degrees in global right? ...|-+ Entity : Local Pitch = 90 <-- And now this entity's pitch is 270 global right? thats it! just add all the parents angle-degrees together. |
| ||
| [Disclaimer: this is from very very old memories of distant 3d experience. It may be bull***] Nope. You are doing it with only one of the angles that is different of zero. In short, you're thinking in 2D. Try with rotations where all the 3 angles (Pitch, Yaw and Roll) are different from 0, and see by yourself. The problem is the final rotation depends on the order the 3 angles are applied (I can't remember what this order is in Blitz3D). The first angle is applied on a given axis. Then the second angle is applied on a second axis, but this axis is itself rotated already, so the result depends on the previous rotation. Same for the final axis (rotation depends on the 2 previous rotations). If the result of a single Pitch/Yaw/Roll already depends on the order of the axis rotations, you can imagine, that simply doing consecutive Pitch/Yaw/Roll rotations won't work great. |
| ||
| but it's working in my engine? i testet it with an entity, which is attached on another, and then moved 4 units in local space, and then i have set the parent to rotate 1 degree on each axis each frame, and it looks like it should? |
| ||
| Well it's hard to see just by eye that the rotation is incorrect, usually all you'll see is that indeed the rotations add up. But they don't add as they should. You'd need to compare with rotations done with equivalent matrixes, all multiplied. Also I suggest you search google for Pitch/Yaw/Roll or "euler Angles", you should find a lot of information on the problem. But again, maybe I overlooked something. The last time I did 3D was literally in another life. And concerning the gimbal lock per se, you'll find even more information. Needless to say, lots of smart people have studied the problem, so rest assured this was not an imaginary problem that can be solved with a simple modulo. |
| ||
| I thought using Quats gets around the gimbal lock problem? |
| ||
| Totally correct. But Qimmer was suggesting to directly add the individual components of the euler angles (Pitch/Yaw/Roll), which is totally different (and incorrect). With Quaternions, one would convert the euler angles to Quaternions, compose them, and convert back the result to Euler angles. |
| ||
| but thats the problem when converting back to euler angles again, because then the gimbal lock occurs .. but i tried to look at the coordinates returned by decomposing the quaternion rotated by the euler angles, and then the euler angles added together, and they are the same? why is my method incorrect then? |
| ||
| but thats the problem when converting back to euler angles again, because then the gimbal lock occurs I wouldn't have thought so. Isn't it the case that the process of applying the different angles causes the lock, therefore, when that process is done using Quats you avoid the issue altogether. There's just the overhead of converting between one system and another. |
| ||
| Gimbal lock is inherent to Euler angles and is not a matter of conversion between systems. It happens when an axis gets rotated exactly onto another axis, causing later rotations to become undefined. The technique of adding parent and child angles is wrong because it simply does not work. It may work in certain special cases, such as only one axis being used. But in general it will fail. |
| ||
| Wrong! Because i am using the addition-method in euler angles, and it works fine with the parent/child system, and it all rotates fine. |
| ||
| Qimmer: People much smarter than you or I worked for years trying to solve the gymbal lock problem with Euler matrices, and failed. That's why they invented Quaternions. Trust what people above are telling you. You haven't solved the gymbal lock issue. And if you have "solved" it, then you've done it in a way which won't work in the general case where you have to transform objects to one matrix or another and all that weird crap people who don't use Blitz have to concern themselves with. :-) |
| ||
| But in my nexus engine i am through developing, i have a skinned mesh working 100% with this method? |
| ||
| Define "working". Do the angles accumulate? Yes. Do the angles accmulate as they sould? No. To be usefull, angle composition should work whatever the original angle was, right? That's not the case with euler angles, that's it. To be honest I'm surprised you still question the reality of the problem. There should be enough material on the net for you to understand what the problem is all about. |
| ||
| working = an animated zombie mesh walking around on a plane. And when you use a skeleton as this one in milkshape, a lot of the bones are rotated specially to fit the special axes of the bones, but still, the whole zombie animates ok. |
| ||
| To clarify, gimbal lock is actually a math problem, not a percieved issue. it is a flaw in the concept of euler angle implimentation. Eulers are really meant to represent a snap shot of a rotation, and as such don't handle rotation as well as other representations (such as quats) which are designed for motion. The issue lies in the base code of MiniB3. It is based on a Euler system, there's no way to get around that besides re-coding it from the inside out (as simon has stated he would like to do at some point but it's a MASSIVE undertaking) so no matter what you do your angles will end up as eulers in minib3d and will suffer from gimbal lock. Check wikipidia for more details on eulers and gimbal lock. The bottom line is gimbal lock is not fixable in the current iteration of minib3d no matter how you try to out smart it because of the way in which the rotations are stored and applied in the engine itself. I retract that statement. theoreticly you could make your program handle ALL rotation calculations in it's own quats and then convert the final angle to eulers and apply that staticly to each entity each frame... but the whole reason of using an engine is so you don't have to do exactly that kind of thing... so if you were to do that you'd be better off making a spin off of minib3d in the first place... I've spent a lot of time trying to work around the issue myself, trying to track orientations and so forth externaly and then apply them to an entity etc. and it will work 95% of the time but then all of a sudden you'll try to do a barrel roll and your object will invert 3 times and then come out facing left and upside down because the adaptation is being back corrected by the eulers. so you have to replace them completely to fix the issue. You can make it better, but you can't make it go away, and when it's better it's harder to figure out what angles are triggering the gimbal lock |
| ||
| A barrel roll? |
   |