"Chris Huff" wrote:
> The "custom_particle" feature is gone, for example, but
> now you should be able to get particle information like
> position, radius, velocity, age, etc. through functions,
> so you can do much more.

Sounds like a more flexible and better solution to me.

> And the whole system no longer has to be recalculated each
> frame, you should be able to use the persistent objects
> feature of MegaPOV to calculate only what is necessary.

Which will make the particles frame dependent...?

Greetings,

Rune

Post a reply to this message

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

> Sounds like a more flexible and better solution to me.

It is, I hope to have some demo images soon. It will allow things like 
orienting particles to the camera, coloring them depending on their 
temperature, etc. The only disadvantage is that you have to make them 
yourself, with a #while loop.


> > And the whole system no longer has to be recalculated each
> > frame, you should be able to use the persistent objects
> > feature of MegaPOV to calculate only what is necessary.
> 
> Which will make the particles frame dependent...?

Uhh, yes and no. It depends on how you set it up. If you declare it as a 
persistent object, and only run it a fixed amount of time per frame, the 
progress of the system will be dependant on the number of frames. If you 
vary the amount of time with the clock_delta, or recalculate the entire 
system from the start each frame, you can make it independant of the 
number of frames.

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

"Chris Huff" wrote:
> "Rune" wrote:
> > > And the whole system no longer has to be recalculated each
> > > frame, you should be able to use the persistent objects
> > > feature of MegaPOV to calculate only what is necessary.
> >
> > Which will make the particles frame dependent...?
>
> Uhh, yes and no. It depends on how you set it up. If you
> declare it as a persistent object, and only run it a fixed
> amount of time per frame, the progress of the system will be
> dependent on the number of frames.

OK. I guess this method will produce results that are entirely different
depending on the number of frames and so on.

> If you vary the amount of time with the clock_delta, you
> can make it independent of the number of frames.

If I understand this right, I think it can produce very consistent results
independent on the frames, but not *entirely* consistent. If you have a very
long animation with thousands of frames, the result in the end of the
animation may vary a lot dependent of the number of frames, and so on,
because a lot of small calculation differences have "piled up" through the
animation. Am I right?

> If you recalculate the entire system from the start each frame,
> you can make it independent of the number of frames.

This I believe is correct :-)

However, this takes a lot of time in scenes with complex particle systems,
right? Isn't that the reason you made the option of not recalculating each
time?

I have an idea how to get entirely frame independent results without having
to recalculate in every frame. I don't know if it will work, but here goes
anyway:

In the first frame of the animation calculate the entire course of the
particles. Kind of anticipate the entire course of the particles from the
first frame to the last. The number of "steps" in this calculation should
not be based on the number of frames, but on a number specified by the user
inside the scene file. That could for example be 1000 steps. After each
"step" is calculated, save the data to a file. After this calculation, we
have a file that contains the particle data needed for the entire animation.

Now, in the rest of the frames, do not calculate any particle data at all,
but simply get it from the file we saved. The number of steps is most likely
different from the number of frames, so the data should be interpolated.

Using the method described above, the entire course of the particles are
calculated the same way always, independent from the number of frames, and
yet we don't have to recalculate in every frame!

So what do you say? Would this work?

Greetings,

Rune
--
Updated June 12: http://rsj.mobilixnet.dk
3D images, include files, stereograms, tutorials,
The POV Desktop Theme, The POV-Ray Logo Contest,
music, 350+ raytracing jokes, and much more!

Post a reply to this message

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

> OK. I guess this method will produce results that are entirely different
> depending on the number of frames and so on.

No. If a fixed amount is calculated per frame, the amount of time which 
passes will be tied to the number of frames, so if you double the number 
of frames, you double the amount of time which passes. If you take 
clock_delta into account, this won't happen, the same amount of time 
will always have passed by the last frame.


> If I understand this right, I think it can produce very consistent 
> results independent on the frames, but not *entirely* consistent. If 
> you have a very long animation with thousands of frames, the result 
> in the end of the animation may vary a lot dependent of the number of 
> frames, and so on, because a lot of small calculation differences 
> have "piled up" through the animation. Am I right?

No. The particle system is just "paused" at the end of each frame, and 
restarted later for a certain amount of time, so there are no 
inconsistencies. The only difference between using a fixed amount of 
simulation time/cycles per frame and either using a clock_delta 
dependant value or recalculating the whole system is the amount of time 
that has passed by the end of the animation.


> > If you recalculate the entire system from the start each frame,
> > you can make it independent of the number of frames.
> However, this takes a lot of time in scenes with complex particle 
> systems, right? Isn't that the reason you made the option of not 
> recalculating each time?

It does, and it is.


...
> Using the method described above, the entire course of the particles 
> are calculated the same way always, independent from the number of 
> frames, and yet we don't have to recalculate in every frame!
> 
> So what do you say? Would this work?

It would work...but is completely unnecessary, since stopping and 
restarting the system has no effect on it. And it would remove most of 
the animation capabilities, since you wouldn't be able to change things 
as the animation progresses.

There are three methods of animation:
0: Particle system is non-persistent, and is calculated a certain 
clock-dependant amount per frame. The amount of particle system time 
which has passed by the end of the animation does not depend on the 
number of frames, but the whole system has to be calculated from the 
start for each frame.
Advantages: Easy/quick to code.
Disadvantages: Can take a long time to calculate the system, especially 
if fluid particles and inter-particle forces are used. The whole series 
of calculations has to be repeated for each frame.

1: Particle system is persistent, and is further calculated a certain 
fixed amount per frame. The amount of particle system time which has 
passed by the end of the animation depends on the number of frames.
Advantages: small calculation time per frame, you can animate moving 
emitters/etc in simulation time.
Disadvantages: simulation length depends on number of frames. The 
results of the system are the same, they just progress further for more 
frames.

