I've just noticed that the documentation of the animation settings is
not entirely in line with the actual implementation.

The docs claim:
-----------------------------------------------------------
Any Final_Frame setting other than -1 will trigger POV-Ray's internal
animation loop.
-----------------------------------------------------------

According to the code however, animation seems to be activated whenever
the initial and final frames are neither both equal to 0 nor both equal
to 1.


This discrepancy raises the question which one is correct: The code or
the documentation?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> I've just noticed that the documentation of the animation settings is
> not entirely in line with the actual implementation.
>
> The docs claim:
> -----------------------------------------------------------
> Any Final_Frame setting other than -1 will trigger POV-Ray's internal
> animation loop.
> -----------------------------------------------------------
>
> According to the code however, animation seems to be activated whenever
> the initial and final frames are neither both equal to 0 nor both equal
> to 1.
>
>
> This discrepancy raises the question which one is correct: The code or
> the documentation?

That goes back to version 3.0 and I would guess it was meant to be a short way
of saying positive integers for final frame would activate animation.
So knowing default initial frame is 1 that meant it had to be at least 2,
obviously not 0, unless you set initial to 0 and could use final 1 instead.

Bob

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> I've just noticed that the documentation of the animation settings is
> not entirely in line with the actual implementation.
>
> The docs claim:
> -----------------------------------------------------------
> Any Final_Frame setting other than -1 will trigger POV-Ray's internal
> animation loop.
> -----------------------------------------------------------
>
> According to the code however, animation seems to be activated whenever
> the initial and final frames are neither both equal to 0 nor both equal
> to 1.
>
>
> This discrepancy raises the question which one is correct: The code or
> the documentation?

I don't recall how the old code worked, but there was some inconsistency or bug
that triggered a change so the animation would only run if there was more than
one frame. I don't think the docs were ever updated.

Post a reply to this message

Am 20.12.2016 um 23:01 schrieb Thorsten Froehlich:
> clipka <ano### [at] anonymousorg> wrote:
>> I've just noticed that the documentation of the animation settings is
>> not entirely in line with the actual implementation.
>>
>> The docs claim:
>> -----------------------------------------------------------
>> Any Final_Frame setting other than -1 will trigger POV-Ray's internal
>> animation loop.
>> -----------------------------------------------------------
>>
>> According to the code however, animation seems to be activated whenever
>> the initial and final frames are neither both equal to 0 nor both equal
>> to 1.
>>
>>
>> This discrepancy raises the question which one is correct: The code or
>> the documentation?
> 
> I don't recall how the old code worked, but there was some inconsistency or bug
> that triggered a change so the animation would only run if there was more than
> one frame. I don't think the docs were ever updated.

Apparently that's not how it was changed: If for instance you specify
`+kfi2 +kff2`, POV-Ray still enters into animation mode (and screws up
the clock; well, until a workaround I just checked in).

Do you know of any possible reason for entering animation when both
initial and final frames are equal but neither 0 nor 1?

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 20.12.2016 um 23:01 schrieb Thorsten Froehlich:
> > clipka <ano### [at] anonymousorg> wrote:
> >> I've just noticed that the documentation of the animation settings is
> >> not entirely in line with the actual implementation.
> >>
> >> The docs claim:
> >> -----------------------------------------------------------
> >> Any Final_Frame setting other than -1 will trigger POV-Ray's internal
> >> animation loop.
> >> -----------------------------------------------------------
> >>
> >> According to the code however, animation seems to be activated whenever
> >> the initial and final frames are neither both equal to 0 nor both equal
> >> to 1.
> >>
> >>
> >> This discrepancy raises the question which one is correct: The code or
> >> the documentation?
> >
> > I don't recall how the old code worked, but there was some inconsistency or bug
> > that triggered a change so the animation would only run if there was more than
> > one frame. I don't think the docs were ever updated.
>
> Apparently that's not how it was changed: If for instance you specify
> `+kfi2 +kff2`, POV-Ray still enters into animation mode (and screws up
> the clock; well, until a workaround I just checked in).
>
> Do you know of any possible reason for entering animation when both
> initial and final frames are equal but neither 0 nor 1?

Hmmm. The pre-3.0 versions lacked subset frames, but I don't know if that means
initial and final frame could have possibly been meant to act as such once that
was implemented for post-2.2 versions.

Clock was basically all there was for animations back then.

Goes against common sense anyhow, unless the clock variable still recognized a
default initial frame of 1 or somehow ignored the start=end frame.

Just looked at what clock says it is when trying equal frames.

-nan(ind)

Not a number (with a dash, minus??), but I don't know what the ind means.
Thought you probably would.

Bob

Post a reply to this message

Am 21.12.2016 um 06:49 schrieb omniverse:

> Just looked at what clock says it is when trying equal frames.
> 
> -nan(ind)
> 
> Not a number (with a dash, minus??), but I don't know what the ind means.
> Thought you probably would.

