The engine doesn't store anything it doesn't use internally, so the only place contacts are 'stored' is a processed version in the solver's prestep data.
Custom INarrowPhaseCallbacks can be used to collect contact information as it is generated by the narrow phase. Some demos, like the ContactEventsDemo and TankDemo, use the callbacks to collect information about contacts.
The ContactLineExtractor in the DemoRenderer takes the processed version of constraint prestep data and uses it to visualize contacts and joints. It works, but it's pretty much the lowest level option possible.
More recently, IDirectContactDataExtractor was added for extracting contact data from the solver. It's still very low level- it was added with the intention that other abstractions could be built on top of it without introducing intermediate overhead- but it is specialized for contact data, unlike the DemoRenderer utility.
An example of its use taken from one of my projects, where contactExtractor is an IDirectContactDataExtractor implementation:
Code: Select all
var body = simulation.Bodies.GetBodyReference(Sensors[sensorIndex]);
contactExtractor.Reset(body.Handle);
for (int constraintIndex = 0; constraintIndex < body.Constraints.Count; ++constraintIndex)
{
ref var constraint = ref body.Constraints[constraintIndex];
ref var location = ref simulation.Solver.HandleToConstraint[constraint.ConnectingConstraintHandle];
if (simulation.NarrowPhase.TryGetContactConstraintAccessor(location.TypeId, out var accessor))
{
accessor.ExtractContactData(constraint.ConnectingConstraintHandle, simulation.Solver, ref contactExtractor);
}
}
The basic idea is enumerating all constraints associated with a body, and using a type-specific contact accessor to parse the AOSOA solver data into a more convenient representation. The IDirectContactDataExtractor itself specifies what data it is looking for as properties (which, in combination with a struct type and inlining, will be considered JIT-time constants within the contact accessor, avoiding unnecessary work) and then has a bunch of callbacks for different types of data.
It's not the easiest thing to use, but it is pretty close to zero overhead and gives you direct access to the solver data in a type-aware way. I've been intending to create a demo showing how to wrap it in a more easily consumed abstraction, but I haven't gotten around to it.