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

Chris Huff wrote:

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

It probably wouldn't be noticed unless someone used a noise3d isosurface as
the emitter.
BUT...
You could get _all_ intersections with each sampling ray - so that if you
hit a surface you keep tracing the _same_ ray until no more surfaces are hit
and therefore no parts of the object could be "hidden" from the particles by
other parts of the object.

Also what about a pattern that is the average particle density (or particle
collision density with the object whose pattern is being determined) in the
vicinity of the intersection point.  The particle(collision) density would
be the # of particles/collision points per unit space in the vicinity of the
intersection point or the addition of blob fields around all the
particles/collision points.
This could be used to visualize the drag on an airplane or fluid density or
other stuff.

Bye
Pabs

Post a reply to this message

In article <396414C4.B17FD9F4@nospamthanks.hotmail.com>, Pabs 
<pab### [at] nospamthankshotmailcom> wrote:

> It probably wouldn't be noticed unless someone used a noise3d 
> isosurface as the emitter. BUT... You could get _all_ intersections 
> with each sampling ray - so that if you hit a surface you keep 
> tracing the _same_ ray until no more surfaces are hit and therefore 
> no parts of the object could be "hidden" from the particles by other 
> parts of the object.

Hmm, that could work, though I would have to save the points for later 
use, kind of like a large number of point emitters...how should I take 
the samples, though? If I take them from the surface of a sphere toward 
the center of the bounding box, there will be a serious tendency for the 
center of the object unless it is hollow and fairly spherical. Maybe if 
I took them from the three sides of a box...along each coordinate axis, 
in other words.


> Also what about a pattern that is the average particle density (or 
> particle collision density with the object whose pattern is being 
> determined) in the vicinity of the intersection point.  The 
> particle(collision) density would be the # of particles/collision 
> points per unit space in the vicinity of the intersection point or 
> the addition of blob fields around all the particles/collision 
> points. This could be used to visualize the drag on an airplane or 
> fluid density or other stuff.

This actually existed in the first versions of my patch, in fact, it was 
*the* first version of my patch, but I have removed it because it was 
too difficult to maintain while the rest of the patch was changing so 
rapidly...I do plan on replacing it, however.
Hmm, particle density...I hadn't thought of that. I will need to write a 
function to compute this for particle fission/fusion anyway, so might as 
well include it...
BTW, one other problem with the particle_system pattern was that it was 
slow, since all the particles had to be calculated. I plan on adding a 
bounding structure based on recursively subdividing boxes(I think it is 
called an octree...) or planes(I have no idea what this is called) to 
speed up inter-particle force calculations, so that should really speed 
up the patterns...

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

> Hmm, that could work, though I would have to save the points for later
> use, kind of like a large number of point emitters...how should I take
> the samples, though? If I take them from the surface of a sphere toward
> the center of the bounding box, there will be a serious tendency for the
> center of the object unless it is hollow and fairly spherical. Maybe if
> I took them from the three sides of a box...along each coordinate axis,
> in other words.

Could work but maybe you could specify some different types of sampling -
like the box method, point & bbox method, sphere & bbox method, random
points in random directions et al.

> This actually existed in the first versions of my patch, in fact, it was
> *the* first version of my patch, but I have removed it because it was
> too difficult to maintain while the rest of the patch was changing so
> rapidly...I do plan on replacing it, however.
> Hmm, particle density...I hadn't thought of that. I will need to write a
> function to compute this for particle fission/fusion anyway, so might as
> well include it...

Are U going to add propogation reactions like when a particle interacts with
a surface/other particle it creates new particles & changes in some way.

> BTW, one other problem with the particle_system pattern was that it was
> slow,since all the particles had to be calculated. I plan on adding a
> bounding structure based on recursively subdividing boxes(I think it is
> called an octree...) or planes(I have no idea what this is called) to
> speed up inter-particle force calculations, so that should really speed
> up the patterns...

What like ignoring particles so far away that the contribution is
negligible.

Another pattern could be based on the velocity & or direction of the
particles.

--
Bye
Pabs

Post a reply to this message

