Rotation issue at some angles (gimbal lock perhaps?)

Hello! I’ve made a function that updates a variable that defines the direction the head of my character is looking in, it works as expected for the most part.

I can look around and it gives me the values I want so I can check for when the character should be looking in what direction. However, if my character faces south, the values appear to range from 0 to 360 degrees, instead of -180 to 180, which I get when facing north.

The value in question is the output of subtracting the actor rotation yaw from the look at yaw.

I assume this means that world rotation is in 0-360, while the look at is in -180 to 180.
How do I get these to behave nicely together?

Could be wrong, but I think if you change that construct:

Camera rotation -> rotate vector

into:

Camera -> unit vector * 1000

( I’m gonna draw it )

Like that ( ignoring dissimilarities ).

It’s a gymbal lock issue though. Basically just the way angles work.

You could convert the value out with some basic trig. But you always get the “jump” between 0 and 360. That is afterall exactly what happens when the angle loops back around.

Being this is an angle, maybe you can Normalize the output and just get similar ranges.

you can find a similar yet different way to do this within the turn in place tutorials…

Yeah, I suspected it might have been gimbal lock. But aren’t there direct ways to work around it? Most tools I’ve used it the past tend to have specific nodes and functions that address gimbal specifically.

That’s 5 hours of streaming, do you have a rough idea where to look?

Thanks for the suggestion, but this appears to behave exactly the same way.

Darn…

It is an issue though. I have exactly the same thing myself with continuing rotations for a certain point. I know that ‘AddLocalRotation’ will always work, and I don’t have to think about whether it’s -180 or +180 or whatever, but you can’t use AddLocal with a timeline… :mad:

So, back to SetRelativeRotation,but then you have to know where the mesh is at the moment, which is the problem…

Basically the best solution to the gymbal locking is to use the other angle, quaternions.

To do that you have to find and implement a CPP class that allows for radians in BP.
there should be several free ones to use.

Though honestly, never have had said issues on a camera that couldn’t be fixed by other means…