Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    text
    copied!<p>If they're circles, the collision point (if it exists) will lie on the line connecting their centres, and the impulse to each will act in the direction from that point to the circle's centre.</p> <p>Assuming centres <code>(x1, y1)</code> and <code>(x2, y2)</code> and radii <code>r1</code> and <code>r2</code>, the circles collide when</p> <pre><code>(x1 - x2) * (x1 - x2) + (y1 - y2) * (y1 - y2) = (r1 + r2) * (r1 + r2) </code></pre> <p>This is just your basic <a href="http://en.wikipedia.org/wiki/Pythagorean_theorem" rel="nofollow noreferrer">Pythagorean theorem</a>.</p> <p>In most cases -- undoubtedly including yours -- collision detection is an approximate rather than analytic business. Which is to say, you move your objects by small steps and test for overlap, rather than solving the motion equations for the exact instant of contact. So instead of looking for the above case, you will use an <em>inequality</em> like this:</p> <pre><code>(x1 - x2) * (x1 - x2) + (y1 - y2) * (y1 - y2) &lt;= (r1 + r2) * (r1 + r2) </code></pre> <p>When this evaluates as true, the collision has basically <em>already occurred</em>, and you have two choices: you can work backwards to calculate exactly when and where that happened, or you can assume that your time steps are small enough that the time you notice an overlap is close enough to the moment of contact that it will serve as a reasonable substitute. Again, it is very likely this is what you want to do, but be aware that this is quite inexact: if your objects are moving quickly with respect to their size then it may look quite wrong, or even miss collisions altogether (sometimes humorously referred to as "quantum tunneling").</p> <p>Since the circles probably overlap a little, you need to determine a proxy contact point -- let's call it <code>(xp, yp)</code>. Since it's an approximation, there are several ways you might to choose to calculate it, but one reasonable choice might be:</p> <pre><code>xp = x1 + (x2 - x1) * r1 / (r1 + r2) yp = y1 + (y2 - y1) * r1 / (r1 + r2) </code></pre> <p>That is, on the line between the centres, at a distance in proportion to the radii. If the overlap is small, this should be pretty close to the real collision point. If it's big, you're in trouble anyway.</p> <p>Ignoring any rotation, each circular object will experience a push from this collision point towards its own centre. Eg, the push on object 1 will act in the direction <code>(x1 - xp, y1 - yp)</code>.</p> <p>To work out what the <em>effect</em> will be -- ie, how the objects will move afterwards -- you need to take into account the <em>mass</em> of each object and apply the law of conservation of momentum. Read up on <a href="http://en.wikipedia.org/wiki/Elastic_collision" rel="nofollow noreferrer">elastic collisions</a> and possibly, if you want to simulate collisions that are <em>not</em> perfectly elastic, the <a href="http://en.wikipedia.org/wiki/Coefficient_of_restitution" rel="nofollow noreferrer">coefficient of restitution</a>.</p> <p>In the special case that the objects are the same size and mass and the collision is perfectly elastic -- which seldom occurs in real life but slightly more often in games -- you can break down the velocity of each object into the components parallel and perpendicular to the line between the centres, and then just swap the parallel components between the two objects.</p>
 

Querying!

 
Guidance

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload