Hi!

The Docs say in 6.1.3.4.2:
final_clock:
This identifier reads the value set through the INI file option
Final_Clock=n.n or the command-line switch +KFn.n.

But saying POV-Ray that it should only render a specific part of the
animation with Subset_Start/End_Frame also changes the value of
initial/final_clock respectively, which is not mentioned in the docs.

I personally think that it should work like described in the Docs and
directly return the value set in the .INI file. But if you think the current
behavior is correct, the Docs need to be updated and you should make it
possible to get, or at leaste to calculate, the absolute values within the
scene.

Bye,
Klaus.

Post a reply to this message

Sorry, forgot: 3.5 Beta 13, Intel compile, WinXP

Post a reply to this message

In article <3c99dba2$1@news.povray.org> , "Klaus Stengel" 
<pro### [at] technologistcom> wrote:

> This identifier reads the value set through the INI file option
> Final_Clock=n.n or the command-line switch +KFn.n.
>
> But saying POV-Ray that it should only render a specific part of the
> animation with Subset_Start/End_Frame also changes the value of
> initial/final_clock respectively, which is not mentioned in the docs.

This does _not_ change the values.  You ask for a _subset_ of the frames and
that is what you get.  Obviously the clock is relevant for the whole set of
frames, not a _subset_ of the frames - without this behavior there wouldn't
even be a point in allowing a subset of frames to be specified.

If you read section "5.2.1.3 Subsets of Animation Frames" you will find that
it exactly specifies the above behavior.

    Thorsten

Post a reply to this message

> > But saying POV-Ray that it should only render a specific part of the
> > animation with Subset_Start/End_Frame also changes the value of
> > initial/final_clock respectively, which is not mentioned in the docs.
>
> This does _not_ change the values. [...]

You are right that it *shouldn't* change the values. The bug is that it
*does* change the values, which I can confirm. Try rendering this scene:
  #debug concat(str(initial_clock, 0, -1), "\n")
  #debug concat(str(final_clock, 0, -1), "\n")
first with +kff10, and then with +kff10 +sf4 +ef6. With +kff10, it outputs
  0.000000
  1.000000
as it should. But with +kff10 +sf4 +ef6, it outputs
  0.333333
  0.555556
which is wrong, since specifying a subset should not change initial_clock
and final_clock.

Anders

--
light_source{6#local D=#macro B(E)#macro A(D)#declare E=(E-#declare
C=mod(E D);C)/D;C#end#while(E)#if(A(8)=7)#declare D=D+2.8;#else#if(
C>2)}torus{1..2clipped_by{box{-2y}}rotate<1 0C>*90translate<D+1A(2)
*2+1#else}cylinder{0(C-v=1).2translate<D+C*A(2)A(4)#end-2 13>finish
{specular 1}pigment{rgb x}#end#end#end-8;1B(445000298)B(519053970)B
(483402386)B(1445571258)B(77778740)B(541684549)B(42677491)B(70)}

Post a reply to this message

Hi!

Thorsten Froehlich wrote:
>
> > This identifier reads the value set through the INI file option
> > Final_Clock=n.n or the command-line switch +KFn.n.
> >
> > But saying POV-Ray that it should only render a specific part of the
> > animation with Subset_Start/End_Frame also changes the value of
> > initial/final_clock respectively, which is not mentioned in the docs.
>
> This does _not_ change the values.  You ask for a _subset_ of the frames
> and that is what you get.  Obviously the clock is relevant for the whole
set of
> frames, not a _subset_ of the frames - without this behavior there
wouldn't
> even be a point in allowing a subset of frames to be specified.
>
> If you read section "5.2.1.3 Subsets of Animation Frames" you will find
that
> it exactly specifies the above behavior.

