global_settings{waffle on}

Okay, so I've made a start on my particle system, but would like a couple of
pointers (or even cheeky samples).  Here's what I've got so far...

Make Some Particles (on first frame):
    pos1=rand(...)
    velocity1=rand(...)
    force1=0
    mass1=1
do for each frame_number
    Load Particle Data (pos, velocity, force, mass, ...extras...)
    Draw The Particles
    Calculate New Positions
    Save Particle Data
next frame_number

Now this seems like a logical choice of steps, so I assume (?) my troubles
are with the calculations.  It must have taken even Him some time to get the
rules right...

The only interaction I'm looking at is the attraction due to each of the
other particles, with BigG being a guess for this system:
//newforce = oldforce + direction*(Universal Gravitation)
#declare force1 = force1 +
    vnormalize(pos2-pos1) * ((BigG * mass1 * mass2) / vlength(pos2-pos1)^2);

which should give me a nice force pulling the particle around, yes?  This is
where I kind of "made it up" to get something that looked like it works:
#declare velocity1 = velocity1+force1;  //first leap of faith
#declare pos1 = pos1+velocity1;  //second leap of faith

Now while this can create some quite nice animations, it seems heavily
dependent on correct settings for BigG with relation to ParticleCount and
mass.
So, is this to be expected?  Particles either achieve escape velocity
immediately, or clash together and head off together into the distance.

Any help greatfully received, although just putting all this down in words
seems to help sometimes too ;)
--

Mark Hanford
http://www.mrhanford.com/povray

Post a reply to this message

Mark Hanford wrote:

> global_settings{waffle on}
>
> Okay, so I've made a start on my particle system, but would like a couple of
> pointers (or even cheeky samples).  Here's what I've got so far...
>
> Make Some Particles (on first frame):
>     pos1=rand(...)
>     velocity1=rand(...)
>     force1=0
>     mass1=1
> do for each frame_number
>     Load Particle Data (pos, velocity, force, mass, ...extras...)
>     Draw The Particles

I tend to draw the particles last, but so long as you are consistent...

>
>     Calculate New Positions
>     Save Particle Data
> next frame_number
>
> Now this seems like a logical choice of steps, so I assume (?) my troubles
> are with the calculations.  It must have taken even Him some time to get the
> rules right...
>
> The only interaction I'm looking at is the attraction due to each of the
> other particles, with BigG being a guess for this system:
> //newforce = oldforce + direction*(Universal Gravitation)
> #declare force1 = force1 +
>     vnormalize(pos2-pos1) * ((BigG * mass1 * mass2) / vlength(pos2-pos1)^2);

I hope you set each particle's force to <0,0,0> before accumulating the
gravitational forces from the other particles. The total force should not
accumulate between time steps, it should be evaluated at each time step only.

>
>
> which should give me a nice force pulling the particle around, yes?  This is
> where I kind of "made it up" to get something that looked like it works:
> #declare velocity1 = velocity1+force1;  //first leap of faith
> #declare pos1 = pos1+velocity1;  //second leap of faith
>

Note that...

velocity = velocity + acceleration*timestep;

and...

acceleration = Force / mass;

Because you have mass = 1, this does not matter, but think of what should happen
when mass != 1.

Note too that the timestep should be small (really small) for a good simulation.
This may mean performing more than one set of position calculations per frame of
animation; for my mini solar system anim, I think I used eight itterations per
frame.

From the looks of it, you are only performing one itteration per frame, so you
might want to try more.

>
> Now while this can create some quite nice animations, it seems heavily
> dependent on correct settings for BigG with relation to ParticleCount and
> mass.
> So, is this to be expected?

Your BigG is scaling your force, so you should expect BigG to make a big
difference. And, the more particles you have, the more forces from neighbours
each individual particle will experience.

Note that BigG in Newtonian physics = 6.67 x 10-11 Nm2/kg2 regardless of the
number of bodies (particles) in the system. My tip is to stick to one BigG value
and adjust the mass of the particles.

> Particles either achieve escape velocity
> immediately, or clash together and head off together into the distance.

> Any help greatfully received, although just putting all this down in words
> seems to help sometimes too ;)

Good luck with it. I'm sure others will be able to give you a better explaination
than myself.

MJL

Post a reply to this message

You're using the (in)famous and forward Euler algorithm, which is very easy
to implement. This algorithm can become instable in some cases (like in your
case).

The following piece of code should make your system a bit more stable.
Increasing the steps per frame and decreasing the step size will make the
simulation slower, but more precise and stable. The damp factor eats away a
very small piece of the velocity at every time step. The more it eats away
(by lowering the damp factor), the more stable the system will be and the
faster the particles loose velocity.

/////////////// code snippet ///////////////
#declare stepsPerFrame = 100;
#declare stepSize = 0.01;
#declare dampFactor = 0.99;

#while (step < stepsPerFrame)
  #declare force1 = force1 + stepsize * vnormalize(pos2-pos1) * ((BigG *
mass1 * mass2) / vlength(pos2-pos1)^2);
  #declare velocity1 = velocity1 * dampFactor + force1;  //first leap of
faith
  #declare pos1 = pos1 + velocity1 * stepSize;  //second leap of faith
  #declare step = step + 1;
#end
/////////////// end of code snippet ///////////////
--
Apache
http://geitenkaas.dns2go.com/experiments/
apa### [at] yahoocom

