If a child entity has a spatial activator and/or trigger (necessitating, ideally, a PhysicsShape for authoring the collider), but the parent also has a collider, then the child's collider is compounding into that of the parent at least in Unity.Physics 0.5.1. This means that, on entry/exit/overlap, the compound entity is reported rather than the specific child entity. For things such as determining a character's visible range, this is not helpful at all.
Now there are multiple workarounds, one of which is to make all colliders siblings. Another is to defer parenting or assignment of the collider. But, in most cases we want to treat the root entity physically with a PhysicsBody or RigidBody. It's used in the simulation in the physical sense, not necessarily as a trigger, although it could serve both purposes. In other words, the workarounds have issues.
It looks like determining the child entity associated with a sub-collider of a compound collider is going to get easier in the release following 6.0.0 according to this forum thread. At one point steveeHavok says "Entity for the Child Collider will be available . . . "
So hopefully that means I can opt for the most specific-colliding entity and improve the spatial events package by defaulting to it.
If a child entity has a spatial activator and/or trigger (necessitating, ideally, a
PhysicsShape
for authoring the collider), but the parent also has a collider, then the child's collider is compounding into that of the parent at least in Unity.Physics0.5.1
. This means that, on entry/exit/overlap, the compound entity is reported rather than the specific child entity. For things such as determining a character's visible range, this is not helpful at all.Now there are multiple workarounds, one of which is to make all colliders siblings. Another is to defer parenting or assignment of the collider. But, in most cases we want to treat the root entity physically with a
PhysicsBody
orRigidBody
. It's used in the simulation in the physical sense, not necessarily as a trigger, although it could serve both purposes. In other words, the workarounds have issues.It looks like determining the child entity associated with a sub-collider of a compound collider is going to get easier in the release following
6.0.0
according to this forum thread. At one point steveeHavok says "Entity for the Child Collider will be available . . . "So hopefully that means I can opt for the most specific-colliding entity and improve the spatial events package by defaulting to it.