OK, so over here in the UK the clocks just changed over from British Summer
Time to Grenwich Mean Time. Hence, although it was 10PM just a while ago, it
is now 9PM [again]. All of which means that I will be awake for another
hour. And what better reason to ask a random question? (OK, maybe having a
*point* would help, but hey...)

As some of you may or may not have noticed, I am currently at work on
another motion simulation. It began ages and ages ago with the "chaos
pendulumn" simulation, but current work is on a grid of particles held
together by elastic connections and allowed to deform under gravity.

Anyway, someone pointed out that my method is "Euler's method", the simplest
but least accurate method. (How exactly someone can tell just from the
pictures what algorithm I'm using I don't know... lol) So I was wondering...
what other methods are there? Have I missed something??

All I know is this: POV-Ray wants to know the positions of all the objects.
I know the initial positions - I *chose* them ;-) But an object's position
can change over time - something we usually refer to as "velocity".
Additionally, an object's velocity can change over time also - but only if a
"force" is applied to it. This force produces an "acceleration" which is
equal to the quotient of the force and the object's mass...

From the beginning, velocity is the rate at which an object's position
changes over time. Taking the movement over 1 dimension only, if an object's
velocity is 3 meters per second, that would mean that in 1 second it will be
3 meters away from where ever it is now. SO... between each frame, I can
take the object's previous position, and add on the velocity multiplied by
the number of seconds that have elapsed since the last frame. (Or, more
likely, the fraction of a second that has elapsed!)

In a similar way, an acceleration of 3 meters per second per second would
mean that in 1 seconds' time, the object will be moving at 3 meters per
second *faster* than however fast it is moving now...

In short, (working in 1 dimension) once I calculate the force acting on an
object (which depends on what I'm simulating), I can do this:
#declare Acceleration = Force / Mass;
#declare Velocity = Velocity + Acceleration*TimeStep;
#declare Position = Position + Velocity*TimeStep;
Now just add some file I/O to load/save the particle positions and
velocities between frames. (As far as I can see, this is the only
information you need from the previous frame.)

Even better, if I'm not mistaken, if I write each of the forces acting on
the object as a vector, then the resultant force is equal to the sum of the
vectors. (Correct?) Also, if I let Acceleration, Velocity and Position be
vectors, the above formulas still work. (Unless I missed something...)

I have found that for my current simulation, if I set certain parameters
certain ways, the simulation seems to go into "infinite acceleration" mode.
(I've actually had POV-Ray CRASH a few times due to number overflow
problems - I say chaps, should it really do that??) Anyway, following some
experiments I did with Excell in my lunch break at work, I tried changing
the simulation so that it does *several* updates each frame - in other
words, the TimeStep is now smaller tham 1/25 seconds.

I tried one set of parameters, and it went totally nutz. I changed the
simulation so that it does 10 updates per frame - 1/250 seconds interval -
and suddenly it's totally stable and works perfectly. Well, *almost*
perfectly... there are still little instabilities in it that seem to take
forever to dissapate. I'm not sure if using a finer grid would solve this,
or whether I need an even smaller TimeStep... or whether I need to use
something other than Euler's method (if, indeed, that is what I'm currently
using).

Basically, I can't really see what I could do any differently here... Any
suggestions folks?

Thanks.
Andrew.

PS. Yes, there *are* dissapative forces. In fact, last time round, I did it
by multiplying each object's velocity by (1 - exp(-8)) (because it's easier
to adjust the exponent). But that means if you change the frame rate, the
dissapation changes. So now it's done by creating a [small] force in the
opposite direction to the object's current velocity. Because it's a force,
it goes through that formula above, which depends on TimeStep. So if I
change the frame rate (or indeed the number of updates per frame) it
shouldn't affect the simulation in that way.

Post a reply to this message