A few observations and questions:

Firstly: at least to me, the jitter value seems to have a disproportionately
strong effect. If I use more jitter than around 0.03 in my spray (quite fast
flow at a tight angle), the particles go all over the place. I understand that
increased speed > greater movement per iteration > greater jitter influence, but
in my case (the "Absudity" scene) the flow speed is 1.2 - not outrageously fast
IMO. Just a minor problem, but still I wonder...

Also, I tried both a little animation and motion blurring the particles. In both
cases the system seems too erratic to give the illusion of 'flow', particles
jump around and *seem* to disappear at a random age?! Might be some
misunderstanding on my part, but it's a relatively simple system with narrow
angle, long lifespan and very low jitter. The animations were 4 frames per TU,
so it shouldn't look all that choppy. I am not wrong in assuming that animation
is done simply through the 'time' parameter, am I?

About the 'lifespan' value: is it measured in time units or iterations? The
former would be more correct IMO, since increasing simulation accuracy should
not affect the number of particles. And even if I set 'lifespan' much larger
than both time and iterations, I still get the "n particles destroyed" message
after a simulation. What does that mean? And, could you add output of the number
of particles in the scene?

Finally, 'cause I'm just too lazy to test <g>: how are the particles arranged
for the get_particle index, newest to oldest or vice versa? I would like to have
the same index number always assigned to the same particle, at any point in
time, but with all the creation and destruction this seems iffy.

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg

Post a reply to this message

In article <3982371C.528B2E10@peak.edu.ee>, Margus Ramst 
<mar### [at] peakeduee> wrote:

> Firstly: at least to me, the jitter value seems to have a 
> disproportionately strong effect. If I use more jitter than around 
> 0.03 in my spray (quite fast flow at a tight angle), the particles go 
> all over the place. I understand that increased speed > greater 
> movement per iteration > greater jitter influence, but in my case 
> (the "Absudity" scene) the flow speed is 1.2 - not outrageously fast 
> IMO. Just a minor problem, but still I wonder...

The jitter value in the particle_system block? Greater velocity should 
reduce the influence...and a ratio of 1.2 to 0.03 should be quite a 
small amount of jitter.


> Also, I tried both a little animation and motion blurring the 
> particles. In both cases the system seems too erratic to give the 
> illusion of 'flow', particles jump around and *seem* to disappear at 
> a random age?! Might be some misunderstanding on my part, but it's a 
> relatively simple system with narrow angle, long lifespan and very 
> low jitter. The animations were 4 frames per TU, so it shouldn't look 
> all that choppy. I am not wrong in assuming that animation is done 
> simply through the 'time' parameter, am I?

To get the best results, the ratio of iterations to time should remain 
constant, so you must increase iterations along with time. Otherwise, 
the accuracy of the simulation changes in different frames, leading to 
different results, and making the particles unpredictable.


> About the 'lifespan' value: is it measured in time units or iterations? 

It is measured in time units.


> And even if I set 'lifespan' much larger than both time and 
> iterations, I still get the "n particles destroyed" message after a 
> simulation. What does that mean?

It just means that when the particle_simulation was destroyed, that many 
particles were left over and destroyed as well. It was just an aid to 
help detect memory leaks...if your lifespan is larger than time, no 
particles will die, and all will be left over to be destroyed.


> And, could you add output of the number of particles in the scene?

I plan to add output of final number and maximum number.


> Finally, 'cause I'm just too lazy to test <g>: how are the particles 
> arranged for the get_particle index, newest to oldest or vice versa? 
> I would like to have the same index number always assigned to the 
> same particle, at any point in time, but with all the creation and 
> destruction this seems iffy.

Ehh, I'm not really sure. :-)
It should be newest particles at the beginning, and oldest at the end, I 
think. If particles die in the simulation, then the indices will 
change...I can't avoid this. It might be possible to give particles 
unique ID's or to allow you to track a specific particle, though.

-- 
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:
> 
> Ehh, I'm not really sure. :-)
> It should be newest particles at the beginning, and oldest at the end, I
> think. If particles die in the simulation, then the indices will
> change...I can't avoid this.

I have absolute control over particle mortality :)
If numbering were the other way around, then theoretically it should work. When
the oldest particle is 1 and no particles are destroyed, all particles should go
through the simulation with fixed index numbers, yes?

-- 
Margus Ramst

Personal e-mail: mar### [at] peakeduee
TAG (Team Assistance Group) e-mail: mar### [at] tagpovrayorg

Post a reply to this message

In article <3982D386.884759BC@peak.edu.ee>, Margus Ramst 
<mar### [at] peakeduee> wrote:

> I have absolute control over particle mortality :)
> If numbering were the other way around, then theoretically it should 
> work. When the oldest particle is 1 and no particles are destroyed, 
> all particles should go through the simulation with fixed index 
> numbers, yes?

Assuming lifespan is either not specified or is larger than the "time" 
value for all emitters, yes. However, remember that particles don't 
always die in the order they are created, so this isn't so neat and 
simple. I haven't really come up with a good way to do this, though the 
unique ID number approach seems to be the best.
How about a get_particle2() function which takes an ID number instead of 
an index. The current get_particle() function is still necessary, it 
would be the only way to get the particle in the first place.

In other words, have get_particle() take an index between 0 and the 
number of particles - 1, and have get_particle2() take a number unique 
to each particle, and return 0 if that particle is dead.

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