Josh wrote:
> >  There are ways to speed it up, like keeping a record of which
> > grains are in similar "regions" to other grains, then you don't
> > have to compare every single grain with every other one.
>
> Cool.  Theres a good head start for me.

I did a simple system in 2D where it divided the screen into a number of
sections.  There was a list for each section that stored which particles
were in that section.  Then for each particle I only had to check the other
ones in that section and the 8 neighbouring sections.  Experiment with
different sizes of section to see what gives the best results.

> > It would look absolutely stunning if you could do this well, but I
> > suspect the simulation times would be massive. Even a very small
> > amount of sand would probably contain millions of grains.
>
> Well, if I'm going to do this, I'm going to create a "generic" system
> of some sort that could model sand, rocks or water (blobs) I guess.
>
> Hopefully the algorythm  will be simple, but the processing heavy (
> all the fun jobs are like that )

The way I did it was to make each particle produce a force on every other
particle proportional to 1/(r^n), where r is the distance between the two
particles and n is some number to play about with.  You might also want to
replace r with (r-x) where x is some fraction of the particle size to ensure
the particles don't get too close together.  IIRC 4 and 8 worked quite well
for n.

Also bear in mind this system can easily become unstable if your time step
is too big or your forces too big.  Just imagine if in 1 frame a particle
moved to be almost on top of another, this would create a *huge* force for
the next frame, sending the particle off into space.  If you really want the
speed in your sim then look at better numerical integration methods rather
than just doing position+=velocity*dt each frame.  Runge-kutta is a good
one, and there are adaptive methods too.

I find the fun part is to make the code run faster by using clever tricks...

Post a reply to this message