Can anyone explain why this configuration produces a hit, when using a Physics.OverlapBox method?
Cube1:
Position (-0.9, 0.57, -7.62)
Default rotation, scale and collider
Cube2:
Position (0.22, 0.76, -8.49)
Rotation (0, -45, 0)
Default scale and collider
Physics default contact offset 0.01
If you set the two cubes as listed above, you can clearly see they are not touching, but Physics.OverlapBox with correct rotation supplied, tells me that the boxes overlap. The gap between the two boxes is larger than 0.01 or even 0.1 for that matter, so the contact offset doesn’t sound like the source of this. Physics.BoxCast also reports this as a hit. Surely these functions don’t use aabbs to test collision, what is going on?
After testing this in an isolated static environment I realized that it is indeed not a hit. I noticed that in my case the collider positions did not match the positions of transforms, and if I used collider data instead of transform data they were touching. I believe the cause of this is physics being out of sync, and in that regard I got what was coming to me when I moved two objects in update and then did the cast. Somehow it never clicked that this should have been in fixedupdate.
That being said, I wish there was a way to work with colliders without getting married with physics. If I don’t want to simulate any actual physics, and my goal is to move a box and check if it touches any other collider, it appears that I still need to worry about doing most of it in a physics step because that’s the only time I know colliders are in synch with transforms.
You can create an extra physics scene programatically and simulate it whenever you need. Maybe that’s an option for you?
See this thread for an example: Separating Physics Scenes