Check for collisions in simulation on demand

[OleksandrVdovychenko]

It is rather a question.
I have a system of rigid bodies controlled by third party code from outside. And I need to check if currently simulation has any collisions. I don't need any forces or inertia or checking physics every frame. Actually I don't have a frames ))) What is the best way to accomplish this task?
I assume the approach would be some kind of this pseudo:

_Setup simulation ('physical' bodies){
// load meshes, and create its physical representations
}

CheckForCollisions(bodiesTransforms){
Apply transfromations to all bodies
Find if there are collisions
}_

Could somebody give me directions to entry points?

[RossNordby]

There's two high level paths: completely external queries, or monitoring bodies in the simulation.

For queries, you request bounds overlaps from the broad phase, then submit the resulting pairs to a collision batcher to collect collision data. This exposes you to some of the more difficult to use internal APIs, but it does work. Check the collision queries demo for an example.

You can avoid some of that by instead adding bodies to the simulation for the things you want to track and then setting up INarrowPhaseCallbacks to match. That is: return true from AllowContactGeneration for pairs involving your 'detector' body, and return false from ConfigureContactManifold for pairs involving the detector to prevent it from generating constraints in the solver. ConfigureContactManifold will provide any detected contacts that you can then store out. Be careful about race conditions- INarrowPhaseCallbacks are called from worker threads, so you have to be careful that however you accumulate the results is thread safe. It's also called from within the collision detection routines, so try to avoid doing anything expensive in the callbacks to avoid skewing load balancing.

Which one is better/faster depends entirely on your use case; I'd suggest doing whichever one is simpler for you.

[LoveBumblebee]

I check the CollisionQueryDemo , BatcherCallbacks.OnPairCompleted:
if (manifold.GetDepth(ref manifold, i) >= 0)
{
QueryWasTouched[pairId] = true;
break;
}
this code just set query shape was touched,but i want know who touched the query,how can i do?

[RossNordby]

The CollisionBatcher itself doesn't know anything about bodies, so it can't directly provide you with that information. If you look at the AddQueryToBatch function, note that it takes a queryId that it then passes off to the CollisionBatcher to associate the results of the test to the query the test came from.

In the demo, it only cares about boolean results, but you could expand it. For each query added through AddQueryToBatch, you could set a value in an 'InvolvedCollidables' buffer (or similar) using the overlaps retrieved from Simulation.BroadPhase.GetOverlaps. Then, in the flush when all the collision tests are actually performed, you can use the queryId to look up the other collidable associated with the query.

Note that the INarrowPhaseCallbacks approach where you just stick things in the simulation and monitor them handles this part for you. You get a CollidableReference for both members of the collision pair as a parameter to the callbacks.

[LoveBumblebee]

If I understand correctly, Simulation.BroadPhase.GetOverlaps is just to get the objects that may collide the query based on the bounding box. The real collision judgment is BatcherCallbacks.OnPairCompleted function.

This means Simulation.BroadPhase.GetOverlaps may have multiple objects, but only part of the objects actually collide the query. but I can't get the collidable refrence from the parameter "pairId" in the function BatcherCallbacks.OnPairCompleted

[LoveBumblebee]

In addition, I think CollisionBatcher is better than INarrowPhaseCallbacks, because I don’t necessarily want to query every frame. With CollisionBatcher, I can use it conveniently when I need it.

[RossNordby]

If I understand correctly, Simulation.BroadPhase.GetOverlaps is just to get the objects that may collide the query based on the bounding box. The real collision judgment is BatcherCallbacks.OnPairCompleted function.

Yup.

This means Simulation.BroadPhase.GetOverlaps may have multiple objects, but only part of the objects actually collide the query.

Yup.

but I can't get the collidable refrence from the parameter "pairId" in the function BatcherCallbacks.OnPairCompleted

Right; so you'd need to store out the collidable references detected by the GetOverlaps. You could keep the list from the broad phase enumerator around, for example, and hand it to the BatcherCallbacks. You could then index the overlaps by the pairId, which here is the queryId provided in the AddQueryToBatch.

EDIT: Should clarify- in the current implementation, the queryId is always aligned with the query, so you get potentially multiple callbacks with the same pairId, but you can modify the value passed for the pairId to encode whatever values you want- that would let you do the lookup.

[vpenades]

Hi, sorry to jump into the middle of the conversation... what I think it could be useful is to have a high level API to check for geometry overlappings, without having to deal with the underlaying complexities of Bepu. Preventing people to having to deal with the lower level details also gives more freedom for reenginering.

My case might be similar to the one of @OleksandrVdovychenko ... In the future, I want to use the full simulation provided by Bepu... but one time after another, I find myself dealing with projects that have two requirements: A- Object location is defined by the client, not by the rigid body dynamics engine. B- I only need overlapping notifications (AKA, object 1 is overlapping with object 6) and at best, a crude separation vector ... so in most cases I end up rolling my own sphere-sphere collision check system.

@RossNordby Think of an arcade game, in which objects move around using predefined paths, or they're attached to function curves, and when objects collide, either disappear or explode. You really don't need to setup rigid bodies with masses and inertia tensors just to do that.

Actually, if I would be me, I would like to begin using Bepu that way, before diving into the deeps of rigid body simulations.

[RossNordby]

My preferred approach for those other use cases is more examples. The engine itself sticks to doing a restricted set of things well with a low-level API, and the examples show how those level things can be put together in more convenient ways. Layers, rather than just a broader core API.

What you're describing is basically a collision only system, which you could set up with a Tree and the CollisionBatcher without a Simulation. It'd basically be a much simpler version of the broad phase/narrow phase, and just a couple of steps more than the CollisionQueryDemo. I wouldn't include such a thing as a distinct feature in the engine, but I might make a demo that shows how you could put that together.

That such examples don't yet exist isn't because of an ideological disagreement with the concept of such demos, just the usual issues of an infinite todo list :P

[OleksandrVdovychenko]

Guys, thank you all for very constructive discussion! Ross, thank you for so detailed answers! Your answer to @vpenades is actually what I was looking for! So I marked it as an answer.