Iterative vs. equation based collision

Started by
5 comments, last by Fenrisulvur 14 years, 5 months ago
Alright, I was in class today and we're going over 3d collisions, and the teacher is using various movement equations to figure out the next time an object will have a collision. He then updates regularly until that time, then deals with the collision at the exact moment of the collision. I was wondering if that way is better than, worse than, or equal performance/complication wise than doing it iteratively where you check regularly every little bit to see if a collision occurred, then figure out the time it occurred and handle it accordingly. Comments?
Advertisement
Toss complex, rotating objects and extra forces (like linear/angular drag) into the mix, and analytically determining a moment of collision quickly becomes intractable. Under certain circumstances it is possible to guarantee, or at least assume, that there will be no collisions in the next n timesteps, which can be useful, but these lookaheads are conservative in nature, not exact "collision appointments".
Forget drag - by this time you've probably gone with a numerical approach to that*, so movement within a frame will probably be either linear or quadratic anyway.

Otherwise, I'm agreeing with Sneftel - the analytical a priori dream goes to hell when things start rotating, because all of a sudden t starts appearing as an argument within your trig functions, and as far as I understand, the solution to

y = ax + sin(bx)

for x transcends the elementary mathematical functions, and libraries that implement...well, whatever that function has been christened, just do some sort of numerical iteration anyway. (correct me if I'm wildly off course)

Anyway, I guess keep in mind that all sorts of mitigating factors in the messy real world throw off any perfect analytical solution of anything - so don't stress too much about it in a videogame.


*Although the analytical solution is interesting.

EDIT: I forgot to note, if your teacher actually is implementing analytical collision detection for translating/rotating objects, that's some deep magic, and I want in. ;)
Quote:Original post by Fenrisulvur
Forget drag - by this time you've probably gone with a numerical approach to that*, so movement within a frame will probably be either linear or quadratic anyway.

Otherwise, I'm agreeing with Sneftel - the analytical a priori dream goes to hell when things start rotating, because all of a sudden t starts appearing as an argument within your trig functions, and as far as I understand, the solution to

y = ax + sin(bx)

for x transcends the elementary mathematical functions, and libraries that implement...well, whatever that function has been christened, just do some sort of numerical iteration anyway. (correct me if I'm wildly off course)

Anyway, I guess keep in mind that all sorts of mitigating factors in the messy real world throw off any perfect analytical solution of anything - so don't stress too much about it in a videogame.


*Although the analytical solution is interesting.

EDIT: I forgot to note, if your teacher actually is implementing analytical collision detection for translating/rotating objects, that's some deep magic, and I want in. ;)


I think so far he's just doing balls colliding with planes and other balls, and rotation isn't really a factor right now.

I just wanted to know if it would be worth my time to find and use different code from his for what I ended up doing for my final.
Oh - if it's just balls and non-rotating planes, no need for iterative methods at all. :)
Quote:Original post by Fenrisulvur
Oh - if it's just balls and non-rotating planes, no need for iterative methods at all. :)


well his examples have non-moving/rotating planes, but my final will. Should I stick with writing it differently than he has now?
Okay, well, firstly, if anything at all in your world is rotating (apart from perfect spheres rotating around their geometric centre), and at the same time anything is translating (that is, being displaced with respect to time - has velocity, etc), then, like has been said, that's a black art - or deep magic at best. If you still want a priori (and now's definitely not the time to wuss out and settle for a posteriori >_>), iterative techniques are probably your best bet, and you should definitely track such information down. The Forum FAQ might help you there; I'm not sure where else to point you.

This topic is closed to new replies.

Advertisement