2: Particle system is persistent, and is further calculated a certain 
amount per frame, like #1, but the amount of calculation done per frame 
depends on the clock_delta value, so it is shorter with more frames. The 
amount of particle system time which has passed by the end of the 
animation and the final results of the system remain the same, 
independant of number of frames.
Advantages: small calculation time per frame, you can animate moving 
emitters/etc in simulation time. Also, it doesn't have the problem of 
#1, it always runs the same amount of time, independant of frame number. 
More frames simply means the simulation is paused at more points.

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

Hi Chris!

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.

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

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.

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?

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?

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?

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?

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?

Hmm, guess that's it for now. Oh, and the "Do you agree so far?" is a kind
of debugging, so I can detect exactly where we disagree! ;-)

Greetings,

Rune
--
Updated June 12: http://rsj.mobilixnet.dk
3D images, include files, stereograms, tutorials,
The POV Desktop Theme, The POV-Ray Logo Contest,
music, 350+ raytracing jokes, and much more!

Post a reply to this message

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

Hi Chris!

I'm getting closer to an understanding of your particle system, but there's
still some things I don't understand. I appreciate that you have so far
taken the time to discuss it with me.

> > the number of cycles is dependent on the number of frames.
>
> 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.
> The number of cycles per frame drops as the number of frames
> increases and the amount of time per frame drops.

So when using method 2 (and method 0, for that matter) the total number of
cycles for the entire animation (for example from clock=0 to clock=1) is
always exactly the same, independent on the number of frames?

Then how is the number of cycles chosen?

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

Yes, that's the advantage, but you still haven't told me what the
DIS-advantage is, using method 2.

Which advantages has method 0 over method 2?

Which advantages has method 1 over method 2?

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

That's what I thought.

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

I can understand that.

What do I do If want to if I want to render frame 60 to 70 out of 100 in an
animation where the particle system is synchronized with the clock using
method 2?

Greetings,

Rune
--
Updated June 12: http://rsj.mobilixnet.dk
3D images, include files, stereograms, tutorials,
The POV Desktop Theme, The POV-Ray Logo Contest,
music, 350+ raytracing jokes, and much more!

Post a reply to this message

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

> I'm getting closer to an understanding of your particle system, but 
> there's still some things I don't understand. I appreciate that you 
> have so far taken the time to discuss it with me.

No problem. :-)


> So when using method 2 (and method 0, for that matter) the total 
> number of cycles for the entire animation (for example from clock=0 
> to clock=1) is always exactly the same, independent on the number of 
> frames?
> 
> Then how is the number of cycles chosen?

Something like:
particle_system {
    iterations TOTAL_AMT*clock
    time TOTAL_TIME*clock
...
for method 0,

run_particle_system {PART_SYS_IDENTIFIER
    iterations NUM_PER_FRAME
    time TIME_PER_FRAME
...
for method 1, and

run_particle_system {PART_SYS_IDENTIFIER
    iterations TOTAL_NUM*clock_delta
    time TOTAL_TIME*clock_delta
...
for method 2.


> Yes, that's the advantage, but you still haven't told me what the
> DIS-advantage is, using method 2.
> 
> Which advantages has method 0 over method 2?

None, other than simplicity of coding.


> Which advantages has method 1 over method 2?

If you want to set up a certain amount of time between frames and render 
a longer animation to see the system progress, you would probably choose 
method 1. Having the particle_system time tied to the frame number is 
it's only disadvantage, and it is only a disadvantage in certain 
situations(the majority of situations, given POV's usual animation 
techniques, but not all).


> I can understand that.
> 
> What do I do If want to if I want to render frame 60 to 70 out of 100 
> in an animation where the particle system is synchronized with the 
> clock using method 2?

You will have to have frame 60 calculate the whole particle system up to 
that point, then you can continue from there. It shouldn't be difficult 
to set up the scene file to do this automatically.

BTW, persistent variables seem to be broken in my compile, :-(, I think 
it might be something to do with the official Mac version's interface 
(since I haven't modified any of the persistence code), so I can't even 
test this feature in an animation(I have to do it all within one frame, 
and "pretend" it is an animation).
But I might have come up with an even better solution: file input-output 
of the particle system, like the feature for radiosity info and photon 
mapping. save_file would save all particle system data to a file, and 
load_file would replace the current system with the loaded data. You 
could do the calculations for a still image once and tweak rendering as 
much as you want.

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

Chris Huff wrote:

> Later. Right now I am making some modifications which will allow much
> more flexible animation and particle generation options.

How about an object emitter where particles are emitted in the direction of
the surface normal and a speed specified by a pattern/function.  The
emmission points on the surface could be sampled by tracing rays from a
point & or direction toward that object- kind of like how photons are done.

--
Bye
Pabs

Post a reply to this message

In article <3962B4A1.A300F52D@nospamthanks.hotmail.com>, Pabs 
<pab### [at] nospamthankshotmailcom> wrote:

> How about an object emitter where particles are emitted in the 
> direction of the surface normal and a speed specified by a 
> pattern/function.  The emmission points on the surface could be 
> sampled by tracing rays from a point & or direction toward that 
> object- kind of like how photons are done.

I have been wondering about this...I just haven't thought of a good way 
of implementing it. It should be quite possible by specifying a point to 
sample surface positions from, as you suggest...but that would only 
cover part of the object. I could shoot at the center of the object's 
bounding box from random points on the surface of a sphere around 
it...but that would only give an even emission distribution for 
spherical objects, and parts of the object could be "hidden" from the 
particles by other parts. Would anyone notice?

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