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

Feature Request CollisionFilter as a separate IComponentData

Discussion in 'Physics for ECS' started by scottjdaley, Mar 14, 2023.

  1. scottjdaley

    scottjdaley

    Joined:
    Aug 1, 2013
    Posts:
    160
    I've been working with ECS for a couple of years now and I've run into several use cases where I want to change what an entity can collide with, either temporarily or permanently. It seems like something that should be relatively simple to do, but is surprisingly difficult.

    For context, here is what change collision filter system might look like:

    Code (CSharp):
    1. public partial struct ChangeCollisionFilterSystem : ISystem
    2. {
    3.     private NativeList<PhysicsCollider> _createdColliders;
    4.  
    5.     [BurstCompile]
    6.     public void OnCreate(ref SystemState state)
    7.     {
    8.         state.RequireForUpdate<MyEntity>();
    9.  
    10.         _createdColliders = new NativeList<PhysicsCollider>(Allocator.Persistent);
    11.     }
    12.  
    13.     [BurstCompile]
    14.     public void OnDestroy(ref SystemState state)
    15.     {
    16.         foreach (PhysicsCollider collider in _createdColliders)
    17.         {
    18.             collider.Value.Dispose();
    19.         }
    20.         _createdColliders.Dispose();
    21.     }
    22.  
    23.     [BurstCompile]
    24.     public void OnUpdate(ref SystemState state)
    25.     {
    26.         Entity entity = SystemAPI.GetSingletonEntity<MyEntity>();
    27.         var collider = SystemAPI.GetComponent<PhysicsCollider>(entity);
    28.         BlobAssetReference<Collider> colliderCopy = collider.Value.Value.Clone();
    29.         CollisionFilter filter = colliderCopy.Value.GetCollisionFilter();
    30.         filter.BelongsTo = 16;
    31.         colliderCopy.Value.SetCollisionFilter(filter);
    32.         PhysicsCollider newCollider = colliderCopy.AsComponent();
    33.         _createdColliders.Add(newCollider);
    34.         SystemAPI.SetComponent(entity, newCollider);
    35.     }
    36. }
    This code isn't super complex, but it highlights a couple of problem areas that new ECS users can easily run into.
    1. It is not obvious that SetCollisionFilter() is going to modify ALL entities using that particular collider. This makes sense because the baking systems use a blob asset store to deduplicate colliders, but this detail is hidden from the user. If you only want to modify one collider, you have to call Clone first.
    2. Calling Clone creates a new blob that must be disposed of when no longer needed. The comments for this function do call this out, but it is annoying to deal with. This problem is even more complicated when considering saving and loading the game and restoring the correct colliders.

    I understand the rationale for storing colliders as blobs. Colliders are sometimes primitive shapes but can also be large meshes. Storing this data outside of a component makes a lot of sense to save on memory. It isn't super common (at least for me) to have to change a collider shape and often there are better alternatives like swapping an entire prefab.

    However, the CollisionFilter is something I'm wanting to change a lot. For example, if I want the player to pick up an object, I may want to temporarily disable collision on the object, but still be collidable with cursor raycasts. It feels like I should be able to just modify an integer on a component somewhere. But instead I have to clone the entire collider and make sure I correctly handle the lifetime of it.

    Internally, a CollisionFilter only contains three integers. Even if it would increase the size of entities slightly, I feel like moving CollisionFilter to its own IComponentData (not in a blob) would reduce a lot of the complexity here. Abstractly, this also makes more sense to me. When I think of a "collider" I think of the physical shape and bounds of the object. A "collision filter" describes how that collider interacts with the world which is a separate concept from the collider itself.

    If it is too late to change something like this, an alternative suggestion would be to add a PhysicsCollisionFilterOverride component added that functions similarly to the existing PhysicsMassOverride, but for override collision filters instead of changing kinematic/dynamic. This PhysicsCollisionFilterOverride would simply contain a CollisionFilter inside of it, no blob required. This component would be optional, but if present the physics system would use the override collision filter for all physics calculations.

    I realize that there might be some internal complexity with both suggestions (especially considering stuff like compound colliders), but I hope that something like this is considered.

    Cheers!
     
    croixbk, toomasio, KANIYO and 8 others like this.
  2. Thygrrr

    Thygrrr

    Joined:
    Sep 23, 2013
    Posts:
    699
    ABSOLUTELY! I've been calling for this as well, it makes no sense (or at least creates some major inconveniences) to not just have this a copyable data, but instead just baked hard into some opaque BlobAsset.

    I assume there may be some limitations with compound colliders.
     
    Last edited: Mar 15, 2023
    daniel-holz and IsaacsUnity like this.
  3. IsaacsUnity

    IsaacsUnity

    Unity Technologies

    Joined:
    Mar 1, 2022
    Posts:
    94
    TL;DR: Work in Progress!

    Hey all, just wanted to share that we're hearing this loud and clear, there are some intricacies about collider and BlobAsset interactions we need to work out so that we can split out CollisionFilters and other related data components. In the most transparent manner, I think we have the right expertise on the team to figure out a solution, so do look forward to it! @daniel-holz @schembri-unity
     
    toomasio, KANIYO, Thygrrr and 5 others like this.
  4. scottjdaley

    scottjdaley

    Joined:
    Aug 1, 2013
    Posts:
    160
    Thanks for the response @IsaacsUnity!
     
    KANIYO likes this.
  5. daniel-holz

    daniel-holz

    Unity Technologies

    Joined:
    Sep 17, 2021
    Posts:
    277
    @scottjdaley : Hi! Just wanted to circle back to you here on this topic.

    We are currently discussing this issue and one thing that came up was that there is already a feature that would allow you to modify baked colliders without cloning them. This is the "force unique" feature that ensures that the collider blob assets are not shared.
    It is currently only exposed via custom physics authoring ("Force Unique" property of PhysicsShapeAuthoring) but we could provide a way to enforce this also for user-selected built-in colliders (e.g., with an extra ForceUniqueCollider authoring component that the user can add to their GameObject).

    I do realize that this means that collider blob sharing is deactivated for these colliders and that this can incur a potentially large increase in memory usage, but I still wanted to point it out in case you weren't aware of this option.

    Would that be an option in your case? Or do you think loosing the ability to share memory would result in a too high memory overhead if you were to enable this for all the colliders that could potentially require runtime filter modifications?
     
    scottjdaley likes this.
  6. daniel-holz

    daniel-holz

    Unity Technologies

    Joined:
    Sep 17, 2021
    Posts:
    277
    Another thing I wanted to mention is that while it is a great idea to move the CollisionFilter out of the collider blob into a component, it is unfortunately not easily possible to do that, for the simple reason that this would be incompatible with how compound colliders are structured at the moment.

    Since every child in a compound collider can have their own collision filter (and material for that matter), the data needs to live within the compound collider blob right now and be associated with their children. Eliminating this information from the collider blobs of the children would allow only a single top-level collision filter for the entire compound collider (within the PhysicsCollider component), which is not desirable since it would prevent people from using different filters for the children of a compound collider.

    We would likely need to redesign things here a bit more, e.g., via a clear split between what should go into shareable blobs (e.g., geometry only) and what should be provided as easily run-time modifiable components(e.g., collision filter and material). With that split in mind we could then build out collider functionality on the ECS component level rather than only inside the lower-level Collider blobs.
     
    scottjdaley likes this.
  7. TheOtherMonarch

    TheOtherMonarch

    Joined:
    Jul 28, 2012
    Posts:
    862
    I am having the same issues as @scottjdaley. In my case I think this would be a ok option for me.

    I have found blobs to be very hard to work with. They really don't interface well with ECS code.

    Forcing compound colliders is also very inflexible.
     
    daniel-holz and scottjdaley like this.
  8. daniel-holz

    daniel-holz

    Unity Technologies

    Joined:
    Sep 17, 2021
    Posts:
    277
    I understand. We are evaluating this data layout right now.

    Regarding compound colliders, when you say "forcing" do you mean that they get automatically created and this is opaque to the user, meaning the user doesn't know about it unless they understand the particularities of how this performance optimization works?
    Would you prefer an opt-in approach here rather than this automatic choice made by the baking systems?
     
    scottjdaley likes this.
  9. TheOtherMonarch

    TheOtherMonarch

    Joined:
    Jul 28, 2012
    Posts:
    862
    I would like away to be able control how compound collider are baked. Even allow for multiple compound colliders. Or keep some parts separated. So that they can be affected by hierarchical transforms and other entity level transformations.

    Not all of my entities need to be super optimized. Units and characters can be heavy weight.
     
    Last edited: Jun 6, 2023
    daniel-holz and scottjdaley like this.
  10. scottjdaley

    scottjdaley

    Joined:
    Aug 1, 2013
    Posts:
    160
    Thanks for the detailed response!

    I was aware of Force Unique, but I don't think it would be the best option for my current project. I'm making an automation game that features hundreds of identical objects and I occasionally want to temporarily edit the collision filter of a single object. Like you mentioned this would have a dramatic effect on the memory usage since every objects needs to duplicate the static collider geometry (although I mostly just use sphere and box colliders so it might not be too bad).

    Yeah, I totally understand that this would be a complicated change, especially considering compound colliders. Personally, I don't use compound colliders so its unfortunate that the API has to be more complicated to support them. I'm assuming that storing the child compound collider information in the blob is an optimization to avoid a lot of random data lookups, but this feels like an optimization that comes at the cost of usability. Perhaps the CollisionFilter and PhysicsMaterial are separate from the Collider by default, but there is some kind of opt-in optimization to bake it all into a blob for when things are static (and advanced users would know how to clone blobs properly).

    Also, I'm curious what you thought of the PhysicsCollisionFilterOverride idea I mentioned in my original post. This would be a way to override the collision filter temporarily using a non-blob component. Just like the existing
    PhysicsMassOverride but for collision filters. I'm not sure how PhysicsMassOverride works with compound colliders, but I'd personally be fine with overriding the entire hierarchy. This idea seems like a simple way to address this problem in the short term before redesigning the entire collider workflow.

    I would definitely prefer an opt in approach for compound collider baking! Or at least give us a setting in the PhysicsShape authoring to control this. I managed to adjust my design to not need this anymore, but I previously had to resort to some baking hacks to prevent a hierarchy from being turned into a compound collider. Although I'm not actually sure its possible with the latest version of physics baking. If I understand correctly, this automatic compound collider was because child rigid bodies don't play nicely with physics so flattening and baking to a compound collider made sense. But for cases where we're not using rigidbodies, just colliders, it seems like we should be able to have child colliders. And from my own testing, it works fine to create (non rigidbody) collider hierarchies at runtime, but for some reason we can't bake hierarchies this way.

    Somewhat related to this discussion, but I would also like to have some way to temporarily turn off the rigidbody of a physics object. For example, I want the character to be able to pickup a loose item on the ground. Doing so would disable the rigid body, but keep the collider active. My workaround thus far has been to add and remove the PhysicsVelocity component, but this requires a structural change. Modifying PhysicsWorldIndex to be something other than 0 doesn't work because that also disables the collider. I'd love to see an IEnableableComponent that lets me toggle the rigidbody of a physics object so that I could avoid structural changes. The structural change for my particular use case isn't a huge deal since it isn't happening every frame, but it seems like it would be a nice addition to the API.

    Thanks again for listening to my feedback and discussing it!
     
    daniel-holz and TheOtherMonarch like this.
  11. TheOtherMonarch

    TheOtherMonarch

    Joined:
    Jul 28, 2012
    Posts:
    862
    Yes I think having a single rigidbody makes sense. Having a single compound collider on the other hand really affects usability.

    I also want to be able to do this for when passengers enter vehicles.
     
    scottjdaley likes this.
  12. daniel-holz

    daniel-holz

    Unity Technologies

    Joined:
    Sep 17, 2021
    Posts:
    277
    @TheOtherMonarch, @scottjdaley : Thanks to both of you for the added context. This is very helpful.

    Just real quick on the topic of temporarily "disabling" a dynamic rigid body, which both of you are interested in. You can achieve this without a structural change by turning it into a kinematic body.
    Here is how:
    upload_2023-6-7_16-41-27.png

    Modifying the
    PhysicsMass
    component on your dynamic rigid body this way gets the job done.
    Unfortunately that would require you to cache the previous
    PhysicsMass
    component but that is manageable since it sounds like what you are doing is already a stateful operation.
     
    TheOtherMonarch and scottjdaley like this.
  13. daniel-holz

    daniel-holz

    Unity Technologies

    Joined:
    Sep 17, 2021
    Posts:
    277
    @scottjdaley : Regarding the
    PhysicsCollisionFilterOverride
    idea, we do agree that this is the right direction but unfortunately with the compound collider situation it would make things half cooked. With this override you would essentially only be able to affect the entire compound and not its children, which, given the fact that currently the colliders are put into compounds in various scenarios, (static collider tree, rigid body that has multiple children etc.) could make this override feature both limiting and confusing.

    To make a link with the mass override feature: it acts only on the rigid body level (top entity level) since that's where the mass properties are defined. So, the hierarchical nature of compounds doesn't get in the way here, making that feature clean and complete.

    We continue to investigate this issue though. So stay tuned.
    In the meantime, I hope that the cloning approach and the force unique option as a workaround at least unblocks both you and @TheOtherMonarch.
    Let me know if this is not the case.
     
  14. scottjdaley

    scottjdaley

    Joined:
    Aug 1, 2013
    Posts:
    160
    Ah interesting, hadn't thought of doing it that way. Although, I'm assuming there are some performance implications of a kinematic rigidbody over a collider-only entity. I still think this could work well in some cases, but my primary use case is to disable dynamic rigidbodies of items when they are conveyor belts and then re-enable them when they are loose on the ground. I still want colliders on the items for raycasting, but I don't want to simulate them as dynamic rigidbodies. Since most of the items are on conveyor belts, I would prefer to not have the physics system iterating all of the items and doing kinematic calculations on all of them. The only time items need to toggle like this is when the player manually picks up or drops an item so its not happening every frame. So I think I'll stick with adding and removing the PhysicsVelocity component for now, but it is good to know that there are some other options!

    That makes sense, thanks for the explanation! I agree that it would probably be a confusing feature when considering compound colliders.

    Overall, it feels like there needs to be a way to control when you want static data or when you want to keep things flexible and easily editable. In a lot of cases, the colliders and collision filters are static so baking it all into a blob is the best option. But other times you want full flexibility and having it in raw non-blob components would be preferable. Even in the compound collider case, perhaps you would rather keep things in separate components on separate entities for flexibility even if that meant the physics system has to do a bunch of lookups for that child data. I think the same could be said for colliders. While mesh colliders probably only make sense as blobs, it would be nice to have easily editable colliders for the other collider shapes. AFAIK, the built-in non-ECS physics colliders support runtime editing of the colliders, such as changing the radius of a sphere collider. Seems like we should be able to opt in or opt out of baking all of this collider data into the blob when that is desirable.

    I'm glad to see that this is being looked into and I'm eager to see what you come up with! Thanks!
     
  15. TheOtherMonarch

    TheOtherMonarch

    Joined:
    Jul 28, 2012
    Posts:
    862
    Setting the values like you say and using a fixed joint is an option. I envisioned parenting entities rather than using a fixed joint. Parenting is what I did in my original MonoBehaviour code.

    When I make my characters into passengers I also need to remove or disable their capsule collider but leave their damage hit boxers. They are already kinematic bodies.
     
    Last edited: Jun 8, 2023
  16. n3b

    n3b

    Joined:
    Nov 16, 2014
    Posts:
    56
    Just my two cents here: if I'm not mistaken, the impact of having moving bodies is almost negligible. Creating collision contacts, which is the most computationally expensive operation in simulation, is worst-case O(n^2) (when all bodies are stacked in the same location), while dynamics is only O(n). The best approach you could take is to set the collider's RespondsToCollision property to false. This way, they will still be available for queries but won't contribute to collision calculations.
     
  17. daniel-holz

    daniel-holz

    Unity Technologies

    Joined:
    Sep 17, 2021
    Posts:
    277
    Most everything related to collisions is fully data parallel which is not the case for calculating the dynamics. The dynamics complexity in an iterative solver (which we are using) is O(k * m) = O(m), with k being the number of iterations and m the number of contacts and joints, but with the type of solver we use here, which has decent convergence qualities, we have data dependencies which need to be detected and then resolved by solving in parallel phases, reducing the parallelism that we can obtain. The ParallelSolverJobs are launched in phases for this reason, and then we also need to produce these phases which also eats up some additional computational time.

    On the collision side, after in the broadphase you identified the potentially colliding pairs of colliders (which can be done as fast as in O(n) for n colliders with worst case complexity of O(n log n)), in the narrowphase you are presented with the data parallel problem of computing the detailed intersection information (contacts) for each of these pairs.
    This can be done very fast in parallel and doesn't require any iterations.
    So assuming that out of your n colliders you have m << n^2 pairs that are potentially overlapping (not the extreme case you pointed out of n^2 colliding pairs, which could be considered a defective situation), your time complexity ends up being O(n) + O(m) with both phases greatly benefiting from parallelization (even the first one).

    If you have a situation without any joints and only with contacts, and assuming that most of the potentially colliding pairs identified above also lead to intersections with a maximum number of contacts k per pairs, you will have k * m = O(m) many contacts which then defines the dynamics complexity (see above).

    So all in all, it depends on how connected your rigid bodies are, allowing for different levels of parallelism. In some cases the dynamics time is higher and in others the collision time.
     
    Last edited: Jun 10, 2023
  18. n3b

    n3b

    Joined:
    Nov 16, 2014
    Posts:
    56
    I was referring to their particular case, meaning that removing motion component won't noticeably change anything, but removing collisions will. I believe body with no collisions will only participate in motion integration that costs nothing, while with removed motion it will participate in contact points creation and in solver phases as well, given that there are other bodies around, like in their case:
    And it doesn't require structural changes, win-win :)
    I did forget about joints indeed, but are they that noticeable with no contacts?
     
  19. n3b

    n3b

    Joined:
    Nov 16, 2014
    Posts:
    56
    This one Screenshot 2023-06-10 3.png
     
  20. filod

    filod

    Joined:
    Oct 3, 2015
    Posts:
    223
    @daniel-holz any news on this ? same pain here (i'm making a house building system which i want change piece collision when in preview mode, unique mode is not ideal and also it's not useful in compound situation)
     
  21. daniel-holz

    daniel-holz

    Unity Technologies

    Joined:
    Sep 17, 2021
    Posts:
    277
    In 1.2, there is a new API for making colliders unique at runtime, including compound colliders.
    Have a look at the documentation. Specifically the new "Collider sharing and unique colliders" section.

    If you make the collider that you want to modify unique at runtime, you can modify its collision filter without impacting any other potentially shared collider.
    Let me know what part of this is suboptimal in your use case.

    Note that the same feature was also backported to 1.1 but the documentation was not updated.
     
  22. optimise

    optimise

    Joined:
    Jan 22, 2014
    Posts:
    2,113
    Hi. I still not really understand why not just make CollisionFilter as a separate IComponentData instead of CollisionFilter inside Physics collider? What's the reason behind it? Is this because of performance reason or because of need to do too large changes that physics team thinks it's not worth the effort to do it? I think the current setup complicate thing that suppose to be simple. Furthermore, it also complicate netcode to support sync CollisionFilter data between client and server significantly that requires quite advanced implementation that I not sure when netcode team going to ship it.
     
  23. scottjdaley

    scottjdaley

    Joined:
    Aug 1, 2013
    Posts:
    160
    I think the unique collider solution isn't great for the use case that @filod is talking about. While it is fine when there is a single building preview, it doesn't scale well when there are lots of building previews. It would mean that each preview would have a unique copy of the entire collider blob, which could be quite large. But the only actual difference between the preview collider and the normal collider is the collision filter bitmask.

    Another solution is to create a prefab entity for the preview version of the building, and then instantiate that as needed, which should share the collider with all identical previews. This works pretty well, but the are some major downsides. Firstly, these preview prefabs have to created at runtime or be real game object prefabs. Maybe there is way to clone a baked prefab entity in a baking system, but I couldn't get that to work. The other issue is that these previews will likely need to be turned into "real" version of the building when the player constructs it. This requires either mutating it in place or swapping it out with an instance of the real version prefab. Mutating in place brings up the same collision filter problem, although, it would be possible to copy this from the "real" prefab rather than making a unique collider. And swapping the preview entity for the real entity is cumbersome and prone to errors since all of the entity references in other components need to be updated.

    Here is the answer that was given previously:

    Personally, I'd love to see a version of unity physics that didn't bake any hierarchies inside a blob. It makes the API worse for the majority of use cases that don't use compound colliders. I'm sure there would be some performance implication, but it feels like compound colliders should be implemented using ComponentLookups instead of blobs. In other words, any time physics needs a child collider or collision filter, it would do a lookup to retrieve the data from the child entity rather than looking it up in the blob. This would keep things flexible and easy to work with.

    Or maybe there is a way to support both. Compound collider entities can continue to represent the hierarchy inside a blob while simple single-collider entities would store the Collision Filter in a normal component.

    I realize that adding a separate code path for non-compound colliders would complicate the physics code base, but the current strategy of assuming that everything might be a compound collider and that every child collider might have a unique collision filter does not create the best user experience for the majority of use cases.
     
    daniel-holz likes this.
  24. daniel-holz

    daniel-holz

    Unity Technologies

    Joined:
    Sep 17, 2021
    Posts:
    277
    I agree that in this case the "unique" approach creates unnecessary memory bloat only for the purposes of modifying the collision filter in the different instances.
    Note that moving the collision filter out of the blob would slightly increase the memory consumption for all rigid bodies.
    The flexibility this offers combined with the potential memory savings in cases where only the filter values are different and the colliders are identical likely makes this superior to the merged situation we have right now.

    A slight modification of the API for compound colliders could also work here and would let us use the same approach for single colliders and compound colliders, which is keeping the top-level collision filter of a rigid body as a separate component.
    When creating a compound collider using
    CompoundCollider.Create
    , the user would hand in a set of colliders together with their respective collision filters, rather than only the set of colliders as is the case today.
    This API is used in baking as well, where we then would simply obtain the collision filter from the individual collider entities (the new collision filter component) which ultimately get batched together into a compound as collider children using the compound collider baking system. So, all the data would be there and we just need to modify the API slightly.

    What do you think?
     
  25. daniel-holz

    daniel-holz

    Unity Technologies

    Joined:
    Sep 17, 2021
    Posts:
    277
    Can you provide some more information about that part?
    If you add a GameObject prefab in your authoring component using a simple field and obtain its entity in the baker using
    var entityPrefab = GetEntity(gameObjectPrefab)
    , you will effectively acquire the baked entity prefab for that GameObject prefab.

    Using
    EntityManager.Instantiate(entityPrefab)
    (or the ECB variants) allows you to then "clone" that prefab at runtime (aka, create an entity prefab instance from it).
    Is that what you were trying to do?
     
  26. scottjdaley

    scottjdaley

    Joined:
    Aug 1, 2013
    Posts:
    160
    Yeah sorry, I tried to be brief since its more about authoring and baking workflows and less about physics, but I'll try elaborate on what I meant.

    Referencing game object prefabs in baking with GetEntity() and instantiating them at runtime works great for me. That is definitely a valid option if you are willing to have separate game object prefabs for each building and each preview building. I've gone down this route and it mostly all works. The problem is when you want to start sharing authoring data between the two mostly identical game object prefabs and keep them both in sync. For example, if I want to change the collider shape, I need to remember to update both the real and the preview prefab.

    For the sake of simplicity, let's say that the preview and real prefab are identical, except for a material, collision filter, and a tag component (to differentiate a preview from a real building). I could make two separate game object prefabs and reference them in baking. But now I have two mostly identical authoring set ups that need to be shared. I could instead make the preview prefab a "prefab variant" of the real one (which I also tried) to avoid duplicating authoring work, but now there is no way to share data amongst all preview prefabs, such as a hologram material. (I wish prefab variants used a composition approach instead of inheritance, but alas).

    Eventually I decided that the game object prefabs were too cumbersome for this use case and just created the preview prefab entities at runtime on startup. Clone the base prefab, update the material and collision filter, and add the tag.

    What I would really like (and what I was referring to in that comment) is to somehow do this in a baking system. So instead of referencing a game object prefab, I want to be able to create a clone of an entity prefab (after all the other relevant data has been baked). However, I couldn't figure out how to make this part work. AFAIK, you would need call CreateAdditionalEntity in a baker, and then somehow clone all of the component data over manually. I don't think you're allowed to create new entities in a baking system via EM.Instantiate since that doesn't handle the incremental baking correctly.

    Ultimately, I decided to go with a third option and just add or remove components to the building entity to turn it into the preview or real version. This avoids all of the headaches with needing to update entity references everywhere. It works for me since I no longer need to change collision filters.

    If I did still need to different collision filters on the building previews, I think a decent option is to, at runtime on startup, clone the collider blob and store it on a separate component (e.g. PreviewCollider) and then swap between the two as needed. I think that would work pretty well, but that is another case where it would ideally be set up in a baking system.

    Sorry that got so long, but hopefully that helps explain some of the tradeoffs of different approaches.
     
    daniel-holz likes this.
  27. scottjdaley

    scottjdaley

    Joined:
    Aug 1, 2013
    Posts:
    160
    That sounds great to me!

    For the record, I haven't actually used the compound collider API, but that sounds like a totally reasonable change. You could even make a version of CompoundCollider.Create that takes a set of colliders and a single collision filter for when the user wants all colliders to use the same filter.

    But does this mean the collision filter data is duplicated both inside the blob and on a normal component? If so, how are the two kept in sync? And if not, how will the physics systems lookup collision filters for child colliders?
     
  28. daniel-holz

    daniel-holz

    Unity Technologies

    Joined:
    Sep 17, 2021
    Posts:
    277
    As usual, the devil lies in the details but in rough terms the collision filter for children in compound colliders would be stored within the compound blob itself. So there won't be any duplication of filters. The compound collider would have a filter itself, but this would be the component. So there is no duplication.

    As to how collision filters are accessed by the physics system internally, that just requires a few little adjustments I believe. I don't foresee this as a problem but would need to look into the details.

    Your idea of providing a simple "uniform filter" CompoundCollider.Create function variation is a nice option.
     
    scottjdaley likes this.
  29. daniel-holz

    daniel-holz

    Unity Technologies

    Joined:
    Sep 17, 2021
    Posts:
    277
    I see. Thanks for the added detail.

    I think you are right with your assumption about creation of entities in a baking system and that you would need to create additional entities in the bakers.
    You could have a look at the way compound colliders are constructed. If I recall correctly we do create additional entities for child colliders and then do a cleanup later in the compound collider baking system.
     
    scottjdaley likes this.