Insufficient processing of RigidBody in the physics engine (Bullet and Godot)

[DimitriyPS]

I sincerely regret that reports of perennial and unrecoverable bugs in basic mechanics of the Godot engine create problems and pressure on participants. However, I am forced to renew this: #44664. Obviously this is not a duplicate message and redirecting it to: #9071 was not constructive.

Godot version:

2.Х/3.Х/4.Х(?)

OS/device including version:

All

Issue description:

RigidBody objects fall through meshes of collisions of other bodies (StaticBody, KinematicBody, RigidBody) as a result of interaction with another active RigidBody (for example, the player stepped on or pushed an object) or other force applied to it.

When using Godot, RigidBody physics (not Bullets physics) with a small colision form can fail on their own or from the slightest interaction with any other object.

Steps to reproduce:

1. open the attached demo project;
2. open the project settings and set the physics (Bullet or Godot) that you will test;
3. run the project and select the player's body type from the menu;
4. Use the [o] and [p] keys on the keyboard to generate a SmallObject "Lid" and a BigObject "Figurine" (RigidBody);
5. Controlling the player, press the generated objects to the floor or walls (the simplest thing is to pinch the statues in the corner);

At the top of the screen, you can see statistics for SmallObject and BigObject in section: generated / fall out/ now in the scene.

I see the following result: https://vimple.co/ae96c02e0b99470e8a237412a19350a2

Minimal reproduction project:

TestPhysics.zip

More detailed:

My test results for insufficient RigidBody processing:

Processing of a BigObject occurs in both engines in the same way - the object does not fall through on its own, but when a force is applied from another object, it is easily pushed. The Bulet physics handles SmallObjects the same way. But the Godot physicist practically cannot cope with small objects at all - the vast majority of generated SmallObjects fail through on their own:

GodotPhisicKrishki.mp4

My test results physics engine performance (Bullet and Godot):

For the test, I continuously generate BigObject until the performance drops. The drop in performance occurs sharply, and not progressively as the number of bodies increases. In the system monitor of the OS, you can see that this happens at the moment when one processor core runs into 100% load. What is strange for me is that the render frames drop sharply (up to 6-8 frames per second and this indicator does not decrease with the continuation of object generation), while the physical frames do not change.

As for the performance of the two physics engines in terms of RigidBody processing, it differs by about two in favor of Bulet:

Bullet physics:

Godot physics:

[Calinou]

Try building the latest 3.2 branch and enable the new BVH.

[lawnjelly]

EDIT: The new BVH is for godot physics only. Bullet has it's own BVH.

Yeah the BVH should make godot physics quite a bit faster with large numbers of objects. It won't fix behavioural issues though (it might possibly improve it just a tad because there is a collision pairing expansion, but the expansion is fixed and small, I decided against having the expansion margin editable for now). In theory if all goes well, the behaviour should be exactly the same, just faster.

One possible problem with physics (aside from just normal tunnelling that is expected without CCD) is that when objects are moved in the broadphase, it uses AABBs to determine which objects are paired and I assume form collision islands. If one object bounces off another during an iteration and outside these AABBs it could potentially miss collisions. This is particularly likely to be a problem (like tunnelling) with low physics tick rates and high velocities, small objects etc.

I'm not familiar with the physics so can't say whether this is handled robustly, it may already be compensated for. In theory you would either increase the AABBs for pairing taking into account the velocities of the local objects (as a fast moving object could bounce a slower moving object), or you'd perform a separate collision broadphase for each bounce. It is a bit of a tradeoff between correctness and performance I suspect.

EDIT : Took a look at your project. There are some tricks to reduce tunnelling that are usually used. Usually you would make your walls / floor thicker, more like breeze blocks than carpet. If the wall is thin, then it is quite easy to push an object to a point where it thinks it is better off jumping out the other side.

Kinematic players will likely cause tunnelling problems. If you force a rigid body into a wall with a kinematic body is has to go somewhere. That is kind of the definition of how a kinematic body works.

