I know that collision detection is a bit of a FAQ, but I have a specific question.
I have implemented circle-on-square collision detection in a very basic manner. Basically it checks the radius of the circle against the center of the square and then also does a short calculation for the corners.
However, because of the resolution of the check it seems to always encounter corner collisions. The speed ends up being too great for the refresh rate and the circle overlaps the square and triggers a collision on the corner.
So I'm thinking that my physics calculations need a paradigm shit. I should probably stop relying on the framerate to set the speed of animated objects.
I am thinking about moving to a time-elapsed based approach. I can then render based on where the objects should be at a point in time rather than simply updating them based on their acceleration and velocity per frame.
Either that or I will start performing look-ahead calculations to make sure that the next velocity step won't land my object inside of another one. Then doing some kind of calculation to determine where it should end up at the next step. This doesn't seem very good, I'm afraid of causing a jump in animation.
Anyway, I was wondering if anyone had any suggestions. I'm sure that some of you have encountered this sort of a problem and had to work out a solution.
Thinking more, I wonder if we can make the collision look better by repositioning the circle better as part of the collision reaction.
I haven't looked at your code, but we usually resolve the collision by pushing the circle back perpendicularly to the line so that it no longer overlaps the line, then sending it on its way [top diagram].
It might look smoother to resolve the overlap by pushing the circle back along its approach vector and then sending it on its way [bottom diagram].
Do experiment with how you sequence drawing the circle and doing the collision reaction. You may find that changing their order makes the effect more realistic/smoother.
Thanks allonestring, that picture pretty really helped visualize my problem.
The next trick seems to be finding that perpendicular vector. That would mean that I need to find the exact first point of intersection between the circle and the line segment.
I could do this by drawing the circle point-by-point as one of your linked posts suggests. I could then take the midpoint of where the circle intersects and use that as the point of collision.
Not sure if this checks out physics-wise, it might look jumpy. I could be smarter about it by shifting the circle back along its trajectory in the calculations until the distance between the points is relatively small (to simulate finding that elusive single point of intersection).
The other trick is I need to calculate the distance left to travel in that frame and move the circle along its new trajectory to that point. Not too bad, but I can't simply reverse the trajectory and let it sort itself out in the next frame it will look like it stuck to the wall for a split second at higher framerates.
Anyway, thanks again for your help! Definitely got me thinking.