JRG wrote:
> 
> [...]
> 
> 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.

I see.  By updating velocities you probably mean mirroring the velocities
at the normal vector (minus damping factor). 

> 
> 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 :)

You probably should have a look at some literature about numerical
integration.  Totally avoiding balls overlapping isn't possible with most
methods, but it is not necessary.  You just have to make sure that when
balls overlap there is a force driving them away from each other.

Christoph

-- 
POV-Ray tutorials, IsoWood include,                 
TransSkin and more: http://www.tu-bs.de/~y0013390/  
Last updated 15 Jul. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message