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