My game is entirely spent flying. The flying system works.
However, when I fly directly downward as much as possible, my character starts glitching out and flipping upside down.
Is there any way I can use an align orientation or something to stop the player from doing that? Any help is appreciated, thanks.
Okay so this all happens on heartbeat. I’m using an AlignOrientation which is parented under the Character. I’ll only give the parts that affect the AlignOrientation.
alignOrientation.CFrame = CFrame.lookAt(Vector3.new(0,0,0), camera.CFrame.LookVector)
local baseMoveVector = controlModule:GetMoveVector() -- from the ControlModule under PlayerModule
local moveVector = Vector3.new(roundToSign(baseMoveVector.X),roundToSign(baseMoveVector.Y),roundToSign(baseMoveVector.Z))
alignOrientation.CFrame = CFrame.lookAt(Vector3.new(0,0,0), camera.CFrame.LookVector)
alignOrientation.CFrame *= CFrame.Angles(-moveVector.Z*100, moveVector.Y, moveVector.X*100)
if you need the controlModule function:
function ControlModule:GetMoveVector()
if self.activeController then
return self.activeController:GetMoveVector()
end
return Vector3.new(0,0,0)
end
Sometimes it’s a simple as ensuring your never going straight up/down. When one of the axis values are at 0/180 you can get a gimbal lock, by padding the input or just forcing it to stay at +/-0.1 instead of 0 may prevent it. You want to try to ensure that no two axis are ever aligned to each other, as that’s when things breakdown.
As @DataSigh eludes to hopefully you don’t need to resort to Quaternions.
To get true 3D freedom (without the risk of gimbal locks) you need to use Quaternions instead of Euler angles. Quaternions (a rotation matrix) is a 4x4 matrix that can properly handle any rotation regardless of original or current rotation. Thing about a matrix is it’s not as easy to understand, you have 4 values X,Y,Z & W and they all work together to form a rotation and while the X, Y or Z values may at times look like the Euler rotation angle(s) you want, change one of the values an you’ll quickly see they don’t work like Euler angles.
While learning about Quaternions shouldn’t be a priority for most, it is helpful to have a bit of an understanding on how they work as they are internally used by most game engines to handle rotations and are often the suggested way to implement rotations.
Here is a pretty decent explanation of how Quaternions work but hopefully you won’t need to read it
After about and hour and a half of playing around with the code, I figured out the in one of the operations the Z value can possibly be set to 180.
So after another 30 minutes I figured out when that happens, and when it does, don’t perform that rotation (luckily, this affected how it looks almost unnoticably).
Yes this took me two hours I’m dumb lol.
To anyone who may view this in the future, @Lithdak 's solution works well, you basically just have to find out if at any point any of the rotation vectors are set to 180, which probably is what causes the gimbal lock. Otherwise you’ll have to read up on quaternions.