Post a reply to this message

Consider:
http://www.geocities.com/pterandon/boids.html

Post a reply to this message

Thanks!  That looks like it might help in more than one place... I'll give
it a go.

--

Mark Hanford
http://www.mrhanford.com/povray


"Mark Lewin" <m_j### [at] yahoocomau> wrote in message
news:3C9AA765.EEFD3B57@yahoo.com.au...
>
>
> Mark Hanford wrote:
>
> > global_settings{waffle on}
> >
> > Okay, so I've made a start on my particle system, but would like a
couple of
> > pointers (or even cheeky samples).  Here's what I've got so far...
> >
> > Make Some Particles (on first frame):
> >     pos1=rand(...)
> >     velocity1=rand(...)
> >     force1=0
> >     mass1=1
> > do for each frame_number
> >     Load Particle Data (pos, velocity, force, mass, ...extras...)
> >     Draw The Particles
>
> I tend to draw the particles last, but so long as you are consistent...
>
> >
> >     Calculate New Positions
> >     Save Particle Data
> > next frame_number
> >
> > Now this seems like a logical choice of steps, so I assume (?) my
troubles
> > are with the calculations.  It must have taken even Him some time to get
the
> > rules right...
> >
> > The only interaction I'm looking at is the attraction due to each of the
> > other particles, with BigG being a guess for this system:
> > //newforce = oldforce + direction*(Universal Gravitation)
> > #declare force1 = force1 +
> >     vnormalize(pos2-pos1) * ((BigG * mass1 * mass2) /
vlength(pos2-pos1)^2);
>
> I hope you set each particle's force to <0,0,0> before accumulating the
> gravitational forces from the other particles. The total force should not
> accumulate between time steps, it should be evaluated at each time step
only.
>
> >
> >
> > which should give me a nice force pulling the particle around, yes?
This is
> > where I kind of "made it up" to get something that looked like it works:
> > #declare velocity1 = velocity1+force1;  //first leap of faith
> > #declare pos1 = pos1+velocity1;  //second leap of faith
> >
>
> Note that...
>
> velocity = velocity + acceleration*timestep;
>
> and...
>
> acceleration = Force / mass;
>
> Because you have mass = 1, this does not matter, but think of what should
happen
> when mass != 1.
>
> Note too that the timestep should be small (really small) for a good
simulation.
> This may mean performing more than one set of position calculations per
frame of
> animation; for my mini solar system anim, I think I used eight itterations
per
> frame.
>
> From the looks of it, you are only performing one itteration per frame, so
you
> might want to try more.
>
> >
> > Now while this can create some quite nice animations, it seems heavily
> > dependent on correct settings for BigG with relation to ParticleCount
and
> > mass.
> > So, is this to be expected?
>
> Your BigG is scaling your force, so you should expect BigG to make a big
> difference. And, the more particles you have, the more forces from
neighbours
> each individual particle will experience.
>
> Note that BigG in Newtonian physics = 6.67 x 10-11 Nm2/kg2 regardless of
the
> number of bodies (particles) in the system. My tip is to stick to one BigG
value
> and adjust the mass of the particles.
>
> > Particles either achieve escape velocity
> > immediately, or clash together and head off together into the distance.
>
> > Any help greatfully received, although just putting all this down in
words
> > seems to help sometimes too ;)
>
> Good luck with it. I'm sure others will be able to give you a better
explaination
> than myself.
>
> MJL
>

Post a reply to this message

I'll try that damping, although at the moment, I think there are more
fundamental issues with my system...

--

Mark Hanford
http://www.mrhanford.com/povray


"Apache" <apa### [at] yahoocom> wrote in message
news:3c9aaded$1@news.povray.org...
> You're using the (in)famous and forward Euler algorithm, which is very
easy
> to implement. This algorithm can become instable in some cases (like in
your
> case).
>
> The following piece of code should make your system a bit more stable.
> Increasing the steps per frame and decreasing the step size will make the
> simulation slower, but more precise and stable. The damp factor eats away
a
> very small piece of the velocity at every time step. The more it eats away
> (by lowering the damp factor), the more stable the system will be and the
> faster the particles loose velocity.
>
> /////////////// code snippet ///////////////
> #declare stepsPerFrame = 100;
> #declare stepSize = 0.01;
> #declare dampFactor = 0.99;
>
> #while (step < stepsPerFrame)
>   #declare force1 = force1 + stepsize * vnormalize(pos2-pos1) * ((BigG *
> mass1 * mass2) / vlength(pos2-pos1)^2);
>   #declare velocity1 = velocity1 * dampFactor + force1;  //first leap of
> faith
>   #declare pos1 = pos1 + velocity1 * stepSize;  //second leap of faith
>   #declare step = step + 1;
> #end
> /////////////// end of code snippet ///////////////
> --
> Apache
> http://geitenkaas.dns2go.com/experiments/
> apa### [at] yahoocom
>
>

Post a reply to this message

I saw that page - I did like what I saw, and it had some quite good examples

--

Mark Hanford
http://www.mrhanford.com/povray


"Greg M. Johnson" <"gregj;-)56590\""@aol.c;-)om> wrote in message
news:3c9c9910$1@news.povray.org...
> Consider:
> http://www.geocities.com/pterandon/boids.html
>

Post a reply to this message