Why do the custom convex shapes disable PCM?

[Zeblote]

It's disabled here https://github.com/NVIDIA-Omniverse/PhysX/blob/release/104.2/physx/source/physxextensions/src/ExtCustomGeometryExt.cpp#L411

and enabling it seems to result in rather jittery behavior. But why is that?

[vreutskyy]

PCM is only useful for complex concave static geometries, like this one

PhysX/physx/snippets/snippetcustomgeometry/VoxelMap.h

Line 95 in 93b6c25

virtual bool usePersistentContactManifold(const physx::PxGeometry&, physx::PxReal&) const { return true; }

It's hard to tell why without seeing it, but the jittering may be caused by the way PCM works: reusing the previous frame contacts, which isn't always accurate enough.

[Zeblote]

Hmm, why does all this exist then though?

https://github.com/NVIDIA-Omniverse/PhysX/blob/release/104.2/physx/source/lowlevel/common/src/pipeline/PxcContactMethodImpl.cpp#L265

https://github.com/NVIDIA-Omniverse/PhysX/blob/release/104.2/physx/source/geomutils/src/pcm/GuPCMContactBoxBox.cpp#L859

(and many more)

I was under the impression that PCM is always used because it can accumulate contacts across frames and improve stability in stacks etc., while also improving performance. Is that not how it works?

For testing, I implemented a custom box based on PxCustomGeometryExt::BaseConvexCallbacks and it seems to behave exactly as a normal box when PCM is disabled, exploding if it is enabled. Maybe you're right that it's not being used normally?

[vreutskyy]

The initial question and my answer were about the PCM usage with the custom geometry. The other geometry types may use some specific computation to transfer contacts from frame to frame and keep them correct, which isn't easy for custom geometry. That's why PCM is only useful for complex and static custom geometry. Otherwise it's easier to recompute the contacts every frame, how it's done for the custom cone and cylinder.

[Zeblote]

I feel like it would be helpful if this api was redesigned to allow custom shapes to decide for themselves whether to store and which type of manifold to store for a given pair. For example, I have a custom shape that acts in different ways based on the size of the other shape. Sometimes it acts as if it was just a box, while other times it uses varying levels of detail from an internal structure. It trying to jam this into the multi manifold outside of generateContacts doesn't seem to be working very well.

[vreutskyy]

Yes, I see what you mean. We'll consider adding this possibility. Thanks for the feedback.

[Zeblote]

I've made a bodge to do this by passing the main cache to generateContacts and basically getting rid of pcmContactCustomGeometryGeometry that has that rigid implementation. So if a custom shape wants to use a normal or a multi manifold it can now do anything it wants with it. To make that work we also need to let the custom shape callbacks decide what to do if one is encountered in PxsContext::createCache. So far it appears to be working.

I'm not convinced this would be a good design for the library overall, because there will be combinatorial explosion of cases between different custom geometries and having to implement PCM for all of them sounds like a drag. But it definitely works great for my use case like this.

Also useful: replacing getLocalBounds with a getWorldBounds that passes in the pose because some custom geometries can report tighter bounds than an AABB around an OBB when given the pose. For example I have one that can generate a simplified convex hull around it instead of just a box and use that for calculating the bounds which often reduces the amount of pairs generated in piles of things.

This shape acts as a convex when interacting with the ground plane, large primitives, triangle meshes (landscape etc), but acts as a concave compound similar to a triangle mesh when colliding with shapes that are smaller than itself.