I'm using Megapov right now, but I'm pretty sure this is also a feature of
povray itself.

I have a problem where I need to access a variable which represents final frame
of an animation.  That is, the final frame_number of an animation.  The problem
is that final_frame, at least in Megapov, has no relation to the final
frame_number of an animation.  It represents the final frame of whatever
segment you happen to be rendering at the time.

I had some effects set up in povray where I assumed the final_frame would be the
final_frame.   I'm just wondering how many people would want to use a variable
that represents the final segment of a rendering subsession.

Post a reply to this message

I've been working with POV animation quite a bit lately (not in MegaPOV,
though), so I'd like to help; but I don't quite understand your question.
(Sorry!) Unless I'm mistaken, you can run only 'one segment' of animation at a
time in POV. Which means the final frame IS the final_frame number, no matter
what total clock duration you specify. (Of course, you can always run the
animation over *part* of the clock.) My apologies if this is a simplistic
reply; I guess I need more details.

It seems to me that (in POV-Ray) some code combination of frame_number, clock
and clock_delta might solve your problem.

KW

Post a reply to this message

"gregjohn" <pte### [at] yahoocom> wrote:

> I had some effects set up in povray where I assumed the final_frame would be the
> final_frame.   I'm just wondering how many people would want to use a variable
> that represents the final segment of a rendering subsession.

That's part of the confusion on my part: Are you looking for an answer with
MegaPOV or POV-Ray?

Post a reply to this message

"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.

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.

Q: Is there a way to access to value of the +kff switch in povray?

I'm trying to imagine the number of scenarios where final_frame = +ef, and the
number are quite few and seem to provide trivial benefit to the user.  Perhaps
I'm complaining about the design rationale of something that's been there from
the start, but it bugs me.

Post a reply to this message

"gregjohn" <pte### [at] yahoocom> wrote in message 
news:web.49d4a116cf786ab034d207310@news.povray.org...
>
> 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.
>

I've run this on 3.7 Beta 29 and it seems to do what you ask. It reports 
ff/24 1920.00.
It reports it as 1921.00 with the +kc option added (which I guess should be 
expected).
So it looks like someone's fixed it for the future.

I seem to remember running into this frustration with 3.6 and ended up 
simply not using the final_frame variable. Now when I try using +kff in 3.6 
at all it causes POV-Ray to hang on my machine. I'm not sure what's going on 
there, but it's prevented me running the same settings in 3.6 for comparison 
purposes.

Regards,
Chris B.

Post a reply to this message

"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

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

gregjohn wrote:

> Render just a few frames of any scene with this settings:
> +fn  +kff1920  +stp5 +sf210 +ef800

I also see this effect in 3.6 but not in 3.7b

> 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 understand you correctly you essentially normalize
the timing of a subanimation so that the number of frames
cancels out. Couldn't you just specify the duration
and start time in terms of "clock" values?

Post a reply to this message

Christian Froeschlin wrote:

> If I understand you correctly you essentially normalize
> the timing of a subanimation so that the number of frames
> cancels out. Couldn't you just specify the duration
> and start time in terms of "clock" values?

I was assuming here the clock always goes from 0 to 1. But
even if you use different values it seems that "final_clock"
has the correct value in 3.6 even with +sf / +ef.

Post a reply to this message