Hi!

After a hard year in the business world, I'm back at the university 
again (God knows for how long :) )

Anyway, this means I get some spare time again, and spare time means 
hobbies (and hobbies means - you guessed it - POV).

Things have changed quite a bit since then, in that I have converted 
completely to Linux (all 3 machines at home run some distro now). 
Progeny's Debian is a favourite (too bad they stopped developing it), 
but I'm looking forward to the Debian "Woody" release as it will 
probably contain some of the features of Progeny. Too bad we also sit so 
firmly in m-softs knee at the uni..I'll do my best to change that.

Well, as I fired up POV at the uni for the first time in a while (3.5 
beta10, Win version) and checked to see how 3.5 worked with my old 
SmokeGen include, I noticed something strange when doing one of the 
animation demos (SplFile2.ini in the SplFile demo directory).

It seems as the initial clock value passed from the ini file gets 
slightly altered by POV3.5 - the ini file reads

Initial_Clock=0.2

but debugging the value at the first frame, I get

0.20000000298023224000000000000000 (str:ing the clock value with 32 
decimals)

..which means the file used to store the values from previous runs won't 
be opened WRITE and thus not overwritten when re-rendering the scene.

Is this a known "problem"? I.e. has there been a change in how the clock 
value gets calculated in v3.5?

- Mikael

Post a reply to this message

In article <3C5### [at] idautbhbse> , Mikael Carneholm 
<mik### [at] idautbhbse>  wrote:

> It seems as the initial clock value passed from the ini file gets
> slightly altered by POV3.5 - the ini file reads
>
> Initial_Clock=0.2
>
> but debugging the value at the first frame, I get
>
> 0.20000000298023224000000000000000 (str:ing the clock value with 32
> decimals)

Floating-point numbers are not precise.  You should never assume they are.

    Thorsten

Post a reply to this message

Thorsten Froehlich wrote:

> 
> Floating-point numbers are not precise.  You should never assume they are.
> 

That's not a problem..the problem is that both Initial_Clock and the 
value it gets compared with in the include file (SceneStartClock) should 
have the same value (at the first frame), as they are both set to 
exactly 0.2 at frame 1 (actually, SceneStartClock is set to this during 
the whole animation, to be exact :) ).

Debugging both values (at frame 1) gives me this:

Clock=0.20000000298023224000000000000000 
SceneStartClock=0.20000000000000001000000000000000

How come they are not both 0.20000000298023224000000000000000? (Or 
0.20000000000000001000000000000000 for that reason, doesn't matter as 
long as they get the same value if one sets them to 0.2, each)

Seems to me that there has been a change in how the clock value is 
calculated - and also notice that +KC (cyclic animation) was not used.

But on the other hand - I may have forgot some important detail, as this 
is the first time I use POV in about a year :)

- Mikael

Post a reply to this message

"Mikael Carneholm" <mik### [at] idautbhbse>
wrote in message news:3C5### [at] idautbhbse...
> Thorsten Froehlich wrote:
>
> >
> > Floating-point numbers are not precise.  You should never assume they
are.
> >
>
> That's not a problem.

But the differences are so minute, it might be.  If you're comparing floats,
you should compare them within a small range, for instance,

if (fabs(a-b) < 0.001)

rather than

if (a == b)

Or something along those lines.
(Sorry, I've been using c++ lately, so the POV SDL equiv escapes my mind,
but it's not too different).

...Chambers

Post a reply to this message

Hi again!

Said and done, I took the bull by the horns and fired up POV 3.1g to 
verify my suspission that something has changed from 3.1 to 3.5 (could 
it be the change of compiler?)

And, to my relief, 3.1g gave me the "correct" values and verified that 
this is something that _used_ to work.

clock=0.20000000000000000000000000000000 : 
SceneStartClock=0.20000000000000000000000000000000

Same scene, same ini file, same params, different behaviour.

Is it the compiler, or _has_ there been a change in the animation clock 
value formula?

- Mikael

Post a reply to this message

In article <3C5### [at] idautbhbse> , Mikael Carneholm 
<mik### [at] idautbhbse>  wrote:

> Said and done, I took the bull by the horns and fired up POV 3.1g to
> verify my suspission that something has changed from 3.1 to 3.5 (could
> it be the change of compiler?)
>
> And, to my relief, 3.1g gave me the "correct" values and verified that
> this is something that _used_ to work.
>
> clock=0.20000000000000000000000000000000 :
> SceneStartClock=0.20000000000000000000000000000000
>
> Same scene, same ini file, same params, different behaviour.
>
> Is it the compiler, or _has_ there been a change in the animation clock
> value formula?

As said, it is a precision issue.  It is irrelevant what 3.1 would output
because it is a precision issue and thus it really doesn't matter if
something changed or not.  Just get used to it.

    Thorsten

Post a reply to this message

Mikael Carneholm wrote:
> 
> Well, as I fired up POV at the uni for the first time in a while (3.5
> beta10, Win version) and checked to see how 3.5 worked with my old
> SmokeGen include, I noticed something strange when doing one of the
> animation demos (SplFile2.ini in the SplFile demo directory).
> 
> It seems as the initial clock value passed from the ini file gets
> slightly altered by POV3.5 - the ini file reads
> 
> Initial_Clock=0.2
> 
> but debugging the value at the first frame, I get
> 
> 0.20000000298023224000000000000000 (str:ing the clock value with 32
> decimals)
> 
> ..which means the file used to store the values from previous runs won't
> be opened WRITE and thus not overwritten when re-rendering the scene.
> 
> Is this a known "problem"? I.e. has there been a change in how the clock
> value gets calculated in v3.5?

I won't answer that question, but I do know a work-around.

I simply define the start clock at 0, the end clock at 100, the
start frame at 0, and the end frame at 100.  This gives me 24 frames
per second.  If don't want all 2401 frames, I used the subset frame
feature.

Very early in the scene code I have this:

#declare Frame=floor(clock*24+.5);
#declare Clock=Frame/24;  // note capitalization!

This gives me the exact frame number, and as near to the clock as
floating point can represent.

Regards,
John
-- 
ICQ: 46085459

Post a reply to this message