I’m working on a space game. Obviously this requires the controls to be in full 3D, being able to move a ship pointing to the Z axis for example.
The issue is that SetActorRotation or MoveComponent only take FRotators as parameters. Worse than that, they also appear to store FRotators internally. FRotators are subject to a -90 +90 issue on pitch and thus are unusable in my case.
So, is it possible to avoid gimbal lock with UE4 ? What are quaternions good for if the internal representation is fundamentally unreliable ?
I’d like to know the answer to this as well. I’ve looked at the code and there are calls to set an FTransform on a USceneComponent but that is decomposed into translation and euler angles, which have this problem.
FRotators in UE4 really need help, I always have issues with them flipping on me as you describe, for me it happens around the -180 to 180 range, and that flipping constantly interferes with my game mechanics.
Clamping all rotators values to -180 to 180 really helps though
This is a classic issue with using euler angles to express rotations. I’m actually surprised USceneComponent stores rotations like this, even if they are doing it for efficient replication (which is what it appears to be), the rotation could be expressed as a quaternion…
After some digging around I think this can be done “correctly” using a USceneComponents ability to attach to a socket of another USceneComponent. If you made your own version of a USceneComponent like UQuatSceneComponent that provided a single socket, you can override HasAnySockets(), GetSocketTransform(), and QuerySupportedSockets() and use that to provide full rotational control using an FQuat.
A good example here would be to look at the SpringArmComponent which is what gave me this idea.
