"SecondCup" <nomail@nomail> wrote:

> Here is my code for method 1:

For step-wise sequences, I found it very helpful and orderly to divide up the
clock span of 0 to 1 into subdivided #switch / #range sections from t to t+0.1.
 That gives me 10 segments that run 1/10 of the whole clock cycle, but I can
think of them metrically like a full clock cycle.

http://news.povray.org/povray.binaries.animations/thread/%3Cweb.53f7a7167def817a5e7df57c0@news.povray.org%3E/

> The problem is the transition. It still feels 'jolty' and the overlap is linear.

Aye.  I would say that what you _don't_ want is "linear" if you're not actually
switching from one linear path to another linear path with the same slope.

What you probably want is something that uses sin and cos to taper off from one
direction and fade in another.

> I was hoping for an arc.


And there ya go.

 It drops vertically, then diagonally transitions in a
> straight line before rotating around the point. If you have a suggestion to
> 'arc' the two movements together i'd love to hear them.

Probably one of the easiest ways to avoid doing more math than you want to, is
to make appropriate use of translate and rotate to move the camera.

Plot what you want to transition from, and what you want to transition to, and
map those paths to a 90 degree segment of a unit circle.  Multiply the first
path by cos of theta, and second by sin of theta.   By the time you're through
90 degrees, you have 100% 2nd path and 0% first path.



> My first time using the spline call but a tonne of fun. This command will be
> used a lot!

Yes.   It's a very handy feature, once you work out how to use it correctly.

> I was running into trouble with the POVray coordinate system.

Er, yeah.   I've done that more times than I can count.
I'm usually surrounded by scraps and scribbles and even 3D corners of boxes to
help me see and keep track of what I'm doing.

> I cant
> get the camera to rotate about the centre in 360 degrees (360 rather than 180 as
> in method 1 just to get a handle on the POVraycoordinate system).

This shouldn't be a problem - I'll have to see what you're doing.
One thing you might try is to do a separate render where you loop from 0 to 1
like the clock would, and plot a sphere at that point rather than putting the
camera there.   Move the camera to a good vantage point, and see what this
"sphere sweep" looks like in 3D space once you render it.

A further suggestion is to use a proxy variable to do your coding with.
#declare Clock = clock;
Then, when you want to cycle through something but not use the animation .ini,
you can comment that out and do a #while or #for loop using _Clock_, and there
won't be problems trying to declare a value for the reserved system variable
_clock_.

> I cant seem to tell the camera to go behind the center point!

I'm not sure why that would be a problem, but explicitly plotting out your
points often reveals where you've gone "code blind".

> I
> tried adjusting the z-value in location but it just pulls me in and out from the
> center. This is probably because I have declared 'look_at' the center.

Yes.   That would be exactly as expected.   But you should still be able to
freely move around the center and look at it from every angle, even from
"behind" it.


How can I
> place the camera in a circular natural_spline around the center, while
> maintaining the camera's focus on the center? If you can advise on my code, I'd
> love to hear it!

> Here is my code for the spline:
>
>  #declare CameraSpline =
>     spline {
>         natural_spline
>
>         0.0, <  0, 40.5, -65>
>         0.1, <  0, 10.0, -65>
>         0.2, < 10,  5.0, -65>
>         0.3, < 30,  0.0, -60>
>         0.4, < 65,  0.0, -60>
>         0.5, < 30,  0.0, -30>
>         0.6, <  0,  0.0,   0>
>         0.7, <-30,  0.0,  30>
>         0.8, <-65,  0.0,  60>
>         0.9, <-30,  0.0,  60>
>         1.0, <  0,  0.0, -65>
>
>        }
>
>   camera{
>     location < CameraSpline(clock).x, CameraSpline(clock).y,
> CameraSpline(clock).z >
>     rotate < 0, 0, 0>
>     look_at < 0 , -10 , 0>
>
>   }

So from 0 to 0.1 you drop in y (elevation).
From 0.1 to 0.2 you drop and move right (+x)
From 0.2 to 0.3 you move right and "zoom in" (move camera closer to 0)
From 0.3 to 0.4 you move right (+x)
From 0.4 to 0.5 you move left (-x) and "zoom in"
From 0.5 to 0.6 you move left again and zoom in, this time all the way to the
origin
From 0.6 to 0.7 (and 0.8) you move left and zoom out
From 0.8 to 0.9 you move back to the right
then from 0.9 to 1 you zoom back out

I think you can just use "location CameraSpline (clock)" as a shorthand.


> With this code I didn't try to zoom as I just wanted to get used to the two
> methods. However, I did try your suggestion to use "angle CameraSpline(clock).f"
> but it was giving me an error.

You'd need a 4th number in your spline coordinates, but I've never done this
before.

By placing a number after the anchor points in
> the spline code does one call this number using 'f' as one does when calling
> 'x,y,z'.

I'm not sure how the additional components are designated, so until that gets
cleared up, I'd just define another spline with a single component, and use that
as your angle.   Call it ClockAngle, and then use "angle ClockAngle (clock)" to
change your angle.

Hopefully I'll have some time to look at your code and offer some more
(hopefully correct) commentary.

Post a reply to this message