Collider partitioning with compounds

Threw this together for optimizing a very large number of static colliders that we have. Instead of adding a physics collider to your entity you add the collider to the partition system, which adds your collider to a compound partition.

It's designed for static or at least colliders that aren't changing too often. Assumes colliders do not occupy the same position the hashing has 2 digit precision.

Basic flow is you add colliders to the system with the entity you want them linked to. The linked entity being an entity that would otherwise have a physics collider.

ChildMapComponent is a (logically) singleton entity you can use to lookup a child by hit information and it will return a ChildColliderInstance with the linked Entity, and/or whatever else you want to extend it to hold.

ChildMapComponentLookup uses ComponentDataFromEntity for job based access.

Removal from the partition can take the original position, the linked entity, or a NativeArray<Entity> of linked entities.

Partitions are designed to be game scoped and live through multiple scene changes. The system has a ClearPartitions() method you can call to clear all the data but leave the partition entities intact. When there are no colliders in a partition it uses a small sphere collider placed at -1000. This avoids some additional complexity and entity creation/destruction that would otherwise be necessary.

https://gist.github.com/gamemachine/0db9891b9ea4793adb13ab1f4da04e27

 

Have you do a benchmark? how much performance improvement this way?

 

Static rebuilds are cheaper. But more likely it will be feature specific per collider costs that will be an issue at a certain scale. You don't need something like this for the average use case. You probably don't need it even for the average lots of static bodies case.


Our scenarios is as follows:
- Several hundred thousand dynamic objects that don't live in ECS proper as entities/components.
- Large variety in object type, around 200 or so.
- Multiple collider sizes per object type in some cases(vegetation/rocks that have variety in scale).
- Worst case it's all loaded over the network on scene load.

So it was details like the core data not being in ECS and collider variety that drove the design. And scene loading times being the main pain point. Like batch entity creation is completely thwarted by the collider variety.