> I see. What I don't understand is how this prevents any intersection to
happen. I
> mean: a collision happens when the distance between two balls (their
centres) is
> smaller than the diameter of the balls. Now what I do is to update their
velocity
> vectors accordingly, but their positions don't get touched. That's why
intersection
> is still possible in very specific cases. Now, do you *fix* the position
after a
> collision has been detected?

Yes. Let's say I have a system with two balls. Imagine this now: One ball is
at (0,0) and is heading towards (1,1). The other ball is at (1,0) and
heading towards (0,1). Assume their radii are extremely close to zero.

They're going to bounce off each other at time=0.5 (assuming time=1 is the
end of the iteration, when they reach their destinations).

I detect the collision at t=.5. I then figure out their new velocities. (In
this case, their velocities will simply be swapped, I believe. Or something
like that. Let's say for simplicity that they swap their velocities.)

Then I place the balls at (their current starting position) + (.5*(their old
velocity)) - (.5*(their new velocity))

Their new position is at (1,0) and (0,0), respectively. In this example,
they happen to have swapped starting positions.

Now that I've taken care of that intersection, I ignore any intersections
that occur at t <= 0.5. That way I won't detect their collision again. And
at the end of the iteration, I just add each balls' velocity to it's
position, so the first ball ends up at (0,1) and the second at (1,1).

Did that make sense?

Before long, I'll work on the code and make a new example for you. But not
now... Warcraft III takes priority =) (two levels left! I think.)

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message