Skip to main content
gamedev.net
🔒 Locked

Timer Based Collision Detection

Started by mameman Apr 11, 2007 at 8:04 AM 5 replies 600+ views
Original Post
mameman
mameman
Hi All, I have two simple 2D objects that are both axis aligned. What I want to do is to determine the actual time of the collision of the two objects within a specific time interval (say dt). Both of the objects are moving under gravity and so their respective velocities are not constant. I can determine the time of the collision when both objects are moving with constant speed but can't find anything for motion under gravity. Any infos appreciated. Thanks in advance, MAMEman.
oliii
oliii
What are the shapes? axis aligned bounding boxes?

1) if both objects are moving under gravity, their respective velocities wont be constant, but their relative velocity will remain constant. Then doing collision tests, it's usually better to consider one object static, and the object having the relative velocity.

2) Usually, for collision detection, the object is considered to have constant speed throughout the time interval, to simplify matters.

3) If that's not enough, I would look into the swept SAT test, extended using the acceleration of the objects. What you'd end up with would be solving a second order equation for each separating axis (with axis aligned boxes, there's only two).
Everything is better with Metal.
pTymN
pTymN
Your collision tests are currently second order:

1st order motion + 1st order motion = 2nd order collision test.

If you enforce that each object can have acceleration, then you will have a 4th order collision test:

2nd order motion + 2nd order motion = 4th order collision test.

I can highly recommend that you save the extra 2 orders of complexity for doing cooler stuff like rotations. Equations higher than 4th order aren't solvable for the general case, so you might want to be aware that you are limiting yourself to objects that don't rotate if you insist on finding the exact collision time for them when they accelerate.

I highly recommend that you live with the inaccuracies and push the complexity of the acceleration out of the collision test and back into the object motion updater. In my physics engine, I call each object to ask it where it wants to move to given a time interval. When collisions happen, I call that method again with a smaller time interval. Given a generous epsilon of separation between objects, even objects with fairly large acceleration on their motion tend to behave linearly in a small enough time interval.

In case you are curious, you can squeeze full dynamic rotation collision testing into a 4th order equation given a few assumptions. So what are you using this collision detection for?
 
pTymN
pTymN
oliii is correct about the collision test only being second order, assuming that gravity points in the same direction for all objects. In the case where gravity is towards a specific point, like the center of a planet, then you'll be dealing with fourth order complexity.
 
mameman
mameman
Thanks for the infos guys. pThmN, I clearly understand the problem that I have now!. Motion equations for objects with constant velocity are simple linear equations (y = ax + b), but for those under gravity then ax^2 + bx + c = 0. After reconsidering I may be using a steam roller to crack a peanut open!.

All of my objects will have gravity pointing in the same direction (-ve y-axis). The objects of interest are a ball object and a platform that has the same motion as a simple pendulum (2nd order differential equation for the motion).


MAMEman.
oliii
oliii
I'm pretty sure whatever the acceleration of the objects, using the SAT, you would still be working with second order equations.

bool CollideSAT(float p, float v, float a, float r, float& t0, float& t1){    // two second order to solve for +r and -r.    //......}float CollideBoxes(Vector P0, Vector R0, Vector V0, Vector A0,                    Vector P1, Vector R1, Vector V1, Vector A1){    Vector P = P1 - P0; // relative position    Vector V = V1 - V0; // relative velocity    Vector A = A1 - A0; // relative acceleration    Vector R = R1 + R0; // relative radius (as an 'extent' vector).    float t_enter = -INFINITY;    float t_exit  =  INFINITY;    if (!CollideSAT(P.x, V.x, A.x, R.x, t_enter, t_exit)) return false;    if (!CollideSAT(P.y, V.y, A.y, R.y, t_enter, t_exit)) return false;    return t_enter;}
Everything is better with Metal.
oliii
oliii
hmm... That might not work completely well actually. Just stick to first order only, by calculating the predicted position (say, p = p + v*t + a*t*t), and your current position, and tracing through.
Everything is better with Metal.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.

Sign in to reply to this topic.