Overlapping 2D triggers slow even if they ignore each other

I have a scene with many small objects with a box collider and a kinematic Rigidbody2D for each of them which is used to check the mouse ray. The collider is on a layer that doesn't collide with anything, not even itself. As long as these colliders don't overlap, the performance is pretty good. But as soon as they start to overlap (which they do often in our case), it uses about 10x more time in Physics2D.Simulate. Shouldn't it be irrelevant that they overlap if they anyway ignore each other? I could understand a small performance decrease, but right now it's really extreme.

As a workaround, I noticed that enabling "Used by Effector" on the collider without having an effector attached increases the performance significantly, while still reacting to raycasts. But I don't completely understand why. Any ideas why that happens?

Here are two screenshots with the same group of objects.

 

Thanks for the answer.

I tried to reproduce the problem in a isolated case and noticed, that it is caused by effector triggers, not just by overlapping normal (non-effector) triggers. In my scene there are the (box collider) triggers which ignore each other, but also some more triggers (circles in the screenshots) which are on the same layer. I assumed they would also ignore each other, but I had "Use collider mask" on with all layers enabled, so they interacted with all the box colliders. At least theoretically, because the triggers (without effector) are kinematic anyway and don't react forces.

The "Use collider mask" checkbox is actually a bit confusing, I wasn't aware that activating it actually overrrides everything in the layer settings, and it's on by default, which means by default effectors don't care about the physics layer mask matrix.

So in my case I could get around it by disabling "Use collider mask" so they properly ignore each other, but I still think it shouldn't actually take a performance hit so big to have effectors interacting with kinematic objects, because they anyway don't have an effect.

The report with a scene that shows the issue: 842783

 

Btw. it still helps to check "Used by effector" on the trigger that shouldn't interact with anything to improve the performance. It looks like putting them into "effector-mode" without an active effector helps ignoring overlaps.

 

I have a similar problem with the 3D physics. Moving lots kinematic rigidbodies in a small area with overlapping colliders is very slow even when all collisions are disabled from the matrix. Seems like the same thing, collisions are resolved first before checking if there should be any reactions to collisions. I wonder if it would be possible to skip collision checks altogether for specified colliders both for 2D and 3D physics. In my case I'd want to use the colliders only for raycasting against kinematic objects, so all the collision checks in the physics resolve phase are just wasted cycles.

 

If there's 1000 overlapping colliders on kinematic bodies moving every frame, it's no longer trivial. Sure there probably won't be as much in an actual situation, but I'd still like to have raycast only colliders that skip the checks altogether.

 

It's the exact same thing with Unity's 3D and 2D physics, I made test scenes for both. Just moving a large amount of overlapping kinematic-but-not-actually-colliding-with-anything colliders is very expensive and the cost increases exponentially with the amount of overlapping colliders. Seems to me it's checking each collider versus all the others every frame and I don't undestand why that's necessary if I know the collider won't collide with anything and I'm only going to use it for raycasting (hence "raycast only collider").

Currently 2D physics takes ~150 ms on my PC when moving 1000 overlapping boxes in a 1*1 area and something negligible when it's a 10*10 area. I guess it's 1000 * 1000 checks every frame in that worst case scenario, and I was hoping I could do with 1000 checks per raycast instead.

Maybe the collider vs collider can't be avoided and I'm better off using a custom spatial hashing + raycasting system for that, but I'd like to be able to use the existing colliders if at all possible.

 

All of them are kinematic rigidbodies with colliders, moving them from a script. All collisions disabled from the physics settings. No problems if they are further apart or if there are no colliders.

 

Basically I just want to (mis)use the colliders for raycasting purposes and skip the actual physics for better performance. I guess it's more of a feature request in that way, but it would be a nice optimization and great to have.

The way I did it years ago in XNA with spatial hashing was something like this:
1) On each frame calculate the bucket for each object.
2) When raycasting, check which buckets the ray hits (broadphase)
3) Check the ray against the bounding box and then the smaller colliders of each object in the bucket (narrow phase)

There was no collider vs collider checks at all, since the colliders don't need to know if they overlap with other colliders. Now I don't know what Unity does internally and if what I'm asking is truly impossible, but "just update position, skip collision checks" doesn't seem that crazy to me.

 

I was already testing with the latest 5.5 betas.

I just found a sort of a solution with 3D physics. If I remove the Rigidbody completely but leave the collider and use Transform.position instead of RigidBody.position, it's much faster and raycasting still works. It's however slower than using RigidBodies when there's no significant overlap.

With 2D there's no tricks I can find. Toggling simulation off and using Transform.position makes it fast, but that leaves the object completely out of the physics and thus also breaks raycasting.

 

This is what the profiler looks like:



My test project is attached, 2DOverlap is the scene.

 

Awesome! Thanks a lot for your time, it's great to get in-depth answers.

If that gets implemented, maybe it would make sense to have Box2D skip the collisions by default if you have a Collider2D without a Rigidbody2D, since PhysX already does so if you have a Collider but no Rigidbody.

Also, maybe this is something that should be mentioned in the physics manual / tutorials, since there are these corner cases where it actually is much better to move static colliders instead of kinematic rigidbodies.

Now, if only I could get colliders that could be used directly from scripts without a GameObject to go along with Graphics.DrawMesh.

 

Right, good point. A checkbox is probably much more obvious anyway, seeing as how long it took me to figure it out with PhysX.

I meant PhysX in this case, should've clarified. Using 3D colliders without rigidbodies avoids the exponential cost with overlaps but has a bit higher constant cost (I think). The PhysX tutorials and best practices are from the Unity 4.6 era and warn against moving colliders without rigidbodies.

Maybe the different cases could be mentioned with small examples, something like:
- Push and be pushed (a physics object) - use a rigidbody and add forces.
- Just push others (characters) - use kinematic rigidbody and use MovePosition.
- Ignore others (significantly overlapping hitboxes for raycasting) - with 3D don't use a rigidbody (3D) and use Transform.position / with 2D use the possibly upcoming option to ignore collisions.

If that ends up happening, I hope the PhysX people will get competitive and do it too. In general I really appreciate the more open direction you're been going. Having new stuff as open source components that you can tweak yourself and having intensive dev presence on the beta forums is so much better than what it used to be earlier with Unity 4, when you'd feel like the bug reports are ignored and the bugs will never get fixed.

 

I checked my project in 5.5b9, it definitely runs much faster and no contacts are generated. I'd consider my specific issue solved, thanks! If it's easy to backport the change to 5.4, I'd appreciate it, but if not, no problem.

 

Another related question: Are contacts supposed to be generated for effector overlaps?

 

I was just unsure if contact specifically means collision (with forces etc.) or any kind of trigger/collider overlap. Just to know if everything is working as expected when I see a lot of contacts generated for overlapping triggers with interacting effectors.