I have two objects, and I’m trying to calculate the size of the difference between the direction they are facing, individually broken out in local axes x, y and z.
I’ve already tried:
Delta rotators: Works fine in yaw and roll, but in pitch when it goes past -/+ 90 the magnitude starts to get smaller.
Dot product: Combines the magnitude of difference of two axes, like pitch and yaw, but I’m trying to find the magnitude of difference of each individual one (x, y, z individually).
I thought either of the following would work, but regrettably they don’t…
Try getting forward vector from the resulting rotator.
Keep in mind that a vector will only count for 1 of the 3 dimensions. So if all you are after is a direction then the +/-90 pitch or any other conversion to avoid gimbal lock shouldn’t matter.
@pezzott1 Nice idea! I thought the forward vector would work, and the output format of a unit vector is ideal… Regrettably though, it isn’t cleanly splitting x, y, z values into local magnitudes.
So to test it if I move the player cleanly only in one axis, the direction difference caused by camera lag should show a difference only on one local axis, because the others would be still aligned. But it is showing changes in two or three local axes.
Here is how I’m setting the position of the Spring Arm (in rotators for the moment). Essentially, it’s a manual version of Spring Arm lag… split by axis… and also dynamic.
My goal is to have a dynamic InterpSpeed for each individual RinterpTo nodes (roll, pitch, yaw). The idea is that as the lag on each axis causes a bigger difference (i.e. magnitude), this increases the InterpSpeed to reduce the difference/magnitude.
This is why I’m seeking to measure magnitude of each individual axis, local to the difference in x, y, z. I favor using vectors because Unreal rotators are messy.
Fantastic @pezzott1, excellent question. Its kind of like Iron Man flying. Yes, the camera can go fully upside down and the player can fly this way too. At this point, with a keypress, the player would normally instigate a roll (using a timeline to drive control rotation roll) to level off and re-orientate the controls. No issues here fortunately.
Gimbal lock hasn’t been a problem yet, so there’s no spring arm ‘hitch’ at the top and bottom (as it used to). Though if gimbal lock shows up, it’s OK… I can switch to setting spring arm world rotation directly with quaternions (using EZDof plugin nodes) which has solved it in the past. So, also no issues here fortunately.
What I’ve been struggling with is that, for each axis of spring arm relative rotation, I’d like a lot of lag at the beginning, which looks cinematic by giving nice camera angles on the player. Then, for gameplay reasons, I’d like less lag as the difference/magnitude becomes more pronounced. So the spring arm won’t actually do a 360 around the character because by that magnitude the InterpSpeed will have increased by a lot.
The BP snippet below gets the idea across, though it doesn’t work in pitch because as the pitch differential goes past +/- 90 it begins to fall because of how pitch in UE is handled. So pitch (unlike yaw and roll) actually gets smaller again once it goes past 90 degrees, which messes up my calculations.
My best guess is that the pitch and yaw have to be calculated separatley using quaternions each in a separate component, yaw to a scene comp and spring arm as child with pitch. Both in relative space. This will not allow the camera to roll off. The roll will have to be inherited from the character.
@pezzott1 Yes, it looks like there is a spring arm ‘hitch’ at +/- 90 world pitch where it seems the spring arm switches sides. I experimented with the EZDof plugin and quaternion rotation of the spring arm. It was about the same, so maybe it’s not gimbal lock… it is a head-scratcher
Regarding measuring the axis difference caused by RInterp lag in each axis, I got it working! Get Control Rotation (instead of Get Actor Rotation ) returns Pitch up to +/- 180 degrees (instead of +/- 90 degrees). Though I’d prefer using vectors for the area in blue, so if someone has any suggestions?
There is a still a spring arm ‘hitch’ at +/- 90 world pitch where it seems the spring arm switches sides. I don’t think it’s gimbal lock, and I’m still puzzling about it.
This sounds VERY interesting, kind of like a virtual cameraperson. There is a marketplace plugin, Cy Advanced Spring Arm, that you might also enjoy… though regrettably it only goes to 5.1.
Made a few (failed) prototypes. Here’s what I’ve learned:
Couldn’t find a way to use Control Rotation with quats and quaternions are needed for the cameras pitch.
Found it best to be done in relative space without dividing the axis into separate components. The limitation is that the clamps won’t be depending on another components rotation, because as soon as the other component moves the camera will go crazy. I did however divided the axis into separate floats and set those with the input, then to quat and finally to rotator. Don’t like this approach very much because the clamp is a square around the character, doesn’t feel as organic as clamping by distance from (0.0, 0.0, 0.0). When one angle starts to slow down near the limit the other feels like it can slide off.
In this case the camera does not affect the rotation of the pawn, so buttons have to be assigned for throttle (1), yaw(2), pitch (2) and roll (2). Trying to figure out how other games solve the buttons issue I noticed the camera is used for pitch and roll allowing free look on button hold.
There are more things I would like to try, but cannot spend more time on this right now.
Thank you for your effort @pezzott1. I really appreciate the detail of your response.
I’m first going to attempt a simpler solution, if I can get it to work:
using the dot product as a base for RInterp
add/deduct custom speeds to each axis, to account for specific situations.
In the image below, I keep Roll at zero, and add to (or multiply) Pitch and Yaw Rinterp speed as needed. So far it works well, but the issue I’m having is gimbal lock. I’m hoping this will fix itself when the EZdof plugin is updated to 5.4, and I rotate the spring arm using quaternions.
