Should I use custom Box colliders or automatic edge colliders?

[Shade]

first off, I've used the 2d toolkit in the past and it's a fantastic asset.

I'm trying to decide what the best approach for another project should be though. In a nut shell I'm trying to build a 2D destructible tile game. The question I have is based on the idea that turning on and off colliders is expensive, but is it more expensive than editing the auto-generated edge collider that tk2d will create? In order to understand the other solution I'm referencing, a picture is worth a thousand words:

https://gyazo.com/4a1c8502db32a176303135e9b40ba539

The idea here would be to generate a box collider for every tile, but as depicted, only those tiles that are on the edge would have their colliders turned on. Destroying an edge tile would make a call to at most 3 other tiles to have their colliders turned on. This seems a reasonable approach to me, but I'm not certain about the application.

While trying to implement the box colliders I noted that the auto-generated edge colliders exist within each chunk of data. I'm not certain of how to obtain the actual chunk object in-order to store the collection of box colliders on it.

Code: [Select]

tileMap.Layers[layerId].GetChunk(x, y); where x,y is the tile coord.
This seems like the right path, but GetChunk returns a tk2dRuntime.TileMap.SpriteChunk which I could find no documentation on.

I figured storing the colliders on the chunks would be an effective way to at least organize where the colliders are based on the mesh they represent, but I guess they don't have to be.

any insights would be much appreciated.

[unikronsoftware]

tileMap.Layers[layerId].GetChunk(x, y);

The tile doesn't exist as a gameobject, thats why the tilemaps render so efficiently - it batches tiles into chunks of tiles. The best way to do this is to create a pool of gameobjects with the box colliders on them (and only that), and position them using GetTilePosition. Be sure to turn off all physics on the tilemap, its way more efficient doing it this way with box colliders.

[Shade]

Hey, thanks for the response.

I've been going down the path of creating a box collider pool and like you said the best way to position the tiles is through the tile positioning.

Here's what i'm toying with right now:
(only trying to draw colliders on edges as shown)
it's 100 x 100 tiles
with 863 box colliders on just one game object.
builds in roughly a second, not optimized.





I tried scaling up to 448 x 128 tiles which is 57K tiles with 4700 colliders and the build time is pretty bad, 20 seconds or more. This may be due to naive coding approaches, but I can't help but think that 4700 colliders on one object is probably bad for performance.

I'm still wondering how to get at the chunk object, not the individual tiles, to store the colliders for that chunk so that I can possibly optimize by turning on and off colliders very far from the camera.
tileMap.Layers[layerId].GetChunk(x, y);  This returns a type of SpriteChunk. How do I access the GameObject with this? is it actually a GO that I can just use a simple cast or what? 

Just to be absolutely clear, I'm saying I want to Isolate the colliders that fall within the chunk and have only those colliders stored on each chunk with the mesh data. pic has the first chunk selected and the colliders.

[unikronsoftware]

Hi there,

When we last implemented this we optimised for the scene viewport and a bit more. Basically we have a gameobject in the scene at 0,0,0, and attach and remove gameobjects with a boxcollider from a pool. As the camera moves, we remove one strip at a time from the X / Y axis and move it to the new right hand side and reposition as need. Its really fast and probably the most efficient thing you could do.

2nd - note that its much easier and more efficient to have multiple gameobjects with a box collider each. That way you can pool the gameobjects on startup and only ever create ones when you have run out of things in the pool.