Physics cost with trigger Collider2D vs Collider

Unity Engine
1

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?

2

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.

3

A Collider2D without a Rigidbody2D is implicitly a static collider i.e. you should not move it. If you add a Rigidbody2D then move the Rigidbody2D and not the Collider2D itself (it’s offset or if it’s a child GO, the Transform). Colliders live in Rigidbody space which is why moving the body is what you should do.

1 Like
4

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?

5

Of course there is, I described what it is i.e. a Static collider. Even in 3D you’re not supposed to move it but there’s nothing stopping you. I’m not sure why you suddenly think this ‘feature’ isn’t available when you’ve already said you’re doing it. I see this all the time; trying to figure out someway to avoid adding a single Rigidbody component. No idea why this is; it’s hardly a hardship and I don’t particularly understand why it’s ‘cool’. :slight_smile:

In 5.5 you can set the body-type explicitly in the Rigidbody2D component so you can select static (not moving), Kinematic (not affected by forces) or Dynamic (affected by forces). When you don’t add a Rigidbody(2D), static is just selected implicitly.

There’s no reason not to do it correctly and add a Rigidbody2D set to Kinematic though.

The reason for the performance hit in 2D (Box2D) is that when you don’t add a Rigidbody2D, the collider is added to a hidden static rigidbody that lives at the world origin known as the ground-body. This means that the colliders geometry is effectively in world-space (the space of the body). This is not required in 3D (physx). When you manipulate the transform of such a collider, the collider needs to recalculate all that geometry and be recreated. If the collider is a PolygonCollider2D then those can be expensive to recreate (if you’ve got lots of them). If you add a Rigidbody2D the collider lives in the space of the body so all you need to do is move the body. This applies no matter what body type (Dynamic, Kinematic or Static).

The main thing to understand is that while this is Unity as a single product, the sub-systems are provided by completely different things; in this case Box2D and PhysX. Whilst we endeavour to create a decent amount of feature parity, they are not the same thing and not everything works the same.

1 Like
6

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.

7

Can I ask why you adding a single component is such a problem that you need to move to 3D physics? It just doesn’t make any sense to me is all.

8

I’m confused by this!! Add a Rigidbody2D set to be Kinematic and do the same i.e. update the Transform then there’s no penalty as you’re moving the body not the collider geometry.

9

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

10

The performance cost of having a Kinematic Rigidbody2D added? I am not aware of any cost of adding such a Rigidbody2D. Same way it wouldn’t if the Rigidbody2D were set to be Static body-type.

11

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.

12

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

13

It’s extremely cheap to move a Kinematic Rigidbody2D via the Transform.

14

I got my laptop opened up so I can type better :smile:

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.

15

Thanks, that clarifies a lot.

So what I’d like to understand is exactly what is slower and is causing the issues you see. There are obviously many aspects to the two physics systems that have nothing to do with having an extra/less dimension. For instance, simply moving a collider (or rigidbody) involves updating its position in the broadphase. I’m wondering if you’re testing movement of the rigidbody including collisions or not.

Also, there are things like ‘moving’ meaning modifying the Trasform. If modifying the rotation/scale then all colliders need to be completely recreated in 2D, not so if only the XY position is updated.

As I say, I’m interested in seeing the set-up here. If you have the test project you’re using for the comparison then it’d be great to have a look at it to see if there’s something obviously that’s causing the issue.

16

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.

2 Likes
17

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. :smile:

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. :smile:

Cheers.

18

Thanks, I appreciate the effort you’ve put in to test this. First few days after Xmas break here so it’s a little busy but I’ll grab your scene and I’ve put it on my whiteboard to look at ASAP so it won’t get forgotten about!!

BTW:

Unity PhysX runs on the CPU for cross-platform compatibility, it doesn’t use hardware accelleration although it does run off the main-thread.

Final question for you; what version(s) have you been testing this with?

19

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

20

Okay, far from the latest code but I’ll check the difference using that version nevertheless.

1 Like