Rectangle to Circle collision test? (2D)

Hi everyone. I’ve recently been adding a simple physics engine to my 2D game engine that I will hopefully be using in my future projects. Right now I have two colliders, a BoundingBox (essentially an AABB) and a BoundingCircle class. Both of these extend my abstract BoundingVolume class. The BoundingBox is defined by an X, Y, Width and Height. The BoundingCircle is defined by an X, Y (the center of the circle) and a radius.

I check collisions between two BoundingBox’s like this:


public boolean intersects(BoundingBox other) {
		if(other.getY() > (getY()+getHeight()) || //check top edge
			(other.getY()+other.getHeight()) < getY() || //check bottom edge
				other.getX() > (getX()+getWidth()) || //check right edge
					(other.getX()+other.getWidth()) < getX()){ //check left edge
			//NO COLLISION
			return false;
		}
		return true;
	}

And between two BoundingCircle’s like this:


public boolean intersects(BoundingCircle other) {
		//get the distance between the two circle's centers
		Vector2f distance = new Vector2f(other.getCenter().getX() - center.getX(), other.getCenter().getY() - center.getY());
		if(distance.getLength() <= radius + other.getRadius()){
			//COLLISION!
			return true;
		}
		return false;
	}

But how would I check for a collision between the BoundingBox and the BoundingCircle? I’ve looked into the Separating Axis Theorem and I don’t think that it can work for circles as they have an infinite amount of sides. I also don’t want to use an open source physics library as I want the learning experience. What is a simple and fast way of checking for a collision between a rectangle and a circle?

P.S. Tell me if you see anything wrong with my way of checking between rectangle-rectangle and circle-circle collisions as well.

Thank you!

Pick one. I like Cygon’s.

Aside: that’s overkill on comparisons (clamp).

I use the following algorithm:


//find closest point inside rectangle from circle center
float closestX = clamp(circle.x, rect.x, rect.x + rect.width);
float closestY = clamp(circle.y, rect.y, rect.y + rect.height);

//find distance from point on rectangle to circle
float dx = closestX - circle.x;
float dy = closestY - circly.y;
float distanceSqrd = dx*dx + dy*dy;

//test distance against radius
if(distanceSqrd < circle.radius*circle.radius){
    //collision detected!!!
}else{
    //no collision
}

Code for clamp()


public static float clamp(float f, float min, float max){
    return f < min ? min : f > max ? max : f;
    /*
    if(f < min){ return min;}
    if(f > max){ return max;}
    return f;
    */
}

Newbies ignore this. Do whatever works and move on.

Q: How often do you compare exactly two things for intersections?
A: Statistically never.

Ignoring that: this method performs 3-5 comparisons prior to completion and they (should be) statistically random between true/false (given the above…if they are not you’re missing information you should be exploiting) with a minimum dependency chain of 7. Alternate methods will binary subdivide the problem. After the first comparison 50% of cases will be decided, 50% of the remaining for the second. A well chosen ordering can cause the comparisons to be not uniformly random (again on average)…so statistically the result will either true or false depending on construction.

As an example (last code snippet):
http://www.java-gaming.org/topics/vectors-what-s-the-point/24307/msg/225743/view.html#msg225743
convert it to AABB looks like this (assume I didn’t screw up):


public boolean intersects(Circle c)
{
  float px = c.x - ref.x; //center.x - delta.x;
  float r  = c.radius;
  
  if (px > r)  return false;

  float py = c.y - ref.y; //center.y - delta.y;

  if (py > r)  return false;
  if (px <= 0) return true;
  if (py <= 0) return true;
  
  px *= px;
  py *= py;
  
  return px+py <= r*r;
}

Symmetry is your friend.

I was debating mentioning a “short-circuiting” algo like you showed, but I figured that a more straightforward, intuitive, what-have-you test might be better for a beginner.
Intuitiveness is subjective as well, however.

That’s why I hedged my comment. Note my version above is broken…I yanked out the abs…see the rotated version and it should be clear.

EDIT: And I should note that the clamped version can be made very reasonable for bulking processing by formulating with min/max assuming the language generates max/max opcodes.