April 17, 2020

This addon contains two nodes that can be added into your scene directly from the Create Node window:

For this to work, this addon must be activated from the project settings, plugins tab. Nevertheless, as you can see, there is one node for 2D and another for 3D. As I have mentioned in the introduction, this addon is largely based on Lawnjelly's Smoothing addon . There are a few key differences, though, which I will explain shortly.

The main objective of this addon is to create a system to automatically calculate interpolation states for visual representation of objects in the game world.

The differences between this addon and Lawnjelly's:

  1. In Lawnjelly's addon, when you add the smoothing node to the hierarchy, you have to manually specify the target that will be followed. This obviously brings a bit of freedom regarding node organization. In the case of my addon, the target is directly obtained by retrieving the parent node.
  2. Internally, my addon deals only with global transforms so it works regardless of the global node hierarchy. Lawnjelly's addon offers means to work with global or relative transforms. Depending on the hierarchy, relative transforms will not work.

Now, why this interpolation system? Simply put, it allows for much smoother animations, specially when dealing with monitors with faster refresh rates than the physics updates per second. It's also one of the ways to keep things running in a networked multiplayer game while the client is waiting for new server state.

Regarding the networked multiplayer game, I did talk about it in the network addon tutorial page. Regarding the smoother animations I want to talk a little more about this. We already know that physics simulations must run at fixed time steps. The frequency itself may change from project to project, but once the game is running it should remain the same. Generally speaking, the entire visual representation of the game is directly tied to its actual physics state. This leads to a problem when the physics frequency is lower than the refresh rate of the screen. The animation will be noticeable choppy.

One of the proposed solutions that "pop around" often is to dynamically change the physics frequency and keep it the same as the refresh rate of the screen where the game is running. This is not an ideal solution because it will lead to the game behaving differently depending on the screen. Basically, this falls back into the original problem of not having a fixed physics time step. It also brings another problem, which is the fact that generally speaking, input is gathered at the physics update. If the physics is running faster on certain screens, players with those conditions will have more input data gathered and processed than others, which obviously is not exactly fair.

Enter interpolation. The basic idea is to use interpolation to only change the visual representation of the game, while the physics state remains updated only at the designed physics frequency. The basic idea, problem discussion and solution are described by Glenn Fiedler in his Fix Your Timestep! article.