In article <396251a8@news.povray.org>, "Rune" <run### [at] inamecom> 
wrote:

> When I talk about time in an animation, I always mean the clock, not 
> the frames. Since many POV-Ray users are used to, and prefer using 
> the clock as the time reference, it is important that the particle 
> system can be 100% synchronized with the clock. It is also important 
> that the results are exactly the same, no matter how many frames you 
> use, for example so a test render and a final render will produce the 
> exactly same result in the end.

It can be 100% synchronized with the clock. The results are 100% the 
same.


> You talk about 3 methods of animating the particle system. Method 0 
> is frame independent (synchronized with the clock), but slow. Method 
> 1 is quick, but not synchronized with the clock.
> 
> What I would like to discuss here is the last method. This is the most
> interesting, I think. (I also noted that you "forgot" to state any
> disadvantages for method 2.)

The advantage is that it is synchronized with the clock instead of the 
frame number.


> What I'm trying to say is, that although the amount of time that 
> passes is frame independent, the results are not necessarily frame 
> independent too, like they should be.

Yes they are.


> Your particle system calculated the movements etc. of the particles 
> in a number of cycles, steps, or whatever you want to call it. For 
> method 1 and 2, and maybe 0 too (I don't know), the number of cycles 
> are dependent on the number of frames. Do we agree so far?

No. The only times where the number of cycles depends on the number of 
frames is when using method 2, where they are corrected using the 
clock_delta value to keep the system synchronized with the clock. In 
type 0, the cycles depend on the current clock value, and in type 1, a 
fixed number of cycles is used per frame, regardless of the number of 
frames.


> For each cycle some calculations are done, and the particles are 
> moved a little. If we for a final render triple up the number of 
> frames, there will be 3 times as many cycles, but we compensate for 
> that by moving the particles 3 times less per cycle. Do we agree so 
> far?

For type 1, yes. For type 2, no. The number of cycles per frame drops as 
the number of frames increases and the amount of time per frame drops.
Type 0 uses the most cycles, but most of them are redundant, simply 
repeating the cycles of the previous frames which were thrown away.


> Your particle system includes collision detection, right? While I do not
> know the details of your particle system, I know that usually collision
> detection can be imprecise when the particles move by big amounts per 
> cycle.
> The particles can "fall through" objects or "miss" each other if they 
> move too far at a time. However, if the particles move a tiny 
> distance per cycle only, this will not happen. It is probably safe to 
> say that the preciseness of the particle behavior are generally 
> dependent on how great distances the particles move per frame. Do we 
> agree so far?

My updated collision detection algorithm predicts how far the particle 
will travel in the next time step, and checks for a collision in that 
area, so it automatically compensates for "skipping" a surface.
But anyway, the distance the particles move per frame is irrelevant, 
only the distance per cycle, or time step, matters. And that stays 
constant for all three animation methods, regardless of the number of 
frames.


> So the preciseness of the particle behavior is dependent on the 
> number of cycles, and the number of cycles is dependent on the number 
> of frames. So in fact, the particle behavior is a little frame 
> dependent, even when we use clock_delta to compensate for the 
> movements. Do we agree so far?

No, see above.


> OK, I don't think I can continue any further before I get some more
> information. So I'll ask some more questions...
> 
> You say that when using method 1 you can animate moving emitters/etc 
> in simulation time. Can you also move the emitters/etc when you use 
> method 0, or are there some restrictions with method 0?

No, emitters/space_warps can only be moved when the "run_system" keyword 
is parsed. I haven't figured out how to parse a piece of code during the 
simulation, so that has to be handled in POV-Script. With method 1 and 
2, it is easy to animate. Method 0 requires some extra handling, which 
can also be used to increase the accuracy of method 2, although it 
probably isn't completely necessary unless you have a relatively large 
number of cycles per frame.

BTW, one thing that may be confusing you is that my particle system 
doesn't use the number of cycles for time. It takes an amount of system 
time to run the system, and a number of cycles to divide that time into. 
If the particle_system is persistent and both the "system time" and the 
number of cycles are tied to clock_delta, the result is equivalent to 
stopping the simulation at the point of time where each frame occurs, 
taking a snapshot, and resuming the simulation as though nothing had 
happened.

-- 
Christopher James Huff - Personal e-mail: chr### [at] maccom
TAG(Technical Assistance Group) e-mail: chr### [at] tagpovrayorg
Personal Web page: http://homepage.mac.com/chrishuff/
TAG Web page: http://tag.povray.org/

Post a reply to this message