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
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