> Are you talking about your system here or mine? I'm also not sure what
> you're trying to say. You can't see the particles in between frames
> anyway, so what do you mean by in between frame interpolation?
>
> Anyway, in my system the precision of the flying curves are not
> dependent on the framerate at all. It is dependent on the calculation
> step rate, which is independent from the framerate. If you specify a
> calculation step rate which is lower than the framerate, then (linear)
> interpolation is used, but I've never been able to actually spot this
> with my eye except in extreme cases where a way too low calculation step
> rate was used.

Yeah, I was talking about that very last bit of way too few calculations
steps. I mixed "framerate" and "calculation steps" in my original post,
my mistake.

Aside of that, I think both our systems would be suited for the IMP,
but you mentioned something about mine being better suited. I have
been thinking about that, and in that regard, I don't think that there
are more reasons for mine than for yours, especially since yours
handles more collision detection possibilities...

BTW, can you call macro on certain events, e.g. when a particle hits
a wall? I've been rendering an animation where my particles bounce
around in a Cornell-Box (the one from my Radiosity Experiments) and
interact with a water-surface (achieved with, what else, my LSSM),
and it looks pretty nice so far. :-)
(even though particles shouldn't bounce off a water surface as if it
was made of stone ;-)

Regards,
Tim

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights

> > There's also the precision thingy we've talked about
> > months ago, remember? That my non I/O calculates
> > an impact with the boundary box, while your I/O
> > one approximates it with trace() calls. I doubt that
> > the precision of your system is so much a drawback
> > though.
>
> Yes, this is the price to pay for having support for collision detection
> with more than a simple bounding box or a plane... In most cases it's
> not really a problem though.
>
> > But one thing I've noticed and that is probably
> > fitting to mention here:
> > I've noticed that the interpolation in between
> > frames doesn't yield smooth flying curves, but
> > rather straight connections.
>
> Are you talking about your system here or mine? I'm also not sure what
> you're trying to say. You can't see the particles in between frames
> anyway, so what do you mean by in between frame interpolation?
>
> Anyway, in my system the precision of the flying curves are not
> dependent on the framerate at all. It is dependent on the calculation
> step rate, which is independent from the framerate. If you specify a
> calculation step rate which is lower than the framerate, then (linear)
> interpolation is used, but I've never been able to actually spot this
> with my eye except in extreme cases where a way too low calculation step
> rate was used.
>
> Rune
> --
> 3D images and anims, include files, tutorials and more:
> rune|vision:  http://runevision.com (updated Oct 19)
> POV-Ray Ring: http://webring.povray.co.uk
>
>


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

Post a reply to this message