Godot Physics performance drop on ConvexPolygonShape RigidBody contact

[fathonyfath]

Godot version

v3.4.2.stable.official [45eaa2d]

System information

Windows 11, GLES3, RTX3060TI [511.23]

Issue description

At the moment the rigidbodies contact, suddenly the performance going bad with the physics process takes 200ms.
It also looks like the rigidbodies stick to one another.
This doesn't happen when I'm using Bullet physics.

Steps to reproduce

Project default settings is using Godot physics.

1. Run the project
2. Press space to start spawning rigidbodies
3. On my machine, as the third rigidbody made a contact with already falling rigidbody, physics process getting slower

Meanwhile switching to Bullet physics on the project settings, it can handle the physics process more stable.

Minimal reproduction project

physics-benchmark.zip

[Calinou]

Related to #48587.

I can confirm this on 3.x 49df809.

The RigidBody's convex collision shape is made of 78 points, which I feel is fairly high for an object with such a simple shape:

However, performance dips as soon as the first RigidBody touches the StaticBody, so this is unexpected.

Replacing the convex collision shape with a BoxShape solves the performance problem, even when there are dozens of RigidBodies. Collisions won't be as accurate, but for the mesh provided here, it gets close enough.

Minimal reproduction project with BoxShape: physics-benchmark-box.zip

I ran a profiler on a 3.x debug build, here are the results:

Top functions (inclusive)

Top functions (self)

Flame Graph

Flame Graph (bottom-up)

perf data: perf.data.zip

[gg312]

Same issue on master 4dc8214

[TideGear]

Still an issue on v3.4.4.stable.official [419e713].

[brundonsmith]

I'm seeing this issue in v4.0.alpha13.official [59dcddc45]

[Calinou]

I recommend testing #63702 locally to see if it fixes this issue.

[fathonyfath]

It looks like that fixes the issue, however, now the bodies jitter and seems cannot go to its resting state. But I think that is out of the scope of this issue. Thanks!

I made new project for the 4.0 for the testing. On unrelated notes, the 4.0 default graphics already looking really good. Kudos to the team!

physics-benchmark-2.zip

[Calinou]

however, now the bodies jitter and seems cannot go to its resting state

See #62819 and #61827.

[fathonyfath]

however, now the bodies jitter and seems cannot go to its resting state

See #62819 and #61827.

Noted, since that is already tracked on a different issues, it means we can close this issue, right?

[Calinou]

Noted, since that is already tracked on a different issues, it means we can close this issue, right?

This issue should be kept open, as this is a different issue from #48587 (which is for kinematic bodies) and the linked PR hasn't been merged yet.

[peastman]

In this case, the jittering might be partly the fault of #63702. The MPR algorithm doesn't precisely determine the separation axis, and hence the collision point. It creates a portal defined by three directions and iteratively refines it. The way it was described in the original article, it stops as soon as it can prove there's a separating axis somewhere inside the portal. The article suggested a way to estimate approximate collision points. That's what I originally tried, but I found it didn't work with the collision resolution code in Godot. The collision points were too unstable, causing things to jump all over.

When I implemented it in Simbody we used a different approach. We needed very precise collision points for a variety of analytic shapes. So we used MPR to estimate the collision points, then followed with Newton iteration to refine them to numeric precision. But that requires colliding shapes to provide extra information that isn't available in Godot, like the radii of curvature at an arbitrary point on the surface.

So instead I settled on having it continue iterating with MPR until the portal is sufficiently small to give an accurate estimate of the axis. I empirically chose some criteria that seemed to work in my tests:

if (extra_iterations == 5 || (dir1.dot(dir2) > 0.995 && dir2.dot(dir3) > 0.995 && dir3.dot(dir1) > 0.995)) {

It's possible they're still a bit too loose. Try increasing the threshold on the dot products a bit, maybe to 0.999. You might also need to increase the limit on extra_iterations a little.