"Thorsten Froehlich" wrote:
> Internally EPSILON is at 10e-10 for a reason.
> And what you call "error" from frame to frame
> stays within the same range because of the single
> multiplication.  Only in iterative calculations
> floating-point errors accumulate.  This isn't the
> case here, thus you have no valid point.

Err, what? Sorry, I literally don't understand what you're trying to tell
me. I tend to focus on results rather than theory.

What I see is that your calculated initial_clock is not precisely the same
from frame to frame and this can cause an expression which includes the
initial_clock value to evaluate differently in different frames, even though
you'd expect it to always evaluate to the same result. This is not the case
with the internal initial_clock, which is truly the same in all the frames.

As this will be a big problem in some of my POV-Ray macros, I have a very
valid point. When I tell you that it's a problem for me as a user it doesn't
make sense when you say that it isn't a valid point. It can only mean that
you have misunderstood what point I'm trying to make. You may however say
that you don't care.

I just don't understand how it can be such a big problem to make directly
available the initial_clock and final_clock values in POV-Ray. I can see
them right there in the command line/ini file, so surely making those values
available in the SDL should be a piece of cake?

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:  http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring:  http://webring.povray.co.uk

Post a reply to this message