How can I keep Control Rotation from freaking out past 90 degrees?

Hi, I’m gone through and setup an inverted sphere world where the control rotation’s up vector always points towards the world’s center (0,0,0). The player can walk around on the inside of the sphere all the way around, but currently when the player hit’s the 90 degree mark of the world the control rotation starts to fall apart. This effect actually starts to occur before 90 degrees (maybe around 75-80) but it’s a gradual transition. I’ve test my walking past 90 degrees on the two working halves of the world ( below the 90, and above) by placing the character upright on the bottom half and then upside down on the top half. The character will fall along his UpVector and then can move along the walls until hitting this point. There’s a big chance it’s still something burried in the CharacterMovementComponent that I haven’t rooted out yet but my gut tells me it’s some sort of rotation math issue. Right as the player hits this 90 degree mark the control will sort of spin/ fall over, it feels as though some value is no longer staying within scope. When I slam into this invisible barrier the character will bounce out off the surface and then start to inherit it’s Local Z is down gravity setup, and sometimes it’ll float over the barrier and allow me to drop down to the ground on the other side (It’s actually kind of cool). Again I’m not convinced it’s not still a lingering evaluation in my charactermovementcomponent but the fact is that the control mechanism that I’ve setup in BluePrint loses it’s effectiveness around this 90 degree limit, and I don’t understand why something that is pointing at a location every tick can wobble out of alignment and break, so I’m looking for some suggestions about where to look. Ultimately I think I should throw away the Blue Print and just embed this stuff in the CharacterMovementComponent, but that’ll be easier once I know what is going on. Attached is shot of the actual BP keeping the UpVector pointed towards the world (0,0,0) vector.

Attached is a little diagram showing a side slide of the problem. Yaw essentially breaks down near the 90 degree mark. No longer behaving as yaw is intended.

If I wanted to put this in code where would I look to find where the rotation of the character is first set/ established?

I see rotation stuff throughout the charactermovementcomponent but nothing that appears to be always maintain or override everything else. For me I need the Pitch and Roll to be set to pointing toward the Vector (0,0,0). I know that I can use MakeRotZX to point my capsules UpVector towards that coordinate so now I need to know where I would put this function at (Character, CharacterMovementComponent, somewhere else)

Is there another system that effects the control rotation besides the settings in the character cpp? I’ve already switched the pitch and roll to true.

Here I’ve got the Control Rotation printing out to the screen. You can see the Yaw doesn’t behave correctly, in the first shot the yaw is low, then in the next it’s been influenced a good bit but the character has not turned any, then in the last shot on the right you can see where the value of the yaw accumulates enough the character capsule actually falls over onto it’s side instead of swiveling along it’s UpVector.

I’ve looked all over for a solution to this and I’m coming up short. I’m not even sure what is going on. If I’m telling Pitch and Roll to be something specific every tick then why do they get influenced at all outside of that? You would think they would always be the result of the BP above. Additionally why does Yaw start to lose it’s orientation as I walk up the slope. Isn’t Yaw always the swiveling down the UpVector? Instead it starts to act like it’s only yawing along the world UpVector and as I get near or cross the 90 degree mark it’s rolling the character onto it’s side.

I’ve noticed that when I cross over the 90 degree mark to the upper side of the sphere, my horizontal input get’s reversed. When I Approach the 90 degree mark the Yaw appears to warp heavily to flip the character over on it’s head. Something is causing the control rotation to flip over when the capsule crosses the horizon, which would be Zero in my world, because the center of the sphere is 0,0,0.

Hey Thumper,

We’re working on providing a potential solution for your problem–what is happening is that you are hitting gimbal lock, which causing your rotations to not behave as desired. We hope to have more feedback for you soon on this issue.

-Steve

Cool, I thought I was going crazy, I tried using Attach control rotation to pawn, thinking that if it was somehow local to where the player is at that it wouldn’t roll out like that, but no luck. Thanks for replying, I had recently put a bunch of work into getting the Walkable angle to be based on my characters up and for the most part I think I have achieved this, but the dead zone in my scene slowly warps the Yaw input/ control rotation. If I was lucky enough to sort of bounce over it to the other side it would fix itself Except that my horizontal control would be inverted, so rotating right made it rotate left.

Now that I have gimbal lock to use for searching I found this post . link text

It sounds like maybe I need to perform this setup using quaternions. Sounds a little fancy but I’ll try and see if I can do it. If I wanted to embed in the class source where would I put it? Is this something I could stick in the CharacterMovementComponent? I’ve been trying to find a spot in there where I could just put a code version instead of having it in BP’s. All my characters will have the same rule applied to them so it’s fine for my purposes.

Hello,

The problem with Euler rotation system is that it isn’t continuous when you change more than 2 components, and it causes gimbal lock issue.

Try this,

  1. Get rotation vector from player as you did up there (pitch and roll with 0 yaw)

  2. Get the yaw value you want as the above graph (yaw)

  3. Now rotate the vector from 1) with 2) rotation

  4. Now convert that vector back to rotator and set to player

This will rotate the original rotator to “yaw” rotator you want, and give the final rotation back.

Thanks,

–Lina,

Are these the proper nodes for getting a rotation vector and rotating a vector from?

The above BP causes the original aiming of the Pitch and Roll to not point at the world center (0,0,0)

Yeah I don’t think I’m using the correct nodes. The above picture is the closest I’ve got trying to add the rotation in the way suggested. What ends up happening is the upvector of my character which should be pointed toward the world center, doesn’t really do that anymore, it just points up. But I don’t think I’m getting the vector “1)” or using rotation from “2)” correctly. It make sense what you’re saying but how do I do that in BluePrints? Is this something I should put in code?

How do I get the rotation vector? It sounds like I have already done it in the BP I posted, but in step 3 I’m supposed to rotate the “vector” but in my BP 1) is a rotation, so which node should I use to convert it to a vector? Also how do I convert the rotated vector back to a rotation?

Is this something that can only be achieved through programming?

I’m still having trouble avoiding gimbal lock. I’ve seen it on a few other posts but the answer seems to be using Quats, but the answer posted in this thread appears to contradict this. Is it possible to avoid gimbal lock by rotating a rotation in steps as suggested above or are Quats the only way to truly do that?

Can someone clue me in on which nodes are used for the answer in this post? I’ve yet to be able to Rotate a rotator, or convert a rotation to a vector.

The answer from Lina is how I got it to work.

1) Get the input from InputAxis Turn Event,  make a rotation plugging float from event into the "Yaw" slot.  Leave Pitch and Roll Zero's.
2) Get Actor Location * -1 ( for me inverted kept the character capsule pointed the correct direction),  
3) Get Actor Forward Vector
4) MakeRotZX with result of 2) in the "Z" Slot,  and Result of 3) in the "X" slot.  
5) Combine Rotation from 1) with Rotation from 4)
6) set the Control rotation to this new rotation. 

This stopped the camera from wobbling as I approached the 90 degree mark (eventually turning/ flipping over onto the character’s head as the gimbal lock set in). This also stops the control’s turning from reversing on the other hemisphere.

Thanks!

1 Like