Search Unity

  1. Megacity Metro Demo now available. Download now.
    Dismiss Notice
  2. Unity support for visionOS is now available. Learn more in our blog post.
    Dismiss Notice

Changing Collision filter Behaviour

Discussion in 'Physics for ECS' started by Thygrrr, Dec 2, 2020.

  1. Thygrrr

    Thygrrr

    Joined:
    Sep 23, 2013
    Posts:
    699
    So CollisionFilter is currently implemented like that:
    Code (CSharp):
    1. // Return true if the given pair of filters want to collide with each other.
    2.         [MethodImpl(MethodImplOptions.AggressiveInlining)]
    3.         public static bool IsCollisionEnabled(CollisionFilter filterA, CollisionFilter filterB)
    4.         {
    5.             if (filterA.GroupIndex > 0 && filterA.GroupIndex == filterB.GroupIndex)
    6.             {
    7.                 return true;
    8.             }
    9.             if (filterA.GroupIndex < 0 && filterA.GroupIndex == filterB.GroupIndex)
    10.             {
    11.                 return false;
    12.             }
    13.             return
    14.                 (filterA.BelongsTo & filterB.CollidesWith) != 0 &&
    15.                 (filterB.BelongsTo & filterA.CollidesWith) != 0;
    16.         }

    and I would like it to be implemented like this (hint: for sparsely populated worlds, this gives you free multiple physics worlds):
    Code (CSharp):
    1. // Perform check only if Colliders are within the same group. Yay, free multi physics worlds (if sparse enough), zero configuration required.
    2.         [MethodImpl(MethodImplOptions.AggressiveInlining)]
    3.         public static bool IsCollisionEnabled(CollisionFilter filterA, CollisionFilter filterB)
    4.         {
    5.             if (filterA.GroupIndex == filterB.GroupIndex)
    6.             {
    7.                return
    8.                 (filterA.BelongsTo & filterB.CollidesWith) != 0 &&
    9.                 (filterB.BelongsTo & filterA.CollidesWith) != 0;
    10.             }
    11.             return false;
    12.         }
    13.  
    How could I properly do this?

    Yes, this is more about "how to use and extend the Unity Physics package", because the CollisionFilter.cs file lives in PackageCache, and I'd literally just want to override this one behaviour but not keep a whole copy of all of Unity.Physics somewhere in my project (or at least - tell me how would I do THAT properly?)

    I'm considering forking the git repo, but I'm not sure if the License even allows this modification.
     
    Last edited: Dec 10, 2020
  2. Thygrrr

    Thygrrr

    Joined:
    Sep 23, 2013
    Posts:
    699
    Well oof, CollisonFilter is part of the (shared) BlobAssetReference for the collider.

    I want to keep my mesh and compound colliders non-unique (too many of them!), but I totally don't want to keep the filters shared. WHO WOULD EVER WANT THIS? (this is in the same category as RenderMesh, an ISharedComponentData, containing the layer, instead of a RenderLayer component, by the way, but I digress)

    CollisionFilter should of intuitively be a separate component. What good are the filter settings for it then, even, if they can't be temporarily changed (except for all that share this collider).

    Unless I am fundamentally mistaken about how this works... I wonder how much memory overhead unique colliders bring. But I also didn't want to write into BlobAssets in my physics systems (even though these writes are rare-ish).
     
    Last edited: Dec 3, 2020
  3. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,356
    Not sure what you are trying to accomplish in the first post. But what you want is the package manager development tools package. That provides a button to move a package out of the package cache so you can make changes.

    For collision filters you can clone the collider as mentioned https://forum.unity.com/threads/modifying-physicsshapes-collisionfilter-at-runtime.880648/.

    And the filters are like they are for performance reasons. And there are probably good solutions for whatever specific challenge you have so I would just post them as you hit them. Physics team is very helpful.
     
    Thygrrr likes this.
  4. Shane_Michael

    Shane_Michael

    Joined:
    Jul 8, 2013
    Posts:
    158
    That sounds useful. I found something called "JCMG Package Tools". Is that what you are referring to?
     
  5. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,356
    Had to go look it up, actual package is com.unity.upm.develop.
     
    Thygrrr and Shane_Michael like this.
  6. Thygrrr

    Thygrrr

    Joined:
    Sep 23, 2013
    Posts:
    699
    Thank you VERY much for the package manager tools recommendation. :)

    Multiple physics worlds (layers) without multiple ECS worlds, easy as that. The change would make it so the normal layering still works, but I can wholesale separate the worlds but simulate them all at once. I expect negligible overhead, in fact, the logistics of instantiating, managing, and updating many physics worlds (as in, ECS worlds) sounds daunting if instead I could get it with zero setup time as soon as I want a new world - just assign a new group index.

    32 layers is not enough, otherwise I could fudge it with the belongs to field. (I generally need 2 or 3 belongs tos per world so... It would get messy, and moving this one line should fully resolve the issue. (Proof pending...))

    My physics worlds are quite sparse, but there can be hundreds of worlds with on average perhaps less than a dozen bodies, occasionally though hundreds in them.

    Collisions are very rare (space game), so the overhead from the layering would be negligible (the BVH should take care of the vast majority of culling either way)...

    Primarily I need unity physics to deal with collisions, really. (Both from queries as well as between objects), but getting the linear and angular velocities and the inertia tensors for free is a nice bonus.

    But ... is that a deep copy? Or how deep? I do not want to duplicate all the compound colliders and mesh colliders in the game times the number of entities.
     
    Last edited: Dec 3, 2020
  7. brunocoimbra

    brunocoimbra

    Joined:
    Sep 2, 2015
    Posts:
    679
    Wow, I never used the GroupIndex as I never needed, but I thought that it already worked like your proposal o_O
     
  8. Thygrrr

    Thygrrr

    Joined:
    Sep 23, 2013
    Posts:
    699
    Sadly it doesn't, it's oddly counterintuitive and I wonder why they did it that way. It's helpful to have that level of fine control, but... it would always glob over all layers at once, meaning the actual uses are quite limited.

    Proper physics groups make much more sense. I'll try tonight and tomorrow to get it to work and do a few performance tests.
     
  9. snacktime

    snacktime

    Joined:
    Apr 15, 2013
    Posts:
    3,356
    It doesn't sound like you have enough query volume to even need multiple worlds. Single world filter out hits from other areas/regions is going to work fairly well with bodies spread out.

    But... Specific best approaches here depend a lot on details not mentioned. Partitioning on worlds is actually not a great solution for most scenarios, there are other approaches that scale significantly better in almost every dimension.

    For example if you can get away with static physics bodies that opens up a number of approaches. And static here doesn't mean not moving.

    Region per world approaches imply quite a bit of overhead regardless of body type. If it's dynamic/kinematic stepping overhead is non trivial with a lot of worlds. If it's static bodies then you don't need a physics body per logical body, you can just use a small pool and move into place and query for example. Since physics is generally local you can use partitioning schemes inside a world also.

    We use something like the above to scale several hundred regions that each have upwards of 100k bodies and up to 200 moving bodies. We do that with around a dozen worlds for peak demand and a pool of around 100 colliders total. That scales in all dimensions by bodies actually involved in queries, or very close to it.
     
    Thygrrr likes this.
  10. Thygrrr

    Thygrrr

    Joined:
    Sep 23, 2013
    Posts:
    699
    Wow, thank you these insightful ideas - for this prototype, rejecting physics collisions may be a practicable solution indeed. I'll try it, it's mildly favorable over forking Unity Physics (even if the fork is a trivial change).
     
  11. petarmHavok

    petarmHavok

    Joined:
    Nov 20, 2018
    Posts:
    461
    I just want to add this is a very interesting suggestion on how one can leverage collision filters in a different way. We'll definitely discuss this internally.
     
    Thygrrr likes this.