# Circle vs Edge collision detection / resolution [closed]

I made a javascript class Ball.js that handles physics interactions betweens balls as well as painting. In the v1.0, the ball vs ball collision detection and resolution is well handled.

In the next version (v2), I'm trying to add edgeCollision handling. I'm having some problems, maybe you will be able to help me.

All the v2 branch source code is on github repository : https://github.com/topheman/Ball.js/tree/v2

The v2 demos (where you can see the bug I will be talking about) : http://labs.topheman.com/Ball-v2/#help

As you will see on the demo, I have two major problems that I'm having a really hard time to solve on Ball.js :

• method resolveEdgeCollision : bounce angle is inconsistent
• method checkEdgeCollision : if the ball's velocity (the length that it runs each frame) is higher than its diameter, eventually, it will pass through an edge, without triggering any collision

Any Ideas ?...

## closed as off-topic by Josh♦Sep 17 '13 at 14:13

This question appears to be off-topic. The users who voted to close gave this specific reason:

• "Programming questions that aren't specific to game development are off-topic here, but can be asked on Stack Overflow. A good rule of thumb is to ask yourself "would a professional game developer give me a better/different/more specific answer to this question than other programmers?"" – Josh
If this question can be reworded to fit the rules in the help center, please edit the question.

• You should edit your question to be more specific, and post your code with your question. If there is too much code to post, all the more reason for you to narrow down the range of your question. Also, you might consider doing this twice, once for each of your two very distinct problems. – Seth Battin Oct 26 '12 at 1:40
• Regarding your second problem, that behavior is expected for fast moving objects, because you are only checking for discrete collisions. To solve that problem, you will have to look into methods of 'continuous' collision detection. One option is raycasting between positions of adjacent timesteps, as described here: stackoverflow.com/questions/5788261/… – kevintodisco Oct 26 '12 at 2:52
• @ktodisco > thanks for the raycasting hint, I will look into, it seems like it's what I will be needing of. – topheman Oct 26 '12 at 12:10
• @SethBattin > I'm aware my question may not be very specific, and I've put the code on github so that anyone could see it. What I need is probably more answers like ktodisco did (a link to point a method already used by other that I didn't knew about) – topheman Oct 26 '12 at 12:15
• @topheman I think I understand what you are looking for. Nonetheless, you should invest some effort in a better description of your problem. Your question should not require that we first figure out the exact nature of your "bounce angle inconsistent" before trying to answer. Maybe you'll find some angelically helpful person regardless, you may feel free to disregard my advice. – Seth Battin Oct 26 '12 at 16:40

The way I've written circle vs line collision before is to modify the problem somewhat:

1. Change the circle into a point.

2. Add the circle's radius to the line. That gives you one circle at each end, and two straight line segments joining them.

3. You can now cast a ray from the previous position to the next position, and test it against the lines and the circles. The earliest collision time from those four tests is the one you want to use.

4. If the ray intersects either a circle or line, it's fairly simple to calculate when and where that collision occurred, and resolve it.

Circle to polygon collision detection devolves into edge vs circle. I wrote about it here: http://gamedev.tutsplus.com/tutorials/implementation/custom-2d-physics-engine-oriented-rigid-bodies/

The idea is to find if the ball's center is closest to a vertex or the edge segment itself. From there deriving resolution information is trivial.

• You should transcribe the helpful parts of your article here; link-only answers are not the preferred way to post. – Seth Battin Jun 18 '13 at 21:42
• @SethBattin I'm sure my answer is much better than nothing, though I do agree with you. I just can't afford the time to re-write so much information. – RandyGaul Jun 19 '13 at 0:26
• That's fine, but answers ought to have substance to them. If you don't have time to write one, a comment is a better place to post quickly. – Seth Battin Jun 19 '13 at 1:22