Static Mesh Coordinates (Integrated transforms)

[RobertMtx]

I'm at the point where I'm trying to figure out how to deploy static triangle meshes for "levels" in my game, but I'm not sure which system would be the most optimal for PhysX. It doesn't make any difference to anything apart from the internal physics, so I'm thinking I should use whatever performs the best. Anyway, here are the three choices:

1. World space vertices: Each vertex position would literally represent its world space coordinates. The shape and rigid static would both be set to identity transforms.
2. World space shape: Leave the mesh vertices in local space, use PxShape::setLocalPose( transform ) to place the mesh in world space, and set the rigid static transform to identity.
3. World space rigid static: Vertices would remain in local space, the shape transform would remain identity, and the rigid static transform would be set to place the mesh in world space.

There is a 4th option of using transforms at multiple steps, but its hard to imagine that being the most optimal solution. Common sense would make me think #.1 would be best, because vertices do not need to be transformed to test collision. But its possible that PhysX will transform them anyway (with the assigned identity transform), or its possible PhysX optimizes out the transform in all three cases. And there's the possibility that world space vertices may cause other issues, such as with the bounding box systems that separate geometry based on locations, etc.

Anyway, any advice is greatly appreciated!

[kstorey-nvidia]

PhysX always applies transforms, but collisions are computed in relative space rather than in world space. Effectively, one shape (usually the simpler primitive shape) is transformed into the local space of the other and contacts are generated in this space.

Options 2 or 3 would be better from a simulation perspective because it can result in better numerical precision. All 3 can work provided the simulation isn't massively offset from the origin.

It doesn't make a massive difference whether you use shape transform or rigid static transforms as world space shape transforms are computed once when you set the transform on the static actor/local offset, so we're not evaluating this chain of transforms every frame.

There is some argument for placing multiple shapes with different local poses under the same static actor because this can save some memory by avoiding having 100s or 1000s of static actors. However, the memory saving is not likely to be very large.

If you are likely to have a very large number of shapes in your scene, consider using aggregates to group together nearby actors/shapes into a single broad phase bounds. You should always measure if this helps, but this can result in performance benefits.

[RobertMtx]

Thanks for the information and advice!

Yes, there will be objects that have child objects, so I will look into using Aggregates. I was considering implementing some type of "binder" hierarchy for that. Bodies could bind themselves to their parent "binder" object, without knowing what it is (scene or aggregate). That would make it easy to try using them in random places without much change in code. If objects need to access the scene, it could be done through a virtual GetScene() method, which aggregates could redirect to their parent, etc.

Anyway, thanks again!