In article <396572FB.AC4D4BD3@nospamthanks.hotmail.com>, Pabs 
<pab### [at] nospamthankshotmailcom> wrote:

> Could work but maybe you could specify some different types of sampling -
> like the box method, point & bbox method, sphere & bbox method, random
> points in random directions et al.

That would be possible, but I don't know how useful it would be. I think 
the best coverage would result from taking a random point in the 
bounding box and firing the ray in a random direction...that seemed to 
produce the best coverage for the proximity pattern.


> Are U going to add propogation reactions like when a particle 
> interacts with a surface/other particle it creates new particles & 
> changes in some way.

I plan to implement things this way:
If a particle impacts a surface while traveling at a speed higher than a 
specified threshold, it will break into multiple particles smaller than 
the original(conserving mass and volume). Particle fission will also 
occur if the particle density in an area drops below a certain threshold.

Low-velocity impacts on a surface will take a different set of rules...I 
might add calculations based on proximity to the surface. The particles 
will cling to the surface, making it "get wet".

Particles will join together(fuse) if their velocities are close to 
being identical. This will be more likely if the particle density in the 
area is higher, and will not happen if it is below a certain threshold. 
This will help keep the simulation fairly efficient, so it doesn't get 
bogged down with a bunch of tiny particles.


> > BTW, one other problem with the particle_system pattern was that it was
> > slow,since all the particles had to be calculated. I plan on adding a
> > bounding structure based on recursively subdividing boxes(I think it is
> > called an octree...) or planes(I have no idea what this is called) to
> > speed up inter-particle force calculations, so that should really speed
> > up the patterns...
> 
> What like ignoring particles so far away that the contribution is
> negligible.

That is already done, but the distance calculation itself takes 
time...which is why I am going to attempt to make a bounding structure.


> Another pattern could be based on the velocity & or direction of the
> particles.

Or even better, a single pattern that can do all of those...particle 
density, average speed, average temperature, average age...

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

> In article <396572FB.AC4D4BD3@nospamthanks.hotmail.com>, Pabs
> <pab### [at] nospamthankshotmailcom> wrote:
>
> > Could work but maybe you could specify some different types of sampling -
> > like the box method, point & bbox method, sphere & bbox method, random
> > points in random directions et al.
>
> That would be possible, but I don't know how useful it would be. I think
> the best coverage would result from taking a random point in the
> bounding box and firing the ray in a random direction...that seemed to
> produce the best coverage for the proximity pattern.
>
> > Are U going to add propogation reactions like when a particle
> > interacts with a surface/other particle it creates new particles &
> > changes in some way.
>
> I plan to implement things this way:
> If a particle impacts a surface while traveling at a speed higher than a
> specified threshold, it will break into multiple particles smaller than
> the original(conserving mass and volume). Particle fission will also
> occur if the particle density in an area drops below a certain threshold.
>
> Low-velocity impacts on a surface will take a different set of rules...I
> might add calculations based on proximity to the surface. The particles
> will cling to the surface, making it "get wet".
>
> Particles will join together(fuse) if their velocities are close to
> being identical. This will be more likely if the particle density in the
> area is higher, and will not happen if it is below a certain threshold.
> This will help keep the simulation fairly efficient, so it doesn't get
> bogged down with a bunch of tiny particles.
>
> > > BTW, one other problem with the particle_system pattern was that it was
> > > slow,since all the particles had to be calculated. I plan on adding a
> > > bounding structure based on recursively subdividing boxes(I think it is
> > > called an octree...) or planes(I have no idea what this is called) to
> > > speed up inter-particle force calculations, so that should really speed
> > > up the patterns...
> >
> > What like ignoring particles so far away that the contribution is
> > negligible.
>
> That is already done, but the distance calculation itself takes
> time...which is why I am going to attempt to make a bounding structure.
>
> > Another pattern could be based on the velocity & or direction of the
> > particles.
>
> Or even better, a single pattern that can do all of those...particle
> density, average speed, average temperature, average age...

That all sounds great :)
Runnning ... out ...of ideas...NOOOOOOOOOOOOOOOOOOOO!!

--
Bye
Pabs

Post a reply to this message