Entity isn't rotating right

[snoozbuster]

Hey, me again. I'm having a little bit of issue with a couple of rotating claws. In Blender, they're both exported with the origin as the point around which I wish to rotate, which isn't the exact center of the model. On a normal day, this would be fixed by setting LocalOffset to be the values offsetting the model in model space (in Blender), which has always worked before, but isn't working for these models (doing this worked for a different model, which I just put in, so I know it usually works). I suspect the issue is the claws have a large, boxy, clubbish looking "weight" on the end of them, for visual effect (here's a picture for reference:)

I figure that Bepu does different mass/volume distribution calculations than Blender does, and since the centers of mass differ (since Blender just does an averaging of the verts, I think), the offsets I need differ, but I've been unable to find the offsets. I thought they were just dumped to entity.Position, but that's modified when I add the desired position of the entity, and the entity starts in the right place and has no LocalOffset (unless I specify one, but it doesn't work with or without). If it's relevant, the entities are kinematic and rotated using entity.AngularVelocity.

tl;dr What determines the point of rotation for a kinematic entity (assuming no LocalOffset)?

[Norbo]

tl;dr What determines the point of rotation for a kinematic entity (assuming no LocalOffset)?

All collision shapes are recentered onto their local center of mass upon construction. The method for computing that center of mass depends on the shape type. For example, a convex hull integrates over tetrahedra built from the surface triangles to compute the distribution of volume. A CompoundShape uses the local positions of its constituent shapes as well as their specified weightings to compute the compound center of mass. A solid mobile mesh uses a general form of the convex hull integration; a hollow mobile mesh uses a shell-based approximation.

All collision shapes with nontrivial recentering processes can output the computed offset from the shape constructor. That is what ConvexHull and other prefab entity types use to position themselves. (Trivial shapes, like BoxShapes, cannot output any recentering offset because the offset is always zero.)

So, if you want to know the recentering offset for a given object:
1) If you're using a prefab entity type like the MobileMesh, check the entity.Position immediately after entity construction and before you move it, or
2) Create the entity's shape directly and grab the offset explicitly. Examples of this can be found in the EntityConstructionDemo in the BEPUphysicsDemos and in the Shape Recentering documentation's associated GraphicMatchingDemo.

[snoozbuster]

If you're using a prefab entity type like the MobileMesh, check the entity.Position immediately after entity construction and before you move it.

I feel somewhat dumb because this didn't occur to me sooner. I considered it while writing this post, but I didn't check it because, for one, I thought I already had, and for two, I didn't think it could be that simple.
However, copying that initial position into LocalOffset works perfectly. I don't think I want to do it every time I create a MobileMesh, or I'd put in into the constructor that associates models with entities, but I will certainly remember that. It just seems kind of odd, because the other method has always worked before.