Is MobileMesh the best class to add a movable physics model into the scene?
When it is
absolutely required that the dynamic physics representation be a true triangulated mesh, yes, the MobileMesh is the best option. The only other possibility would be a CompoundShape of TriangleShapes, but that would lack some of the MobileMeshShape's specialized features like boundary smoothing.
For performance reasons, however, it is virtually always a better idea to use simpler shapes when possible. For example, if the shape of the model is basically two cylinders, create a CompoundShape from two CylinderShapes. This would easily be an order of magnitude faster than a fully triangulated racket.
Please note the positioning, scaling and collisions are all working with static meshes, cubes and spheres, but not with mobile meshes.
If you are using Entity.WorldTransform to apply scaling, note that entities are rigid, meaning their state is only able to represent position and orientation, not scale or shear. If Entity.WorldTransform is set to some matrix with scale in it, the scale component will be ignored and the orientation will probably end up wrong because of it. (That property is mainly there for convenience when reading data for graphics purposes; when setting values, using the Position or Orientation properties directly is usually more convenient.)
Scaling mobile meshes is done at the shape level on creation. When creating a MobileMesh(Shape), the constructor takes an AffineTransform. That 'local' transform is applied to the triangle vertices before applying the entity's position and orientation. This can be seen in action in the MobileMeshDemo inside the BEPUphysicsDemos. Fiddle with the scale parameter in the AffineTransform constructor to see the effect.
While testing with a bigger model, found out that collision too is working but the model is not getting drawn in desired location of the scene which results in a perception of collision not working.
So, if I am correct, this brings down the problem to setting correct center-of-gravity and applying correct world transforms. But the question is how to find perfect center-of-gravity for an object that is in tennis racket shape and how to set this in mobile-mesh object.
This is related to shape recentering. All entity collision shapes are centered on their center of mass. For simple primitives like spheres and boxes, this is enforced directly through the dimensions growing outward from the center. For more complicated shapes like the ConvexHullShape and MobileMeshShape, the shape constructor takes raw data, computes the center of mass for it, and stores a processed version of the data local to that center. These shapes have a constructor which outputs the center of mass that was computed by the constructor.
The center of mass output by that constructor can be used to compensate for the 'recentering' that the constructor did. For more information, check out the
shape recentering documentation.
Btw at this, wondering why BEPUphysics doesn't work out of the box w.r.t scaling and center-of-gravity with mobile meshes!
With regard to scaling:
-
Local scaling of the MobileMeshShape should work fine, as mentioned.
-Scaling and shearing at the Entity level are disallowed because they are not a part of the simulated dynamics. It is a rigid body simulator, hence rigid transformations.
With regard to centers of gravity, there were basically two options:
1) Recenter the data given to the shape to ensure that collision shapes are always positioned on their center of mass (the current approach), or
2) Just use the information as given to the shape without modification, and make it the user's responsibility to pick a reasonable center of mass.
#2 imposes requirements on the artists making the content or on the content pipeline. If the artist chooses a bad center of mass, the shape would fling all over the place relative to the Entity in a very unintuitive way. To avoid burdening the artist with something that could be automated very precisely, this approach would probably end up with some recentering operation applied in the content pipeline outside of the engine.
At that point, #2 becomes equivalent to #1 in end result, but #1 can make use of the fact that the shape already has to do a bunch of relevant processing to compute inertia tensors, and it avoids dirtying up the content pipeline with details of the physics representation. The physics-related work is centralized in the physics engine.
(Note that the collision shape can be offset relative to the entity by using the Entity.CollisionInformation.LocalPosition if you actually want an effective center of mass different from the analytically computed one, so #1 doesn't remove any freedom.)
Some other side notes that might be relevant to mesh collision behavior:
1)
I'm trying to update the mobile mesh position like this: mobileMesh1.Position = new Vector3(x, y, z);
Watch out- setting the Position directly is equivalent to teleportation. The velocity of the object fails to represent the motion of the object. This can lead to 'squishy' or just broken collision response behavior, depending on how badly the velocity and actual motion diverge. Prefer controlling objects at the velocity level by either setting the velocities directly or using constraints.
2) A MobileMesh with a solidity setting of Solid, Counterclockwise, or Clockwise requires that the mesh has consistent triangle winding. If it does not have consistent winding, some triangles will let objects into the mesh, and others will fight in the other direction. This can cause really nasty behavior.
3) A MobileMesh with a solidity of DoubleSided will (as the name might imply) collide on both sides, which can sometimes 'trap' objects. While turning on CCD to stop objects from tunneling inside the mesh can help, it is not free from a performance perspective and it can't stop all interpenetration. For this reason, it's usually best to use a one-sided sidedness if possible.