[Third Person Template] 6DOF Gimbal Lock problem.

Development Programming & Scripting Blueprint
1

I know that there are a bunch of people who have asked about 6 DOF movement, gimbal lock solutions etc, but I have searching for a blueprint solution to gimbal lock in Third Person Template for about 2.5 weeks now and I have finally given up, as it seems it MUST be done within C++.
While I have very basic C++ knowledge, I am trying to avoid using C++ at all for this, but will if it the only solution.

I am not that great at maths or physics, but I do understand Gimbal lock and why it happens. I also THINK I have a general grasp of Quaternions (been looking at a bunch of explanations), and why they are important as a solution to the gimbal lock problem, but unfortunately, I am not sure about how to implement a work-around within blueprints. I can see that there is a “Make Quat” node, but it is a struct, and the only thing I can really do from that is break the struct, I am not sure how I could convert that Quat back to a Euler rotation, if that is even what I have to do.

From what I can see, PenguinTD posted a snippet of the code from inside of the Combine Rotators node:



FRotator UKismetMathLibrary::ComposeRotators(FRotator A, FRotator B)
{
    FQuat AQuat = FQuat(A);
    FQuat BQuat = FQuat(B);

    return FRotator(BQuat*AQuat);
}

Which to me, says “Create 2 Quaternion’s (AQuat and BQuat), AQuat contains X,Y,Z information from FRotator A, and BQuat from FRotator B. So if Frotator A = 0,90,0, and FRotator B = 45,0,0, then the function would return A rotator value of 0,0,0”…is this right?

While I have left, right, up, down and roll movements all working ok, the pitch and yaw movements are problematic. And from what I have read, everyone says to use Quaternions. I also was reading that “Combine Rotators” node has in build Euler to Quaternion conversion, but I can’t even work out how to use rotators in this instance and it is making me feel rather stupid :frowning:

Zero-G will play a part in my game, so this is pretty important.

If I work out a solution on my own, I will definitely be posting it for everyone else, but I have a feeling I won’t work out a solution at this rate.

Thank you in advance. Any help is greatly appreciated.

2

did you get any further with the problem?

3

I didn’t see your post mkat45.

Unfortunately I did not.
I originally made the post in hope that someone with more experience could give some direction, but there was no response and I wasn’t getting anywhere, and I had other features to work on, so I just figured I would come back to it eventually.

It is a very important feature in my game, so I need to get it done. I have come back to it today, but after hours and hours, I am still sitting here, yawning profusely and wondering if I am just incredibly stupid and incompetent…so I’ll probably give up on this soon because I don’t need to be thinking like that :stuck_out_tongue:

4

sorry if i got your hopes up by posting, i can’t actually help. but i’m curious: what does the problem actually look like, and what does the third person template have to do with it, since it’s not 6DOF?

5

i ran into this issue when i built the game Dispersion for a game jam. (it involves a spinning cube in all directions controlled by the player). This was blueprint only, and to overcome gimbal lock, I basically just applied local rotation offsets from current rather than set an explicit rotation value. let me know if this solution helps. if this doesn’t make sense, i’ll post a screenshot of the blueprint script when i’m back on the machine with the source.

6

I’ll probably come back to this in a few days, because I wasted an entire day trying to work it out 2 days ago, and I just ended up incredibly disheartened and frustrated :frowning:

@Dividual:
The problem is that when moving the camera’s pitch up near the 90 or -90 degree points, the character starts to spin on it’s yaw to try and compensate for the movement of the pitch beyond the gimbal lock position, thus spinning around 180 degree’s when reaching the poles (90, -90).

@Paradoc:
As far as rotating static mesh objects, that seems to be ok, but when it comes to the Third Person character, with a camera attached to the head position, it’s a different story, as soon as the camera gets to the pole’s, it flips out, as does the character mesh itself.
I think I understand what you mean. But at the same time, I’m not too sure. A screenshot would help :slight_smile:

7

was just reminded of this today. wow, time flies. sorry for the delay, but if you’re still trying to solve this, you can use this solution:
1a61e0bcb56f7cfd07892d86877f1386bc073b15.jpeg

Call HandleRotation in tick. Then input is used to open a gate that adds local rotations to both the character mesh and spring arm simultaneously giving you a seamless rotation through the poles. Have done something like this in the past (but using desired rotations and RInterpTo’s), but just to be sure, tested this in the top down example (and making the character flying to simplify things) and worked out ok with full upside down camera support.

8

I had forgotten about this thread also paradoc. Thanks for posting that blueprint.

While it works well in top down, the third person character blueprint is a bit annoying to work with. But I think a little bit of tweaking and I’ll have something that I can share that works. Zero-G stuff and 6DOF isn’t priority number 1 right now, but I know once it’s working, I’ll be super happy :slight_smile:

The issues I am currently running into now is that the camera rotation is different to that of the actual character rotation, so the camera movement accelerates faster than the mesh obviously causing odd issues.
Thankfully, I don’t think it is a difficult fix. It is a matter of locking the camera to look straight ahead, and allow the pitch value to control the player mesh rather than the camera.

The other issue is that once flipped upside down, when the player turns right, the mesh and camera actually turn left (from the camera perspective) and vice versa, so I think there would just need to be a value check to if player’s pitch value is upside down, then reverse the yaw value modifier or something like that.

Ideally, I would make a rotation threshold where if the player moved his head beyond the threshold upwards or downwards, then the players body (mesh) would follow to make the experience feel a little smoother and polished.

I haven’t played Adr1ft without the Oculus Rift, but I imagine that there would be a similar control system for those playing without a VR device.

Anyway paradoc, once again, thank you for posting that, you’ve got me all excited to attempt doing 6dof zero-g stuff again :slight_smile:

9

Has anyone come to a final solution to this? I’ve been trying to solve this for such a long time, it would be FABULOUS if I could get this to work :slight_smile:

10

I would like to know the solution to this as well. So far this is what I have.

FQuat orgRot(FRotationMatrix::MakeFromZX(GetCapsuleComponent()->GetComponentLocation(), GetCapsuleComponent()->GetForwardVector()).Rotator());
FQuat addInRot(FRotator(0, mouseX, 0));
Controller->SetControlRotation(FRotator(orgRot * addInRot));

This allows my character to walk around the planet with the control rotations down vector always pointed at the worlds center. The mouseX is from the mouseX input and it adds correctly - right up until I reach the axis poles of the world. Then, as detailed above the character flips over on its head as the 90 - (-90) yaw values try to compensate crossing the zero into the opposite range. I keep hearing everyone say that it’s easier in c++ but I was actually able to do this in BLueprint back when I first started on my project. It was simple. The combine rotators node in Blueprints will add rotations together without a problem. I can’t seem to replicate this in code.