Not sure on how to approach negative contact depths with triggers

[Kermalis]

Hello, I wrote in #328 that I was working with checkpoints as triggers. I am using ContactEvents straight from the demos. My trigger is a static box shape and I have a dynamic box shape which is the "car", using continuous collision detection.

I'm finding that the contact events report "started touching" 1 tick late, and rarely 2 ticks late.
Here is a sideways view of what I mean:

The first image is when I would expect the "touching" to start. The car's box is piercing into the trigger box slightly (and each time I try this with different angles).
The second image is when "touching" begins, because of the positive depths on the contacts. However this is too late.
The only time it is "on time" is if I start the simulation with the dynamic box inside of the static box already. Then it reports touching immediately. But in these examples, I'm coming at the trigger from the sides, which is when I'm getting the negative contact depths.

I am just wondering why the first image is reporting negative contact depths? And if I should consider using "contact added". The ContactEvents demo properly reports that as a "ContactAdded" which I can also use. I'm just trying to learn what the difference is and when I should use each event, since I'm not clear on what a negative contact depth is representing. I assumed it was for speculative contacts, but that's not the case. I tried looking around the documentation and manifolds but couldn't find an answer.
I'm also curious why there are 4 contacts here. Where are they coming from? There is a "floor" but I'm ignoring those manifolds when debugging this problem, so this is purely between the trigger and the car. Sometimes there are even 0 contacts in the manifold, which I'm not sure what the purpose is either.
And last question, is any of this affected by the type of ContinuousDetection I choose?
This also happens when I use a custom mesh with duplicated+flipped verts, as I explained in #328.
Again, I'm on 2.5.0-beta.23 in case that's relevant.

[RossNordby]

Negative contact depth corresponds to separation at the time of the collision test and is indeed used in speculative contacts.

Collision testing occurs at the beginning of the timestep, and pose integration occurs at the end (sort of; substepping does a bit of position integration for each substep). I suspect what you're seeing is just the fact that poses are integrated forward in time relative to the contacts.

This is more noticeable for triggers because there's no solved constraints to stop intersection, and there's no impulse to use for detection of impact. If you'd like, you could modify the depth by taking into account the relative motion of the bodies at the contact point (like this, but you could use nicer non-AOSOA math to do it.)

Four contacts would be the typical number of contacts for a box-box collision. The contacts can be thought of as bounding a contact patch where the objects are in touching. For triggers, this intuition doesn't work as well because extreme penetration is typical. Zero contacts can make sense if all the contacts were more distant than the speculative margin, though why the manifold would be reported would depend on other details.

And last question, is any of this affected by the type of ContinuousDetection I choose?\

It would change which speculative contacts are generated sometimes. If you enable swept CCD, it'll use a sweep to find contacts rather than using closest contacts alone.

[Kermalis]

Alright, after reading your answer a few times I understand what's happening now. I'll break it down just to see if it's all correct.

Essentially the collision detection happens at the start of the tick. I assume this is because the user may teleport things into each other outside of bepu and you need to solve them first before moving the bodies. Since the ContactEvents demo class is called from the NarrowPhaseCallbacks, we're also getting these contacts from the start of the tick, which may include speculative contacts from the velocities at the start of the tick, resulting in negative contact depths if they're not yet penetrating. In the contact events demo, you create particles whenever a contact manifold is created, regardless of depth (which may result in false positives if I'm understanding it properly, or are the contacts only generated if they're guaranteed to collide in this tick?)

The PoseIntegratorCallbacks just changes the velocities for bodies based on our needs, and this happens for each substep, but after contacts are dealt with. If collisions are enabled, I assume each substep would also affect velocities based on the collisions. This is obvious, but I'm writing it because I believe we can prevent the start-of-tick velocity from moving the body by exactly that amount, even without collisions.

Since I'm deferring the ContactEvents events to call my callbacks after the Simulation.Timestep(), I'm getting contacts correctly from the start of the tick, but I am processing them at the end. This is why I'm getting this behavior; the body has moved into the trigger any time during this physics tick, but I don't have contacts for the new position of the body, I have contacts for the old position.

So assuming that's all correct, I understand you're suggesting that in the case of triggers where we know there will be no collision, I should consider something like PenetrationLimit.UpdatePenetrationDepth(). It would give me an updated depth if I supply the start-of-tick body velocity, rather than the newly updated velocity? My only concern is that the car would be colliding with other things (for example, other cars or the ground) which may still provide false positives if it was prevented from entering the trigger instead of going directly into it uninterrupted. It's also possible but unlikely that gravity/damping in PoseIntegratorCallbacks can prevent the start-of-tick velocity from entering the trigger as well?

It may not be a definitive answer for whether they are penetrating at the end of the tick, (especially if the speculative margin is changed, lots of the assumptions around updating the contact depths can result in more false positives). Is there a way for me to perform a secondary collision test (with or without speculation) at the end of the tick? I think Sweeps are the answer..? The performance hit here wouldn't matter to me in this use case, especially if I can filter it to use the objects from these contacts I collect at the start.
I can't rely on a simple box-box test if I change the checkpoints to use a custom mesh (which I'm going to end up doing) so I may need to do a Mesh/Box collision test in bepu, or create my own check if sweeps aren't the answer.

Sorry for the long messages, I know you're extremely busy and I'm grateful for your replies!

[Kermalis]

Since the contact events are too late for me, I decided to go with sweep tests. They work perfectly since I can run them at the end of the tick with the new positions for everything, and I can pass in 0 velocity with the arguments so it looks for exact intersections which is what I want.
Now I get the results I was looking for, and I can still use the other contact events from the demos for things like particles (which don't care too much about the rare false positives)

This was kinda a blessing in disguise since I am now further optimizing these checkpoints. For example, I can stop creating contact manifolds for the checkpoints completely, and thus also I don't need to "filter" my contact events to see if the contact was with a car rather than some other object. I can also simply not do a sweep test if the "car" is too far away from the center of the checkpoint, and If I'm "close" to the checkpoint, I can do the sweep test. Even if the sweep test determines they're not intersecting, I could do things like confetti or crowd ramping up since I know I'm approaching the checkpoint. Just overall the perfect solution for me, and I don't need to double-side the triangles of the mesh anymore since sweeps are bidirectional, which is great

Thanks again ross, I got there eventually lol