You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When a KinematicBody2D collides with a group of bodies of a large enough number, its recovery step in trying to get unstuck can lead to a too large of a recovery motion where its original velocity will not even lead to it colliding in that step. This results in visually apparent jittering and non-continuous collisions when using move_and_slide to slide along a row of bodies, such as a tilemap. This is due to the line in
and similar other lines, where the magic number 0.4 is used to help scale recovery motion. When cbk.amount is large, which is proportional to the number of shapes collided with, the recovery motion also becomes overly large. This can be solved here and in other places by dividing by cbk.amount instead of multiplying by 0.4, as seen in #36280, but can be its own pull request since it's not unique to one way collisions and probably also applies to 3D.
Steps to reproduce:
Create a kinematicbody2d long enough to collide with multiple other bodies, see that it over-corrects and leads to jittering of the kinematicbody2d.
Godot version: 3.2.1
OS/device including version: Win10
Issue description:
When a KinematicBody2D collides with a group of bodies of a large enough number, its recovery step in trying to get unstuck can lead to a too large of a recovery motion where its original velocity will not even lead to it colliding in that step. This results in visually apparent jittering and non-continuous collisions when using move_and_slide to slide along a row of bodies, such as a tilemap. This is due to the line in
godot/servers/physics_2d/space_2d_sw.cpp
Line 854 in 0ee0fa4
0.4
is used to help scale recovery motion. Whencbk.amount
is large, which is proportional to the number of shapes collided with, the recovery motion also becomes overly large. This can be solved here and in other places by dividing bycbk.amount
instead of multiplying by0.4
, as seen in #36280, but can be its own pull request since it's not unique to one way collisions and probably also applies to 3D.Steps to reproduce:
Create a kinematicbody2d long enough to collide with multiple other bodies, see that it over-corrects and leads to jittering of the kinematicbody2d.
Minimal reproduction project:
test tilemap collision.zip
The text was updated successfully, but these errors were encountered: