Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice

Collider partitioning with compounds

Discussion in 'Physics for ECS' started by snacktime, Dec 30, 2020.

  1. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,356
    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
     
    petarmHavok likes this.
  2. MicCode

    MicCode

    Joined:
    Nov 19, 2018
    Posts:
    59
    Have you do a benchmark? how much performance improvement this way?
     
  3. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,356
    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.