"Christoph Hormann" wrote:
>
>
> 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).

Exactly.

> >
> > 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.

Actually I've just studied numerical calculus at University... but didn't take the
exam yet (I'll probably do it in september) so I still have to read through my papers
before doing something useful with the new notions I have... :-)

> 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.

Yeah, that's the other way round :) I didn't take into account *forces*, just gravity
acceleration and collisions. Anyway I'll look into it deeplier as soon as I have my
calculus exam done.

Cheers,

--
Jonathan.

Post a reply to this message