Is there performance difference between OnCollisionEnter and OnTriggerEnter? I have around 12 objects all calling OnCollisionEnter when in fact OnTriggerEnter could work as well. So I wonder if the are is any difference PERFORMANCE WISE between the two


1 Answer 1


Calling the methods themselves should not really matter. The physics system figures out there is a rigidbody collision / trigger collision and after that it figures out if the objects in question implement the respective handler methods. Yes, the OnCollision* methods receive a Collision object which contains far more information about the collision event than you have in the OnTrigger* methods, and that object must get constructed, no matter if you actually need all that information or not. But it's all information which is available anyway from detecting the collision, so we are talking about just a hand full of CPU cycles here.

But it's the detection itself which might matter. OnCollisionEnter only triggers for rigidbodies. Managing a rigidbody require far more physics calculations than managing a simple trigger collider. So you might want to reconsider if all the objects which got rigidbodies in your scene actually need them or if a simple trigger would also do the job (or if you at least can make the rigidbody kinematic to absolve the engine from calculating forces you don't actually want anyway). Generally speaking, you can use a trigger when you have an object which doesn't interact physically. For example, if you would create a modern clone of Super Mario Bros, then:

  • Mario would have a rigidbody, because you want to be able to detect collisions between Mario and triggers and between Mario and other rigidbodies.
  • The Goombas would have rigidbodies, because when Mario jumps on them, he bumps off a little. This can be easily implemented as a physics collision with a bouncy physics material. The data from the Collision object passed to OnCollisionEnter would also be useful for deciding whether Mario collided with the Goomba from above or from the side.
  • The coins would have trigger colliders instead of rigidbodies, because Mario's movement isn't affected when they are collected.
  • Regular blocks would have rigidbodies marked as kinematic, because although they do not move themselves, they do block the movement of other rigidbodies like Goombas or Mario.
  • 2
    \$\begingroup\$ Just to add to this (which is kinda covered when you talked about rigidbody costs) is that collision often implies it will be resolved. This technically also takes time. It depends on the system but I believe Unity(Box2D) is using an iterative solver, so this can impact performance. \$\endgroup\$
    – gjh33
    Commented Mar 20, 2019 at 13:27
  • \$\begingroup\$ They are 2D so I don’t have the kinematic option. I rather froze all the constrains, if that is considered kinematic \$\endgroup\$
    – Joe Robert
    Commented Mar 20, 2019 at 16:54
  • \$\begingroup\$ @JoeRobert You can set a Rigidbody2D to kinematic. It's the "Body Type" combo box in the inspector. Activating all the constraints will likely not have the same effect. \$\endgroup\$
    – Philipp
    Commented Mar 20, 2019 at 17:51

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .