This is my node config

When I try to play the scene this happens

Hi!
This addon is incredible, the movement of the character and other objects has become much smoother. However, I have a problem, where I hide an object, but when I make it visible again, for a moment, the object appears in the last position where it was seen before being hidden and then immediately moves to the correct position.

On 22 seconds, you can see that. The video is in slow motion.

I have a problem: the addon is smoothing the character's "flip," which is the negative scale. I wish there was a way not to smooth this. Unfortunately, if I disable the option scale from inspector.. everything gets messed up. I saw that I can use Teleport to change the position without interpolation... But would it work for my case?

Sorry this isn't an issue, but I've been wondering for a long time if this addon does something different to the built-in physics interpolation in 3.5? If not, should they be used together?

I am using a customized version of Godot 4.1 and I had really bad jitter in a simple test project. I've found that this addon helps but it doesn't completely solve the jitter. Based on this screenshot of my player scene tree, am I actually using the addon correctly? Are there any tips for better results?

Hey lawnjelly, thanks for this great addon!
Had some issues in 4.1.3 with the plugin in 2d:
The smoothed sprite was several frames behind (input lag) and had stutters, which became really noticeable when i attached a ui label as child to the smoothed sprite. All this problems went away when setting set_process_priority(100) to 0 in smoothing_2d.gd's _ready() function.

Whats the reasoning for setting the process priority that low? Are there issues i could run into leaving it at 0? (edit: nvm, found the readme section about it)

For my project, I have included a crouching mechanic.

Crouching in many games will typically move the player directly downwards to compensate for the change in collision shape size, but doing this with the Smoothing node causes a very noticeable jitter.

Is there some kind of workaround I can implement to avoid this jitter when changing position instantaneously?

Scene causing the problem with smoothing node added:-

Script attached to Player node (Kinematic Body):-

extends KinematicBody
var constant_speed: Vector3 = Vector3(0, 0, -10)
func _physics_process(_delta):
    constant_speed = move_and_slide(constant_speed)

Output:-

Expected Output:-

As seen in the first output gif the player moves away from the camera which it shouldn't. The expected output is what it should look like.

The following scene without the smoothing node works as expected and gives the expected output:-

Seems to be some kind of infinite recursion bug in Godot 4.x. Shows when pressing space bar to teleport in the demo project.

I'm not sure at this stage whether it is a bug in Godot core or the addon. Needs investigating.

I have the following setup, a Sprite wrapped in a Smoothing2D that targets a KinematicBody2D. I also have a Camera2D with smoothing enabled, that follows the character. It is a child of the Sprite. This all works fine.

But I noticed issues when you also want to have something that follows the Camera2D rather than the player. In my case I wanted to have a Light2D right in the center of the screen, so I first tried setting this as a child of the Camera2D. Turns out the Camera2D doesn't actually update its position during smoothing, but I managed to work around that by attaching a script to my Light2D that compensates with the actual camera position that you can get in get_camera_screen_center().

This seems to work, but I noticed that the when the character quickly changes movement direction, the light seems to lag behind one frame. Here's a video of it in action

I figured the reason is probably that my script on the Light2D was updating before the camera smoothing and therefore using the old position, so I increased the process priority to ensure that it happened after, but nothing happened. It wasn't until I tried setting it to a ridiculously high value of 100 where suddenly - the issue was gone.

Turns out the reason is this line, which sets the process priority to an arbitrarily high value of 100, just like I did:

I'm not sure if there's a good fix for this. In my case, I realized that a better solution is probably to just place the Camera2D under the KinematicBody2D instead. It means that the camera smoothing will be completely separate from my character smoothing, but in my case that looks pretty good, maybe even better. And the Light2D follows at the center of the screen as expected.

Hopefully just by reporting this, someone might find this issue and be able to find a solution faster than I did. I have also attached a minimal project to test this.

camera2d-smoothing-demo.zip

Using more than one smoothing node does not make all affected nodes jitter free, and in some cases causes extra jitter,

