BEPUphysics

Is there any way to reshape an entity without entirely reforming it?

Three cases of this:

Changing the scale : it'd ideally be possible to make an object bigger or smaller on the fly (in particular a MobileMesh)

Changing the bounds of an AABB : I'd like my AABB objects to be able to shrink and grow quickly

Changing the vertices in a mesh (uncommon) : a mesh might animate or something, and it needs to be able to update its shape in the faster manner possible. (Ideally an animated object would instead be built from AABB's jointed together instead of from raw vertex-based meshes - eck!)


... while I'm here, what's the proper way to make an AABB without using the soon-to-be-removed prefabs? What are the advantages of that method?

From my searches while trying to answer this, I encountered that doing the above might actually help the scaling issues, by using a TransformableShape.


As always, thanks for the amazing quality support on all my questions!

First, a warning across the board:
Resizing objects is not a physical operation. Any objects in collision with a resizing object will not feel the resize-driven 'velocity' of the surface, only the penetration error. This will cause collision against the resizing surface to be 'gooey' in appearance since it relies only on penetration recovery.

Objects support scaling in different ways. Some don't support scaling at all. BoxShapes, for example, can be scaled by just changing their width, height, and length. ConeShapes can be partially scaled by changing radius and height, but the cone itself does not support scaling such that the base becomes an oval. SphereShapes can have their radius changed, and so on.

By default, the MobileMeshShape does not support scaling. The MobileMeshShape was designed to be immutable to reduce some of the implementation complexity. You could work around this by forcefully changing the MobileMeshShape.TriangleMesh.Data. Then, you would need to:
1) Call MobileMeshShape.TriangleMesh.Tree.Refit() when non-topological changes are made, or Reconstruct() when the topology changes,
2) Update the MobileMeshShape.hullVertices, and
3) If it's a dynamic object, call UpdateEntityShapeVolume with the new volume and volume distribution.
This isn't a particularly fast process, and it would require changes to the source. Avoid it (and MobileMeshShapes in general) if you can.

Changing the vertices in a mesh (uncommon) : a mesh might animate or something, and it needs to be able to update its shape in the faster manner possible. (Ideally an animated object would instead be built from AABB's jointed together instead of from raw vertex-based meshes - eck!)

If the goal is to match collision shapes to an animated character, it would indeed be hugely faster and better to use simple proxy shapes like boxes. For example, it's pretty easy to get accurate hit detection with 15-20 hitboxes that follow the character's main bones. If they're just there for collision detection, they don't even require any complicated constraints- just make them kinematic and set their motion states accordingly, and make sure their collision rules are configured properly. I do this in a game that requires fine-grained hit detection.

... while I'm here, what's the proper way to make an AABB without using the soon-to-be-removed prefabs? What are the advantages of that method?

Check out the EntityConstructionDemo in the BEPUphysicsDemos for a full explanation and examples. Basically, just pass in a shape to the Entity constructor. The advantage is a vastly simplified API that has a cleaner split between collision and dynamics representations. Right now, there's about a dozen ways to do the same thing.

From my searches while trying to answer this, I encountered that doing the above might actually help the scaling issues, by using a TransformableShape.

TransformableShapes do indeed permit the linear transformation of other convex shapes. They add a tiny bit of overhead, though, and prevent things like boxes from using their special case collision detection routines.