Hi @daniel-holz . I would like to know when move CollisionFilter out of Collider blob asset to make it so much easier and higher performance to change CollisionFilter at runtime and also enable dots netcode to sync CollisionFilter component from server to client? Is that planned to ship at 1.1 or 1.2?
We are not moving the collision filter out of the collider blob at this point but are rolling out some improvements for runtime collider changes which will make it much easier to modify collision filters going forward.
Keep your eyes peeled for upcoming releases.
I see but from what I know the dots netcode requirement to sync data from server to client must be IComponentData so it’s possible to put [GhostField] attribute. Is that the improvements for runtime collider changes are implemented based on this to support dots netcode component data sync?
I’ll get back to you on this. I am inquiring with the netcode team internally regarding these limitations.
Hi. Any new update?
Not yet. Sorry. I’ll keep you posted.
Hi optimise!
Syncing the collision filter does not require to remove the filter itself from the collider. Indeed, having that separate from the header would immediately make it possible to sync it via [GhostField] attribute.
I would like to exclude synching the whole blob asset because it is too bandwidth expensive and does not make sense at all.
But an approach you can definitively use is to add your own component that track the current collision filter of the collider (or compound collider depends) of you ghost and replicate that instead.
So when the server change the filter of the collider, also update that component. And the client will use that to update the the blob data accordingly.
Another possilbity, that is more complex but I think explorable somehow, would be to use ghost component variants and a custom template to implement the collider filter replication. However, I would sincerely suggest to implement the other approach for sake of simplicity.
Ya. I know you can create own component to achieve it but it’s not trivial to implement that required some work to achieve it. And also I think this is common use case for dots netcode project that official should support it by default. Official can do like what u mentioned that provide some kind of another CollisionFilter regular component and a system to fetch this CollisionFilter regular component to change CollisionFilter at PhysicsCollider blob asset. Whether to change CollisionFilter regular component to ghost component is up to user to decide.
I’m not sure why official want to put into CollisionFilter instead of just move CollisionFilter out from PhysicsCollider blob asset that I believe it’s costly to change blob asset data at runtime that I’m curious to know the reason behind it of this decision. It’s even true when u want to sync CollisionFilter at dots netcode project that mentioned previously that u will need to purposely create a completely new system just fetch CollisionFilter component and then change CollisionFilter at PhysicsCollider blob asset at both client and server to sync them properly. If official just improve dots physics package by move CollisionFilter out of PhysicsCollider blob asset as regular component then just sync CollisionFilter component will just work without require more work to achieve the goal assuming dots physics is implemented to support dots netcode nicely by default that is completely stateless.
When you think about it, make sense that collision filter is part of the CollisionShape, it is a property of it. We can indeed discuss about the fact we don’t have by default these property replicated if they change.
As I said, it is achievable somehow to implement this without requiring to change the overall CollsionShape design. No promises here, but we can try to prototype that idea of using variants and template to achieve that.
My worries though is that tomorrow, there will be another similar requirement in another area, and so on and so forth. That means, we need to think a little more holistically in general. But for now let’s see if we can provide something for this, with just some minor changes.
Yes and no… We can be slightly smarter and store as data in the component the pointer to the header and modify that directly when write to it. So there will be no need to write a system or anything like that. Everything will stay in sync immediately.