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