Yes: "Indeterminate". Meaning that the expression has no solution at all
(not even infinity), or that it has more than one solution (typically
infinitely many).

For example, the expression

    a / b

is supposed to yield the number x that satisfies

    x * b = a

so the expression

    0 / 0

should yield the number x that satisfies

    x * 0 = 0

which is true for all numbers, so the computer can't decide on any
particular one to give as a result.


At the other end of the spectrum, the expression

    sqrt(-1)

has no answer at all in the set of real numbers, so the computer is
again can't give you any meaningful result.


A slightly different case is the expression

    1 / 0

for which some mathematical systems add two special values to the set of
real numbers, named "positive infinity" (defined as 1/0) and "negative
infinity" (defined as -1/0), so in this case the computer does have a
result to present -- which is still "not a number" though, so it is
reported in a similar way:

    nan(inf)


Not sure what that minus sign means. Might be just an intrinsic part of
the way "Not-a-Number" values are reported, or might actually mean
_something_. Maybe the IEEE would know.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 21.12.2016 um 06:49 schrieb omniverse:
>
> > Just looked at what clock says it is when trying equal frames.
> >
> > -nan(ind)
> >
> > Not a number (with a dash, minus??), but I don't know what the ind means.
> > Thought you probably would.
>
> Yes: "Indeterminate". Meaning that the expression has no solution at all
> (not even infinity), or that it has more than one solution (typically
> infinitely many).
--->8 ok 8<---
> Not sure what that minus sign means. Might be just an intrinsic part of
> the way "Not-a-Number" values are reported, or might actually mean
> _something_. Maybe the IEEE would know.

Curiously, the clock was put in as a light_source color when I tried this.
Thought maybe it went to -1 and luckily I used a simple candle scene, lit
externally by that other light, so the flame light should have still been there.

Tried -1 instead of clock and the flame light was still there, just not the same
as with the NaN clock! Found it takes more like -100 to get the equivalent
appearance, extinguishing the flame entirely. Difficult to know exactly but -50
was ever so slightly different on the wick and melted wax edges.

Try and explain that. Why would it equate to approximately -100 for a
light_source? Anyway... going astray I fear.  ;)

Bob

Post a reply to this message

Am 21.12.2016 um 07:58 schrieb omniverse:
> clipka <ano### [at] anonymousorg> wrote:
>> Am 21.12.2016 um 06:49 schrieb omniverse:
>>
>>> Just looked at what clock says it is when trying equal frames.
>>>
>>> -nan(ind)
>>>
>>> Not a number (with a dash, minus??), but I don't know what the ind means.
>>> Thought you probably would.
>>
>> Yes: "Indeterminate". Meaning that the expression has no solution at all
>> (not even infinity), or that it has more than one solution (typically
>> infinitely many).
> --->8 ok 8<---
>> Not sure what that minus sign means. Might be just an intrinsic part of
>> the way "Not-a-Number" values are reported, or might actually mean
>> _something_. Maybe the IEEE would know.
> 
> Curiously, the clock was put in as a light_source color when I tried this.
> Thought maybe it went to -1 and luckily I used a simple candle scene, lit
> externally by that other light, so the flame light should have still been there.
> 
> Tried -1 instead of clock and the flame light was still there, just not the same
> as with the NaN clock! Found it takes more like -100 to get the equivalent
> appearance, extinguishing the flame entirely. Difficult to know exactly but -50
> was ever so slightly different on the wick and melted wax edges.
> 
> Try and explain that. Why would it equate to approximately -100 for a
> light_source? Anyway... going astray I fear.  ;)

"NaN" values propagate through every computation they take part in --
until they are converted to integer values, at which point their effect
depends on what compiler was used to build the application, what
compiler settings were used, and what colour your socks are.

In POV-Ray, that point is the actual writing of the output image file
(or display in the preview window), and the result will typically be
either bright white or pitch black pixels.

Post a reply to this message

> Do you know of any possible reason for entering animation when both
> initial and final frames are equal but neither 0 nor 1?
>

   It makes sense when you're using the clock to obtain a series of
different stills. I remember with my Tierra project, I used to let an
animation rendering overnight with different, random parameters for each
frame. Then at the next day I would check them all and re-render at
better quality only the good-looking ones.

--
jaime

Post a reply to this message

Am 2016-12-21 03:29, also sprach Jaime Vives Piqueres:

>> Do you know of any possible reason for entering animation when both
>> initial and final frames are equal but neither 0 nor 1?
>>
>
>   It makes sense when you're using the clock to obtain a series of
> different stills. I remember with my Tierra project, I used to let an
> animation rendering overnight with different, random parameters for each
> frame. Then at the next day I would check them all and re-render at
> better quality only the good-looking ones.
>
> --
> jaime

But if initial and final are equal, what would the clock be?
final - initial = 0; which is not a good clock divisor.
I do final = 10; and then +SF2 +EF2 to do single frames.

-- 
dik

Post a reply to this message