RossNordby
commented
5 years ago After adding an UnsafeManifoldViewer (8ee8de044f4ffe954fdfdba60af31dec73295eaa) for raw access with the intention of wrapping it in enumerators for ease of use, I've become increasingly dubious about pulling contact data from the solver.
- Contact callbacks provide manifolds in a convenient AOS layout and don't require an AOSOA unpacking step.
- Pulling contact data out of the solver only works for pairs which have actually generated constraints, so it's useless for 'detector' use cases.
- Users could easily be confused by the involvement of constraint handles when trying to request collision detection related information.
- The tendrils it creates are confusing enough even to me. It required an extension of ContactConstraintAccessors and an awkward per-constraint interface implementation. (Not that big of a problem since all the contact constraints are autogenerated, but it still adds cognitive overhead.)
The ContactLineExtractor in the demos shows a way of pulling contact data out of the solver for users interested in that sort of usage.
For now, I'm backing out the UnsafeManifoldViewer and focusing on the contact callback usability.
While the engine does not track collision data outside of generated constraints, a way to enumerate a body's existing contact constraints interpreted as contacts would be convenient for application logic. Contact mutability is a questionmark; contact callbacks are the best place for that logic, but we could still expose it in the enumerator.
It would also be nice to have an example in the demos showing how to use contact callbacks to capture collision information in cases where constraints are not being generated.