## Gimbal Lock

KiroNeem
Unregistered

Post: #1
Currently I am building a rope simulation program for one of my games. The rope calculations seem to work fine, although when I try and take the coordinates for the rope and turn them into bones for another program, I am getting what looks like a gimbal lock situation. Basically when the pitch of the bone is either pointing directly up or down, the heading seems to act erratically. I have looked up a few articles about gimbal lock and they suggested a few way to solve this. First I read that I could use matrix math. Second, I heard that there is a way to throw another gimbal into the situation that would be a constant. Has anyone had any personal experience or suggestions about this?
Moderator
Posts: 869
Joined: 2003.01
Post: #2
"Quaternion" is the magic word.
KiroNeem
Unregistered

Post: #3
Indeed that normally would be the best answer, although the program that I am converting it to requires me to give it Heading Pitch Bank information.
Moderator
Posts: 869
Joined: 2003.01
Post: #4
You can convert HPB rotations to quaternion form easily enough, but I am curious as to why HPB is required, and at what step of your simulation?
KiroNeem
Unregistered

Post: #5
It is not actually a step of my simulation, it is actually when I am taking the data from the simulation and feeding the data back into Lightwave. Lightwave saves all of it's rotation data into HBP informaiton unfortunetly. So what I originally was doing was using a cartesianToSpherical() coordinate conversion function that I wrote, although thats when the gimble lock problem occured. So at the end of the day the data I want needs to be in HPB information.

Will quaternions work the other way around then you mentioned? quaternion->HPB? I know that gimble lock will always be there when using these three coordinates, although there should be some way to eliminate the erratic nature of the other axis's when in gimble lock.