"Slime" wrote:
> Ooooh, you wrote this in C++? No wonder it's so fast. Mine's in POV-SDL =)
> mainly so I can use the trace() function.

Yeah, no in C, but hey I told you that :). The POV version was basically the same
thing and, according to my previous post, the last frames took about 9 sec to parse
(200 balls, 10 iterations per frame).

> The algorithm basically works like this, for each iteration:
>
> 1. find every possible collision that will occur during this iteration
> 2. take the first collision and react to it, advancing all the balls the
> amount of time that has passed
> 3. repeat until there are no more collisions during this iteration
>
> Now, it doesn't work exactly like that; if it did, it'd be about 10 times as
> slow. I've optimized it in various ways, but that's the gist of it. (the
> main optimization is only checking for collisions involving balls that have
> had collisions earlier during the current iteration, or which *will* have a
> collision sometime during the iteration. That is, if a ball is found to have
> no collisions during the iteration, ignore it in subsequent loops until the
> next iteration.) Hard to explain, as you can see.

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?

I would like to see your algorithm used to fill up a container just like this, for
comparison :-)


--
Jonathan.

Post a reply to this message