This is registering overlaps. It becomes far less accurate with any form of rotation. I did not bother with collider offset so that less bugs could be in the test. Code:
int count = Physics2D.OverlapBoxNonAlloc(
transform.position,
col.size,
transform.eulerAngles.z,
overlapColliders,
layers
);
Finally, both boxes have these settings:
Should they be registering overlaps without touching? maybe I’m not understanding. I do filter results and print the name out so to rule out self overlaps.
Depends on what the distance is between them in that image. As you may know, 2D physics (for box/polygon colliders) use a gap to ensure correct collisions: Unity - Scripting API: Physics2D.minPenetrationForPenalty (soon to be renamed to DefaultContactOffset).
You can turn on full kinematic collisions and see if there are contacts between the two either using the rollout or the contact-arrow gizmo.
OK so OverlapBoxNonAlloc uses rules for DefaultContactOffset - this is not immediately intuitive so please document it, as OverlapBoxNonAlloc doesn’t imply it needs contacts.
All fixed now, thanks for clearing it up - had no idea they were related, doh!
That function doesn’t use a specific offset, the whole physics system does so there’s no need to say this in every cast and overlap call. All physics queries return exactly what the physics system does by default which should be intuitive i.e. it’d be unintiutive to return something different. If the physics system counts this as an overlap, you’d expect any explicit overlap query to return true as well.
I wish Box2D didn’t require this separation; it’s been a source of pain for users and myself.
NOTE: You are free to set the separation to zero but it can cause polygon/polygon collision issues with dynamic Rigidbody2D (mainly tunneling and stacking issue) but, depending on what you’re doing, this might not even be a problem for you; it’s just a default after all.
This should not be the case at all, the separation should always be the same.