Maybe I was a bit unclear: I'm _not_ talking about the Initial_Clock /
Final_Clock settings in the .INI-File but the 'initial_frame' and
'final_frame' identifiers in the scene language. The bug is that
Subset_Start_Frame / Subset_End_Frame affects these indentifiers while
according to the docs it should not. (See also Anders K.'s post)

Bye,
Klaus.

Post a reply to this message

In article <3c9a1048$1@news.povray.org> , "Klaus Stengel" 
<pro### [at] technologistcom> wrote:

> Maybe I was a bit unclear: I'm _not_ talking about the Initial_Clock /
> Final_Clock settings in the .INI-File but the 'initial_frame' and
> 'final_frame' identifiers in the scene language.

Ah, yes this wasn't clear.  A check reveals that what you observe is indeed
what happens.  This bug is a leftover from the original patch :-(

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" wrote:
> Ah, yes this wasn't clear.  A check reveals that
> what you observe is indeed what happens.  This bug
> is a leftover from the original patch :-(

However, knowing the clock value at the start frame (not initial frame) is
still very valuable! Knowing the start frame number itself is equally
valuable for that matter.

With the described bug fix, I will no longer have any way of knowing if a
given frame is the first of a render session, and I really need that, for
example in my particle system.

I know it's a feature request, but I think the clock identifiers
start_frame, end_frame, start_clock and end_clock should be added, because
they're very critical for certain things, and also for consistency. While
the bug is fixed anyway, could these things be added by any chance?

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

In article <3c9e3ed4@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> start_clock and end_clock should be added

They sound useful...

> start_frame, end_frame,

No, there is no need: You can easily calculate them yourself given the
existing keyword work correctly!

Actually, either the current initial_clock/final_clock *or*
initial_frame/final_frame are also redundant because one can be calculated
using the other by using the clock_delta.  Not that I am for/against removing
either I am just pointing this out ... in particular when having all the clock
identifiers the frame identifies could all be removed and replaced by one line
simple declares!


    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" wrote:
> > start_frame, end_frame,
>
> No, there is no need: You can easily calculate them
> yourself given the existing keyword work correctly!

But surely calculating an integer from floats can easily lead to floating
point precision errors? Ok, one can add 0.5 and use the int() function on
that, but the typical new user surely don't know that.

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

In article <3c9e5bca@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> But surely calculating an integer from floats can easily lead to floating
> point precision errors? Ok, one can add 0.5 and use the int() function on
> that, but the typical new user surely don't know that.

Well, all what is needed is an "animation.inc" file which provides the correct
calculations.  And also there would be some minor error, only very few
operations are applied and the error would be on the 10th or so digit.

Anyway, it turns out to be more natural to drop the initial_clock and
final_clock in favor of a start_frame and end_frame.  This also has the
benefit that no hacks need to be applied to the core code to get the
user-specified initial_clock and final_clock.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" wrote:
> Anyway, it turns out to be more natural to drop the
> initial_clock and final_clock in favor of a start_frame
> and end_frame.  This also has the benefit that no hacks
> need to be applied to the core code to get the
> user-specified initial_clock and final_clock.

Um, how then does the user derive the initial_clock and final_clock from the
avaiable clock variables?

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

In article <3c9f57b4$1@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> Um, how then does the user derive the initial_clock and final_clock from the
> avaiable clock variables?

Doing this (untested, minor corrections will be necessary):

initial_clock = clock - (frame_number - initial_frame) * clock_delta
final_clock = initial_clock + (final_frame - initial_frame) * clock_delta

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" wrote:
> Doing this (untested, minor corrections will be necessary):
>
> initial_clock = clock - (frame_number - initial_frame) * clock_delta
> final_clock = initial_clock + (final_frame - initial_frame) * clock_delta

Calculating a constant from a variable?? Come on, this cries out for
confusing precision errors! And here, since we're not talking about
integers, it's not even possible to "correct" the result by using the int()
function.

The result will be that a value that even people familiar with precision
errors will expect to be exactly identical in every frame, may have small
but critical variations from frame to frame. I strongly advice against this
approach and ask that the initial_clock and final_clock values are available
as build-in values.

Also, I didn't quite get, if neither start_frame and end_frame nor
start_clock and end_clock are build in, then how do one calculate those? Or
will start_clock and end_clock indeed be build in? I didn't quite get that
from your reply.

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

In article <3c9fbe07@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> Calculating a constant from a variable?? Come on, this cries out for
> confusing precision errors!

No, you are completely misunderstanding how floating-point precision works.
If what you imply would be true, POV-Ray could not even work at all.

And even if it would matter, as the clock values are internally with single
precision and all declared floats are of course double precision, you probably
even gain precision by calculating them this way...

> Also, I didn't quite get, if neither start_frame and end_frame nor
> start_clock and end_clock are build in, then how do one calculate those? Or
> will start_clock and end_clock indeed be build in? I didn't quite get that
> from your reply.

You didn't read what I said:  "to drop the initial_clock and final_clock in
favor of a start_frame and end_frame"

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" wrote:
> > Calculating a constant from a variable?? Come on,
> > this cries out for confusing precision errors!
>
> No, you are completely misunderstanding how
> floating-point precision works.

You must have misunderstood me.

My point is that calculating a constant such as initial_clock from a
variable such as clock will cause the constant to slightly change from frame
to frame even though you'd expect it to be 100% the same in every frame.

I can prove this.

Render the code below with the given command line settings.

// -ga +gd +gf +ki0.5 +kff9000

#declare Initial_Clock1 =
initial_clock;
#declare Initial_Clock2 =
clock - (frame_number - initial_frame) * clock_delta;
#declare Value1 = (Initial_Clock1-0.5)*100000;
#declare Value2 = (Initial_Clock2-0.5)*100000;
#declare Test1 = (Value1=0);
#declare Test2 = (Value2=0);
#debug concat(
   "Frame: ",str(frame_number,4,0),
   " - Value1: ",str(Value1,16,13),
   " - Value2: ",str(Value2,16,13),
   " - Test1: ",str(Test1,1,0),
   " - Test2: ",str(Test2,1,0),"\n"
)
#if (Test2=true)
   sphere {z,0.1 pigment {green 10}}
#else
   sphere {z,0.1 pigment {red 10}}
#end


I used beta 14 to test it and I hope you get the same results as I. I see
Value2 gain greater and greater precision errors from frame to frame, and
this ultimately causes a test to be true in some frames and false in others,
which is based directly on the calculated initial clock based on your
formulae. The initial clock provided directly by POV-Ray on the other hand
truly is the same in every frame.

This is why it's a very bad idea to calculate a constant from a variable,
and this is why I think the values initial_clock, final_clock, start_clock
and end_clock should be provided directly by POV-Ray and not in some
animation.inc file.

I'd like to hear your arguments against this.

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

In article <3ca0688b@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> I can prove this.

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.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"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

In article <3ca0d14f@news.povray.org> , "Thorsten Froehlich" <tho### [at] trfde>
wrote:

> Only in iterative calculations floating-point errors accumulate.

After playing with your example a bit more I concluded that the precision
decrease was unreasonable for a simple multiplication and investigated it:

You actually found a precision bug in POV-Ray because the animation loop uses
such an iterative approach by simply adding clock_delta to clock when it goes
from one frame to the next.  This can easily be corrected by applying a proper
multiplication, which should fix this precision problem as well.  This fix
will be in the next beta.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" wrote:
> You actually found a precision bug in POV-Ray because
> the animation loop uses such an iterative approach by
> simply adding clock_delta to clock when it goes from
> one frame to the next.

> will be in the next beta.

Thanks, this sounds great.

However, I still stand by my belief that a supposedly constant value such as
initial_clock should not even variate the slightest bit from frame to frame.

The current initial_clock value in POV-Ray does indeed stay exactly the same
in every frame, and what I ask is that the initial_clock and final_clock
values will not be dropped.

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

In article <3ca0dba3@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> However, I still stand by my belief that a supposedly constant value such as
> initial_clock should not even variate the slightest bit from frame to frame.

Try to see it this way:  Specify a value to to the 20th digit on the command
line and then look at what you get when displaying it.  You will notice some
variation (unless you select certain values that will always be precise).  Of
course this variation will not be from frame to frame, but it still exists.
in fact, by carefully tweaking the values in the INI file it is possible to
get *closer* or even match the value you specified using the calculation
method compared to the internally known initial_clock.

This is because the precision is _finite_ but _very_ complex to track when
using floating-point numbers, and the only correct way to handle this is to
not depend on infinite precision at all, ever.  For this reason POV-Ray
internally has its EPSILON at 10e-10 by default because most platforms cannot
provide more accurate results even after just a "few" calculations.  This is
also the reason why the equality comparison operators take EPSILON into
account in POV-Ray.

Sure, you can display the value such that the precision error is visible, but
then again you can probably display 40 digits in many cases and 30 of them
will just be "random" jitter...

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

In article <3ca0688b@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> #declare Value1 = (Initial_Clock1-0.5)*100000;

After looking closer at what you are doing (multiplication by 100000  to see
more digits right of the comma) and your precision arguments and way of
testing it, I conclude you are probably misunderstanding the meaning of
"precision of floating-point numbers".

See, what you are effectively doing is tricking the display to show 19 digits.

I guess you assume "precision" refer to the part right of the comma.  However,
this is _not_ how floating-point precision is defined!

Floating-point numbers are not you every day binary (or decimal for that
matter) numbers.  I am not sure you are aware, but in memory double precision
(IEEE754 standard) floating-point numbers have exactly 64-bits to store your
number.  64 bits allow exactly 2^64 possible numbers to be represented.  This
implies about 1.845*10^19 possible numbers, which makes it obvious that more
than 19 digits of a number (which is not one of these 1.845*10^19 numbers that
can be represented as exact values) are impossible to be represented no matter
how you calculate it.  In order to allow very small values down to 2*10^-308
and very big values up to 2*10^+308 floating-point numbers use an exponent-
based format (there are many books about, so I am not going to explain it
here).  Effectively you get only about 15 to 16 digits precision after a few
calculations, and a steady decrease of precision when applying more and more
calculations.

So, what you are displaying in your example is in fact exceeding (!!!) the
available precision that is mathematically possible at some point.  I hope
this explains a bit better why you cannot expect never changing values - they
will nearly always change in a not mathematically exact way after applying
even a single operation to them.  thus, requiring a value to be always
constant is only possible if you never use it, because as soon as you do you
likely will perform some calculation and thus create similar inaccuracies
sooner or later.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" wrote:
> After looking closer at what you are doing
> (multiplication by 100000  to see more digits
> right of the comma)

Look, when I don't multiply with 1000000 and run the code, the value Test2
evaluates to 1 in all the frames. But when I multiply with 1000000, it
evaluates to 0 in frame 36 and the following ones. So I had to multiply with
1000000 to prove my point, which was that the changes in precision errors
from frame to frame could ultimately lead an expression to evaluate to
different results in different frames.

Now, having looked closer at my code, why would you say that I was just
multiplying with 1000000 to show the digits in a different way???

> and your precision arguments and way of testing it, I
> conclude you are probably misunderstanding the meaning
> of "precision of floating-point numbers".

Why?

> See, what you are effectively doing is tricking the
> display to show 19 digits.

As mentioned, it had nothing to do with showing the digits in a specific
way. The evaluation of the values Test1 and Test2 is what's interesting. And
these were dependent on that multiplication I did.

> I guess you assume "precision" refer to the part right of
> the comma.

No. I know that floating points are exponentially based, and I know they
have precision limited to about 16 digits of precision in base 10. But in my
code the multiplication with 1000000 made a difference, as I have explained,
and which you can test on your own.

> So, what you are displaying in your example is in fact
> exceeding (!!!) the available precision that is
> mathematically possible at some point.  I hope this
> explains a bit better why you cannot expect never
> changing values - they will nearly always change in a
> not mathematically exact way after applying even a
> single operation to them.

I can and will expect the constant values such as initial_clock to stay
completely the same from frame to frame. Maybe you didn't grasp the point I
wanted to show in my code, but there are two parallel set of calculations
going on. One based on the initial_clock value provided by POV-Ray, and the
other based on the initial clock formulae you provided, which is based
partly on the ever-changing clock variable.

Value1 and Test1 are derived from the initial_clock value from POV-Ray while
Value2 and Test2 are derived from your initial clock formulae. As the debug
steam shows when you run the code, Value1 and Test1 are *exactly* the same
from frame to frame, while Value2 and Test2 changes from frame to frame.
This is why I don't like your formulae and prefers an initial_clock value
given directly by POV-Ray.

Now, I know that the values derived from POV-Ray's initial_clock keyword are
just as inaccurate, but that's not the point. The point is that the value
doesn't change from frame to frame, because constants that change from frame
to frame would be a hell to debug for scene builders and macro coders.

Again, I'm still curious to hear why it's so important for you to drop the
initial_clock and final_clock keywords, when obviously, it would make things
more difficult for the users.

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

In article <3ca10568@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

> No. I know that floating points are exponentially based, and I know they
> have precision limited to about 16 digits of precision in base 10. But in my
> code the multiplication with 1000000 made a difference, as I have explained,
> and which you can test on your own.

Hmm, maybe I still failed to explain it.  The precision refers to the total
number of precise digits let or right of the comma:

You intentionally "break" the comparison operator.  Your number then has *19*
digits, which is basically above the precision available.  If you do
comparisons on numbers this way the internal EPSILON is not big enough and you
need to do "fix" it yourself by rounding.  It has nothing to do with the
calculation (assuming the precision bug in the animation loop is fixed).

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" wrote:
> You intentionally "break" the comparison operator.

Yes. But comparison operators are often broken by coders unintentionally.
The initial_clock keyword could easily be involved in a long series of
calculations which for each new calculation gets a little more imprecise.

When you have an animation with one object moving in a specific way and you
see a bug in the behaviour that changes from frame to frame, and there are
100 different places the bug could origin from, the first thought that comes
to your mind is not exactly the initial_clock value, which should be exactly
the same in every frame. An initial_clock value that has small variations
from frame to frame thus makes debugging much more difficult than needed be.

I must again refer to the fact that the current initial_clock value in
POV-Ray is indeed the same in every frame. Even if it's imprecise, it's the
*same* imprecise value in every frame, as one would expect. Why do you want
to take that away in favour of a worse solution where there are small
changes from frame to frame?

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

sad to see there has bin no change in this matter.
(and yes, this issue has driven me nuts ... again)

Bad documentation is worse then no documetation!

Post a reply to this message

What's the problem?

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

hum, well, ok ...

basicly it come down to the fact that the animation INI settings
[Subset_Start_Frame] & [Subset_End_Frame]
effect the built-in variable values of
[initial_clock], [final_clock], [initial_frame] & [final_frame].

I personally don't understand the WHY of this behaver,
but worse, there is no indication in the documentation of this behaver.

basic rood-map to flame:
1) you think you understand those settings/variables (based on doc)
2) you start using those settings/variables (experimenting and finding out
there usefulness)
3) at some point you try to render a subset of your animation
4) and your completely surprised by a subset render that make no sense.
5) you finally figure out you got to rip out all used
(initial/final_clock/frame) and
replace them with hard core value's, just to get that subset rendered
correctly.
(very high innocence level, if you ask me)

In my case I use like to use the AVI frame-time value to my animation work,
instead of the raw [clock] value.
But to make this work I need to know the 'real' start and ending frame of
the whole animation sequence.
And there is no way to calculate them ... unless you cheat.
besides, calculating them also defeats the purpure of having built-in
variable that refer to INI settings.

I still don't understand why they don't just provide a full set of build-in
animation variable that
directly give the value's of the used setting.
It would be a good thing, because its clear, simple to use, and effective.
(if it would be really useful ... is something that should be judge by
Animators,
 not the programmers!)

haaaaaa, that feels a lot better :)

ps:
- I'm not a regular (webpage-login), nor a great talker (no discussion)
- so, it will probably take along time for me to react (if ever)
- however, I do read up ... from time to time.

Post a reply to this message

In article <web.41129b4e217d299beb697f1c0@news.povray.org> , "...Tyrell..."
<Tyr### [at] hotmailcom> wrote:

> sad to see there has bin no change in this matter.
> (and yes, this issue has driven me nuts ... again)

This is the wrong group to discuss anything in POV-Ray 3.6.  this group was
for the beta test of POV-Ray, which has been over for several month now.

Please read the posting as well as bug reporting guidelines in the
frequently asked questions group.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message