Clarification regarding penetration and narrow-phase callbacks

[Grimelios]

Hello!

To render objects in my game engine, a 3D model follows its associated physics body. I noticed that certain objects (say, a box falling to the ground) visually clip into the ground for a single frame, with the magnitude of the clip dependent on velocity. The image below demonstrates the problem.

https://imgur.com/uddckLE

The left column ("Expected") matches my understanding of how Bepu's narrow phase works. On frame 0, the box is still airborne and falling downward (fast enough that it'll hit the ground next frame). On frame 1, the box penetrates the ground (with whatever depth), then Bepu resolves that collision by pushing the box back up and out. Assuming no bounciness, I'd expect the box's resulting position (i.e. its position after the simulation step completes) to be resting comfortably on the ground. In other words, there's never a frame where the box remains overlapping the ground.

The right column ("Actual") demonstrates what's actually occurring. Frame 0 is the same as above (the box is airborne and falling fast enough to hit the ground next frame). On frame 1, the box partially penetrates the ground, i.e. it's still clipped into the ground after the simulation's step completes, without calling into narrow-phase callbacks. On frame 2, Bepu resolves the collision by pushing the box up and out. To reiterate, narrow-phase callbacks for the box are not called until frame 2.

Given this reality, it's clear why 3D models visually clip beneath the ground for a single frame (they're correctly following their associated physics body, which itself clips into the ground for a single frame). I've tested with both kinematic and dynamic objects.

I'd like to clarify whether my understanding on Bepu's collision resolution is accurate. If so, then so be it. If not, then it's likely I've made another mistake and can continue investigating.

Note that this question is not about continuous collision detection. The box is plenty large enough and moving slowly enough that it doesn't come close to tunneling through the ground's plane. I even turned on CCD as a sanity check and the results illustrated above didn't change.

Thank you!

[RossNordby]

In isolation, the behavior of the body in the image makes sense; all contacts are configurable springs. Softer springs will allow more overlap upon collision.

But if the body's velocity was modified during a frame by a collision, then contacts must have been created, and if that's the case, then narrow phase callbacks should have fired. Contacts can have negative depth during the callback (so-called speculative contacts) and still change velocity if the incoming velocity is high enough that the contact would be activated at some point over the next timestep.

1. Is it possible the narrow phase callback implementation is filtering out reports of negative depth?
2. Are the speculative margins of the involved collidables configured to have very low maximums (e.g. 0) such that negative depth contacts cannot be created? (This still doesn't explain why frame 1 would show penetration without any contact report.)
3. What version is this?
4. Can you reproduce it in the demos?

[Grimelios]

Appreciate the quick response.

1. Good thought, but no. I've set breakpoints on the very first line of all narrow-phase callbacks and they're not hit until a frame too late.
2. I don't believe speculative margins are the cause here. My default is 0.1. I've also tried 0, 0.5, and all the way up to 1.0 with no change ("no change" meaning the narrow-phase callbacks still aren't called until a frame too late).
3. 2.4.0.
4. I'll work on reproducing in a smaller demo.

To verify my observations (and be a little more specific), the "ground" from my image above is at Y = 40. Using a sphere with radius 1.0 that begins airborne and falls straight down (and assuming the ball is laterally above the ground, i.e. doesn't hit a triangle with a glancing blow), that ball should logically land at or below Y = 41 (plus speculative margin). What I've determined is that after a simulation step, the following are true:

1. The ball's Y position is well below 41 (closer to 40 actually, given its falling speed), so penetration definitely occurred. The ball does NOT tunnel through the ground.
2. The ball's Y velocity is still negative. That means that your statement above makes sense: if the body's velocity was modified by a collision, then contacts must have been created. Since the velocity wasn't modified by the collision, it makes sense that contacts weren't created, which explains why the narrow-phase callbacks aren't called.

So that seems to be the crux of the issue. For some reason, it's seemingly possible for an object to penetrate another (even with relatively large depth), but no contacts are generated. I recreated the issue with the ball falling onto a box as well (rather than a mesh). As I said, I'll work on creating a smaller demo.

[Grimelios]

Here's a sample project that reproduces the issue: https://github.com/Grimelios/Bepu/tree/main/Bepu

There are three relevant files in the project:

1. Program.cs, responsible for creating the simulation, creating a static box, creating a dynamic sphere, then stepping the simulation until the sphere penetrates the box.
2. NarrowPhaseCallbacks.cs, which contains narrow-phase callbacks. All implementations are "empty" except for one, which simply tracks whether the function has been called.
3. PoseIntegratorCallbacks, which contains pose integrator callbacks. Uniform downward gravity is applied to the sphere.

When run, the sphere penetrates the box BEFORE any narrow-phase callbacks are run. I verified this using both console output and breakpoints within all narrow-phase callback functions. Hopefully I'm simply misunderstanding something.

[RossNordby]

1. In the reproduction, no contact is created prior to visual penetration because the sphere moves 0.22 units within a single timestep, which is larger than the configured maximum speculative margin of 0.1.
2. The reproduction is detecting "penetration" by adding speculative margin onto the radius, which isn't correct.

By the way, with 2.4 and up, you can almost always just leave speculative margins at float.MaxValue (which is the default when no margin is provided). The effective margin scales with velocity automatically.

[Grimelios]

Thanks so much for the help! Leaving the speculative margin with its default value works like a charm.