Man… I just have to say… SCREW THE CAMERA SPRING ARM LAG. So I’ve been running into a few problems with the Spring Arm Component and it’s Lag functions. Seemed like a few things weren’t very well thought out when they made this. Especially for anything with flight.

The First thing was the issue with the Gimbal lock on the +90/-90 rotational polar coordinates. I was seeing the ship wobble when I was trying to get the camera to follow the ship when reaching this polar coords and causing this…

Fortunately I found the thread that has this gif and understood what the author said his work around was.

https://answers.unrealengine.com/questions/487337/spring-arm-rotation-lag-flip-at-90-pitch.html

I didn’t actually use the RInterpTo because I prefer my Lerp+Timestep method to control it (Probably same way of doing it but w/e). What he was missing and what I was also doing with the lag was adding in roll and such to the rotation, which means I needed to also combine the current Ship Rotation Delta to the Roll Delta and it gave me the result I wanted.

I also applied this to the Weapons rotations and went back to a local rotation which fixed a lot of the Roll issues with the weapons. This means they follow the ship properly and also combine with the Spring Arm’s Relative Rotation to get the proper aim location. Wooo another win!

BUG: One bug with this though as a side effect. The Addition of the Roll on the ship causes the aim offset to not quite match up to where the weapons are shooting and causes a dip in the weapons aim.

I was trying to reverse calculate this when making an isolated rotation experiment in Max, but I wasn’t really able to mathematically come up with a formula to compensate for the local rotational reversal on the Aim Dip. I’ll need to look at this bug later when I have a better understanding of Rotational Offsets or find someone more mathematically inclined to help me.

As for the Camera Lag movement, I was seeing some awful use with the Camera and the compounding problem of trying to sub-step the tick. With performance drops, the update wasn’t in line with the Actor’s movement, which usually meant that the Camera was trying to guess where the actor was and the result was never really 100% accurate. From the User’s perceptive, the Ship was jittering with lag back and forth in the direction of the movement delta. Trying to mitigate this, Unreal has a “Sub-stepping” float that’s exposed which just basically tries to update the camera within this time step when more frames are processed (which is even more expensive! And still never 100% accurate). The better way of dealing with this is to sync up with your actor’s tick and update the Spring Arm position yourself in BP. This eliminates any terrible lag seen because both Spring Arm and Actor are updated on the same frame rather than this lag shit to try and guess where the actor is.

I did this by using the same inverse position theory as the Rotational one I did above. Basically inverting the Actor’s Local movement delta and applying it to the Spring Arm. And BAM! Works. This is great because now you will never see any sort of position jitter as both the Spring Arm and Ship are now updated in the same frame.

Great Success!