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 https://github.com/godotengine/godot/blob/0ee0fa42e6639b6fa474b7cf6afc6b1a78142185/servers/physics_2d/space_2d_sw.cpp#L854 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.
madmiraal
commented
4 years ago
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 https://github.com/godotengine/godot/blob/0ee0fa42e6639b6fa474b7cf6afc6b1a78142185/servers/physics_2d/space_2d_sw.cpp#L854 and similar other lines, where the magic number
0.4is used to help scale recovery motion. Whencbk.amountis 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.amountinstead 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