Persisted Contacts not... persisting?

[SSNTails]

From what I understand about OnContactPersisted, I would expect to receive a call to it on every update of the physics system. But it seems like I only receive OnContactAdded on the first time the player makes contact, and then OnContactPersisted is never fired. The player is a dynamic sphere in this case, and the mud plane is a kinematic triangle mesh sensor. Am I misunderstanding how this works?

I also created another kinematic triangle mesh object for testing, and when the mesh is solid, the persisted event constantly fires, as expected. But when set as a sensor, it is unreliable, even when the dynamic sphere is obviously intersecting the triangle mesh.

Using v4.0.2.

[MrOnlineCoder]

Sorry for offtopic, the game looks nice, wanted to ask did you use 1 shape for your terrain/level or something else?

[SSNTails]

Static world geometry is one gigantic static mesh in the physics system - for rendering, it is sorted and batched by material.

[cuppajoeman]

I also do this: https://github.com/opengl-toolbox/physics/blob/5bc7e829f1935f003168d79d9379495dcd717254/physics.cpp#L77

There's also an example of loading a map it in the demos for the Character class I think it's in CharacterBase.cpp or something like that (in the Jolt source code)

[jrouwe]

As long as the object doesn't go to sleep, you should receive an OnContactPersisted every frame for a dynamic (!) rigid body vs another rigid body. In this case you're using a mesh shape which has no concept of inside and outside, so unless your sphere is intersecting with a triangle of the mesh (which I cannot see from your screenshot) you will not receive any callbacks (but I'd expect you to at least receive an OnContactRemoved).

[SSNTails]

Yes, the sphere is intersecting with a triangle of the mesh, it is easiest to see in the second screenshot (look at the sphere position, and where the player gets clipped by the mud plane). While this image was taken while the player was at rest, if I have the player move within the mud, ContactPersisted is still not called. Is there a way I can try 'waking up' both bodies to make sure it doesn't have something to do with sleep?

[jrouwe]

BodyInterface::ActivateBody or set BodyCreationSettings::mAllowSleeping = false.

There's one more thing that may be the cause of this: If I remember correctly, back facing triangles (i.e. center of sphere is behind the triangle) would also result in the collision being ignored.

[SSNTails]

There's one more thing that may be the cause of this: If I remember correctly, back facing triangles (i.e. center of sphere is behind the triangle) would also result in the collision being ignored.

Just tested this by lowering the plane a little bit -- this is exactly what's going on! Is there any remedy for this?

[SSNTails]

I can understand for solid objects, but with a sensor though, getting stuck doesn't apply, does it? Or are there other issues with making a special exception for sensors?

In this particular case, I can build this mud plane as a convex shape, but I was hoping to be able to not have to edit level geometry when converting to Jolt.

[jrouwe]

The point where Jolt decides if a body is a sensor (based on a callback) is after collision detection is done, so that's not really a possibility.

[SSNTails]

OK, thanks. I suppose this limitation also applies when doing shape casting? Will a sphere just slightly behind a triangle mesh but intersecting it (even if the radius of the sphere is very large) not trigger any contacts from the cast?

[jrouwe]

In this case you can choose, see: ShapeCastSettings::mBackFaceModeTriangles.

Now that I think of it: You don't need to use sensors in this case, you can also every frame do a CollideShape check with CollideShapeSettings::mBackFaceMode = CollideWithBackFaces of the sphere vs the world (and the preferably with a layer that only collides with these mud plane meshes) to detect overlaps. This would probably result in a similar performance compared to using the sensor.

[SSNTails]

Awesome, this is all good information to have in my back pocket. For this level, I converted them to convex hulls and they worked really well. If I end up with a situation where I know a convex hull isn't going to work, I'll be able to try the CollideShape method. :)