In this animation I just want to show off one of the features the System
will have: when a particle hits an object, it may call a macro, which in
turn may add new particles to the System. The macro can be applied generally
to a particle, but it can also be set that when a certain particle hits a
certain object, a certain macro gets called (many certainties there, huh?).

So far, I've only implemented that once a particle his an object, and that
object has an impact-macro attached to it, that macro gets called. Here this
produces the orange/yellow glows which act more like a fluid than like
bouncy particles, that is because their settings are of a different make-up.

Nontheless, all particles are run from within one core structure, so it's
not like I've included the same script twice or such to make this possible.

I'm open for suggestions (though I do have quite a many features in my head
that I want to implement eventually, so maybe yours are already there), but
for now, I gotta go work. Enjoy!

Regards,
Tim

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de

Post a reply to this message

Attachments:
Download 'enhancements.mpg' (367 KB)

I like your particle-system because the versions I've tested can be rendered
distributed with SMPOV,
that is not the case with the Mech-Sims.

--Theo
-----------------------------------------------------------------------
Distributed Network-Rendering or Local SMP-Rendering. With SMPOV and
POV-Ray 3.5. * Download free at: http://www.it-berater.org/smpov.htm

Post a reply to this message

> I like your particle-system because the versions I've tested can be
rendered
> distributed with SMPOV,
> that is not the case with the Mech-Sims.

Ah, well, this System uses a different approach, as it uses frame-by-frame
integration (along with some adaptive sampling during a frame), so I'm not
sure if it is distributed-rendering compatible. I want to make some tests in
that regard once the main core is up and running properly and won't need
modifications anymore, but I tend towards saying that this particle system
won't be distributed-rendering compatible. The old one does, but this is a
new system, not an update of the old one. Once I know more I'll post some
statement in that regard, but don't keep your hopes too high.

BTW, I think Runes particle System is capable of distributed rendering, as
he doesn't use an adaptive approach, but a set amount of timesteps to
calculate the path. AFAIK, different machines with different frames to
render should still come to the same results.

Regards,
Tim

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de

Post a reply to this message

Just made a quick and dirty first test with the system as it is now:
distributed-rendering isn't possible. A system which calculates the data
right from the first frame onwards will get different results than one which
tries to begin at frame 26 and backtrace the path a particle has taken. This
is due to the precision differences and adaptive timestepping. There are of
course slightly different results, e.g. if a particle has to do 1.5
timesteps in a frame, it can quickly do 3 when jumping across two frames,
instead of doing 1.5 + 1.5. The difference in this stepping adds up to
different end results, which is of course no surprise.

It boils down to my decision to take advantage of calculating on a
frame-by-frame basis. My former particle system based itself on graphs and
thus inheritantly would produce the same result no matter at which frame you
start. This came with a great parsing cost, no frame could make use of
former calculations and thus, all calculations were done for every frame.

With this System, I wasn't coding for looping animations or such, but for a
straightforward approach with lots of room for object-interactions, and some
sort of interactivity: the User may define Macros which are called for
example when a certain particle type hits a certain object. These new
particles get stuffed into the running simulation. In effect, every frame is
based on the results of the former frames. To make a break visible, my
particle system keeps track of the last frame rendered. You may continue a
trace from there, or one frame later, otherwise, the System resets itself,
as the data it finds isn't in synch with the data it needs.

The only other way to go would be to preparse the animation in a rough cut,
saving the particle-data per frame and supply those for the scene-files
instead of letting each system simulate the particles... But then you could
also use MechSim for that.

Regards,
Tim

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de

Post a reply to this message

> I'm confused. Is this all written in POV SDL?

Yup, all in POV-SDL.

> If so, how are you rendering multiple frames of an animation?

Well, the command-line "+KFI1 +KFF150", for example would give me 150 frames
with numbers from 1 to 150. Look it up in the docs. ;-)

> Doesn't an animation need a POV file for each frame, basically?

No, it doesn't, that's what the clock-variable is for: if you put a sphere
at <0,clock,0>, then during those 150 frames, it will move from <0,0,0> to
<0,1,0> (as clock is "0" in first and moves to "1" in last frame by
default).

> Couldn't you output these all first, then distribute the render?

I'm not sure if you know what Theo was talking about: he wasn't referring to
having different machines render different frames (like the IMP does it),
but instead, ALL machines render parts of the SAME frame. This is especially
useful for images which would otherwise require days and days of rendering
time. But for this to work, every machine must have the exact same data for
the scene...
Thinking about it some more: if every machine renders part of every frame,
then actually the distributed rendering should work. It just doesn't work if
the System has to backtrace the particles.

> I haven't used SDL very intensively, and certainly nothing as
> sophisticated as doing animation calculations in it beyond just "clock"
> based stuff, so I'm curious how you're using SDL to invoke the renderer
> yourself or something?

No, nothing of the sort. What I do is simple: if a certain file is present,
I load the data from there and use that for calculations. If it's not, I
generate new data.

Depending on some other variables, I thus either set the data to the initial
state, or just base it upon former data. In this manner, the same scene-file
with render differently every time it is run. Now, with an animation, that
is exactly the case: the same scene-file is run several times, and only the
clock-variable changes. If I additionally base my calculations on data that
is stored externally, and also change that data during the runtime, every
consecutive run will yield different results.

So, for this particle system I just put some extra parameters in these files
to track their "age", and let the data get "older" for every frame.
Understood, or should I clarify some more?

Regards,
Tim

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote in news:4043ed77$1@news.povray.org:


> 
> I can see where it might be harder to coordinate, but still...
> 

You have come across some of the great POV religous Schisms ;)

Distributed rendering and particle system design

This could be a long thread...


-- 
Tom
_________________________________
The Internet Movie Project
http://www.imp.org/

Post a reply to this message