"Chris B" <nom### [at] nomailcom> wrote:
> "RC" <nomail@nomail> wrote in message
> news:web.49a4526f21b0f15ae1acfc5e0@news.povray.org...
> > "Chris B" <nom### [at] nomailcom> wrote:
> >>
> >> Maybe it would help if you could list the values you'd like to generate
> >> for
> >> the x-displacement for say the first 12 frames.
> >
> > 1-1fps
> > 2-1fps
> > 3-1fps
> > 4-2fps
> > 5-2fps
> > 6-2fps
> > 7-3fps
> > 8-3fps
> > 9-3fps
> > 10-4fps
> > 11-4fps
> > 12-4fps etc.
> >
>
> I'm still not quite sure I'm getting it, but I'll take another stab at it.
>
> What you've listed is simply 'div(frame_number,3)+1', so if that's what you
> need then it's easy, but I can't see how that fits with your descriptions
> and I can't see what fps means in this context. In my experience fps
> normally means frames per second, but I don't see how that would be relevant
> here.
>
> Is this the speed? ie the distance travelled per frame? If so you'd get a
> displacement from the initial position of:
>
> Frame 0 - 0 units in 'x'
> Frame 1 - 1 unit in 'x'
> Frame 2 - 2 units in 'x'
> Frame 3 - 4 units in 'x'
> Frame 4 - 6 units in 'x'
> Frame 5 - 8 units in 'x'
> Frame 6 - 11 units in 'x'
> Frame 7 - 14 units in 'x'
> Frame 8 - 17 units in 'x'
> Frame 9 - 21 units in 'x'
> Frame 10 - 25 units in 'x'
> Frame 11 - 29 units in 'x'
> etc?
>
> If that's what you need then the following code should give you this:
>
>
> #declare ObjectXDisplacement = 0;
> #declare Speed = 1;
> #local I = 1;
> #while (I<=frame_number)
>   #if (mod(I,3)=0) #declare Speed = Speed+1; #end
>   #declare ObjectXDisplacement = ObjectXDisplacement+Speed;
>   #local I = I+1;
> #end
> #debug concat("Frame Number: ",str(frame_number,3,0),"  ObjectXDisplacement:
> ",str(ObjectXDisplacement,3,0),"\n")
>
>
> Here's hoping that's what you want :-)
>
> Regards,
> Chris B.

Ah-ha! Works! That mod function is exactly what I was looking for. Thank you for
your patience. RC

Post a reply to this message

"Stephen" <mcavoysAT@aolDOTcom> wrote in message 
news:7ps8q4hv45ljto9071p64u5brp06cm2f4i@4ax.com...
> On Tue, 24 Feb 2009 21:17:28 -0000, "Chris B" <nom### [at] nomailcom> wrote:
>
>>I can't see what fps means in this context.
>
> Just a guess Chris, Feet Per Second
> -- 
>
> Regards
>     Stephen

Ah yes. I never thought of that. :-)

So it would be speed rather than displacement. Hopefully the code will fix 
the problem then. If it's anything other than 1 POV-Ray unit = 1 Foot  it 
may need  scaling.

Regards,
Chris B.

Post a reply to this message

On Tue, 24 Feb 2009 22:53:51 -0000, "Chris B" <nom### [at] nomailcom> wrote:


>>>I can't see what fps means in this context.
>>
>> Just a guess Chris, Feet Per Second

>
>Ah yes. I never thought of that. :-)
>
>So it would be speed rather than displacement. Hopefully the code will fix 
>the problem then. If it's anything other than 1 POV-Ray unit = 1 Foot  it 
>may need  scaling.
>

The cobwebs blew away and 60 mph = 88 fps sprang to mind. 
I was thinking along the lines of using the switch directive but I'm modelling
an animated chain drive and it is so labour intensive I can't stop to think :)
Congrats BTW.
-- 

Regards
     Stephen

Post a reply to this message

RC wrote:
> At what point in the code
> would I include a variable that changes the "function of t" value every
> three frames?

It doesn't work that way.

Suppose you want a variable to multiply by two every frame. You don't put
a = a * 2 assuming it will run on every frame, because a would be deleted
and re-initialized on the next frame. You need a = pow(2, frame_number), so
that 'a' is 2 to the uhh... frame_number'th power :)

Post a reply to this message

RC wrote:
> No way to have the code count/render for three clocks then add a value to
> our function?

No, because "our function" is not preserved from one frame to the next. All
values are reset.

Post a reply to this message

These animation accelleration questions have also intrigued/perplexed me
recently. I'm just now coming in at the tail-end of the discussion here, and I
see some good suggestions and explanations, better than what I've come up with
on my own.

Although not specifically what you're asking for, I did come up with a simple
way of starting off an animation's CAMERA motion at slow-to-zero speed, ramping
up to 'full speed' by the mid-point of the animation, then ramping back down to
slow-to-zero at the end:

#if(clock <= .5)
#declare my_clock = 1/2*pow(2*clock,2);
#else
#declare my_clock = 1 - 1/2*pow(2*(1 - clock),2);
#end

then just plug my_clock into your camera motions, with some appropriate
multiplier(s). This could be used for an object's motion instead. The exponent
in the pow() equations can be varied, and things will still come out right-- as
far as I've been able to determine, anyway. However, with this simple scheme,
there is never a point when the camera is moving at a constant speed; it's
always ramping either up or down.

As-is, though, it adds a bit of 'movie realism' to a moving (or panning/tilting)
camera.

Ken W.

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:
> These animation accelleration questions have also intrigued/perplexed me
> recently. I'm just now coming in at the tail-end of the discussion here, and I
> see some good suggestions and explanations, better than what I've come up with
> on my own.
>
> Although not specifically what you're asking for, I did come up with a simple
> way of starting off an animation's CAMERA motion at slow-to-zero speed, ramping
> up to 'full speed' by the mid-point of the animation, then ramping back down to
> slow-to-zero at the end:
>
> #if(clock <= .5)
> #declare my_clock = 1/2*pow(2*clock,2);
> #else
> #declare my_clock = 1 - 1/2*pow(2*(1 - clock),2);
> #end
>
> then just plug my_clock into your camera motions, with some appropriate
> multiplier(s). This could be used for an object's motion instead. The exponent
> in the pow() equations can be varied, and things will still come out right-- as
> far as I've been able to determine, anyway. However, with this simple scheme,
> there is never a point when the camera is moving at a constant speed; it's
> always ramping either up or down.
>
> As-is, though, it adds a bit of 'movie realism' to a moving (or panning/tilting)
> camera.
>
> Ken W.

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?

Post a reply to this message

"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