Gimbal Lock?
BlitzMax Forums/MiniB3D Module/Gimbal Lock?
| ||
| Am I correct in that there hasn't been a fix for the Gimbal lock issue hasn't been solved with any reasonable method? I heard people saying you have to use quats, which I have never used, while other people say you'll have to rewrite MiniB3D to make it work. I made a space game in B3D awhile ago, but with a casual test of MiniB3D it looks like it won't be possible. Is there an easy way to convert quats to euler angles, or is this out of a league of a semi-casual programmer? |
| ||
| Do you have a demo of this Gimbal-Lock? even from the wikipedia article I can't visualize how it affects rotations. EDIT: nevermind, just saw an explanation in YourTube. |
| ||
| gimbal lock directly only has consequences in +- 90° rotations on X / Z (looking straight in +- Y direction) The only way to fix gimbal lock is to handle rotations through quaternion only. Neither matrix nor euler rotation is able to avoid gimbal lock, as they both suffer the same singularity issue |
| ||
| Hrm, I'll look into quats then, there seems to be a few good articles. I'll update my post if I find something interesting. *Edit* Warner solved the problem by reprogramming the core of MiniB3D to use Matrixes, I just tested it and it works beautifully. This opens a new avenue for me... http://blitzbasic.com/codearcs/codearcs.php?code=2498 |
| ||
| To use Quaternions, you mean. PS: Lovely code, just rebuilt my Mb3D to use that. Big thanks to Warner! My next challenge is how to adapt a single surface sprite system and use the camera matrix to align each quad, while still allowing for each sprite to have individual rotations. Much faster than using a pivot and reading the TFormed vectors, like some systems out there do. |
| ||
| you would be shocked how fast TForm actually is in the regular blitz3d :) |
| ||
| Oh, I don't doubt it. It's just that using a pivot to extract the vectors is slow because of the transformations applied to it: it's positioned at each quad's center, aligned to the camera and rotated to the quad's rolls, then the vectors are extracted. These transformations cost something that is easily eliminated with matrix multiplications (I think this is what Particle Candy uses to achieve its lightning-fast performance, but I'm not sure, haven't seen the source). |
| ||
| Much faster than using a pivot and reading the TFormed vectors, like some systems out there do. (I think this is what Particle Candy uses to achieve its lightning-fast performance, but I'm not sure, haven't seen the source) Is there an updated version of Particle Candy available ? I only have the Blitz3D library. There's no real magic in my Particle Candy source. Just a pivot here and then, a little bit of PointEntity and some TFormPoint(). |
| ||
| I'm not sure if there is a new version; perhaps if you send an e-mail to the author, just to know. About the technique, hmm, I really didn't that was it. It surely must be "highly optimised" (taken from the Features, on the website heh). About this matrix single-surface technique....unfortunately, I have absolutely no understanding of how 3D transformations are done. The major goal here is rotating every quad in a surface through the camera's matrix, although I don't know how to do that on a per-quad basis (if you'd do it in the entire model, that would simply be a RotateMesh). Any help in this department will be greatly appreciated. The best reference we have so far is the mat_sp, a special matrix made for the normal Mb3D Sprites. |
| ||
| You guys should be aware that Warner's quaternion "fix" slow things down *a lot*. I had a small particle test on miniB3D, running at nice 70fps, and once I switch to Warner's code, it droped below 10fps! The code *is* very good, and very appreciated, but do some tests before using it, and later complaining about miniB3D being slow... ...and also, Blitz3D has the same gimbal lock problem AFAIK, so it shouldn't be that much as a problem as people believe it to be :P |
| ||
| thats the price of using quaternions, their requirement to be forward and backward converted a lot has some pretty hefty consequences. though to run on your framerates the system on its own must be bad enough to start with. And yeah, Blitz always had gimbal lock and its no problem if you restrict the X / Z rotations to [-89,89] disallowing the 90 degree rotations |
| ||
| I didn't know Blitz3D had the same problem. Then I have no idea what people are complaining about - gimbal lock never occurred to me when using it back in the old days (or most likely I didn't notice it). |
| ||
| I made a 3D space game in Blitz3D and never encountered gimbal lock. |
| ||
| I believe RotateEntity has gimbal lock but not TurnEntity. |
| ||
| And yeah, Blitz always had gimbal lock and its no problem if you restrict the X / Z rotations to [-89,89] disallowing the 90 degree rotations I thought Blitz3D used quaternions internally. I'm pretty sure I recall a post by Mark stating that fact. |
| ||
| I believe RotateEntity has gimbal lock but not TurnEntity. Are you saying that regarding Blitz3D or MiniB3D? |
| ||
| He was saying that in regards to B3D I am pretty sure. Also, B3D DOES use the "super slow" quatrains. But at a C++ level. http://blitzbasic.com/Community/posts.php?topic=42657 |
| ||
| Anyone willing to convert Warner's code to C? =X |
   |