Recommended method for Compound Body shape addition/removal?

[Spankenstein]

If I would like to add or remove shapes from a CompoundBody each frame.

Currently I do the following:

- Remove the old compound body from the space
- Create a new list of CompoundShapeEntries
- Create a new CompoundBody from the new list and add it to the space

This seems a little slow. What would you consider a better approach?

[Norbo]

The CompoundHelper was added in v1.0.0 to help with the splitting of compounds, which amounts to removing pieces from one compound and putting them in another. The technique it uses is to leave the shape itself alone, quickly remove child collidable instances from one compound, and put those collidable instances in the new compound. This approach allows many compounds to share the same shape will all having different subsets of the original immutable CompoundShape's children. It ends up being very fast and convenient in fracture simulation.

It does not explicitly support adding new elements to a compound since that's not something used by the fracture simulation. It wouldn't be too hard to add back in a missing collidable instance to a compound using a similar method, so long as the missing collidable corresponds to a shape in the original compound shape. It would likely require some fiddling in the source (CompoundHelper/CompoundCollidable) right now, though.

Adding an element to a compound that is not in the compound's shape would require a new compound shape. I chose not to implement support for mutable CompoundShapes because shapes can be shared between multiple collidables. There's not currently enough information present from a ShapeChanged event to efficiently and intuitively update all associated collidables. Most of the time, CompoundShape changes are associated with a single CompoundCollidable anyway, so it's easier to handle it from the CompoundCollidable side of things.

Depending on the shapes composing the compound, the largest cost of the compound-changing process can be dynamic data recomputation. This is bypassed in the CompoundHelper by using the CompoundShape's ComputeChildContributions. It can very efficiently recompute the center of mass, volume, and inertia tensor using the cached values. You could use a similar approach to efficiently rebuild the physical data and provide it to the entity directly, without it having to recompute it naively.

The remaining cost is the hierarchy reconstruction, but for anything below a large number of elements (a few hundred on Xbox360, a few thousand on Windows) the hierarchy reconstruction is pretty speedy. It's not too noticeable during intense fracturing, even. The GC pressure should be controllable as well, though it could become an issue if new compounds are being made every frame on the Xbox360 or something. Garbage could be reduced by using a scheme similar to the CompoundHelper methods which take pre-existing 'output' compounds and fill them up with also pre-existing collidable data. This can be used with pooling if necessary.

[Spankenstein]

Garbage could be reduced by using a scheme similar to the CompoundHelper methods which take pre-existing 'output' compounds and fill them up with also pre-existing collidable data.

This sounds good Thanks.