> Speed based traces sounds like a good idea. How do you plan on being able
to
> render from a frame starting from the middle of an animation?

The idea is simple: the random streams of POV-Ray rand() are
pseudo-random, or, so to speak, predictable. If I generate
times when a particle is born, with which speed etc with the
same random-stream, the initial startup for all particles will
always be the same. From then on, the speed-based algorithm
will take hold, generating as many trace()-calculations as required
to parse the entire path. Moving objects etc will be handled
with their own macros, probably the same way as my LSSM do
it. Aside of other macros, of which the effect can be calculated
for each required moment of time "on the fly", the resulting
animation should be the same, no matter if I begin from frame
1 or 500. This is the same reason why the LSSM can calculate
from any given frame onwards.

Regards,
Tim

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
Email: no_lights (@) digitaltwilight.de


> I only started this little test a few days ago so I haven't quite decided
on
> the final method of collisions, but it won't be a single point. I
initially
> pre determined the distance the particle would travel, which assumed it
> would always land at the same height it launched from. As you can tell
this
> was a silly way to go about it, but I just wanted to see the ball bounce
> damn it! I'll probably end up tracing perhaps 6 rays from the sphere's
> surface, one in each direction, then getting the shortest ray and tracing
> another set of rays from the half of the sphere of the previous ray. This
> would continue until there is either the ray length is 0 (or very small)
or
> some threshold for the number of rays is reached. Kind of a divide and
> conquer thing to help reduce parse time. As for particle particle
collision,
> I'd like to implement it but haven't thought of any efficient methods for
it
> yet.
>
> Speed based traces sounds like a good idea. How do you plan on being able
to
> render from a frame starting from the middle of an animation?
>
> Michael B.
>
> "Tim Nikias v2.0" <no_lights (@) digitaltwilight.de> wrote in message
> news:3f606a90@news.povray.org...
> > Hm. So you're actually using just a single point
> > for your particles, right? Not full fledged object
> > collision? (I'd guess so for a particle system, its
> > not intended as a pun).
> >
> > Still, 1000 traces is a bit much, don't you think?
> > What I'm planning to do for my next system with
> > collision detection is to calculate the traces based
> > on distance travelled: every 0.1 POV-Units or such.
> > Slow moving particles don't require that many tests,
> > as long as I've got some variables to keep control
> > that a particle is lying on the floor and just won't
> > drop any further.
> > Faster particles do require more traces, because they
> > might easily pass through a wall from one frame to
> > the next. Speed-Based traces will do just that. On
> > my next particle system, I won't be doing loopable
> > animations, but the system should still be able to
> > reparse the simulation in case the render begins at
> > some frame in the middle of an animation.
> >
> > Oh, and does your system handle particle-particle
> > interaction?
> >
> > --
> > Tim Nikias v2.0
> > Homepage: http://www.digitaltwilight.de/no_lights
> > Email: no_lights (@) digitaltwilight.de
> >
> >
>
>


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.515 / Virus Database: 313 - Release Date: 01.09.2003

Post a reply to this message