Hi, I’m trying to get nphysics working with amethyst, which uses specs. I noticed in https://www.nphysics.org/rigid_body_simulations_with_contacts/ it said that you could provide your own BodySet/ColliderSet/etc implementation for ECS integration. I’ve tried that out by creating a BodySet implementation with Entity (an ECS “handle”) as the handle and is essentially a wrapper around an ECS component that contains a Box<dyn Body<f32>>. The main ECS handles storage of the components, rather than DefaultBodySet. But due to lifetimes each frame ends up constructing its own MechanicalWorld, GeometricalWorld and the wrapper BodySet.
The alternative is to keep the nphysics world and the rest of the world separate. To figure out which specs Entity an nphysics body corresponds to, you would embed an Entity inside the user data for an nphysics body. That’s kind of ugly, and I believe that using Entity as the handle for BodySet is much cleaner. You also need a mapping from an Entity to its corresponding Body by keeping a handle to the Body as a component of the Entity, for example to keep track of what’s been removed.
I’m having trouble getting this working due to lifetimes, but ignoring that fact, are there significant performance downsides of creating a new MechanicalWorld and GeometricalWorld every frame as opposed to keeping one around between frames (is there any sort of caching)? Intuitively, any idea as to CPU and memory tradeoffs between constantly translating between the nphysics world and the rest of the world versus creating a brand new MechanicalWorld and GeometricalWorld on every frame?