There are subset options for the command line that might fix this problem:

+SF0.n              Same as Subset_Start_Frame
+EF0.n              Same as Subset_End_Frame

Leave +KFI & +KFF as the absolute first and last frames and set +SF0.n and
+EF0.n to starting and ending percentages.

At that point final_frame which is set from the value of +KFF will equal the
total number of frames in the whole animation.

Incidentally, I'm working on a comprehensive animation tutorial that covers the
timing calculations as well.  If anybody would be interested in proofreading,
I'd be happy to have the input.

A.D.B.

"Kenneth" <kdw### [at] earthlinknet> wrote:
> "gregjohn" <pte### [at] yahoocom> wrote:
> > "Kenneth" <kdw### [at] earthlinknet> wrote:
> > > Which means the final frame IS the final_frame number, no matter
> > > what total clock duration you specify.
> >
> >
> > no.
> >
> > Render just a few frames of any scene with this settings:
> > +fn  +kff1920  +stp5 +sf210 +ef800
> >
> > And this SDL in it:
> > #debug "clock " #debug str(clock,4,3)
> > #debug "  seconds " #debug str(frame_number/24,4,2)
> > #debug " frame " #debug str(frame_number,5,0)
> > #debug "  ff/24 " #debug str(final_frame,4,2)
> > #debug "\n"
> >
> > You'll see that POV-Ray 3.6 (and MegaPOV) have perverted the meaning of
> > "final_frame" to mean not the last frame in your whole animation but rather
> > the last frame in that-which-you-choose-to-render-right-now.
>
> Strangely, I haven't *noticed* this situation before--possibly because I set up
> my animations in a different or simplistic way(?). Or that I'm not expecting to
> get the results you're after(?) I'm still not sure I'm 'getting' you're
> argument, but now that you bring it up, I need to experiment and understand
> what this is all about. (In my own animations, I use .ini file keyword settings
> rather than command line switches, possibly another source of my confusion--but
> they *should* be equivalent, of course.)
> >
> > I set up several routines, from walking to blinking, to be based on the
> > final_frame.  In this way I can use the code interchangeably between projects
> > without worrying over whether the animation were 10 frames or 1000-- the
> > character will walk or blink at a reasonable rate.  If I want a robot to walk
> > at a reasonable pace no matter what the project, I can base its movement on
> > final_frame.   To me, final_frame has great value if it were in fact === to
> > the value of the  +kff switch.
>
> I DO see the usefulness of this idea; in my animations so far, I haven't even
> attempted to get this effect--probably because I couldn't easily figure out how
> to code it. (Once I settle on an animation length, in frames, I design the
> entire scene's action and timing based on that.  Rather limiting, as I can't
> easily port one scene's action to another scene of a different frame length.) I
> think I'm finally starting to 'get' you're argument!
>
> Sorry I can't offer any useful suggestions at the moment.
>
> KW

Post a reply to this message