Physics change between 3.2.3 and 3.2.4 RC5

[nightblade9]

Godot version: 3.2.4 RC4

OS/device including version: Windows 10

Issue description:
Just switched from 3.2.3 to 3.2.4 RC5 to fix a GPU issue. I noticed that physics changed. Specifically: I have a grid of KinematicBody2D objects, boxed in on all four sides by StaticBody2D. In _process, I apply something like move_and_slide(0, 100) to each tile. In 3.2.3, the tiles are stable; in 3.2.4 RC5, they twitch up and down, and break the boundary. (Could be my setup is bad.)

Here's a screenshot of the issue:

Here's a video where you can see the second-last column twitching near the bottom: https://imgur.com/a/obzu0Ty

[akien-mga]

Could you test other beta/RC builds between 3.2.3 and 3.2.4 RC5 to narrow down the release where the regression first happened?

If you can reproduce the issue in a minimal project that would be very helpful for debugging and fixing, but I can understand that it might not be easy to extract from your current code.

[nightblade9]

No problem, I'll take a look and see if I can do it. My code-base is fairly young, it shouldn't be a problem removing/deleting things until I get an MVP.

[nightblade9]

I tested RC1 and RC2, which look fine to me. RC3 seems to be the first version where this problem manifests.

Here's the MVP. I made the StaticBody2Ds 50% transparent so you can very easily see the overlap. Also, it seems like removing the top one doesn't do anything. Let me know if you need any clarification or further removal/refactoring/etc. of the code to make it easier to understand.

issue-47015-mvp.zip

[robertarnborg]

would also like to add that my kinematicbody2D are sliding down slopes with move_and_slide_with_snap since rc3 regardless of snapping to -normals on slopes etc.

[pouleyKetchoupp]

@robertarnborg Could you please open a separate issue for your case, with a minimum repro project? It will make it easier to track down and fix.

[robertarnborg]

sure thing 🙂

Bugsquad edit: Issue is #47042.

[pouleyKetchoupp]

@nightblade9 You can fix this issue by setting a collision safe margin of 0.01 on your tiles.

Some changes have been made in KinematicBody2D that work well with a character moving on the ground, but for a stack of kinematic bodies like in your setup the default settings are not ideal. Lowering the safe margin allows the kinematic bodies to separate from each other more accurately (at the expense of consistency in floor detection, which doesn't seem relevant in this case).

[nightblade9]

@nightblade9 You can fix this issue by setting a collision safe margin of 0.01 on your tiles.

Can confirm that this fixes the issue with RC5 and the MVP project. Can you explain a bit more about what this field is and how it works? I've never looked at it before, and the tooltip in-editor is a big vague.

Also: while my sprite is 32x32, the collision rectangle extents are 31.9x32. Is this correct, or is there a better way to do this?

@akien-mga is this considered a real issue, or should I close it now that I know the fix @pouleyKetchoupp mentioned?

[pouleyKetchoupp]

Can confirm that this fixes the issue with RC5 and the MVP project. Can you explain a bit more about what this field is and how it works? I've never looked at it before, and the tooltip in-editor is a big vague.

Glad it works for you! This parameter is used for collision recovery, it's the distance at which a kinematic body is testing if it's stuck and tries to get unstuck before performing the actual motion. A higher value means it's more flexible for detecting collision, which helps with consistently detecting walls and floors in most cases. A lower value forces the collision algorithm to use more exact detection, so it can be used in cases that specifically require it, e.g:

• High level of zoom on a pixelated game to avoid jittering.
• A stack of kinematic bodies (I'm discovering this case today with your setup) to prevent kinematic bodies from pushing each other from the top of the stack.

I agree the documentation could be more explanatory and should be improved.

Also: while my sprite is 32x32, the collision rectangle extents are 31.9x32. Is this correct, or is there a better way to do this?

This is the correct way to get collision in sync with visuals with KinematicBody2D, the safe margin needs to be subtracted from the actual collision size.

@akien-mga is this considered a real issue, or should I close it now that I know the fix @pouleyKetchoupp mentioned?

I'll let @akien-mga confirm, but I think we can consider the regression solved, although I would keep this issue open until the safe_margin documentation is made clearer.