Experimental contacts modification API

Indeed. I'm still looking into different optimization strategies, but this one isn't so bad.

Another thing I'm interested in is having the rigidbody rotation and position be exposed in addition to the colliders. It would not take much to vastly improve the usability and power of the contact mod API in general.

 

Sounds excellent! Having the velocity getters is extremely useful; I'll be updating to 2022.x as soon as they're in!

An immediate request that I have has to do with the position/otherPosition and rotation/otherRotation variables: they only give access to the colliders' transform data, but not the rigidbodies'. Having both might be required in a lot of different cases (for example, to derive relativeVelocity). In my case, the need arises from using child colliders with offset centers relative to the rigidbody center-of-mass. I recommend a change to/add the following:

colliderPosition (collider center)
otherColliderPosition (collider center)
colliderRotation
otherColliderRotation
bodyPosition (center of mass)
otherBodyPosition (center of mass)
bodyRotation
otherBodyRotation

Regarding the lack of impulse:

Given the above (along with the velocities and a given collision point), it's possible to derive the relativeVelocity of the colliders at the collision point, which is a broadly useful value (especially given the absence of impulse). It's a bit tricky to calculate because the relative velocity at a given point is affected by the angular velocity of both bodies (the gist is that you need to calculate the linear displacements at a given point on both colliders caused by their angular velocities, and add them to their linear velocities), so it might be worth adding a helper function for this for new user, although I'm not sure if that would be efficient system-wise. Weighting velocities by mass and inertia tensors before calculating a final relative velocity also seems to be the only or best way of guesstimating what the impulse will be, but this is something I have not toyed very much with yet.

More requests to come!

 

@yant friction modification doesn't seem to work with articulation body components...is it intended? If so, have you any time estimations when this will be implemented? Thanks!

 

Hello ! Is it possible to implement it on an existing project ? What I want is really simple : freeze the rotation of a boat, produced by collisions with his environnement. Literally "don't rotate with external collision, but rotate when I add to you a force"

 

You may want to check out the Layer-based collision detection, which will do exactly what you want. Also, make sure to read through the Colliders/Collisions in unity, which will give you a solid understanding on how those work. You don't need to use experimental contacts modification for suck a simple task.

 

If I make it based on the layer, the boat will just pass through objects. Am I missing something ?
My problem is more complex than it sound, I want to keep the collision, but not the rotation while NOT freezing it.
But thanks for your answer, you gave me an idea : simulate the rotation using torques inside a separate rigid body unaffected by external environnent and child of the boat. Then using it's rotation and apply it to the parent, wich is affected by the collisions !

 

Try this:

Code (CSharp):

1. ModifiableMassProperties modifiableMassProperties = pair.massProperties;
2.  
3. modifiableMassProperties.inverseInertiaScale = 0f;
4. pair.massProperties = modifiableMassProperties;

 

Hey, I'd like to implement something like a hole in a mesh collider with Contact Modification, but I am struggling a bit with how to detect that the colliding object is in the hole, or outside. What would be the best approach to detect this? Have another trigger collider, and modify contacts as long as the colliding object is colliding with the trigger collider (with OnTriggerStay?). Any help appreciated.

 

Thanks for getting back! Easiest way of definition would be by having e.g. a sphere collider / shape defining the hole. It needs to move with the rigidbody to which the mesh collider is assigned to, so a dynamic scenario.

 

@yant any idea if this is solvable with contact modification? right now I am using a mechanism with collision layer switching based on collision trigger, but this is complicated setup and not very precise.

 

Yeah it's solvable with the existing API. Are you needing help with anything? Why would you use a collision trigger when Contact Modification callback is more accurate and timely?

Basically once you get the callback and pair, you choose to ignore the collision within the hole and (optionally) construct a valid normal for the response for anything colliding. That is pretty much all you need to do to pretend there's a hole you can collide with properly.

 