BTW I'm not trying to suggest you will get a good result using a physics engine. You might be surprised at the number of games don't use a physics engine for character controllers like that. Or at least, not in the way you think.

[DimitriyPS]

Try building the latest 3.2 branch and enable the new BVH.

I'll unsubscribe on this later.

It is a bit of a tradeoff between correctness and performance I suspect.

This is not a level that can be considered a compromise. It's just not a working condition. In such conditions, it is impossible to use the simulation of the physics of objects.

Usually you would make your walls / floor thicker, more like breeze blocks than carpet. If the wall is thin, then it is quite easy to push an object to a point where it thinks it is better off jumping out the other side.

Yes, I also tested it. This can lead to the fact that the object gets stuck in the thickness of the collision grid of the wall and endlessly "twitches" there. And more... I analyzed the resources of some modern (and not very) games, they do not practice thick collision meshes. And nakots with the same Bullet I am familiar in other projects, and it does not allow you to immerse one body in another at the same time providing good performance.

Kinematic players will likely cause tunnelling problems. If you force a rigid body into a wall with a kinematic body is has to go somewhere. That is kind of the definition of how a kinematic body works.

Yes, I know, but I suggest both body types for the test. I also take this body from the official example in order to proactively remove potential questions.

[slapin]

Well, to me it looks like lack of collision force between objects because normally trivial cases are handled in single frame directly and I observe that if smaller object sunk into bigger one it takes lots of frames for them to separate. This also happens in large Kinematic vs Static collisions which lead to heavy CPU consumption and freeze/low fps from one collision. Something is wrong with engine tuning or some missing tuning handles (this doesn't happen when playing with Bullet demos).

I agree that this behavior is fine with kinematic body and in this case it should be handled with other means, but rigid vs rigid case as well as kinemativ vs static sound phishy.

[slapin]

BVH change does not affect Bullet physics (Bullet uses its ovn BVH independent of Godot's). However, testing on recent 3.2 with BVH merged did not produce any difference on my side (I do not use Godot physics though and did not test it).

[mrjustaguy]

The BVH option is for Godot Physics only...

[DimitriyPS]

Try building the latest 3.2 branch and enable the new BVH.

@Calinou, I tested on Godot builds: 8f265e8, I tested Bullet and Godot physics, no difference. The error is repeated with the same ease.

[DimitriyPS]

I will add one more demo for tests, simpler but perhaps even clearer. It also uses thick collision meshes as suggested by @lawnjelly. Thick collision meshes give more resistance, but this does not negate the immersion of some bodies in others; this behavior highlights the error more clearly.

TestPhysics_2.zip

[o], [p] - generating objects;
[a], [d] - piston control.

[dedm0zaj]

Godot 3.4 2D

Cubes fall normally at standard settings, but slowly. To accelerate the fall, the Default Gravity is set to 980 (instead of 98), but physics cannot cope with these settings.

2021-11-26.17-42-14.mp4

Minimal project:
test_phys2d.zip

[slapin]

Physics is discrete, you should check your bodies won't run away through collisions too fast so un-penetration force will work.
If this happens with normal speeds, it is a bug.

[Calinou]

@dedm0zaj This is a known issue, which you can work around by increasing Physics Fps to 180 or 240: #2092

[Calinou]

The minimal reproduction project uses infinitely thin walls and floors for collision, which isn't advised if you want robust physics (and lighting – see below).

Adding a StaticBody with primitive BoxShapes around the walls and floor fixes the issue without having to alter level geometry. I tested this with both RigidBody and KinematicBody, on both Bullet and GodotPhysics – objects will no longer phase through the walls and floor.

That said, I recommend adjusting your level geometry so that walls and floors have some thickness to them (ideally as much as possible). This will also fix some light leaks when baking VoxelGI and lightmaps.

Minimal reproduction project with primitive shapes added: TestPhysics2.zip