POV-Ray : Newsgroups : povray.general : How to access the value for the final frame of an animation, the kff value : Re: How to access the value for the final frame of an animation, the kff v= Server Time
30 Jul 2024 10:20:16 EDT (-0400)
  Re: How to access the value for the final frame of an animation, the kff v=  
From: Kenneth
Date: 2 Apr 2009 11:00:00
Message: <web.49d4d205cf786ab0f50167bc0@news.povray.org>
"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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.