"Bald Eagle" <cre### [at] netscapenet> wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
>
> > ...but I'm thinking now of extending the length of
> > the entire animation with some new action at the end, maybe by 25%, but
> > without messing up all of the clock-specified events and timings that are
> > already there.
>
> Those ought to stay exactly the same.
> If you're just increasing the number of frames, then everything should
> stay the same as well.
>
> If you are _appending_ more things to the animation, then maybe just declare a
> Clock2 variable that is
> #declare Clock2 = max (1, 2-clock);
> Then when the 0-1 clock "runs out", you get a second 0-1 clock variable
> to use.
> You can also just search-replace all of your "clock" instances with "Clock"
> #declare Clock = min (1, clock);
> so that it stops at 1.
>

Yes, I've used constructs similar to those as well (although the use of min/max
is a new twist that I didn't think of; thanks.)

For me though, it really boils down to 'clarity of code'. In other words, if I
use frame_number to start an event, I'll 'know' immediately what I intended, and
where the event happens in the animation. With something like max(1,2-clock), I
have to actually think about it-- ouch! :-P Especially if I come across this
piece of code years from now, not remembering why I did it this way. Unless I'm
smart and add a nice little comment to *tell* me why, ha.

But there ARE other instances where I'll 'mix and match' clock and frame_number.
Dave B's waving flag is a good example: something like sin(19*pi*clock) is
perfectly fine for such 'continuous' animation, regardless of if I change the
running length of my animation later (where clock would go past 1.0). Using
frame_number there instead would be an unnecessary complication.

Post a reply to this message