Haha! Its interesting how I replied a post and covered
the technique you used, and you replied a post and covered
the technique I used... Thats amusing! :-)

And yes, the technique is similiar to Chris' Spray,
but when implementing this with a box (instead of just
one plane), it gets quiet difficult. Just a few days ago
I had to fix a bug where particles still dropped through
a wall: It hit one hall, and the new impact-position from
which the next path is generated was so close to the
wall, that it fell through the time-calculation of impacts...
(If any of that makes sense... Would be nice to think
it makes some sense! ;-)

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

>
> By using several functions with different coefficients, where a particle
> follow a new appropriate one every time it bounces. It is easy to check
> if the x, y or z value of the position of a particle is below or above
> certain values, so it is possible to simulate what appears to be
> interaction with a non-rotated box. It would be possible with other
> shapes too, but it would be way too advanced and inefficient.
>
> I can't tell about it in details of course, but the technique is not a
> new one, since the same basic technique is used in Chris Colefax' Liquid
> Spray Include File from 1998, though that one only supports a single
> ground plane instead of a box.
> ( http://www.geocities.com/SiliconValley/Lakes/1434/spray.html )
>
> Rune

Post a reply to this message

> Nice work.

Thanks!

> I must admit however I'm a bit confused as to what's happening.  I'd be
less
> disoriented if there were some object or other way to get a feel for where
> the particles are being generated from.  I was expecting it to be one end
of
> the railing but am not sure of its purpose.

Hm, that would probably be of use. In some cases, the emitter
need not be visualized, because particles are present in the first
frame, but when particles appear, it might be better. I'll add it.

> It's cool that you have squash & stretch: does this limit use of other
> particles?

Nope. The effect may even be applied to other particles, though
that will most probably look strange. Its achieved by stretching
the particle along the z-axis and rotating it appropriately. So this
is best used with single-colored spheres, as then this method isn't
obvious.
Rebouncing takes place by calculating impacts of a spherical-field
with the box, so differently and uneven sized objects may look strange when
rebouncing, but that's a problem all general particle systems suffer
in POV (at least those I've seen so far).

> It looks like the particles are intersecting each other.  Is this a
> yet-to-be fixed bug, OR is your system more designed for fluids and the
> like?

Its not a bug, its a feature! :-)
To be honest, it cannot be overcome, and the system thus is best
used for liquids, smoke, fire etc. Efficiently and expertly used it
may not be obvious that particles intersect (when they're spaced far
enough apart and move around, you'll hardly notice one or two
intersections). After all, its not a real physical simulation. I'd like
to do that one day, but using pure POV-script this is just toooo
slooooow.

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

Post a reply to this message

Tim Nikias wrote:
> 
> Haha! Its interesting how I replied a post and covered
> the technique you used, and you replied a post and covered
> the technique I used... Thats amusing! :-)
> 
> And yes, the technique is similiar to Chris' Spray,
> but when implementing this with a box (instead of just
> one plane), it gets quiet difficult. [...]

I wonder if it's worth the efforts.  Of course it's very nice to be able
to calculate the state of the system at several arbitrary points of time
but for most purposes this is not necessary since you either calculate a
complete animation or you just want one final result.  And your method
can't calculate any more complicated influences like wind, friction etc.  

BTW, you gain quite some speed advantage if you use a hardcoded system. 
If you turn off collisions between masses in Sim-POV and use method 2
environment
collisions you can use quite large time steps without problems and will
have quite negligible simulation times with particle counts like in your
sample.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 28 Oct. 2002 _____./\/^>_*_<^\/\.______

Post a reply to this message

> I wonder if it's worth the efforts.  Of course it's very nice to be able
> to calculate the state of the system at several arbitrary points of time
> but for most purposes this is not necessary since you either calculate a
> complete animation or you just want one final result.  And your method
> can't calculate any more complicated influences like wind, friction etc.

Well, I've begun this project just about more than two
years ago, so I was hardly thinking about implementation
issues, but rather my own skills at that moment. I just moved
from there, and at some point decided to stay non I/O.
Also, I'm a purist kind of artist, modelling and creating
with the intention of being able to say that "absolutely
everything you see is made by me", thus for particle effects
(which shall be used for explosions, smoke, etc) I needed
my own particle system.
I can still remember the day I began: A few spheres scattered
randomly across a disc, moving from their initial location to
a given end-location in a given time. It all evolved from there...

> BTW, you gain quite some speed advantage if you use a hardcoded system.
> If you turn off collisions between masses in Sim-POV and use method 2
> environment
> collisions you can use quite large time steps without problems and will
> have quite negligible simulation times with particle counts like in your
> sample.

I know that "hardcoding" calculations with C++ or even make a
custom version of POV increases the speed with which it is
calculated. Still, I like to use "original" packages, so I use POV-Ray
in its "pure" state. I only downloaded MegaPOV once, after
I knew that isosurfaces would get implemented, to have a look
at that.
And this way, my script can be run by anyone using POV-Ray,
no recompiling necessary. I like this aspect very much, which
is the same reason why I personally like Java, though C++ is
much more effective and AFAIK faster in many situations.

And regarding parsing times... I'm a very patient kind of guy, if
there is need for it. I do like getting things as quick as possible,
but if the ability of saying "that picture is MINE! *grin*" requires
a few more hours of tracing, no problem. I'm about to build
a second PC from former, updated parts, in order to have a
single PC just set up to trace images once I'm finished with
one...

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

Post a reply to this message

"Tim Nikias" <tim### [at] gmxde> wrote in message
news:3dbf12c8$1@news.povray.org...
>
>  Still, I like to use "original" packages, so I use
>  POV-Ray in its "pure" state.

See my boids algorithm, which uses I/O, and was "free" from day one.

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


I haven't used it since 3.5.

Post a reply to this message