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