What's unclear to me is how do I determine if I am actually inside the hole inside the callback, and only manipulate the response if it is the case. Only way I can imagine would be to use a trigger collider in the shape of the hole and "OnTriggerStay", but I'd guess there must be a more elegant solution.

 

I figured it out somehow to do it only with contact modification: by running through all pairs, finding all instances which collide a) with the main body and b) with the hole defining collider, and then manipulating the eligible pairs in a second loop. Works great, albeit the code does not look like that ...

 

Hey @yant! Thanks for adding this API! It adds a lot of sweet possibilities.

Trying it out in Unity 2022.1.0b2 has some issues (see bug reports 1393368, 1394290).

Is there a newer build available to try?

Edit: Tried 2022.1.0b3 and, unfortunately, it crashes even more easily.

 

Oh wow, this sound so promising.
Then it would finally be possible to do proper "fake" holes in colliders using other colliders (triggers) as a mask. currently its not really possible without extensive use of Layers and tweaking the collision layermask.
Any Updates when this will land?

 

Would you be willing to share your code?
I'm tackling the same exact problem

 

I was able to simplify it, with "faking" the second collider, as I realized that the callback seems to be called multiple times per frame in parallel, if multiple collider are colliding at same time with the colliders enabled for contact modification (not sure if this is wanted behavior or a bug in the current implementation), and with this behavior the above mentioned approach does not work reliable.
By faking second collider, I mean that I am doing the math of calculating an overlap myself, instead of relying on Unity collision detection. I can share the actual contact modification code:

Code (CSharp):

1.     public void ModificationCallback(PhysicsScene scene, NativeArray<ModifiableContactPair> contactPairs)
2.     {
3.         for (int i = 0; i< contactPairs.Length; i++)
4.         {
5.             var pair = contactPairs[i];
6.             int idToUse = capsulesForHoleCheckPerMainBody.ContainsKey(pair.bodyInstanceID) ? pair.bodyInstanceID : pair.otherBodyInstanceID;
7.             Capsule[] capsules = capsulesForHoleCheckPerMainBody[idToUse];
8.             Sphere[] spheres = spheresForHoleCheckPerMainBody[idToUse];
9.             for (int j = 0; j < pair.contactCount; j++)
10.             {
11.                 bool foundCollision = false;
12.                 for (int k = 0; k < capsules.Length; k++)
13.                 {
14.                     if (capsules[k].Contains(pair.GetPoint(j)))
15.                     {
16.                         pair.IgnoreContact(j);
17.                         foundCollision = true;
18.                         break;
19.                     }
20.                 }
21.                 if (!foundCollision)
22.                 {
23.                     for (int k = 0; k < spheres.Length; k++)
24.                     {
25.                         if (spheres[k].Contains(pair.GetPoint(j)))
26.                         {
27.                             pair.IgnoreContact(j);
28.                             break;
29.                         }
30.                     }
31.                 }
32.             }
33.         }
34.     }

I am updating the positions of the "fake" collider in "FixedUpdate", so I can use them in the callback

 

PS: I am using Capsule and Sphere checks from here:
https://answers.unity.com/questions/1279384/capsule-calculations.html

 

Hi, this seems like a very useful addition! I want to cancel a collision depending on the resulting impulse (like in Collision.impulse.magnitude). As I understand it, at this stage the actual impulse is not yet known. Is there a way to work around this? The context is that I have breakable windows, walls, etc. which are static colliders that get deactivated after a strong enough collision. This of course means that any rigidbody that breaks a window/wall/etc will bounce off of it, instead of ignoring the collision and flying through.

Using pair.GetMaxImpulse won't work as it often returns values such as 1x10^32. Reverting the rigidbody to the last fixed update is not sufficient as it visibly freezes for a split-second, plus it is quite inefficient to save the state of all tracked rigidbodies to a dictionary every physics update. Reverting just the velocity but not the position does not work as sometimes the rb.position is already mid-bounce in OnCollisionEnter, for whatever reason.

