in writing a game involving a fair amount of collision, i've hit (eh!) a problem in collisions involving more than one body.
i have a decent understanding of general collision detection and the physics of colliding objects, its just when there are a few objects colliding at the same time that my head starts to spin...
my first problem came up as follows :
+
|
|
|(1) <- (2)
|
|
+
ball (2) is heading directly for ball (1), which lies flush against the boundry.
in open space (ie no boundry) the collision is easy to solve, based on velocity, mass, transfer of energy, etc.
with the boundry, however, ball (2) will hit ball (1), which in turn "hits" the wall causing ball (2) to bounce back out.
with my first (simple) algorithm, i wouldnt detect that until it was too late.
depending on the sequence of balls evaluated, ball (1) may end up other side of the boundry, or bouncing off back at ball (2) which would only "register" that in the next game tick.
no matter which way, it always ended up wrong...
i hit similiar problems with situations such as these :
(1)(2) <- (3)
and
(1) <- (2)
^
|
(3)
(in which ball (2) and ball (3) are moving at equal velocities - again, depending on the order of balls evaluated, either (2) would hit (1) following which (3) hits (2), or (3) hits (2) and its finished. the results of which are totally different!)
as well as
(1) <- (2)
^
|
(3)
(in which (2) and (3) are set to hit (1) at exactly the same time. (1) should move off with the combined effect of these two balls - instead, it only responded to one
of them, and that depending on which was evaluated first!)
there were a couple of other similiar problem cases in which my simple system just failed to give consistent results.
after much problem-bashing, i cooked up a working system with *loads* of bulky code involving transactions, complex commit queues and way too much coffee.
i cant help but think that there must be a more elegant solution - something simple that i missed? something simple i would never have thought of?
or perhaps i am just over complicating things here? is there a way to avoid these problems altogether?
[edited by - craigf on August 11, 2003 6:22:12 PM]