"Christoph Hormann" wrote:
> Nice, could you have a few more words on the algorithm used? How do you
> handle multiple simultaneous collisions of one ball?

I have to say that the real fun was to handle the vector structs and functions... the
algorithm itself (which I shamelessly copied from my previous POV coded version) is
rather banal. A simple and not too optimised O(N^2) algorithm:

1) For frame = 1 to final_frame.
1.1) For iteration = 1 to num_of_iterations.
1.1.1) For ball = 1 to balls (frame).
1.1.1.1) Update positions and velocities.
1.1.1.2) Check collisions with walls and floor.
1.1.1.3) For other_ball = ball +1 to balls (frame)
1.1.1.3.1) Check collision with other_ball.

That's it. As you can see, I do not handle simutaneous collisions at all. One ball
can collide with another one. After that (point 1.1.1.3.1) its velocity gets updated.
Then it can collide with another ball during the same iteration. The new collision is
treated just as the other one, but with the updated velocity vector.

The main problem is to handle the balls staying one on each other. They rather tend
to *sink*, because the top balls tend to go down for the gravity acceleration while
those on the bottom of the container cannot sink anymore. I've used some trick to
avoid this: for example after a collision loop I save the mean of the distances (a
vector) between the ball considered and those which it collided with, and do not
consider the component of the acceleration along that vector during the next
iteration. This trick helped a lot but it's still not enough.
Any idea? I can post any code you want, but it's pretty ugly :)


--
Jonathan.

Post a reply to this message