"RC" <nomail@nomail> wrote:
> Yes, why is it that you can never hold the value of the changed variable unless
> its just for one particular instance? I find it strange that it seems so
> difficult to change one variable for speed and have it maintain a constant
> value throughout any number of frames you wish with the ability to change it at
> any time without it reverting back to the declared value on the next cycle. I
> guess you would have to write that value to a separate file and reference it
> that way?

The reason is quite simple: POV's animation capabilities are still just
rudimentary. At the very core, the only support it offers for animation is
basically rendering a batch of stills described by the same SDL file.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "RC" <nomail@nomail> wrote:
> > Yes, why is it that you can never hold the value of the changed variable unless
> > its just for one particular instance? I find it strange that it seems so
> > difficult to change one variable for speed and have it maintain a constant
> > value throughout any number of frames you wish with the ability to change it at
> > any time without it reverting back to the declared value on the next cycle. I
> > guess you would have to write that value to a separate file and reference it
> > that way?

Yes, one approach that would work.
>
> The reason is quite simple: POV's animation capabilities are still just
> rudimentary. At the very core, the only support it offers for animation is
> basically rendering a batch of stills described by the same SDL file.

.....yet it's still possible to write some *intriguing* code within the SDL to
'mimic' the missing functionality. I haven't (yet) run across a situation where
I couldn't get the effect I was after. Sometimes it can get quite tricky,
though. (I'm still working on a few paradigms that *aren't quite there* yet.)
For example, one idea is to set up an array, and load the array (during each
and every animation frame) with whatever values you might need for the duration
of the animation (identical values from frame to frame), then use some tricky
frame_number-or-clock-based scheme to pull particular values out, when and
where needed. Kind of a dumb 'brute-force' method, but it works for certain
things.

KW

Post a reply to this message

RC wrote:
> Hello,
> 
> I know this question is going to be a head slapper but I can't seem to get an
> object to increase in speed. I need this object to increase in speed every x
> clock cycles, so I'm using an if statement. Problem is I can get it to enter
> the 'else' section, but it never returns to my original condition after I reset
> my variable counting to x (num).
> 
>         #declare num = clock*60;
>         //60 being the total number of frames
>         #declare speed = clock;
>         #if (num <= 3)
>               object { Ball
>                 scale 0.7
>                 translate <-5.5, 0, 0>
>                 translate <speed, 0, 0>
>                 #declare num = num + 1;
>                }
>               #debug "speed the same\n"
>         #else
>               #declare speed = speed + 1;
>               #declare num = clock;
>               #debug"speed increased\n"
>         #end
> 
> This is hurting my brain, and I know the answer is staring me down I just can't
> see it. Any input? I have a feeling its related to the declare statements.
> 
> 
Let's simply inject some basic physics here.  Clock runs generally from 
0 to 1 regardless of the number of frames unless changed via the command 
line or INI.  Do this:

// Initial position
#declare x0 = -5.5;
// Initial velocity
#declare v0 = 1;
// Acceleration
#declare acc = 0.45;

// Actual position
#declare xp = x0 + v0*clock + 0.5*acc*clock*clock;

// Object
object { Ball
	scale 0.7
	translate <xp, 0, 0>
}

You can alter the numbers or even make them vectors as desired.

Post a reply to this message