"Jetlag" <bga### [at] microsoftcom> wrote in message
news:395f89c3@news.povray.org...
a clickable link for urls, but stops at the space.
|
| This should work also (at lease for Windows/IE):
| http://homepage.mac.com/chrishuff/mpovplus/multitex2%20Movie.mov

Thanks, I was putting a / in-between there and it hadn't occurred to me it was
meant to have a space.
Ok, seen it now.  The overpowering purple streamer pushing the yellow streamer
is great, the color mixing flickers about a lot but tough to say how it should
behave.  Except a mixing amount might be the way to go, you know, like hetero-
or homogeneously.  This animation seemed an blend of the two, if that makes
sense.  A better way to say it might be: if you had blue and yellow mixing to
just green or retaining their blue and yellow colors only.

Bob

Post a reply to this message

Got it, this space irritated me and OE.

Marc-Hendrik

Post a reply to this message

In article <395f8ffa@news.povray.org>, "Bob Hughes" 
<per### [at] aolcom?subject=PoV-News:> wrote:

> Thanks, I was putting a / in-between there and it hadn't occurred to 
> me it was meant to have a space.

Sorry about that, I will keep from using spaces in online files in the 
future.


> Ok, seen it now.  The overpowering purple streamer pushing the yellow 
> streamer is great, the color mixing flickers about a lot but tough to 
> say how it should behave.  Except a mixing amount might be the way to 
> go, you know, like hetero- or homogeneously.  This animation seemed 
> an blend of the two, if that makes sense.  A better way to say it 
> might be: if you had blue and yellow mixing to just green or 
> retaining their blue and yellow colors only.

The texture mixing can't really be helped...it is a blob.

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

Interesting... Show me some more. :) Why didn't you announce this in
.general?

Post a reply to this message

In article <39600391@news.povray.org>, "Tony[B]" 
<ben### [at] panamac-comnet> wrote:

> Interesting... Show me some more. :)

Later. Right now I am making some modifications which will allow much 
more flexible animation and particle generation options. 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. 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. And I plan on adding things like fluid types, particle 
fission/fusion, custom inter-particle force profiles, low-speed impact 
effects...

Some other modifications I have made already: collision detection is 
much more accurate, and you can specify a texture on an 
emitter-by-emitter basis(demonstrated by the animation).


> Why didn't you announce this in .general?

Er, well, I didn't think about it. I assumed anyone looking for an 
animation would look in povray.animations.

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