Camera collision has "springing effect" at lower physics ticks rate when colliding with objects

[sly obsidian]

Hi all,

I think this is more of a design issue rather than any issue with physics or Godot, but I am stumped on how to solve it.

I started the project in Godot 4.4.1, but promptly ported to 4.5 beta 2 due to the physics interpolation rewrite, which so far has been a God send! I am using jolt physics.

My problem is that as the camera follows the player, if it collides with any objects, it will have a noticeable "springing effect" at physics ticks rate seemingly lower than 40. Allow this video to demonstrate the problem.

https://www.youtube.com/watch?v=aMBK6SOjZNQ

My setup is as follows.

The player is a CharacterBody3D node, with a simple character controller script.

The camera is a separate scene and uses the "gimbal" setup, it consists of a Node3D as root, another Node3D which acts as a pivot, a SpringArm3D node, a Marker3D node as a child of the SpringArm3D, and finally a Camera3D node, which lerps to the position of the Marker3D node. See the attached image. The script to control the camera is here, and yes it is super messy, forgive me. https://pastebin.com/1Z11tugN

I think the problem is that because the camera scene follows the player by lerping towards the player, and the camera lerps to the position of the Marker3D node, this is what causes the "springing effect", because the camera is being told to lerp to one position, while the camera's root node is also being told to lerp to the player position.

How can I solve this? I just can't seem to come up with a solution that is fully satisfying. I've tried modifying the code to only follow the player if it's not colliding, but that means if the camera collides with any object, it stops following the player altogether. If anyone has solved this problem in the past and could share some pointers, I'd much appreciate it!

[half field]

For things interacting with the physics engine it should be using _physics_process(delta) to move them. It's probably fighting with the interpolation with _process(delta) being used

[sly obsidian]

That's a good theory, I'll try it out. The only concern I have is that the Godot docs covering physics interpolation pretty much say not to do that, but it's vague and may be outdated.

[sly obsidian]

OK, so that did have a huge impact! Now that the logic is all tied up in _physics_process(), except for the code that affects the camera's rotation staying in _process(), the springing effect has been eliminated!

So I would say that following the docs, in this case, actually caused my problem, rather than solve other issues. Wild!

Thank you so much!

[shell sigil]

Just a heads up, the documentation does note that cameras are a general exception to physics interpolation, particularly for first-person or third-person games: https://docs.godotengine.org/en/stable/tutorials/physics/interpolation/advanced_physics_interpolation.html

might be some good reading for you in there

[sly obsidian]

Yes, this was originally what I had followed and what I had implemented, and in general it did seem to work, until I encountered the springing effect. I think the general idea is correct, but there may be something in the way, either with Jolt, the physics interpolation itself, or my design, that causes the springing effect to occur when the physics ticks get too low. I just couldn't think of a general solution on my own, and every video I could find always had the movement code in _physics_process.

I am playing around with my design and implementation to see if I can truly get everything to work as described in the documentation.

[sly obsidian]

Alright, I solved this!

So, it turns out I was making an error in not only my code, but in my interpretation of the documentation.

Basically, this is what I did.

First, I made sure that physics interpolation was off for my root node for my camera scene. Then, I made sure both the SpringArm3D and Marker3D node had physics interpolation ON.

The camera itself is still part of the scene, so it inherits rotational data from the gimbal setup, but otherwise I set the camera's postion to the interpolated position of the Marker3D.

The below video shows it working perfectly in action!
https://youtu.be/grHqUOn-Ivw