Inconsistent results from collide_with_motion_and_get_contacts

[Pizzaandy]

Describe the bug

There are some cases where intersect_shape will find a shape but an equivalent call with collide_with_motion_and_get_contacts (aka shape_collide) won't.

To Reproduce

Steps to reproduce the behavior:

1. Find a list shapes with an intersect_shape query
2. Call collide_with_motion_and_get_contacts against each shape with the same parameters as intersect_shape
3. Observe contacts not being found in certain positions (note the contacts blinking in and out)

Expected behavior

Contacts found with collide_with_motion_and_get_contacts are consistent over time.

Environment:

• OS: Windows
• Version: latest
• Godot Version: v4.3
• Type: single 2d

Example project(zip)

mrp-collide-and-get-contacts.zip

[Pizzaandy]

I think this is actually a parry bug:
dimforge/parry#180

[Ughuuu]

Seems to be related to the epsilon value used in minowski sum (the _eps_tol value). Either allowing user (in this case godot-rapier) to set a higher eps for specific use cases, or increasing default value should probably fix this then.

[Pizzaandy]

I think this will have to be fixed upstream - there doesn't appear to be a way to configure this value

[Ughuuu]

Yes, of course, the upstream will have to allow the library user to configure that value. Doesn't seem like complicated change but will need to be tested that it indeed fixes this.

[Ughuuu]

Sure enough, multiplying the value by 100 instead of 10 fixes this. I wonder though if this would affect accuracy for 3d case though. Will leave it like this for now on both 2d and 3d, but at some point I might want to do a PR in rapier to have it configurable from rapier.

[Ughuuu]

https://github.com/Ughuuu/parry/pull/3/files#diff-ba19e4deda422123fcd9962ec1c1f38c05f409e025ebad604e38d8f1c37700e4R38 diff with change that fixes this.