Early in the morning between coffee and jumping to work I changed a little
detail in my animation and rerenderd from the half. I made a typo and the ini
option was set to.

+kff125 +sf167

Everything went ok but it only rendered the useless frame 167. I think that
should throw an error or give a messagebox.

==========================================================================
Preset INI file is 'P:\POV\INI\QUICKRES.INI', section is '[360p, No AA]'.
Preset source file is 'F:\Temp\light_test.pov'.
Rendering using command line '+kff125 +sf167'.
Rendering with 4 threads.
-
Parser Options
  Input file: F:\Temp\light_test.pov
  Remove bounds........On
  Split unions.........Off
  Library paths:
    P:\pov\include
    C:\Windows\Fonts
Animation Options
  Initial Frame:        1  Final Frame:      125
  Frame Step:           1
  Initial Clock:    0.000  Final Clock:    0.000
  Cyclic Animation.....Off  Field render.........Off  Odd lines/frames.....Off
Image Output Options
  Image resolution.....640 by 360 (rows 1 to 360, columns 1 to 640).
  Output file..........F:\Temp\light_test167.png, 24 bpp PNG
...
...
...
"F:\Temp\light_test.pov" line 40: Parse Warning: Clock = 1.339
==============================================================================

Why set the parser Final Clock: 0.000 but still calculating the value after
Final Frame is reached.

System Win10 x64
Pov 3.7 RC 7 and 3.8 alpha

Post a reply to this message

"Kontemplator" <haf### [at] yahoocom> wrote:
=============================================================================
>
> Why set the parser Final Clock: 0.000 but still calculating the value after
> Final Frame is reached.
>

Even during a regular animation, Final Clock never changes from 0.000 in
'messages'-- which seems kind of odd. The running 'clock' value apparently isn't
coupled into the message stream, like it should(?) be-- if I understand the
meaning of Final Clock. It should at least show *something* different than
0.000, IMO.

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
> "Kontemplator" <haf### [at] yahoocom> wrote:
> =============================================================================
> >
> > Why set the parser Final Clock: 0.000 but still calculating the value after
> > Final Frame is reached.
> >
>
> Even during a regular animation, Final Clock never changes from 0.000 in
> 'messages'-- which seems kind of odd. The running 'clock' value apparently isn't
> coupled into the message stream, like it should(?) be-- if I understand the
> meaning of Final Clock. It should at least show *something* different than
> 0.000, IMO.

Clock changes, if you set values for +ki and +kf. Even tried +kff10 +sf20 +ef30.
That would make sense if you want a different numbering of the output files. But
it doesn't work too.

Post a reply to this message

Am 10.01.2018 um 22:00 schrieb Kenneth:
> "Kontemplator" <haf### [at] yahoocom> wrote:
> =============================================================================
>>
>> Why set the parser Final Clock: 0.000 but still calculating the value after
>> Final Frame is reached.
>>
> 
> Even during a regular animation, Final Clock never changes from 0.000 in
> 'messages'-- which seems kind of odd. The running 'clock' value apparently isn't
> coupled into the message stream, like it should(?) be-- if I understand the
> meaning of Final Clock. It should at least show *something* different than
> 0.000, IMO.

The values reported there are those (explicitly) set vial the `+ki` and
`+kf` options, /not/ those computed from the `kfi` and `kff` options.

Post a reply to this message

On 01/10/2018 04:00 PM, Kenneth wrote:

> 
> Even during a regular animation, Final Clock never changes from 0.000 in
> 'messages'-- which seems kind of odd. The running 'clock' value apparently isn't
> coupled into the message stream, like it should(?) be-- if I understand the
> meaning of Final Clock. It should at least show *something* different than
> 0.000, IMO.

That *does* seem like a bug.
with +sf2753 +ef2753

-----
Animation Options
   Initial Frame:        1  Final Frame:     3343
   Frame Step:           1
   Initial Clock:    0.000  Final Clock:    0.000
-----

Frame step? I thought that was an uberpov thingy.

-- 
dik
Rendered 344576 of 345600 pixels (99%)

Post a reply to this message

dick balaska <dic### [at] buckosoftcom> wrote:

> -----
> Animation Options
>    Initial Frame:        1  Final Frame:     3343
>    Frame Step:           1
>    Initial Clock:    0.000  Final Clock:    0.000
> -----
>
> Frame step? I thought that was an uberpov thingy.
>

It's now in POV-Ray too (as of one of the 3.7.1 development versions, I think.)
Very handy too, for doing quick-and-dirty animation tests-- like rendering only
1 frame of each 10-frame group for example. Like key-framing.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
>
> The values reported there are those (explicitly) set vial the `+ki` and
> `+kf` options, /not/ those computed from the `kfi` and `kff` options.

Ah, I see now.

Given that fact, though, it nevertheless seems strange that leaving those out
(to invoke the default +ki of 0.0 and the default +kf of 1.0) produces a Final
Clock value of 0.000 instead of 1.000. That's kind of illogical... in my humble
opinion ;-)

Post a reply to this message

On 01/10/2018 08:45 PM, Kenneth wrote:
> dick balaska <dic### [at] buckosoftcom> wrote:
> 
>> -----
>> Animation Options
>>     Initial Frame:        1  Final Frame:     3343
>>     Frame Step:           1
>>     Initial Clock:    0.000  Final Clock:    0.000
>> -----
>>
>> Frame step? I thought that was an uberpov thingy.
>>
> 
> It's now in POV-Ray too (as of one of the 3.7.1 development versions, I think.)
> Very handy too, for doing quick-and-dirty animation tests-- like rendering only
> 1 frame of each 10-frame group for example. Like key-framing.
> 

Yes, very handy. My renderfarm can do a mosaic (6,3,8,2,5,10,1,4,7,9)
which is awesome, but I've always wanted it for scene development.

-- 
dik
Rendered 344576 of 345600 pixels (99%)

Post a reply to this message

Am 11.01.2018 um 03:09 schrieb Kenneth:
> clipka <ano### [at] anonymousorg> wrote:
>>
>> The values reported there are those (explicitly) set vial the `+ki` and
>> `+kf` options, /not/ those computed from the `kfi` and `kff` options.
> 
> Ah, I see now.
> 
> Given that fact, though, it nevertheless seems strange that leaving those out
> (to invoke the default +ki of 0.0 and the default +kf of 1.0) produces a Final
> Clock value of 0.000 instead of 1.000. That's kind of illogical... in my humble
> opinion ;-)

The output there disregards default values, and really only shows the
values as set by the user.

Unfortunately, the output uses "0.000" as a placeholder for "not set",
which makes the output ambiguous. I might change that... if I find the time.

Post a reply to this message