A very crude solution I'm considering is:
- Have a concurrent dictionary, for rigidbody colliders, between instance ID and momentum.
- Have a concurrent dictionary, for destructible object colliders, between instance ID and a tuple containing their max impulse tolerance and a flag for if they should be broken once we're back on the main thread.
- Every fixed update, all tracked non-sleeping rigidbodies have their momentum saved to the dictionary for each collider which they are composed of.
- In the modify contacts callback, use the contact normal and saved momentum to estimate the resulting impulse (use max among all contact points in the pair).
- Check the impulse magnitude against the max impulse tolerance. If it exceeds, disable all contact pairs and set the broken flag to true. Otherwise, do nothing.
- In OnCollisionEnter, the destructible object checks the broken flag in the dictionary and acts accordingly (gets broken or does nothing).

Does anyone have a better way to handle this?

 

In 2022.1 you can access bodyA and bodyB linear/angular velocities. This is very useful especially if you want to calculate the impulse. The collision impulse is determined by the relative velocity, restitution, collision normal and the mass values from the bodies involved (i think, i don't remember the exact formula, there was a dot product somewhere...). With this in mine you could calculate the impulse yourself before it is calculated by the physics engine.

Once you have the impulse value, you can ignore the contact if the value is greater than X. Here's a very simplified example, i'm just checking if bodyA velocity is greater than X (bodyB is static).

 

I've only just found this thread - so glad this feature finally made it into Unity!!

I've been a pro customer since 2010 & have been asking for this to be added since Unity 4.

I primarily do console work & so I only use LTS versions of Unity and am currently on 2020.3 LTS, looking forward to having this.

(@yant) just to confirm: Physics.ContactModifyEvent (& other related stuff) is in the docs for 2021.2 so I'm right to assume it's is in 2021.2 & non-experimental so will be solid in 2021 LTS right?

 

There's no reason why Unity would remove this from upcoming 2021 LTS. Contact Modification is a released feature on 2021.2 already. It also exists on current 2022 cycle too.

 

To expand on the LTS question: Will/has this come to 2018 LTS?

Bit of a long shot because it's such an old version of Unity, but I've got a lot of legacy assets that would completely break in 2021+

PS: Love this addition, been wanting this for an extremely long time.

 

Unity doesn't typically backport new features to already released older versions. Also worth noting that Unity 2018 LTS support ended one year ago already so there's pretty much zero change they will add anything to it.

 

Aye, figured something like that. Thanks anyway!

 

@yant any updates on exposing physx immediate mode?

 

Wait what! I never thought there would be a not-horrible way to make Portal-style portals with Unity!

And it's even in 2021.2 already :O Mind blown. Thank you for your work, @yant! The more control we can get over PhysX, the more interesting things we can do without hacks and terrible workarounds

 

Hrmm, would water physics be a good use case for contact mods? What might that look like? Just starting out and I see you can do cool things like tractor beams with it. Wish there were more tutorials, but it's still relatively new so it makes sense that this thread is about all there is for learning resources.

 

Basically contacts are what the physics engine gathers about a collision that is in progress, before resolving it. So you get to intercept and meddle. For example ignoring a contact if there is a hole near this contact in 3D space.

So it can do anything from emulating weird shapes (normals or ignoring) to simulating a thick fluid of some kind (impulse etc). Be aware some values are not rational so look up if its inverted etc.

 

Is there a reason contact pairs involving fast moving objects with Continous Dynamic detection mode are sometimes not ignored? From what I can tell, pair.IgnoreContact is still being called but I'm still getting a visual "collision".

The repro is to use yant's build, change the collision mode on the sphere to Continuous Dynamic, and move it's Y coordinate to about 30 so it can pick up some speed.

Just wondering if this is expected as a quirk from the collision mode or if this might indicate a bug.

 

Without knowing further details/your code: there's often more than one pair on same object. Make sure you ignore all of those contact pairs and not just the first one.

Could be a bug / nonsupported scenario of course but would help if you could give direct repro proejct

Also why would you use yant's experimental build when the api is already on 2021.2+ with bunch of fixes?

 

rz_0lento Here is a repro project, you can see it's just a modified version of yant's. I refactored the code a bit to be simpler to sandbox and extend but it's not functionally different. I made this in 2021.2.19 but I think any of the newer versions should be fine.

 

You have to use ContactModifyEventCCD for CCD collision pairs. I had to use both CCD + nonCCD callbacks in combination to get the the thing ignore the plane fully:

Code (CSharp):

1.     private void Awake()
2.     {
3.         Physics.ContactModifyEvent += ModificationCallback;
4.         Physics.ContactModifyEventCCD += ModificationCallback;
5.     }
6.  
7.     private void OnDestroy()
8.     {
9.         ModifiableContacts.Dispose();
10.         Physics.ContactModifyEvent -= ModificationCallback;
11.         Physics.ContactModifyEventCCD -= ModificationCallback;
12.     }

Here I just reused ModificationCallback callback function for CCD version, this worked with this sample but you'd probably want to have separate callback function for CCD since CCD version also inverts the contact normals, more about it on the docs here: https://docs.unity3d.com/2021.2/Documentation/ScriptReference/Physics.ContactModifyEventCCD.html

 

rz_0lento Oh perfect, that fixes it entirely. Thank you so much for your help! I wonder why the separate callback... what is the use case meant to be? Odd about the contact normals being inverted for it.

 

Physx itself has separate callback for CCD contact mods so Unity just wraps that too.

 

I want to create a arcadey bounce impulse velocity between two dynamic rigidbodies that make contact, such that one receives substantially more bounce than the other.

pair.SetBounciness(i, 2f) is doing what I want... however I would like the bounce to only happen to one of the bodies in the pair. Is there some way I can achieve this?

 

@iDerp69 contact pairs apply to both sides once PhysX gets to resolving these things and we don't have access to that stage of physx solvers. I don't have any good suggestions on how to fix this, maybe you could temporarily add the damping (or whatever drag Unity calls this) on the RB that you don't want to bounce off so easily.. and make sure the other side has minimal damping.

 

I used this to create a sphere that allows other spheres to *collide within it*.

Thread: https://forum.unity.com/threads/exp...econtactpairs-inner-shape-collisions.1308105/
Git: https://github.com/spiderworm/unity-modifiableContactPairs-experiments

I'd like to figure out how to make a cylinder roll around inside that sphere as well. I think I can figure out circle to sphere collisions (for the top & bottom of the cylinder) but after that I'm lost.

 

ModifiableContactPair

has

SetTargetVelocity(int, Vector3)

, but no

SetTargetTorque(int, Vector3)

.

Do ContactPairs not need to store torque or is this a missing feature? My real question is obviously: how do I apply torque to Rigidbodies via Modifiable Contact Pair? This seemed like the obvious solution maybe (probably) I'm wrong.

 

Just curious, could this be used to prevent pops when objects Slide Over collider seams at high speeds?

 

I know this was a bit old post already but since nobody answered, I wrote a bit about this in here:
https://forum.unity.com/threads/experimental-contacts-modification-api.924809/#post-6482950
(my git repo sample also has simple example for this)

and here:
https://forum.unity.com/threads/experimental-contacts-modification-api.924809/page-2#post-6720985

 

Thanks so much for sharing! Ill definitely give this a try.

 

@rz_0lento , amazing, works super well!

I had my character going through the ground a couple of times with Valve so I avoided that one. I noticed that No Separation worked well, but became jittery at very low speeds, so I just added a small speed check to the function. Works perfectly now.

This should be an option in standard unity physics! @yant, any thoughts on exposing some of this in settings?

Thanks again!!