I'm trying to slap some demonstration scenes together
for my particle-system and on this one I'd like to get
some information. I'm not too sure if it isn't overloaded
with animation, with camera movement and fast paced
particles and all...
This scene is to demonstrate particles that have no initial
speed by themselves (they aren't "shot" anywhere), but
rather only move due to the inertia that is inflicted upon
them by the moving field in which they are born.

You can also see the "standardized" setup of the system's
boundary-box, the "Physics Room" (the system may
calculate the paths very realistic "physics", pretty easy
and quick "simple", or using a "macro").

All comments welcome!

Regards,
Tim

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

Post a reply to this message

Attachments:
Download 'inertia.mpg' (279 KB)

> *snip*
> You can also see the "standardized" setup
> *snip*

Hm... With "standardized" I mean standard for
the demonstration files, not for the system. Just
wanted to make sure that that's clear...

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

Post a reply to this message

I like it. No criticism at all.

All the best,

Andy Cocker

"Tim Nikias" <tim### [at] gmxde> wrote in message news:3dbe5bfe@news.povray.org...
> I'm trying to slap some demonstration scenes together
> for my particle-system and on this one I'd like to get
> some information. I'm not too sure if it isn't overloaded
> with animation, with camera movement and fast paced
> particles and all...
> This scene is to demonstrate particles that have no initial
> speed by themselves (they aren't "shot" anywhere), but
> rather only move due to the inertia that is inflicted upon
> them by the moving field in which they are born.
>
> You can also see the "standardized" setup of the system's
> boundary-box, the "Physics Room" (the system may
> calculate the paths very realistic "physics", pretty easy
> and quick "simple", or using a "macro").
>
> All comments welcome!
>
> Regards,
> Tim
>
> --
> Tim Nikias
> Homepage: http://www.digitaltwilight.de/no_lights/index.html
> Email: Tim### [at] gmxde
>
>
>

Post a reply to this message

Tim Nikias wrote:
> I'm not too sure if it isn't overloaded with animation,
> with camera movement and fast paced particles and all

I had to view it a few times, but after that I had no problems to understand
what's going on. The camera movement is a little distracting because it has
nothing to do with the P.S., but I guess it helps to optain a good viewing
angle all the way. Maybe it could move less, though.

It would be great with collision detection between the balls, even though
such a feature would be slow. It would be a great step towards realism and
help separate your P.S. from Rune's. It seems your system is aimed at
simulating solid objects falling around.

Nice work.

Hugo

Post a reply to this message

> I had to view it a few times, but after that I had no problems to
understand
> what's going on. The camera movement is a little distracting because it
has
> nothing to do with the P.S., but I guess it helps to optain a good viewing
> angle all the way. Maybe it could move less, though.

I was beginning to think so to. Its a little too much movement
of the camera...

> It would be great with collision detection between the balls, even though
> such a feature would be slow. It would be a great step towards realism and
> help separate your P.S. from Rune's. It seems your system is aimed at
> simulating solid objects falling around.

That is actually not possible. Rune's PS works by using I/O, every
next step is based on the last, particles move from their position
with a given velocity and direction, the new position is saved, and
loaded and redone for the next frame.
My system uses no I/O, the path a particle takes is calculated using
the simple graph
Position=Initial_Position+Direction*Velocity+Gravity*t*t

Solving the equation to find certain x, y and z values and recalculating
the graph from there results in what you see as the rebouncing off of
walls.
In this manner, I can't check for every particle, IF and WHEN at
*some* time, two particles *might* collide, and IF they DO, what
to do then...
So, I'm not calculating in iteration steps, but rather as processing the
path through time, which is (when not interacting with other particles
and only with the boundary-box) already quite difficult.

In my case, there's no interaction with the environment, but only with a
mathematical boundary, which *happens* to be like a non-rotated box...

So, solid (spherical) objects falling around is actually Rune's
strength, the particles interact with the environment. My system is
aimed at custom particle effects, more like "Magic Sparkles",
perhaps a splash of water, some fire. But without real interaction
with an environment. The strength of my system is that it can
animate backwards, and fade to a stop (bullet-time). Search the
animation-posts for "Matrix-Effect with PartixGen"...

Regards,
Tim


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

Post a reply to this message

Thanks. So I've already got one satisfied customer... ;-)

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

> I like it. No criticism at all.
>
> All the best,
>
> Andy Cocker
>

Post a reply to this message

Tim Nikias wrote:
> 
> [...]
> 
> That is actually not possible. Rune's PS works by using I/O, every
> next step is based on the last, particles move from their position
> with a given velocity and direction, the new position is saved, and
> loaded and redone for the next frame.
> My system uses no I/O, the path a particle takes is calculated using
> the simple graph
> Position=Initial_Position+Direction*Velocity+Gravity*t*t
> 

I don't really understand how this is supposed to work.  Your particles
seem to interact with the ground plane and the walls.  How do you do that
without using discrete time steps and linear movement between those steps?

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

Nice work.

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.

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

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?

"Tim Nikias" <tim### [at] gmxde> wrote in message
news:3dbe5bfe@news.povray.org...
> I'm trying to slap some demonstration scenes
> together for my particle-system

How much will  **yours** cost?

Post a reply to this message

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

It seemed clear to me that the particles were reacting to centrifugal force, rather
than any
pre-built-in force (such as being shot from a canon, or water compressed emiting from
a
fountain). Hence the rail.. the motion of the emitter (which travels along the rail)
at any
one point dictating the direction and velocity of the particles at the moment that
they're
emitted.

And I like the camera motion, though I would agree that it's not strictly neccessary.

All the best,

Andy Cocker

Post a reply to this message

Christoph Hormann wrote:
> I don't really understand how this is supposed to work.
> Your particles seem to interact with the ground plane
> and the walls.  How do you do that without using
> discrete time steps and linear movement between those
> steps?

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
--
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