Character won't rotate properly

Hi.

I want my character to rotate towards where he is heading, but with his head first.
So I get the Velocity, make a RotationXVector out of it. I subtract 90 degrees from the pitch (because Head first).

But whenever the Character reaches 90 Degrees (going slightly downwards) the Rotation glitches.
My node setup looks like this (Tick):


Here’s a demonstration:

v=VXARKUfz038

I understand that when the Velocity reaches 0, the Character’s Rotation becomes 0,0,0. But I don’t understand why the rotation bugs whenever I want to go straight downwards…

Gimbal Lock?

Not sure, but wasn’t there a bug in the “Pitch” handling? If the angle is below 0, and not between 0 & 359.
Or something like that.

How can I solve this? Aren’t the values of rotators -180 to 180?

fix:

Short answer:
You have to use values between 0-360, and not -180 to 180, because the pitch is getting reset to 0 if its below -90, and reset to +90 if its above +90

I thought that mod 360 would solve the problem,
but it does not…

I still have this problem…

Do you know how to resolve this type of rotation problem with a mini map?, as my pawn runs on the map, you can see the animation, and he moves through the map
but when the map rotates (when you rotate the camera), he won’t rotate around with the map and remains running in one direction while the map rotates…

Try printing out the angles to the screen while the game is running. I’m particularly suspicious of your pitch angle. I think it may be going past -180 and hitting +180, and thus causing the problem here.

nothing helps:

Rotators are always converted to -180 to 180.

nothing helps:

Rotators are always converted to -180 to 180.
[/QUOTE]

I had problem with this too :slight_smile: and i solved it (almost - 99% satysfaction)) very well with my ultimate custom BP code… (i have jet fighter flying like your character downwards and mesh is rotated well)
i totally dont remember my setup but when ill be at home ill take screenshot of my setup (spent about 2 days with it), maybe it will help you… if i forget then quote me ill get notification

that’d be nice :slight_smile:

sooo… i checked mine bp… its a bit different but i hope it will help you (copying this wont help you because behavior is different, in mine is mesh rotation based on controller rotation). I dont remember very well how its working (its some months ago when i done it)
making this was pain and i think you will suffer too :smiley:
bp: http://i.imgur.com/wG8g9l8.jpg
video how its working in mine project:

Hi @Raildex_,

I had this exact problem when working on my swimming code a few months ago lol. The issue is Gimbal lock and the pitch getting reset.

Here is my solution:
6765c45906bb5c427bb08f03810e0ae5ad0992fd.jpeg

On my setup Im using Control rotation pitch and yaw to drive character rotation. So, I’m constantly checking pitch against a threshold (say 75 degrees). When the character goes past the threshold…

a35afb140fbd116503536501c7f299a2fb077126.jpeg

Switch from Impulse to AddWorldOffset and do a delta location in the Z vector (up) or -Z vector (down).

Try this and play around with the pitch values (75-85 seem to work best for me).

Hope this helps!

Thank you. I’ll try it out.

Man, we really need quaternions in Blueprint…
These are hacky workarounds :frowning:

You guys should check out: https://wiki.unrealengine.com/Blueprint_Six-DOF_Flying_Pawn_Tutorial

Using this “add actor local rotation” type method will avoid all gimbal locking, but a 6DOF setup might not be what you’re looking for becuase it’s more suited for flying/space games. I’m assuming that it’s converting the yaw/pitch/roll into quaternions internally. There would be no real reason to expose them for manual editing because they aren’t in a format that your brain can easily comprehend like XYZ; without knowing all the atan2 cases. You’d have to use degree<=>quat calculators to go back and forth anyways.

And for reference, pitch starts at zero (default horizontal angle), goes upward to 90. From that same default zero position, it goes downward from 0 to 270(because 0=360). You just need to set up some branch logic, using some booleans, to check if it’s greater than 0 AND less than 90, you’re in the “up” direction so do XXXX. If it’s greater than 270 AND less than 359.999(360 will bug out and throw a 0), you’re in the “down” direction so do YYYY.

EDIT: And if you really want to play around with quaternions, just to see how whacky the numbers are, trying playing around with this interactive graph: http://quaternions.online/

Somehow AddActorLocalRotation doesn’t work,too. It still bugs out.
eb50ba9a05972650cbe7467ad5f081fc966088dd.jpeg

How exactly should I setup branching of the Rotation for Pitch, when I need to interpolate to this rotation?

Just put a cap on pitch angles. Look, I don’t know your exact setup or how convoluted it is, but if you’re having gimbal lock issues, then just cap the angles. What’s really weird is now my pitches are showing 90 to -90. On another project of mine, they range from 90 to 0/360 to 270.

How this example works: I’m just using the mouse “lookup” axis in the third person template because I’m being lazy. Use whatever axis you need. The multiply by -10s are just to invert the direction and the 10 is just making it rotate faster.

It then gets added with the actor’s CURRENT pitch angle as in BEFORE it before it actually modifies the actor’s rotation. It enters into the first branch, which compares that value to +89 degrees. If it’s greater than that, you set the “actorlocationandrotation.” Just plug in the current location, current roll and yaw. However, for the pitch, you manually set it to 89. This is your “limiter,” by the way.

If the current pitch and amount getting added to it are NOT greater than 89 degrees, then it proceeds into the next branch. From there, it does the same thing, but compares vs -89 and if the number will be less than -89. Again, if it is, then it caps it to -89.

If it passes both limit tests, then it proceeds to adding the positive or negative axis value to the actor’s local rotation.

Try something along these lines and it will work fine for you.

Here’s a quick clip showing it working and preventing the yaw from spazzing out:

v=66_qRplWLAM

^You are clamping the Pitch between -90 and 90. Something I do not want at all.

I want to rotate my Character head first because of Swimming.

Yaw and Pitch change from 0 to -180 as soon as Pitch reaches -90. Which makes Pitch go from -90 to 0 again.
Even with “AddActorLocalRotation” the camera behaves odd.

I somehow found a solution:

Instead of using GetActorRotation() as a Current Input in RInterpTo, I saved the ActorRotating in a separate Variable.
I then used the Make Rot From X from my Movement Input, and used Delta(Rotator). The B input for Delta is Pitch: -90. and used this as Target for RinterpTo.
I then used SetActorRotation.

When using GetActorRotation, the Rotation bugs around.

Oh I see what you want now. You essentially want the character to be completely upside down as in standing on their head. You can do the same thing I showed, just clamp the ranges to a wider range, but still Max-1 and Min-1. Might have to map the pitch ranges to a different range though. I will modify that test scene to do what you’re talking about.

As for your solution, that has more to do with “WHEN” in the chain of commands that you are sampling the rotation from. Like in my example, I sampled the rotation BEFORE it actually makes it to the part of rotating the actor, and from there it compares the numbers to the limit ranges. Only IF it passes those ranges, will it make it to the parts of the command chain that will rotate the character.

There is a BIG reason why almost every single game you’ll ever play, that has swimming in it, will never allow you to point 100% down. It’s almost always slightly off by a degree or two. It’s to prevent gimbal locking.