Using physics interpolation

How do we incorporate physics interpolation into a Godot game? Are there any caveats? We have tried to make the system as easy to use as possible, and many existing games will work with few changes. That said there are some situations which require special treatment, and these will be described.

Turn on the physics interpolation setting

ProjectSettings.physics/common/physics_interpolation. You can now run your game. It is likely that nothing looks hugely different, particularly if you are running physics at 60 TPS or a multiple of it. However, quite a bit more is happening behind the scenes. Tip ProjectSettings.physics/common/physics_fps to a low value such as 10, which will make interpolation problems more obvious.

Move (almost) all game logic from _process to _physics_process

_physics_process (which runs at a physics tick) rather than _process (which runs on a rendered frame). This means your scripts should typically be doing the bulk of their processing within _physics_process, including responding to input and AI. between physics ticks, and ensures the game will run the same whatever machine it is run on. As a bonus, this also reduces CPU usage if the game is rendering at high FPS, since AI logic (for example) will no longer run on every rendered frame. Note outside the physics tick, the calculations for the interpolated position will be incorrect, and you will get jitter. This jitter may not be visible on your machine, but it will occur for some players. For this reason, setting the transform of interpolated objects should be avoided outside of the physics tick. Godot will attempt to produce warnings in the editor if this case is detected. Tip soft-rule. There are some occasions where you might want to teleport objects outside of the physics tick (for instance when starting a level, or respawning objects). Still, in general, you should be applying transforms from the physics tick.

Ensure that all indirect movement happens during physics ticks

if you are using them to move objects (these methods can also be used to control properties that are not interpolated). Note SceneTree. The movement of parents should therefore also only occur during physics ticks.

Choose a physics tick rate

When using physics interpolation, the rendering is decoupled from physics, and you can choose any value that makes sense for your game. You are no longer limited to values that are multiples of the user’s monitor refresh rate (for stutter-free gameplay if the target FPS is reached). As a rough guide: Note You can always change the tick rate as you develop, it is as simple as changing the project setting.

Call reset_physics_interpolation() when teleporting objects

not be what you want. That is when you are initially placing objects, or moving them to a new location. Here, you don’t want a smooth motion between the two - you want an instantaneous move. Node.reset_physics_interpolation function. You should call this function on a Node after setting the position/transform. The rest is done for you automatically. Even if you forget to call this, it is not usually a problem in most situations (especially at high tick rates). This is something you can easily leave to the polishing phase of your game. The worst that will happen is seeing a streaking motion for a frame or so when you move them - you will know when you need it! Important reset_physics_interpolation() after setting the new position, rather than before. Otherwise, you will still see the unwanted streaking motion.

Testing and debugging tips

Even if you intend to run physics at 60 TPS, in order to thoroughly test your interpolation and get the smoothest gameplay, it is highly recommended to temporarily set the physics tick rate to a low value such as 10 TPS. Node.reset_physics_interpolation, or where you should be using your own custom interpolation on e.g. a Camera. Once you have these cases fixed, you can set the physics tick rate back to the desired setting. _process() and interpolate manually.