Convex vs Trimesh collision issue

[marcell-baranyai]

Hello, I'm experiencing an interesting behavior when convex meshes collide with static trimesh.

Sometimes CCD collisions go super bouncy, even if the restitution is set to 0.1 And in some circumstances, also with convex vs flat trimesh surfaces the collision impulses result in only linear velocity change leaving angular velocity unchanged.

Please observe these in motion: https://youtu.be/KAPsZp7596E https://youtu.be/1JAPvvFfie4

And for reference here is the very same scene with CCD disabled. https://youtu.be/vyRGd02erFA

The only difference in case of bad behavior is the CCD: setRigidBodyFlag(PxRigidBodyFlag::eENABLE_CCD, true);

Regarding global settings PCM and TGS are used, all other settings are left default. The scene is in the close proximity of the origin.

I'll try to make some PVD capture, that may help.

Thanks in advance.

[kstorey-nvidia]

The CCD model enabled with PxRigidBodyFlag::eENABLE_CCD is a linear sweep-based CCD.

Have you tried PxRigidBodyFlag::eENABLE_SPECULATIVE_CCD? This enables a different CCD model that dynamically adjusts contact distances. It handles angular motion a lot better than the linear model and is usually less computationally expensive. However, it is not as robust as the sweep-based model.

Regarding the bouncing effect when the model is tumbling, I'm not quite sure what could be causing that. If you could capture and provide a PVD capture, we might be able to reproduce locally. Having said that, the TGS implementation in PhysX 4.1 can be a bit aggressive when correcting small penetrations. How many solver iterations are you running with?

We have some significant improvements to TGS in the works that address this behavior, but for now you could try adjusting maxDepenetrationVelocity on the bodies to try and reduce this effect. By default, maxDepenetrationVelocity is infinite, but you can get reasonable-looking results with a value of around 2-3m/s.

[marcell-baranyai]

I tried with speculative ccd, that looks much better in this situation, although it looks like the friction is out of the game above a certain velocity. I also tried with PGS and with more solver iterations (pos: 16, vel: 8) but it was not much better than what I originally used (4, 1). Lowering the DepenetrationVelocity (2m/s) didn't make much difference either.

Please find attached the original scene capture: Capture.zip