What is the best way to handle physics interpolation with a 3rd person camera?

Help
, ,
1

Godot Version

v4.6.1.stable.official [14d19694e]

Question

I’m struggling to get a 3rd person camera setup to work well with physics interpolation and mouse motion.

My simplified node hierarchy looks like this:

Player (CharacterBody3D)
- Rig (Node3D)
- CameraPivot (Node3D)
  - SpringArm3D
    - Camera3D

I’ve followed the recommendations in advanced physics interpolation, by disabling physics interpolation for the CameraPivot (and children), setting its top_level = true, and rotating the CameraPivot (in y-axis) and SpringArm3D (in x-axis) directly in the _input() function based on InputEventMouseMotion, and using the physics-interpolated transform of the Player to set the CameraPivot position in _process(). Everything except the CameraPivot and its children have physics interpolation enabled and all other logic runs in _physics_process. This works great while the orientation and movement of the Player and Rig is driven by directional input (“WASD”). Camera movement by mouse is smooth and consistent with variations in physics tick rate and frame rate.

The problem I have is with implementing “aim“ mode - so when switching to a mode where the orientation of the Rig is driven by the CameraPivot orientation instead of the directional input. If the frame rate is not an integer multiple of the physics tick rate, then there will be some stuttering introduced to the Rig rotation, which happens in _physics_process().

As an extreme example, if the physics tick rate is 10, and the frame rate is 35, we will alternate between 3 and 4 frames per physics tick. So if we rotate the CameraPivot by 0.1 rad in each frame based on mouse motion, the sampled rotation values look like:

process frame: 0.1
process frame: 0.1
process frame: 0.1
> physics frame: 0.3
process frame: 0.1
process frame: 0.1
process frame: 0.1
process frame: 0.1
> physics frame: 0.4
process frame: 0.1
process frame: 0.1
process frame: 0.1
> physics frame: 0.3
process frame: 0.1
process frame: 0.1
process frame: 0.1
process frame: 0.1
> physics frame: 0.4
...etc

So clearly if I use the physics process sampled values to orient the Rig, there will be stuttering of the Rig. This seems like a very common use case, so I’m curious what are your solutions to this problem? Maybe there is a simple solution that I’m just overlooking.

2

I wouldn’t interpolate/smooth anything that is controlled by mouse movement. Just set it directly in input event handler, depending on received motion delta.

2 Likes
3

You are right. And on perusing the docs again, I see this use case is mentioned (for a “top view“ game - but it’s the same concept): Disabling interpolation on other nodes. Not sure how I missed it the first time. Thanks for the guidance!

1 Like