> And he couldn't have used mine, cause he used an I/O
> system (its in the headline) and mine is non-I/O. People
> always forget that (or never know)... :-)

Hmm maybe the camera then needs to gradually move into and out of its
rotation.  Rather than a fixed speed?

Post a reply to this message

I loved The Matrix, and I really rather like this test anim too! Nice work.

Andrew.

Post a reply to this message

Mark James Lewin wrote:
> It should be able to run backward. I'll have to try.

Slowing down to a stop I can understand, but I can't see how you can
make it run backwards, without having to recalculate everything from
scratch in those frames that run backwards (which would parse very
slowly). Unless of course you save the data for each calculation step so
that you have at once the data for the entire simulation, as opposed to
just for one frame at a time. But that can require quite big amounts of
space for simulations with many particles...

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated Oct 19)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

Thanks you!

MJL

Andrew Coppin wrote:
> I loved The Matrix, and I really rather like this test anim too! Nice work.
> 
> Andrew.
> 
> 
>

Post a reply to this message

I haven't tried it yet (hopefully will in a few days), but assuming

V(new) = V(old) + Acceleration*Delta_Time
P(new) = P(old) + V(new)*Delta_Time

I cannot see too much trouble with negative Delta_Time values so long as the 
Acceleration term is constant. Environmental collisions shouldn't be too much of 
a problem either. Am I missing something here?

As for saving particle data for each frame, I do this sometimes to make 
re-rendering a slow-parsing animation faster (eg. if I want to change how the 
particles are textured). I can typically save data for 1500-2500 particles before 
the data files get larger than a 320X240 frame saved in an uncompressed format. I 
don't see this as a major problem considering hard disk sizes nowadays.

MJL

Rune wrote:
> Slowing down to a stop I can understand, but I can't see how you can
> make it run backwards, without having to recalculate everything from
> scratch in those frames that run backwards (which would parse very
> slowly). Unless of course you save the data for each calculation step so
> that you have at once the data for the entire simulation, as opposed to
> just for one frame at a time. But that can require quite big amounts of
> space for simulations with many particles...

Post a reply to this message

Mark James Lewin wrote:
> I haven't tried it yet (hopefully will in a few days),
> but assuming
>
> V(new) = V(old) + Acceleration*Delta_Time
> P(new) = P(old) + V(new)*Delta_Time
>
> I cannot see too much trouble with negative Delta_Time
> values so long as the Acceleration term is constant.

Well, to have it work accurately, you have to slow down the rate of the
calculation frames themselves, not the Delta_Time. (I think.)

For a small simulation, simply changing the Delta_Time may seem to work
perfectly, but imagine having a simulation running for 10 seconds, then
going 10 seconds backwards. (Or if you need a more extreme example, make
it one minute both ways.)

The small precision errors can accumulate very much in such a situation,
so you have no guarantee that the particles will end up at exactly the
same positions where they started. And if they can end up a little off,
then they can also end up completely off, given a more complex case.

> As for saving particle data for each frame

> I can typically save data for 1500-2500 particles
> before the data files get larger than a 320X240
> frame saved in an uncompressed format. I don't
> see this as a major problem considering hard disk
> sizes nowadays.

2500 particles for how many seconds and with how many steps per second?
And how much data do you have per particle per step?

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated Oct 19)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message

Rune wrote:
> Mark James Lewin wrote:
> 
>>I haven't tried it yet (hopefully will in a few days),
>>but assuming
>>
>>V(new) = V(old) + Acceleration*Delta_Time
>>P(new) = P(old) + V(new)*Delta_Time
>>
>>I cannot see too much trouble with negative Delta_Time
>>values so long as the Acceleration term is constant.
> 
> 
> Well, to have it work accurately, you have to slow down the rate of the
> calculation frames themselves, not the Delta_Time. (I think.)

Using Newton's method (which is what I use) requires a large number of 
itterations for accuracy anyway.

For each frame in an animation, I have a variable called Time_Step which is the 
amount of time which has passed since the last frame in the animation. The value 
of Delta_Time used in each itteration of the calculation depends on both the 
number of itterations specified, and the value of Time_Step.

> For a small simulation, simply changing the Delta_Time may seem to work
> perfectly, but imagine having a simulation running for 10 seconds, then
> going 10 seconds backwards. (Or if you need a more extreme example, make
> it one minute both ways.)
> 
> The small precision errors can accumulate very much in such a situation,
> so you have no guarantee that the particles will end up at exactly the
> same positions where they started. And if they can end up a little off,
> then they can also end up completely off, given a more complex case.

I am well aware of this problem. There is even the concern that you have not 
inadvertantly rounded off some important significant figures when saving the data 
  between frames.

I do not consider my particle system to be a rigorous physics simulation by any 
means. It was designed to automate some effects that I wanted to animate, and for 
this it has generally suceeded. If I wanted a more accurate system, I would 
probably look into Runge-Kutta methods for solving particle positions.

>>I can typically save data for 1500-2500 particles
>>before the data files get larger than a 320X240
>>frame saved in an uncompressed format. I don't
>>see this as a major problem considering hard disk
>>sizes nowadays.
> 
> 
> 2500 particles for how many seconds and with how many steps per second?
> And how much data do you have per particle per step?

One 320X240 frame bitmap ~ 226kb. Typically, I save particle position, velocity, 
age, and mass. On average, each particle uses about 90 bytes to store this 
information, and that's about 2500 particles to give a file size equivelent to 
the bitmap for that frame.

Saving particle data for each itteration is redundant for re-rendering purposes; 
all that is required is the data from the last itteration. If you are doing a 1 
minute animation at 25 fps, you'd generate ~ 330 Mb of bitmaps, and 330 Mb of 
particle data. I really don't see this as a problem when (a) hard drive sizes are 
measured in gigabytes now, and (b) if you wanted to keep the particle data for a 
long time, you could create a zip with good compression because the files are 
just ascii.

MJL

Post a reply to this message