The blue line tracks the target interpolation point.

The single green line represents the position the camera should have after all interpolation calculations.

The red line represents the past interpolation points (in other words, positions where the green line was).

You can see how the camera is usually in the same position as the green line (indicated with the camera icon). This is when the camera tracking was working as expected. This was used while I was trying to figure out why the camera was jolting rapidly in certain directions. I wasn't sure if it was the interpolation calculation breaking, or something else breaking it.

You can observe the target blue line suddenly jumps to a distant location, and at the same moment, the camera goes to its position. This itself visually represents the bug, as the camera should've kept at the same position as the green line, which kept moving smoothly even when the blue line had a big sudden shift in position.

This showed me that something was overriding the valid calculated position (green), immediately snapping the camera to the target position (blue). In this case, the old code was forcing the camera to fit within our area bounds. Our intended effect was that the target (blue) point would jump suddenly so it stayed within bounds as seen in the video, but not force the camera with it at the same time, instead, allowing it to smoothly track to the target point

3:23

How I smoothed camera feel even further, illustrated with shrew diagram:

C = Camera

P = Player

LG1 = Last frame's calculated camera goal position

LG2 = Current frame's calculated camera goal position





The calculated camera goal position is based upon things like camera bounds, player position, and aiming direction.

Your typical basic interpolation would, on the previous frame, have lerped (linearly interpolated) to LG1, and on this frame, lerped to LG2.

We now also calculate an interpolated goal position (positions of which exist on the red line, in the direction of LG1 to LG2), and the camera interpolates to that interpolated position instead (this new path of the camera path represented by the green line).

The difference between our method and the basic lerp can be seen by comparing the color-coded paths of the camera. Consider on frame 1 we are on LG1, and on frame 2 we need to go to LG2. The gap between the two purple lines indicates the difference between the camera trajectory when using a basic lerp method. In our method, the difference in camera trajectory is between the purple line to LG1 and the green line leading to the inner-interpolated position.

This difference is mainly felt in the case of sudden large shifts in goal position. These shifts in goal position will feel smoother compared to a basic lerp method. Imagine for example if LG1 and LG2 were on opposite sides of the camera. In a case like this where the target position made a large sudden movement, with a basic interpolation approach, the camera would turn on a dime to go to its new dramatically different destination. The camera's trajectory would therefore suddenly be in a completely different direction even though its movement is interpolated. Our technique is about also smoothing the trajectory, not just the movement.

In our method, the change in destination would not have such a dramatic and immediate effect on camera trajectory because the destination we actually use (in the red line above) is the product of interpolation, so the camera will have a soft turn to the new destination. In extreme cases, the direction of the camera's trajectory can still change quickly, but because the destination is interpolated, the camera will 'turn around' slower. The camera isn't immediately interpolating to the distant target point (which would result in high speed), it instead targets the interpolated destination, resulting in a gradual ramp in speed as the interpolated destination tends toward the real destination.

 

Lerping Old:





Camera Improvements:





Camera 3: