Physics cost with trigger Collider2D vs Collider

I have recently started using Collider2D, but I have noticed that for triggered colliders, Collider2D costs a lot more in terms of Physics processing when they are moving. This is not the case for the 3d colliders. I did try and attach rigidbody2d and set them to kinematic , but it still does cost a lot way more than just having 3d collider with trigger option.

This is frustrating, because it seems like there is extra cost of using 2d counter version when I just want to have moving trigger.

Has anyone have any good idea? Is this a bug?

 

I also wonder if it matters if I move the object by transform or rigidbody when there is rigidbody attached and it is set as kinematic.

 

Humm.. So there isn't the same variant version of just having Collider with trigger option for 2D? For 3D colliders, I can just have collider without rigidbody and check the trigger option to have physics not simulating but still able to move them and catch the OnTriggerEnter events and such. This actually is cool way of running the moving trigger without almost no cost to physics.

It's pitty to loses this feature and always need to add the rigidbody for Collider2D. I think A Collider2D without rigidbody2D but using trigger option should behave the same say as the 3D Colliders?

 

thanks for the explaination.
i can understand that the core system under the 2d and 3d colliders are different so i will have to just add the rigidbody.

it is just pitty that it cost more performance to move trigger collider for 2d than 3d that does not have rigidbody. i guess there is nothing i can do about it. i dont plan to run a lots of actual physics simulations so i might just use 3d colliders instead. i wonder if the performance also got to do with hardware as well. that the 3d physx has better performance on my nvidia card. and perhaps maybe 2d physics are not taking as much adventage from hardware acceleration.

not having rigidbody for 3d collider that has trigger option is cool because we can move it by transform and cost almost nothing in physics and yet we can still have all the trigger events.

 

it is not the problem of act of adding a rigidbody. it is the difference in between performance cost.

 

adding rigidbody2d and setting it as kinematic is the fastest way of moving a trigger collider for 2d but it is still cost more than just having 3d collider trigger and then no rigidbody.

 

sorry.. i was talking about performance cost difference compared to the 3d colliders.

 

I got my laptop opened up so I can type better

I think I need to clear up some of the possible confusion with all the questions I was asking here.

Here is the thing.

When I have a moving gameobject with 3d boxcollider with no rigidbody and trigger option turned on, it runs faster than having it with 2d boxcollider with rigidbody and trigger + kinematic option turned on. I have profiled this in Unity and I can confirm that this is indeed true. With the 2d options, I was able to see some cost with physics in profiler but almost no cost with the 3d version.

Now, it may be ok if there are few moving objects, but I was testing it with 100s of moving objects so the cost difference between 3d vs 2d setups maybe very little per object cases, but it could eventually add up making a difference.

I can totally understand that I will need to add rigidbody if I want to use 2d colliders. I have no problems at all for adding rigidbody components. I was merely comparing the runtime performance cost difference in between 3d and 2d setup for doing basically the same thing on both setup.

The original question was to ask about if there was some way to make 2d collider to "work" the same way as the 3d version so the performance costs are the same or similar but obvious difference in under laying system means it is not possible and it is just the way it is.

I must admit that I did think that the overall performance for 2d physics should be cheaper than 3d and that is why this discovery of particular case of "not really" was annoying for me. But I do admit that I was a bit naive thinking that it should be faster for 2d just because it didn't need to consider the extra dimensions in the physics calculation.

The only reason why I am thinking of going 3d colliders than 2d at the moment is simply because of the performance difference in between the setups. I am sure it is going to be a bit different story if there is any actual "force" physics simulations going on, so it is just this particular case of moving trigger only.

 

just moving positions. translation only. no actual collisions. just trigger option only.

i certainly can mock something up for you to check out. i will link one here in about 6 hours or so after i got some sleep.

 

Hi Melv.

Here is test for the colliders.

https://www.dropbox.com/s/73itpjgpyh5iofz/ColliderTests.zip?dl=0

Inside, there are 3 scenes :

1. 2D collider test
2. 3D collider test
3. 3D collider with rigidbody test.

In all tests , there are 1000 sprite units just randomly bouncing off the 8 unit world distance. The code to do this is very crude so please ignore my short fall on that one.

Each unit has collider on it with trigger option turned on and every time it registers OnTriggerEnter event, it will increase a integer value on the Test game object. You can see it on the inspector.

Now after I have done this test, I think I was perhaps prematurely thinking that the only moving part was responsible for the performance difference, but I think the trigger event calculation as well.

2D collider test registers the event against the all other units as well which is perhaps one of the reason why it is more expensive. The 3D collider test without rigidbody only registers event with the one other collider with rigidbody in the middle so a lot less trigger event means it will obviously run faster.

Which is why I tested the 3D collider scene with the units also having the rigidbody. To make everything the same and fair to test. However, interestingly, 3D colliders with rigidbody was still a lot faster than the 2D colliders. Even with units registering events with each other.

The profiler shows that the physics cost is at around 2.5ms or less in average for 3d with rigidbody but for 2D it was at around 7.4ms

This brings up some interesting options.

If I want to create a moving trigger which only tests the event against a static (maybe moving too) , selective and fewer objects then this could be the fastest way to do it. For things like projectiles etc. (without fiddling with physics layers)

The 3d colliders with rigidbody was still a lot faster which is pretty puzzling. Perhaps something about the Collider2D and Rigidbody2D that is very different than the 3D version like you have said is causing the issue. This leaves me to wonder what would be the best practice to do what other 3D collider scene is trying to do. It is obvious to me that I can't be using 1000 units using 2D collider + trigger this way.

The test is running 1000 units, and I am not saying this should be "normal". I perfectly understand that the average need of game may not be that many, and so the application may not be the practical usage. However, I also think it is worth while to notice this performance difference and know the difference and limitation so we can design, work around it to make best use of all.

Perhaps 3D physics runs faster because of Nvidia hardware physx acceleration...?

I am here to contribute at any time so please let me know what you think about it.

Cheers.

 

I am currently running with 5.5.0x3-2D experimental 2D build.