Resolved Netcode: Prefab entity spawn with different CollisionFilters?

Hi,
maybe someone has an idea how to solve my problem.

I use Unity netcode & for this, I have "1" unique Prefab which is spawned as an entity for each player.
To detect a collision with the environment and other players, I cast a short ray in front of each player entity.

When I move the player forward, the ray touches sometimes the player itself & detects a hit.

So I set the Filter-BelongsTo of the Prefab to 1u (first bit).
For the hit-detection raycast I use a filter with CollidesWith = ~1u (all but first bit).

Now, according to the documentation the ray will not detect a hit with the player anymore, so far so good.
--------------
The problem now is, that it does not detect the hits to other players anymore too.

When the entity is getting spawned, I tried to manipulate the Collider for each entity, but since its shared by the Prefab, I always manipulate the single source of truth, so ever player entity has always the same CollisionFilter.

So I tried several things:

• I tried the "ForceUnique" Option in PhysicsShape for the Prefab, but without luck.
• Also I tried to clone the collider (according to this) but it also did not work.
• I checked also the DOTSSample project, but it seems, they did not have this problem!?

 

My suggestion is to write a custom collector and solve it that way. You can take a look at CharacterControllerClosestHitCollector, it stores a m_selfRBIndex and filters out all hits coming from that same body.

 

Thanks @petarmHavok,
I checked it shortly and it makes sense so far. Will give it a try when I'm back from work

 

I tried this & it works perfectly Thank you so much petarmHavok!

 

My pleasure! We use the same for character controller since it has the same requirement - to do a query and ignore itself in it.

 

That kind of collectors may be needed often enough to consider adding to the default collectors of the physics package.

 

Yeah, we've thought about that and my experience was that it's often not just self-filtering, but something else gets added to that after a while. Like in the character controller, it's also triggers and some predefined list of hits... So if anyone has that extra need it immediately becomes obsolete. And in fairness, it's quite easy to write, you just need the closest hit collector code and this extra check. Not saying I'm against it, I just feel like it would ultimately be unused.

 

I think ultimately it is less about difficulty to write but more about the reduction of boilerplate code. The user shouldn't need to reimplement something basic for every new project.There are probably a few configurations which cover the majority of use cases.