2D platform physics collision jitter

[rick551a]

Godot version: 3.2.4 beta6 (mono)

OS/device including version: Win10 Nvidia 1650

Issue description:

Tested a simple 2d platformer, the player is unable to jump and continually jitters up and down, almost through the ground.

Worked fine in 3.2.3 (stable) mono.

Steps to reproduce:
Open project, run, move left right, try to jump.

Minimal reproduction project:
This simple project by heartbeast:
https://github.com/uheartbeast/simple--heart-platformer

[Calinou]

@rick551 Can you reproduce this in 3.2.4beta5?

cc @pouleyKetchoupp

[pouleyKetchoupp]

Confirmed regression from #42574.

[rick551a]

Apologies for late reply, the issue was not in 3.2.4beta5.

[pouleyKetchoupp]

@rick551a Could you check that everything works ok again if you set a safe margin of 0.01 on the KinematicBody2D?

When working with pixel art / low screen resolution, the scale you use for motion is lower (including gravity), so a lower safe margin is needed for collision algorithms to work properly.

There used to be a workaround in move_and_slide that helps with floor detection in this case, even with the default safe margin, but it had to be removed as part of #42574 because it was causing issues in some other cases.

[rick551a]

Hello, just tested the heartbeast example (linked above) with 3.2.4 rc1. Ok, here is the report:

with physics_fps=60 and safe margin=0.01 works fine
physics_fps=60 safe margin=0.001 cannot jump consistently player continually bouncing on platform whilst resting
physics_fps=144 safe_margin=0.01 player can jump but does quick bouncing for few miliseconds after landing
physics_fps=144 safe margin=0.001 player cant jump, continually bounces on platform

If you test this example, it is important to diagonally jump and move around to really see the issues.

[rick551a]

@pouleyKetchoupp

Just uploaded a video to show the jitter after landing with physics_fps=144 & safe_margin=0.01 (video quality is bad, just 30fps but you get the idea)
https://vimeo.com/506193456

[rick551a]

After some testing, i now see that with physics_fps=144 & safe_margin=0.005, it works as intended.
So, as the physics_fps goes up, the safe margin must be reduced proportionally?
Thanks @pouleyKetchoupp

[pouleyKetchoupp]

@rick551a Thanks for testing all these cases! It makes sense to set the safe margin depending on the physics fps, because at higher fps the distances in each step will be reduced and again the algorithm is not adaptive.

Note for the physics team:
I'm keeping this issue open for now, as we can still improve the algorithm to be more adaptive and/or update the doc.
As discussed in PR meeting, test_motion_min_contact_depth could be also dependent on the safe margin for the algorithm to be more robust.

[Zireael07]

Unless the fix would be very fast (as in the next version, 3.2.4 which I understand is already at RC), docs should be updated to mention the relationship between (increased) fps and safe margin.