Home » Community » Forums » » Simple Bounding-Sphere Collision Detection
  Intel sponsors gamedev.net search:   
[Control Panel] [Register] [Bookmarks] [Who's Online] [Active Topics] [Stats] [FAQ] [Search]

Add Forum to Favorites |  Send Topic To a Friend | View Forum FAQ | Track this topic
 Last Thread Next Thread 
 Simple Bounding-Sphere Collision Detection
Post Reply 
Reply Quoting This MessageEdit Message Anonymous Poster  
Warning Level: 10%
 Posted - 2/17/2003 4:24:17 AM
hie i need some help on how to detect collision between cylinder and box ??
 User Rating: 1015    Report this Post to a Moderator | Link

Reply Quoting This MessageEdit Message bargasteh    Member since: 10/12/2003  From: Manchester, United Kingdom
 Posted - 2/25/2005 8:17:44 PM
Very nice tutorial, but is there any other tutorials to explain collision response for inelastic collisions ?!

Thanks
 User Rating: 982   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Reply Quoting This MessageEdit Message Anonymous Poster  
Warning Level: 10%
 Posted - 11/9/2005 12:35:02 AM
Nice article, but seems to be a typo.
The first condition of Check(3) should be "vv - pv" as it is in the math.
 User Rating: 1015    Report this Post to a Moderator | Link

Reply Quoting This MessageEdit Message Anonymous Poster  
Warning Level: 10%
 Posted - 5/9/2006 4:21:00 AM
Don't know if you are still looking at this, but there is a small typo where when calculating the formula for d^2 - r^2 = 0 you say you can solve this using the "determinant" instead of "discriminant" as you say later in the article. Very useful article, though!
 User Rating: 1015    Report this Post to a Moderator | Link

Reply Quoting This MessageEdit Message dizwax    Member since: 7/20/2007
 Posted - 7/20/2007 5:28:16 AM
The code is correct in Check(3) (pv + vv <= 0). It's the math that is wrong. I was having trouble using this code, so I ended up going through all of the math. It turns out I just needed to compute t. I was incorrectly thinking that tmin in the code was the t value.

If you're interested in the actual t parameter where the collision occurs, do something like this:

// (3) Check if the spheres can intersect within 1 frame
if ((pv + vv) <= 0 && (vv + 2 * pv + pp) >= 0) {
return false;
}

// tmp is a term for getting next check into good float range
float tmp = -pv/vv;

// tmp2 = -D/(4*vv)
//(4) Check discriminant
float tmp2 = pp + pv * tmp;
if (tmp2 > 0) {
return false;
}

// calculate the t value
t = tmp - sqrtf(-tmp2/vv);
return true;
 User Rating: 1015   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Reply Quoting This MessageEdit Message dmp1ce    Member since: 6/27/2003  From: USA
 Posted - 7/28/2007 8:00:01 PM
I noticed that the 3rd code snippet didn't work for me when the 3 cases passed. I believe the reason is because you actually divided by -vv instead of vv as stated in the article. If I am correct that would make the last line "return ( pp + pv * tmin < 0 );" instead of "return ( pp + pv * tmin > 0 );" because the inequality needs to be flipped when dividing by a negative number which -vv would be.

Thank you for the article!
 User Rating: 1015   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Reply Quoting This MessageEdit Message jonboym    Member since: 6/17/2003  From: Derbyshire, United Kingdom
 Posted - 8/21/2007 3:37:15 PM
I don't understand how you derived the condition vv + pv <= 0

Be grateful if someone could explain.

vv + 2pv + pp >= 0 is easy to understand as its just a straight rearrangement but vv + pv seems to spring from nowhere??
 User Rating: 1015   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Reply Quoting This MessageEdit Message NightCreature83    Member since: 2/21/2008  From: Leamington Spa
 Posted - 2/21/2008 3:48:19 PM
In this code the * operator has been overloaded to mean a dot product right.
I have not overloaded star in my vector classes so I need to know if its a dot product or a component wise product.
And its always nice to tell people if the operator is overloaded or not when dealing with vectors.
 User Rating: 1006   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Reply Quoting This MessageEdit Message Locutusborg    Member since: 5/22/2008  From: Hoorn, Netherlands
 Posted - 9/27/2008 4:46:00 AM
Am I wrong in saying that the 2nd check should be:

if ( pv <= 0 ) return false;

instead of

if ( pv >= 0 ) return false;

from the math above I understand that it should be negative when the spheres are moving away from eachother.

Otherwise, great article, been looking for an understandable one for a long time!
 User Rating: 1015   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Reply Quoting This MessageEdit Message dmitriyd    Member since: 4/27/2009  From: florencio-varela
 Posted - 6/1/2009 12:01:48 PM
This is method that I use, Its easy to understand, see above:
Dmitiy Deordiy.

int sphere_collision(VERTEX3D pos1, VERTEX3D pos2,float radius1,float radius2)
{

//calculate a limit distance (radius1 + radius2)
float distance = radius1 + radius2;
//make a vector
VERTEX3D result = subtract_vector(pos1, pos2);
//calculate current distance from two bodies
float current_distance = vector_length(result);
if(current_distance < distance)
return 1;
else
return 0;

}

VERTEX3D subtract_vector(VERTEX3D a,VERTEX3D b)
{
VERTEX3D c;

c.x=a.x - b.x;
c.y=a.y - b.y;
c.z=a.z - b.z;

return c;
}

float vector_length(VERTEX3D c)
{
return (float)sqrt((c.x * c.x) + (c.y * c.y) + (c.z * c.z));
}
 User Rating: 998   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

All times are ET (US)

Post Reply		  Last Thread Next Thread 
Forum Rules:
You may not post new threads
You may post replies
You may not edit your posts
You may not use HTML in your posts
Jump To:
Administrative Options: