Why no "CurrentColliders" function?

As we all know, destroying or deactivating a gameobject doesn’t trigger OnCollisionExit(), which has caused many of us to write convoluted workarounds.

Does anyone know WHY Unity doesn’t offer a “which other colliders are currently touching this collider” function? That would solve hundreds of common use cases and would make a lot of code less fragile, not to speak of thousands of work hours it would solve.

Anyone know the reason? I’d guess the physics engine has this information, so why not expose it?

The first thing I had in mind when I read this was: ugh, then everyone would be writing custom OnCollision methods that would either end up being in conflict with normal OnCollision callbacks or add a non-neglectable overhead to collision handling due to the same thing being done twice, or many times per frame, and possibly causing all kinds of issues within the physics simulation.

Do you have a couple links where this is being discussed and workarounds proposed? I actually haven’t heard of this issue.

Okay found this thread: OnTriggerExit/OnCollisionExit and destroyed GameObjects

I see how that is annoying. But once you know about it, the proposed workarounds (flags, Enter/Exit counting, On**Stay state progression, move object away and wait for FixedUpdate) are rather trivial and reliable. It’s not like this is an unsolvable problem. This could even be handled within a (pooling) system that puts affected objects in a “zombie” state for a frame before putting it back to the pool (or destroying it) so you don’t have to think about it in future projects.

I’m thinking Corgi framework and such assets almost certainly have to have implemented a generic solution for this issue.

This should be confirmed first. If you can find a convenient method or API call to get such information in the physics engine (PhysX) then Unity devs could consider exposing it. Here’s the documentation on the PhysX SDK:

https://gameworksdocs.nvidia.com/PhysX/4.1/documentation/physxguide/Manual/Index.html

You only stated “Unity” so all I can say is that for 2D you’d use Collider2D.OverlapCollider or Collider2D.GetContacts and via the Rigidbody2D (all attached colliders) you’d use Rigidbody2D.OverlapCollider or Rigidbody2D.GetContacts.

It does, it’s the Contact Modification API. You can completely replace Unity’s OnCollision… stuff with it and gain a lot of performance and control back on top of that.

It does require more work and has a poor amount of documentation and samples, but that would be Unity’s job to fix. However should you be able to work with that, all your issues are solved.

You can also use the regular API and when you want to destroy something just do an overlap check to gather all the colliders touching it. In short I’ve done what you are asking for since 2010 in regular Unity (the overlap check).

IMHO Contact Modification API could be better and this whole OnCollision stuff is horribly dated but it is all workable and not a ship-stopper.

If this weren’t yet another experimental, badly documented Unity feature, I’d consider it.

The overlap check might be an idea. It’s an unnecessary workaround, but it probably is the easiest solution.

It’s not experimental anymore. It’s in the mainline, not in the experimental namespace: https://docs.unity3d.com/ScriptReference/Physics.ContactModifyEvent.html

It cannot be removed now. It’s also simply to use (see link above).

Maybe post what you want for the docs and I’ll mention this thread to the 3D physics guys. What do you want? Something in the physics manual?

A few simple example code pieces. Overlap checks are clearly a common use case. Detecting something no longer colliding or suddenly colliding - including because it was Destroy()ed or Instantiate()ed are also often asked questions on this forum.