It has been quite a while since I've posted any animations here, but I was 
recently inspired by Tim Nikias' website about his particle system to try a 
Matrix style effect with an I/O based particle system. The anim is quite crude, 
but was only intended to determine whether it could be done. It can :-)

MJL

Post a reply to this message

Attachments:
Download 'partimatrix.mpg' (277 KB)

Ooh, neat! You should have let it go longer, though, so we could see them
settle down a bit.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

Very nice! Is this your own particle system or did you expand Tim's?

When you say "matrix" what does it mean - that it's calculated with static
functions rather than evaluating the enviroment, what ever it may be?  If
so, the only reason I can imagine for using a static approch would be higher
speed of parsing.. At the expense of flexibility. But it could be useful in
some situations, for example water fountains.

Your animation doesn't look crude.. I like it.

Regards,
hugo

Post a reply to this message

Matrix was used to refer to the bullet-time effects
of the movie "The Matrix", not the matrix of
POV...

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

--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde

> Very nice! Is this your own particle system or did you expand Tim's?
>
> When you say "matrix" what does it mean - that it's calculated with static
> functions rather than evaluating the enviroment, what ever it may be?  If
> so, the only reason I can imagine for using a static approch would be
higher
> speed of parsing.. At the expense of flexibility. But it could be useful
in
> some situations, for example water fountains.
>
> Your animation doesn't look crude.. I like it.
>
> Regards,
> hugo
>

Post a reply to this message

I knew that it can be done. After all, I/O may be
modelled in such a way that particle may move
slower and slower until they stop, its just the
velocity and gravity have to be influenced appropriately
as not to negate the realistic effect.

But, is it possible for your system to run backwards?

But never mind. I guess everything can be implemented
in a non-I/O as well as an I/O system, its just patience and
knowledge that divides the possibilities. Look at Rune's
system, it supports looping. So, in a sense, it could
support moving backwards through time, as it would
just have to calculate the path of a particle a little less
further...
But sometimes you want nice, easy and intuitive
algorithms and setups, and then its sometimes the
best idea to model programs to fit a certain task.

And I do like the animation, though it should go a
little longer to see the balls drop, and they should
be stretched a little from speed, like you can see
in some of Rune's animations (IIRC) and Chris'
System, and last of all, mine. :-)

--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html
Email: Tim### [at] gmxde
"Mark James Lewin" <m_j### [at] yahoocomau> schrieb im Newsbeitrag
news:3DC### [at] yahoocomau...

> It has been quite a while since I've posted any animations here, but I was
> recently inspired by Tim Nikias' website about his particle system to try
a
> Matrix style effect with an I/O based particle system. The anim is quite
crude,
> but was only intended to determine whether it could be done. It can :-)
>
> MJL
>

Post a reply to this message

Thanks.

Slime wrote:
> Ooh, neat! You should have let it go longer, though, so we could see them
> settle down a bit.

I know, but it was just a test.

MJL

Post a reply to this message

Hugo wrote:
> Very nice! Is this your own particle system or did you expand Tim's?

Thanks! This is my own system.

> When you say "matrix" what does it mean - that it's calculated with static
> functions rather than evaluating the enviroment, what ever it may be? 

Matrix, the movie.

MJL

Post a reply to this message

Tim Nikias wrote:
> Matrix was used to refer to the bullet-time effects
> of the movie "The Matrix", not the matrix of
> POV...
> 
> 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)... :-)

I remember this only because the non-I/O approach is so different to my own.

MJL

Post a reply to this message

Tim Nikias wrote:
> I knew that it can be done. After all, I/O may be
> modelled in such a way that particle may move
> slower and slower until they stop, its just the
> velocity and gravity have to be influenced appropriately
> as not to negate the realistic effect.
> 
> But, is it possible for your system to run backwards?

It should be able to run backward. I'll have to try.

> But sometimes you want nice, easy and intuitive
> algorithms and setups, and then its sometimes the
> best idea to model programs to fit a certain task.

Yes, I can't agree more here. This was the first time in about 6 months that I 
touched my particle system. It was a little more difficult to get back into it 
than I had hoped.

> And I do like the animation, though it should go a
> little longer to see the balls drop, and they should
> be stretched a little from speed, like you can see
> in some of Rune's animations (IIRC) and Chris'
> System, and last of all, mine. :-)

Thanks. I think stretching is quite redundant on what is essentially a simple 
test, though.

MJL

Post a reply to this message

Nice.  Would be interesting to see how they bounce on out.  Can they remain
stationary on the floor?

Post a reply to this message

> 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