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:
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.
Interestingly, there isn't much that is needed to use this addon. Normally you just attach the
Smooth*D node between the physical object (rigid body or kinetic body) and the visual representation (mesh instance, sprite...) of the game object.
Two very common node hierarchies for characters are depicted bellow:
To smooth out the visual representation those hierarchies would then become like this:
With this the physical object remains tied to the physics tick while the visual representation of the game object smoothly follows it. Indeed the visual representation of the game will have an small delay when compared to the actual physical state. Some people may think this is unacceptable, however think about this, the amount of delay here is really small. Normally, a fraction of a single physics tick to be more exact. So if you configure your game to run at only 30 physics updates per second, then the interpolation will result in delay of at most 33.33 milliseconds. However, because the objects are moving between the physics ticks (ideally tied to the screen's refresh rate - IE.: VSync enabled), there won't be a sense of delay.
The interpolation can be disabled and the smooth node basically do nothing. If you set the
Enabled property to false then the interpolation will not be used and the smooth node will snap into the target (the parent node), which will then result in the visual representation also snapping into the physical state.
Obviously you can manipulate this property from code:
# Disable the smoothing of the visual representation $character_node/Smooth2D.enabled = false # ... some code # Enable the smoothing again $character_node/Smooth2D.enabled = true
If desired you can teleport the smooth node into the specified transform, which can be very useful when an smoothed object is spawned and its initial position is not in the world's origin:
# Teleport smooth node into the character's transform $character_node/Smooth3D.teleport_to($character_node.global_transform)
There is a shortcut function within the smooth nodes that can be used when the desired teleportation transform corresponds to the smooth node parent:
# Teleport smooth node into the character's transform $character_node/Smooth3D.snap_to_target()