With the new approach, not using TopLevel to solve issues in Ysort, I noticed that smoothing doesn't seem to work when snap options are active, such as Snap vertices and transformations. Previously, with Top Level, the jitter was resolved. Now, it seems that it's no longer rounding the sprite's position and causing visual jitter. I tested this on version 4.x. ~It seems that without top level, there might be some limitation, perhaps?

YSort is enabled properly on 'TileMap' node and 'Level' node. When dragging 'Player' node in the editor, the YSort seems to work. So it's only broken when running the game.

Minimum reproduction project: smoothingysortsetup.zip

(At least I believe that's how a minimum reproduction project works. First time doing this haha. Just everything stripped down to the bare minimum needed to showcase the issue I'm assuming.)

Hi, so as mentioned in my other issue I seem to have Jitter (I think) with a moving player.

Here is a video of what I mean. The sprite seems unsharp, almost filtered. Though it is not filtered. It looks like the position is slightly changing really fast. At the end of the video, I think from second 12 on you can see suddenly after moving the character a bit, the sprite gets sharp (actually, when starting the scene it's sharp and becomes unsharp after movement). This happens both when using toplevel and the default mode as shown on the screenshots below*.
https://github.com/lawnjelly/smoothing-addon/assets/9001667/3a04a6cf-4fd1-4fa9-a761-c02a3b01cc75

Any suggestion to prevent this?

*Tried these setups:

This would be the project I am testing this with:
testproject.zip

Hi there!

I'm trying to use the smoothing add-on in a top-down 2D setup, but this far I'm failing to make it work with a Camera2D that scrolls to follow the character.

I think I've setup the scene as documented (find MRP attached), no pixel snapping is enabled:

CharacterBody2D
|__Smoothing2D
   |__Sprite2D
      |__Camera2D

When both FPS and physics ticks are set at 60, everything looks good:

When reducing physics ticks to 20/s, stutter is very bad on camera scroll, it looks like Camera2D and Smoothing2D are fighting:

When setting the camera to run on physics, instead of idle, jitter is not that bad, but still very bad:

Smoothing the camera position fixes it! But forces to use a smoothed camera, which I didn't intend to (the recording doesn't actually show the camera's delay behind the character, happens in real-time play though):

As usual, setting Smoothing2D as toplevel fixes the jitter, but breaks y-sorting, which is a deal-breaker:

I've also tried to make Camera2D a child of all the other nodes, with the same result.

Is my setup wrong / am I missing something? Or is Godot 4.2's Camera2D known to break the add-on?

Thanks for your time and for a great tool!

(By the way, amazing pixel art by https://limezu.itch.io/!)

I have a player with a node structure like this;

and whenever i run the scene (or another scene that its placed to) no matter where i place the player in the editor the visual representative always starts at the origin, the collision shape as you can see remains at where i moved the player back in the editor, however the sprite always begins the scene at the origin, smoothing seems to work but it looks very weird and is unusable as sprite and the body are at different places.

Here is the sample project, you can run the "Testing" scene and see the issue yourself. (Sorry if i made a mistake and this isn't actually an issue but when i try the same thing at Godot 3.x it works fine)
SmoothingCharacterBody2DIssue.zip

To prevent mistakes (like I've done for so long…), we could probably disable the physics jitter fix automatically whenever this plugin is enabled. This means we'd be making the assumption that the smoothing add-on is used on all physics bodies, but it's likely the case in real-world projects anyway.

When using the 3d smoothing node on the head of my character, it works really well to smooth the movement instead of jittering at physics speed. The problem is :

Camera rotation is not updated in physics ticks!

When using a smoothing node before the camera, then rotations are smoothed rather than keeping their updated values between physics frames.

When disabling 'basis' on the smoothing node, rotation will not update with the parents, removing rotation altogether.

This makes setting up an FPS controller that doesn't have jitter very complicated.

Thank you so much for this addon, it works very well with the kinematic2D player, but my game is still very jittery because the camera movement. Is it possible to use the addon to smooth the camera?

i noticed that when spawning scenes that has this addon, at _ready it will always interpolate from the origin to the point you want the scene to spawn. i looked in the code and i replaced at line 36 this:

`var _m_Trans_curr: Transform2D = Transform2D()

var _m_Trans_prev: Transform2D = Transform2D()`

with this:

`@onready var _m_Trans_curr: Transform2D = get_parent().transform

@onready var _m_Trans_prev: Transform2D = get_parent().transform`

and so far it worked like a charm. for sure it's probably not the best way to go about it (probably), but i wonder if you could implement the fix in a way or another.
:)

I didn't know how to say thank you, so I'm creating an issue to thank whoever did it :)

Thank you for putting this together. It may be that I have not set up correctly as I don't see the addon doing anything.

physics set to 60 fps
Physics Jitter 0 to 0.5 --> no difference
Use VSync On --> no difference
Use VSync Composite -> huge difference for about 15 seconds then jitters, but less than without

I don't see that mesh connection like in 3D. So I just connected the player. Am I supposed to connect something else?
global in --> no difference
global out --> no difference

Did I set up something incorrectly? I don't see any differences with the addon on or off.

I see that the 2D node is using a home made _LerpAngle() function. What is the reason for not using the lerp_angle() builtin? Apart from that -- great work!

So I ran into the same issue as #7 and attempted to get around it by setting the Smoothing node as toplevel, but then realized that interpolation happens in local space for 3D nodes. Admittedly I don't know how feasible it would be to interpolate in world space (my math's not the best), and the workaround described in #7 (comment) does work, but it'd be nice not to have to reorganize the scene tree, especially for more complex scenes (not to mention changing a bunch of node paths).

The addon worked fine on Linux, but when I reopened the project on Windows I got this every game start:

Warning
Unable to load addon script from path: 'res://addons/smoothing/smoothing_plugin.gd’. This might be due to a code error in that script.
Disabling the addon at 'res://addons/smoothing/plugin.cfg' to prevent further errors.

If I open the Project Settings I can see the addon is disabled. Enabling it then re-disabling it confirms disabling and will stop showing the error. In this case you cannot Add more Smoothing2D nodes, but the existing nodes will still work.

So technically it shouldn't break exported games.

I know it's not common to attach a Control of a PhysicsBody2D, but I have a local HUD displaying life gauge near attached to my CharacterBody2D so it's convenient, and I need to smooth it or it will jitter relatively to my smoother character sprite.

(usually I'd use a Canvas Layer and manually move the gauge to match character, but it's more complex)

When you do so, you get a double assert error on start: _SetProcessing(): Condition "!viewport" is true on set_as_top_level:

Godot code:

func _SetProcessing():
	var bEnable = _TestFlags(SF_ENABLED)
	if _TestFlags(SF_INVISIBLE):
		bEnable = false

	set_process(bEnable)
	set_physics_process(bEnable)

	set_as_top_level(_TestFlags(SF_GLOBAL_OUT))  # here

Callstack:

E 0:00:01:0024 smoothing_2d.gd:110 @ _SetProcessing(): Condition "!viewport" is true.
<C++ Source> scene/gui/control.cpp:2984 @ _notification()
smoothing_2d.gd:110 @ _SetProcessing()
smoothing_2d.gd:57 @ @flags_setter()
smoothing_2d.gd:234 @ _ClearFlags()
smoothing_2d.gd:245 @ _ChangeFlags()
smoothing_2d.gd:121 @ _notification()

(this shows twice)

However, the Control is still smoothed correctly, although set_as_top_level failed, apparently because it's called again later.

Line 201 in smoothing.gd, it's the rotation part.
I solved the issue by adding .orthonormalized() at line 136 on the global_transform.
I think the problem come from this:

Player physics process:

var lerps = Math.lerp_angles(owner.rotation.y, Vector2(direction.x, -direction.y).rotated(1.57).angle(), 5.0 * delta)
owner.rotation.y = lerps

Math.gd

func short_angle_dist(from, to):
	var max_angle = PI * 2
	var difference = fmod(to - from, max_angle)
	return fmod(2 * difference, max_angle) - difference

func lerp_angles(from, to, weight):
	return from + short_angle_dist(from, to) * weight

The full error is:
E 0:00:18:0186 smoothing.gd:201 @ _process(): Basis must be normalized in order to be casted to a Quaternion. Use get_rotation_quaternion() or call orthonormalized() if the Basis contains linearly independent vectors.
<C++ Error> Condition "!is_rotation()" is true. Returning: Quaternion()
<C++ Source> core/math/basis.cpp:702 @ get_quaternion()
smoothing.gd:201 @ _process()

and the rotation get stuck until project close

Hey, so I've read the paragraf on toplevel multiple times but have not clue how to make it work. The basic setup of the plugin including use was pretty simple but toplevel - no idea.

So what works
(Additional node: No target explicitly assigned on the smoothing node)

How would I set this up for toplevel, to test ist out?

Sorry if that might be obvious, but I'm new to godot (not to development) and cannot seem to figure it out.

Cheers!

Edit: Kudos for the plugin btw.! This is essential.

Scene structure:-

• World Scene is the main scene where player and block scenes are instanced.
• Target for InterpolatedCamera node is CameraFollow node.

Player Script:-

extends KinematicBody
var constant_speed: Vector3 = Vector3(0, 0, -29)
func _physics_process(delta):
    constant_speed = move_and_slide(constant_speed)

Block Script:-

extends RigidBody
func _ready():
    linear_velocity = Vector3(0, 0, -29)

Output:-

As seen in the output the Small cube = Player (Kinematicbody) is causing jitter, the Bigger Block = RigidBody is fairly stable.

I tried putting the Interpolated camera as a child of Smoothing node which gives me the following result:-

Output:-

Here, the Small cube = Player (Kinematicbody) is smooth but the Bigger Block = RigidBody is causing jitter.

Now the problem doesn't exist if both bodies are Rigidbody.

minimal reproduction project:-
kinematic_smoothing_prob.zip

The problem

I created a simple little game but on some weak gpus (mobile) it does not run very well. This created a jitter. I tried to apply this addon to fix the issue but it did not work. After looking at the code a bit I think I found the problem. All in 2D, fps limited to 58, physics_fps is set to 60.

What I think is wrong

In the code the last frames that are used for the interpolation are updated in the process function via the RefreshTransform() function. This works perfectly if the game runs at a high fps with relatively slow physics. However this is problematic in case the visual process can run twice between two physics frames. In this case the previous and current positions are updated twice, effectively to the same value. This makes the object jump to the next frame, same as if no interpolation was applied.

My fix

For me, changing the code in a way that the positions are always updated in the pyhsics_process fixed the issue.

Is there a reason the updates are implemented inside the process function with flags signaling wether to use it or not? To me it looks like the flags only try to mimic the case where the physics_process function updates the positions.

Otherwise I really like this addon, it helped me a ton. Hope I could help.

I'm trying to make an infinite runner in Godot 4, however when I try to import, it says it can't. Furthermore, I look into the files, and many of them have Godot 3 syntax. This confuses me because others can run it on Godot 4. Can someone plz explain to me what I can do to fix? Probably a stupid question, I'm fairly new to Godot.

Since changing the smoothing nodes to be top level a few months ago, I hadn't noticed, but it seems that visibility from parent nodes is not propagated to top level nodes, and thus the smoothing nodes can't so easily be hidden except by hiding them explicitly.

This is kind of strange and it comes from the core source code, I'm trying to work out whether this is intentional in Godot (and should be fixed) or whether I should fix in the addon.

UPDATE:
Turns out the core CanvasItem visibility propagation is not propagated across toplevel nodes as of godotengine/godot#58870 .
This is presumably because the visibility in VisualServer is not inherited because they are parented to the toplevel node rather than the parent in the scene tree. But this means there is no notification for us to detect efficiently when the parent visibility has changed.

We might have to call is_visible_in_tree() every frame on the parent just in case it had changed. This is very inefficient.

Argg, this problem and the z sorting suggests it would be nicer to use the new use_identity_transform method for canvas items, but I only added this for core interpolation, and when that is available there is no need for the addon. 😆
Catch 22 situation.