CompoundShapeEntry absolute position

[sergiusz308]

Hi, I'm having this problem with CompoundShapeEntry positioning.

Results I'm getting are that some shapes positions within compound are not as expected - they're shifted several game units up in particular example. That's at least how it looks like when drawn using BepuModelDrawer. I'm not talking about physics not matching grapchics here, just particular shape entries being located at different positions than provided. Now, searching through posts here I learned that there's magic happening inside, related to physical center computations etc. I understand that this could change resulting position. That's ok, but is there any way I can set specific position of CompoundShapeEntries exactly where I need?

How I build CompoundBody:

1) there is a game WorldTransform for particular scene element. That scene element is complex so it's physical representation is built of several simple shapes like box, capsules and sphere
2) for each collision mesh, exported from DCC package, I create corresponding CompoundShapeEntry, i.e. BoxShape, CapsuleSphere etc., using CompoundShapeEntry ctor that takes shape, RigidTransform and mass
3) RigidTransform contains transformed by WorldTransform position and orientation I got form DCC - I checked here, my transformations are ok. Whenever I'm using my WorldTransform or just manualy provide some arbitrary vector3 position, it's drawn not where expected anyway
4) once I'm done with CompoundShapeEntries I create CompoundBody entity, supplying CompoundShapeEntry list created above
5) I don't alter CompoundBody position or any other property in any way
6) I add entity to the space
7) I add entity to BepuModelDrawer (Instanced version)

It looks like shapes are repositioned due to physical center computations - I understand lopgic behind that - but what I need here is to be able set their position in compound exactly how it was done in DCC package, or at least learn how I can control this to get the same result. What's interesting here is that after CompoundBody is created (and before added to the space - I don't know if it's of any relevance) I inspected its internals and looked at Shapes local positions - they are the same as provided during creation time.

[Norbo]

When a CompoundShape is constructed from CompoundShapeEntry objects, the CompoundShapeEntry objects are localized around the new center. They do not move relative to each other at all; they are just using a different origin for the position.

The CompoundShape constructor can optionally output the origin it is using. So, here's an example adapted from the EntityConstructionDemo:

Code: Select all

            var compoundShape = new CompoundShape(new List<CompoundShapeEntry>
            {
                new CompoundShapeEntry(convexHullShape, new Vector3(7, 3, 8), 1),
                new CompoundShapeEntry(convexHullShape, new RigidTransform(new Vector3(8, 2, 8), Quaternion.CreateFromAxisAngle(Vector3.Forward, MathHelper.PiOver2)), 5),
                new CompoundShapeEntry(convexHullShape, new Vector3(9, 1, 8), 1)
            }, out center);

All the CompoundShapeEntry positions are far away from the world origin, but clustered near each other. The center (as determined by shape weight and distribution; in this case, {8,2,8}) is computed. All shapes are pulled into local space by subtracting this center from their world position.

The resulting local shape positions are then {-1, 1, 0}, {0, 0, 0}, and {1, -1, 0}.

So, if we wanted the local shape positions to end up back at exactly the same world space positions as we passed in initially, we simply move the entity using the CompoundShape. Setting its position to {8, 2, 8} moves the shapes back to their original position, and the entity still behaves as though the center of mass is correct.

The CompoundBody prefab entity type does the above process automatically. It sets its own initial position to the center computed by the shape so that the shapes end up in the expected spots while retaining proper rotational behavior.

If you wanted to maintain the original physically incorrect center of mass, you could set the entity.CollisionInformation.LocalPosition to the center value ({8, 2, 8} above) instead of moving the entity. The LocalPosition offsets the collision shape from the entity.Position.

The center value computed by the shape constructor can also be used in other helpful ways, like translating graphics to match. It can be used to compensate for any mismatch between 'content local space' and 'physical local space.' To get the value, either use the CompoundShape constructor directly or check the CompoundBody's position immediately after construction.

[Edit: I should also mention that this recentering that goes on in a shape constructor is unavoidable. Shape data is required to be local by various systems. The whole shape can then be transformed around in ways that compensate for this, but the shape data itself always stays local.]

[sergiusz308]

It doesn't work Norbo. Please look at attached screenshot - shape A supposed to be located (lower hemisphere of the capsule) at black line but it's sitting some units higher. Probably at compound shape computed physical center, but it's not what I'm looking for. BTW, compound shape is built of shape A and B, with proper mass distribution (weights).

I tried setting resulting CompoundEntity LocalPosition like you described below but no change.

Any other suggestions there may be?

[Norbo]

If the capsule is supposed to be at the black line but the box should be where it is, then something external to the compound shape recentering process is causing it. The recentering process will never move shapes relative to other shapes in the compound; they are all translated into local space by exactly the same amount.

Working with the above assumption, I'd guess the translation from content to compound has an inconsistency. For example; if the content considers the center to be something that isn't the center of volume of a constituent shape, the translation will not look as expected.

[sergiusz308]

Hmm.... I'll look into this, you're may be right here.

Thanks for late-night help!

P.S. I don't know what're doing for living but amount of time you put in helping poor souls like me here, considering all the details and depth of your explanations here is astonishing. All the best to you.