Game Development Stack Exchange is a question and answer site for professional and independent game developers. It only takes a minute to sign up.
Sign up to join this community
I have taken the task of building a basic impulse physics engine. Circle vs Circle collision resolution has been done and I moved onto Line vs Circle. I can detect a collision and know that the normal should be perpendicular to the line which can be calculated easily (2d physics engine). However it's the direction of the normal that I cannot work out.
From the image you can see there are 2 possible normals, one upwards (the correct one) and one downwards. How do I choose the correct normal?
Generally you'd check which side of the line your circle is on, and flip the normal if it's pointing away from the circle:
Vector2 outward = circle.center - line.startPoint;
if(Vector2.Dot(outward, normal) < 0f)
return -1f * normal;
return normal;
This is susceptible to an error called "tunneling," where a small, fast-moving circle might move into and juuuuust past the line in a single update. Then, even if it came from the top side, our check above will see that the circle is currently on the bottom side and produce a downward-pointing normal instead.
For extreme cases of tunneling (where the circle hops all the way over the line and we never detect the collision at all), there's not much we can do except reduce the timestep, give the colliders some "thickness," or switch to more expensive continuous collision detection.
But for slight tunneling we can sometimes do better by checking against the incoming velocity instead of position - assuming that if we've encountered a collision, then whichever way the circle was moving should be opposite the surface normal. That would look like this:
// Compute relative velocity of the circle from the perspective of the line.
Vector2 inward = circle.velocity - line.velocity;
if(Vector2.Dot(inward, normal) > 0f)
return -1f * normal;
return normal;
This can run into errors if you have multiple collisions being resolved in sequence, if an earlier collision resolution modified the velocity so it's not pointing in the direction that originally caused the collision. So watch out for that, and make sure you're looking at the snapshot of the velocity from the impact, not from a subsequent rebound.
