Collider combining at runtime?

TrentSterling
Member
Registered: 2014-04-07
Posts: 28

Topic

Not sure if the API already supports this, but I had an exchange on twitter recently that makes me want to post this here:

https://twitter.com/Trent_Sterling/stat … 9333867520

Basically, it'd be nice to have the simplified 2d colliders by just hitting play, and waiting a moment for the combining, Or perhaps trigger it through code? Is this already a possibility?

Lea Hayes
Rotorz Limited
From: United Kingdom
Registered: 2014-03-04
Posts: 638

Response 1

Hi Trent

The class ReduceColliderUtility was exposed into the runtime library in a recent release which means that you could create an editor script which listens for play mode changes to make these changes. Be warned, if the changes occur in "edit mode" then they cannot be reversed (other than by manually refusing to save changes to your scene).

Alternatively you could perform this process at runtime, which might be great during development but for production will incur longer loading times (duration of optimization + static collider overhead due to changes made to static colliders) and slightly larger build sizes (since builds would contain a larger quantity of colliders).

I hope that this helps!

TrentSterling
Member
Registered: 2014-04-07
Posts: 28

Response 2

That's exactly what I was looking for. And I figured there'd be a risk of blowing away the scene if it saved at the wrong time. Is there some way to recover/rebuild a tilesystem from some kind of serialized version of the mapdata somewhere? It won't be an issue for me to implement this- but I wonder if theres some way to make this feature easier/safer for others?

Lea Hayes
Rotorz Limited
From: United Kingdom
Registered: 2014-03-04
Posts: 638

Response 3

TrentSterling wrote:

but I wonder if theres some way to make this feature easier/safer for others?

If the tile data has not been stripped then you could loop through each of the tiles and restore collider components and configurations by looking at the tile prefabs. This probably wouldn't be straightforward and of course intended manual tweaks would be lost.

A safer approach would be to save the collider states to a custom component BEFORE using this utility, and then restoring them afterwards from that custom component. Also, if the Unity editor explodes, the original collider state is retained. If the Unity editor doesn't explode, then you can use your component to revert all affected colliders.

In either case, its wise to ensure that you are in play mode before performing this optimization. In fact, the serialization shouldn't be needed if you perform the optimization inside an Awake() method.

Last edited by Lea Hayes (2014-12-17 23:49:46)

TrentSterling
Member
Registered: 2014-04-07
Posts: 28

Response 4

Well that sounds like what I'll do. I think having the collider optimization stuff is really nice. Once you get bigger tilesystems, it can get pretty heavy. I do think I'll serialize and rebuild everything going back and forth between playmode and edit mode.

I think it's funny that someone contacted me on twitter about your tool. I suppose I've been praising it a lot wherever I go.

I'm curious to see how many people use manual offsets. When I refresh tiles, I always end up unchecking those options and I always keep things locked to my grid.

Lea Hayes
Rotorz Limited
From: United Kingdom
Registered: 2014-03-04
Posts: 638

Response 5

TrentSterling wrote:

I think it's funny that someone contacted me on twitter about your tool. I suppose I've been praising it a lot wherever I go.

Thanks for your help on both accounts; it is greatly appreciated!!

TrentSterling wrote:

I'm curious to see how many people use manual offsets. When I refresh tiles, I always end up unchecking those options and I always keep things locked to my grid.

In my experience a LOT of people are using manual offsets since it's often easier and quicker than correcting the original tile meshes themselves.