2d collider auto-tiling and composite collider permormance

Hi everyone. I’m making platformer-like physics based mobile puzzle and I have a couple of questions regarding physics performance (because it’s more critical on mobiles):

  • What’s performing better on the image below, 1) or 2) ? I’m asking because for 1) I’m using auto-tiling option on a collider so it makes additional sections when I tile a sprite. Are those sections like separate colliders (because they look like they are in the editor) and therefore they consume additional resource or it’s just a representation of auto-tile option in the editor and in the build I will have one single collider instead? For 2) I’m using a tiled sprite and manually adjusted single collider.

  • Imagine I have a castle-like level with walls, ceiling, floor, platforms etc.All those things are obstacles and in the hierarchy they’re children of the Castle object (plain object with no extra components). All obstacles have colliders on them. Is there any point (performance wise) to create a composite collider on the Castle object so it will get composed from child colliders ? Player walks inside the castle and can collide with any obstacles. Doesn’t composite collider add extra complexity during the collision checking? Like first take the composite collider then check all its child colliders instead of just checking all children colliders separately?

Thank you in advance, hope my questions are not too lame

It happens that I got my answers on Unity forums so I share it here (thanks to MelvMay from Unity):

What’s performing better?

This is too much of a general question that’s almost impossible to answer without understanding how it’s being used.

You can go to any collider in the inspector > Info and see the physics shape count. Yes, you’ll get multiple shapes with slicing sometimes same as you do with (say) a PolygonCollider2D. The physics system knows nothing about Unity colliders, only its primitive convex shapes. Each shape takes a trivial amount of memory yes but we don’t do anything crazy like iterate all shapes in the physics world each update. A static physics shape has no continual CPU overhead. If they are moving then yes there’s a small overhead but the same goes got a PolygonCollider2D or TilemapCollider2D etc.

Static in physics means not moving so it won’t move via physics and you shouldn’t move the GameObject transform either. Note that this has nothing to do with the “Static” checkbox related to a GameObject. Go to the Rigidbody2D in the inspector and look at the BodyType property to see it. Note that you can explicitlly select Static body-type here but also Unity will use a Static body implicitly if you don’t add a Rigidbody2D.

The CompositeCollider2D doesn’t know about children/parents or anything like that. In the end, the physics system (Box2D) does its thing and is not bothered by how the Unity Transform hierarchy is set-up. It’s just physics shapes.

Go ahead and create a composite with thousands of shapes. After it’s created, it has no work to do. Any collisions happen on a per-shape basis, it doesn’t have to iterate all the shapes or anything crazy like that. This is what the broadphase is for which is an acceleration structure designed so that you can quickly query regions to find what might be there before you have to perform a more expensive geometry test (narrow-phase). In short, it’s no faster/slower to query a composite/polygon-collider/tilemap that has 10 shapes than one that has 1000 shapes.

In the end, set-up a quick test a run the profiler to find performannce info out.

Why use a composite collider?

It can take the geometry of multiple colliders and merge it all into a single collider for you to deal with hence the name “composite”. By merging the geometry it can take advantage of producing (potentially) simpler geometry (due to merging of edges etc), it can also generate polygons or continuous edges (chosen by you). Continuous edges don’t suffer from the problem of ghost collisions where you seem to catch edges of colliders even though they are aligned. The shape-count I mentioned previously will generally be less than the individual collider shapes. A lot less as the number of colliders and shared edges goes up. For instance, in a TilemapCollider2D. Another advantage is that the individual colliders (box, polygon) calculate their geometry when they are created (level load, creation etc). If they are attached to a composite, this doesn’t happen as the geometry calculated is stored so it’s faster from start-up to getting the geometry into the physics system.

The downside is that, of course, this acts like a single collider now as the individual colliders have no shapes and the colliders are effectively not there as far as the physics system is concerned.

There are multiple shapes if I use auto-tiling but they are not hitting the performance. You say that Unity doesn’t iterate all shapes, but how could you know then that, say, a ball collided with an object I have as 1) on my screenshot if you don’t iterate all its shapes? Is that really possible?

This is a question of how physics engines work really. I already described this though but I’ll ellaborate a little more. It’s using something called a broadphase and is what is known as a spatial acceleration structure i.e. it allows a quick aproximate check to see if something is possibly within a region without the need to perform the more costly “narrowphase” check to see if stuff really does contact. There’s lots of info online you can read up on this. Search for “broadphase” and “narrowphase”.
You’re focusing on how what you see works but the physics system doesn’t work like that. By this I mean the physics system doesn’t ask questions like the bounding box of a collider because it simply doesn’t know about them; it only knows about primitive physics shapes as I’ve said so If you have a Unity collider with thousands of physics shapes and you perform a query in a certain area, it goes to the broadphase and asks and it gets the answer super quick because the broadphase stores physics shapes based upon their AABB so can quickly determine if it’s a potential candidate for collision and knows nothing about Unity colliders. Each physics shape references the Unity collider it belongs to so results can be related to Unity colliders but this is just user-data we store. This potential candidate check is super quick and typically involves navigating a tree structure which in a few steps can find appropriate AABB very quick.

Does having more shapes have a performance impact of any kind? Yes, of course because everything does but changing a performance impact to a one-off or continuous impact changes how/if it affects you. In Box2D moving 1000 physics shapes has an impact as they have to be updated in the broadphase but there’s more complex stuff going on to greatly reduce this cost. If it’s not moving then there’s no cost.

I don’t want to go into anymore detail as much more detailed info is online as I said. Here’s the 2D physics engine broadphase for Box2D known as a dynamic tree which is a tree-based bounding volume hierarchy.

Hey Thanks for posting, I may need to re-read it. But basically, the amount of child colliders in the parent composite collider will not affect performance if those colliders are not moving which is pretty much the case in a terrain/map.