Feature request: adjust max depenetration velocity in contact modification callback

[proc-sim]

Currently you can modify friction/restitution/impulse in a contact callback, but you can't modify the max depenetration velocity between rigidbodies in contact. Being able to modify max depenetration velocity for contacts on-the-fly allows for really nice treatment of inter-penetrating rigidbodies at the frame of their initialization - if bodies start off penetrating, modifying their depenetration velocity (setting it to zero) prevents them from exploding and gives them a nice 'sticky' effect...this works really well with offline destruction sims where many bodies may be interpenetrating depending on the quality of the input geometry.

The reason you'd want to do this modification in a contact callback instead of directly on their rigidbody properties is that the depenetration velocity should be set back to normal for contacts once the bodies separate - and kept normal for all bodies that are not interpenetrating at the start. So it needs to be modifiable on a per-body, per-contact basis.

I implemented this idea myself to test it out and it works great. I can't offer a pull request because the way I got it working is really messy (since no easy paths currently exist for this to happen natively, I instead set the contact friction to a magic number in the contact callback and set depenetration velocity to zero when I detect that magic number in 'constructContactConstraint' in DyContactPrepShared.h) and it needs to be implemented separately for GPU rigidbodies anyways...so it should be something that the NVidia team does properly.

Here's an example showing how this benefits a rigidbody collapse sim, where some rigidbodies start off interpenetrating. There's a 20 frame leadup before rigidbodies are activated, to show their initial configuration.

Without depenetration modification - everything immediately explodes:

depen_Perspective_preview_v001_1.mp4

With depenetration modification - everything crumbles much more gracefully:

depen_Perspective_preview_v002.mp4

[jcarius-nv]

Hi @Tysoni ,
thank you for the suggestion and the nice visualizations -- it does look like a nice idea!

We will discuss the proposal in the team. For the meantime it seems you found a working solution already (albeit hacky as you say).

[jcarius-nv]

Hi @Tysoni

would it be possible to achieve the same effect with the existing parameters that are exposed in the contact callback, in particular setMaxImpulse and the inverse mass and inertia scales?

The issue with exposing max de-penetration velocity is that I feel it's rather an implementation detail of the solver than a property of the contact, so we'd limit our ability of rewriting the solver in the future by exposing that value even more.

If you just want to set the maxDepenetrationVelocity and not calculate the maxImpulse or related quantities, could your application not do that per-body (PxRigidBody::setMaxDepenetrationVelocity) while keeping track of the relevant bodies through contact reports?

[proc-sim]

Hey @jcarius-nv

Unfortunately the existing parameters won't allow me to achieve the same effect. Since it's the start state of the sim that has the interpenetrations, the impulse control won't do it because there are no impulses in the sim yet...just overlapping colliders (I did try achieving the same control with the contact impulse modifier like you suggested, but it didn't give the desired effect - the depen velocity is really the key).

The reason changing setMaxDependetrationVelocity for the entire rigidbody won't work is because it's important to maintain per-contact control. For example, if rigidbody A and rigidbody B are interprenetrating at frame 0, I want their contact depenetration velocity to be 0 until they are separated (which may not be for a long time). However, prior to their separation, rigidbody C may come into contact with either A or B in a way that causes them to penetrate...and if maxDepenetration velocity is zero for A/B that will result in improper interaction between A/C and/or B/C. And C itself may already have maxDepenetration set to 0 due to its starting penetrating with D, etc. It can't be an all or nothing value for a rigidbody...it has to be per-contact.

If the GPU solver wasn't a black box DLL I'd be happy to just use my own workaround in my implementation...but since I can't add the GPU support myself that's the main reason why I'm requesting it as an official addition. And I really think the use case I present would be a useful feature. It's honestly a game changer for destruction sims.