Hello all! I'm kind of stuck in a rut here: I've got a collision detection system working for a first-person sort of game that I've been working on-- the player has a bounding sphere around him, and I do the following for collision detection against him and the polygons of the collision map:

I call a ray-on-polygon collision check from the center of the player's sphere in the reverse direction of a given polygon's normal. If the ray is colliding with the polygon, and the distance from the sphere to the polygon's plane is less than the sphere's radius, I push sphere that is the player back in the direction of the polygon's normal vector the amount that the sphere is in the wall (sphereRadius - spherePlaneDistance).

I hope this idea is clear. If it isn't, I'll try to explain a little better, but I'm pretty sure this method is pretty popular. Anyway, I've having issues with the corners and edges of meshes course.

The attached "good collision.png" shows a collision friendly to this system: we know there is a collision, and how to respond.

The "bad collision.png" shows the problem: Although the sphere really is colliding with the polygon, the ray doesn't actually hit the polygon so we can't tell. You can imagine this would make any convex joining of two polygons not work with the collision detection.

Sorry for the long and badly worded/drawn write-up ;D. Can someone help me out?

Like most math problems, this one can easily be solved by looking at it differently.

The way I would approach this problem is completely opposite. I would find the closest point on the box to the circle you're testing against. From there it becomes a trivial matter of finding the distance from closest point on the box's edge to the center of the circle, and testing against the circle's radius.

I hope that made sense. The nice thing about this technique is that the vector from the box's closest edge point to the circle's center also serves as the edge (or corner) normal for intersection, making the "pushing the player back" part of the code also relatively simple if your have a small intersection. If you don't, then things could get a little hairy.

But, of course, all these things (like collision correction, bullet-through-paper problems, etc), can be turned into a slightly simpler problem, if you're willing to settle with close-enough-to-look-right accuracy. If so, I will always redirect to Paul Firth's excellent blog post:

http://www.wildbunny.co.uk/blog/2011/03/25/speculative-contacts-an-continuous-collision-engine-approach-part-1/

Hope this helped!

~CulDeVu

That's great, thank you. A fresh pair of eyes is often all it takes. :)