Complete easing for transform changes outside fixed time step #10
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Objective
Currently, changing the
Transform
of an interpolated or extrapolated entity outside of the fixed time step (e.g. inUpdate
) disables easing until the start of the next fixed time step. It effectively teleports the entity and interrupts easing.While supporting
Transform
changes outside the fixed time step is useful, this moment where easing is not applied has been a major source of annoyance for many users. It means that mutably accessing theTransform
in any capacity can cause visible stutter to movement. This negatively impacts cases such as:big_space
grid cell transitionsWe need a way to teleport entities without breaking easing.
Solution
Rework
reset_easing_states_on_transform_change
. Changing aTransform
in a schedule likeUpdate
will now teleport the entity such that the current eased transform matches the new target transform, but thestart
andend
easing states are updated such that the existing easing is still carried out, just from the new transform. This results in teleports that doesn't break easing.However, it also means that the end state of the interpolation won't perfectly match the value that the
Transform
was set to. I believe this is inevitable if we want the easing to be carried out smoothly. For cases where you do want a true teleportation without any easing (the old behavior), there is now aResetEasing
command. In a way, it is similar to Godot'sreset_physics_interpolation
method.Below you can see an object being teleported backwards by changing its
Transform
inUpdate
.2025-04-12.19-48-55.mp4
If we make the camera follow the entity, we see that the movement remains entirely visually smooth, and we don't even see the teleportation happening.
2025-04-12.19-49-23.mp4
Previously, the object stopped for a while whenever it was teleported.
Migration Guide
Changing the
Transform
of an interpolated or extrapolated entity outside the fixed time step, such as inUpdate
, no longer interrupts easing. This allows things like:big_space
grid cell transitionswithout any visual stutter.
However, a side effect of this is that the
Transform
of the entity may not perfectly match the value it was set to after easing has been completed for the current time step.To teleport an entity without any easing, or to otherwise temporarily disable easing, you may use the
ResetEasing
command.