In Unity3D, and others, there are Layer Based Collision System which makes collisions only happen between specified Layers.

It defaults to all layers colliding with all others.

Does making use of these setting decrease performance, or increase performance?

I could imagine it decreases it if every potential collision had to be checked for it's layer. Or are those collisions completely bypassed?

  • \$\begingroup\$ I didn't know you could disable and enable layer based collision. How do you do that? \$\endgroup\$ – S. Tarık Çetin Dec 14 '17 at 12:27
  • \$\begingroup\$ @S.TarıkÇetin the link up there explains it well :) \$\endgroup\$ – Alexandre Vaillancourt Dec 14 '17 at 12:54
  • 1
    \$\begingroup\$ @S.TarıkÇetin Ah, you're right, it doesn't seem that you can enable/disable the layer based collision. I think the OP meant actually changing the collision interaction between the layers. \$\endgroup\$ – Alexandre Vaillancourt Dec 14 '17 at 13:33
  • 1
    \$\begingroup\$ @S.TarıkÇetin Alexandra is correct, my original wording was misleading, implying that it could be turned on. It is always active; I meant to ask if removing layers from the default (all on) configuration would affect performance. I had re-worded the Question for future viewers \$\endgroup\$ – Jethro Dec 15 '17 at 9:39
  • 1
    \$\begingroup\$ Fyi for people searching the same functionality in UE, it's called collision channels. The help page also confirms that it has a positive performance impact. \$\endgroup\$ – Pieter De Bie Dec 21 '17 at 9:26

Does making use of this setting decrease performance, or increase performance?

It (generally) increases performance. If you only have a handful of colliders in a scene, this could result in a slight performance hit, but it wouldn't be noticeable. Best practice is if you don't ever intend two layers to interact with each other, go ahead and disable it in the Matrix.

I could imagine it decreases it if every potential collision had to be checked for it's layer. Or are those collisions completely bypassed?

Your assumptions are correct.

The Matrix is a filter on objects: If the object currently being checked belongs to this group, then check for collisions against object belonging to checked groups.

This means, for layers where you've disabled some collisions in the matrix, you are only checking for collisions between subsets of the colliders in the scene. Since there's less checks to perform, you gain some performance.

This is really only necessary as a performance optimization when you have a large number of objects in a scene. Most of the time this is used to support game functionality. For instance if you want bullets to only impact with players and walls, but not balloons that get pushed around the room by players as they move.


I could imagine it decreases it if every potential collision had to be checked for its layer. Or are those collisions completely bypassed?

I don't have the first-hand knowledge about how Unity handles its internal connections with PhysX, but I imagine those layers would be bypassed. If anything, I imagine disabling collisions between layers should increase the performance since the physics engine would have fewer calculations to perform.

On the other hand, I imagine this question is a typical scenario of premature optimization, which I usually interpret as trying to optimize your code without actually even having a working code.

Instead of trying to predict the performance effects, I would suggest building a test project and actually measuring it.

Even better, forget about optimization and build your game. After you have a game that works but runs at 2 FPS, then you can begin optimization phase with a clearer state of mind.

  • \$\begingroup\$ I generally agree with the answer, except the premature optimization part: There is genuine premature optimization, which I interpret as "making an effort to optimize code just for the sake of optimizing it; without any real necessity or measurements of the effects", and then, there is something almost completely different, which is to set-up and structure the project the way it should be set-up and structured, as you're building it. --- Ignoring the structure or settings of the project while building it, will lead to having to restructure/revise the whole project later (very bad). \$\endgroup\$ – XenoRo Dec 14 '17 at 14:20
  • \$\begingroup\$ @XenoRo Good point! I agree with you on deciding the structure of the project beforehand, but I don't think these decisions should be based on performance. In my humble opinion, performance problems are much easier to fix than other problems in code; since for performance problems, you would have a clear idea of what the problem is without much investigation thanks to the Profiler. \$\endgroup\$ – S. Tarık Çetin Dec 14 '17 at 14:34
  • 1
    \$\begingroup\$ I agree with that. The problem is that, if you build the game with everything on the standard layer, and more importantly because you've built the game with everything on the standard layer, you will have a nightmare on your hands when you try to separate those layers. You will have to go around every object, maybe every script, in the project, trying to hunt down what fits where regarding physics collision-detection. --- An approach where you do things right from the start will avoid that headache. --- PS: I'm not talking about performance here; the profiler is useless in this case. \$\endgroup\$ – XenoRo Dec 14 '17 at 14:55
  • \$\begingroup\$ Just as a note: "I imagine disabling collisions between layers should increase the performance (...)" in the first part of the answer is absolutely correct. In fact, using different layers and setting up the collision-matrix such that each layer only tests against the layers that it needs to test, is what unity recommends in the Physics Best Practices documentation, exactly because it, as already mentioned, avoids the physics engine having to test between stuff that's not meant to collide in the first place. \$\endgroup\$ – XenoRo Dec 14 '17 at 15:04

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.