Hi All,

My first posting so if I am short on etiquette please let me know! A little
context: learning to code for maybe one year. I've been learning POV-RAY for
about a month.

I'm trying to create a video animation where the camera zooms in and pans around
an object at the center of the screen. I can create the two commands easily but
individually. I can zoom in and I can pan around the object. The problem is the
the smooth transition between both actions. Id like to create a small, smooth
arc to connect both. Right now I zoom in...stop abruptly...and then pan. Its a
little jolty (if thats even a word).

Can anyone point me to a good link to help me out? Or is there a sure-fire way
to connect the two camera shots?

I have a feeling I may have to go over some trigonometry notes but so be it :)

Post a reply to this message

Le 07/04/2016 20:34, SecondCup a écrit :
> Hi All,
> 
> My first posting so if I am short on etiquette please let me know! A little
> context: learning to code for maybe one year. I've been learning POV-RAY for
> about a month.
> 
> I'm trying to create a video animation where the camera zooms in and pans around
> an object at the center of the screen. I can create the two commands easily but
> individually. I can zoom in and I can pan around the object. The problem is the
> the smooth transition between both actions. Id like to create a small, smooth
> arc to connect both. Right now I zoom in...stop abruptly...and then pan. Its a
> little jolty (if thats even a word).
> 
> Can anyone point me to a good link to help me out? Or is there a sure-fire way
> to connect the two camera shots?
> 

Greetings and welcome,

My first question would be how do you pan ? (is the object a fixed point ?)

And how do you zoom ?

Let's assume that you pan by moving the camera (changing the location value of the
camera,
while keeping the look_at at the object, and a constant angle for the camera),
and that you zoom by keeping the camera at the same location while adjusting the
angle.

The key to your request is overlapping a bit each part.

There is many ways to do it.

If your scene/camera setting was (or could be) something along:

#if (clock < ZoomTime )
 panning code
#else
 zooming code
#end

You could transform it into:

#if (clock < FirstTime )
 panning code
#else
#if (clock < SecondTime )
 end panning and start zooming code
#else
 end zooming code
#end
#end

With FirstTime < ZoomTime < SecondTime

The difficulties are in all in the "end panning and start zooming code", to be aligned
with both other parts.
And for the smoother effect, the first derivative of each movement (panning and
zooming) should be contiguous. That's the hard part.
(actually, the second derivative might also have to be continuous)

*OR* you can just dive into spline for the location and angle.

> http://wiki.povray.org/content/Reference:Spline

First, you declare the spline, then you will use it indexed with the clock.
A natural_spline is probably the simpler to use for you.

#declare CameraSpline=spline{ natural_spline
 0, <start_xposition, start_yposition, start_zposition, start_angle>,
 // add intermediate points as needed for your panning, especially if you are rotating
around a point
 //
 // transitition:
 FirstTime, < intermediate_xposition, intermediate_yposition, intermediate_zposition,
start_angle>,
 SecondTime, < end_xposition, end_yposition, end_zposition, intermediate_angle >,
 EndOfTime, < end_xposition, end_yposition, end_zposition, end_angle >,
}

camera
{ location < CameraSpline(clock).x, CameraSpline(clock).y, CameraSpline(clock).z >
//... and whatever you want too, such as right, up, direction, look_at...
//
// and angle to control zoom
angle CameraSpline(clock).f
}

// then scene as usual




> I have a feeling I may have to go over some trigonometry notes but so be it :)
> 
> 
>

Post a reply to this message

> And for the smoother effect, the first derivative of each movement (panning and
zooming) should be contiguous. That's
 the hard part.

That's "The slopes should be equal at that point"   ;)

> (actually, the second derivative might also have to be continuous)

Yikes.   I'd really have to see that graphically to see where you're going with
that.

> *OR* you can just dive into spline for the location and angle.

Yes.  Or if it's a simple, short sequence, use a formula to zoom in, then slow
the zoom as the panning starts, and then smoothly transition to all (mostly)
panning.   "Plot a nice smooth curve, like a hyperbola."

OR -  if you have trouble with that, piece together a curve like you'd piece
together shapes with CSG, but using #if or #switch.   Zoom in with a straight
line, then transition to a circular or elliptical arc, then transition to
another straight line.

Welcome to the forums   :)

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:
> Le 07/04/2016 20:34, SecondCup a écrit :
> > Hi All,
> >
> > My first posting so if I am short on etiquette please let me know! A little
> > context: learning to code for maybe one year. I've been learning POV-RAY for
> > about a month.
> >
> > I'm trying to create a video animation where the camera zooms in and pans around
> > an object at the center of the screen. I can create the two commands easily but
> > individually. I can zoom in and I can pan around the object. The problem is the
> > the smooth transition between both actions. Id like to create a small, smooth
> > arc to connect both. Right now I zoom in...stop abruptly...and then pan. Its a
> > little jolty (if thats even a word).
> >
> > Can anyone point me to a good link to help me out? Or is there a sure-fire way
> > to connect the two camera shots?
> >
>
> Greetings and welcome,
>
> My first question would be how do you pan ? (is the object a fixed point ?)
>
> And how do you zoom ?
>
> Let's assume that you pan by moving the camera (changing the location value of the
camera,
> while keeping the look_at at the object, and a constant angle for the camera),
> and that you zoom by keeping the camera at the same location while adjusting the
angle.
>
> The key to your request is overlapping a bit each part.
>
> There is many ways to do it.
>
> If your scene/camera setting was (or could be) something along:
>
> #if (clock < ZoomTime )
>  panning code
> #else
>  zooming code
> #end
>
> You could transform it into:
>
> #if (clock < FirstTime )
>  panning code
> #else
> #if (clock < SecondTime )
>  end panning and start zooming code
> #else
>  end zooming code
> #end
> #end
>
> With FirstTime < ZoomTime < SecondTime
>
> The difficulties are in all in the "end panning and start zooming code", to be
aligned with both other parts.
> And for the smoother effect, the first derivative of each movement (panning and
zooming) should be contiguous. That's
 the hard part.
> (actually, the second derivative might also have to be continuous)
>
> *OR* you can just dive into spline for the location and angle.
>
> > http://wiki.povray.org/content/Reference:Spline
>
> First, you declare the spline, then you will use it indexed with the clock.
> A natural_spline is probably the simpler to use for you.
>
> #declare CameraSpline=spline{ natural_spline
>  0, <start_xposition, start_yposition, start_zposition, start_angle>,
>  // add intermediate points as needed for your panning, especially if you are
rotating around a point
>  //
>  // transitition:
>  FirstTime, < intermediate_xposition, intermediate_yposition,
intermediate_zposition, start_angle>,
>  SecondTime, < end_xposition, end_yposition, end_zposition, intermediate_angle >,
>  EndOfTime, < end_xposition, end_yposition, end_zposition, end_angle >,
> }
>
> camera
> { location < CameraSpline(clock).x, CameraSpline(clock).y, CameraSpline(clock).z >
> //... and whatever you want too, such as right, up, direction, look_at...
> //
> // and angle to control zoom
> angle CameraSpline(clock).f
> }
>
> // then scene as usual
>
>
>
>
> > I have a feeling I may have to go over some trigonometry notes but so be it :)
> >
> >
> >


Thank you for the awesome input Le_Forgeron! Ive been working on both of your
suggestions for the past few days. Here is where i'm at with both:

Suggestion number one: The overlapping time codes.

A bit of math and coding knowledge required for this one. Took me ages to get
the transition correct. To make it a little easier for myself all I required to
do was drop the camera down vertically and then pan around (Doing away with the
zooming for now). All while focusing on slightly below the center "look_at < 0,
-10 ,0>". If the results were satisfactory I would then use the math and coding
to punch out my actual animation. Here is my code for method 1:

#declare drop = 0;
#declare pan = 0;

#declare FirstTime = .4;
#declare SecondTime = .6;
#declare ratio12 = ((clock - FirstTime)/(SecondTime - FirstTime));
#declare ratio23 = ((clock - SecondTime)/(1 - SecondTime));

#if (clock < FirstTime)              //camera drops
 #declare drop = 25 * clock;
#else
#if (clock < SecondTime)             //camera drops and rotates
 #declare drop = 10 + ratio12*5;
 #declare pan = 15 * ratio12;
#else
 #declare pan = 15 + ratio23 *165;   //camera rotates
 #declare drop = 15;
#end
#end


 camera{
    location < 0, 0 - drop, -20 >
    rotate < 0, 0 + pan, 0>
    look_at < 0, -10 ,0>
  }

This drops the camera 15 POVray units then combines both a drop (for 10 units)
and a pan (rotate around the center for 15degrees) before settling into a
horizontal pan about the y-axis for 165 degrees to complete a full 180degrees.

The problem is the transition. It still feels 'jolty' and the overlap is linear.
I was hoping for an arc. 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.

So with this, I tried method two: The fly-by spline method

My first time using the spline call but a tonne of fun. This command will be
used a lot! I was running into trouble with the POVray coordinate system. 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). I was trying
the same actions as in method one, dropping the camera then arc into a pan. For
the first couple of animation shots its really excellent, a drop then a nice
smooth arc. I cant seem to tell the camera to go behind the center point! 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. 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! For you seasoned pros this one may be an easy fix.

Ultimately I think method 2 is the way to go without using some complex math.
Plus it also gives me some fun control over the camera and its navigation. Its
smooth and pretty dynamic.

Here is my code for the spline:

 #declare CameraSpline =
    spline {
        natural_spline

        0.0, <0,40.5,-65>
        0.1, <0,10,-65>
        0.2, <10, 5, -65>
        0.3, <30, 0, -60>
        0.4, <65, 0, -60>
        0.5, <30, 0, -30>
        0.6, <0, 0, 0>
        0.7, <-30, 0, 30>
        0.8, <-65, 0, 60>
        0.9, <-30, 0, 60>
        1.0, <0, 0, -65>

       }



  camera{
    location < CameraSpline(clock).x, CameraSpline(clock).y,
CameraSpline(clock).z >
    rotate < 0, 0, 0>
    look_at < 0 , -10 , 0>

  }

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. 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'. Again this question may be straight-forward for you seasoned pros :)

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> > And for the smoother effect, the first derivative of each movement (panning and
zooming) should be contiguous. That
's
>  the hard part.
>
> That's "The slopes should be equal at that point"   ;)
>
> > (actually, the second derivative might also have to be continuous)
>
> Yikes.   I'd really have to see that graphically to see where you're going with
> that.
>
> > *OR* you can just dive into spline for the location and angle.
>
> Yes.  Or if it's a simple, short sequence, use a formula to zoom in, then slow
> the zoom as the panning starts, and then smoothly transition to all (mostly)
> panning.   "Plot a nice smooth curve, like a hyperbola."
>
> OR -  if you have trouble with that, piece together a curve like you'd piece
> together shapes with CSG, but using #if or #switch.   Zoom in with a straight
> line, then transition to a circular or elliptical arc, then transition to
> another straight line.
>
> Welcome to the forums   :)

Thank you Bald Eagle!

Ive just posted a reply to Le Forgeron. Id be interested to hear your thoughts
too!

Thanks for the feedback :)

Post a reply to this message

"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

Plots of your camera paths:
http://news.povray.org/povray.binaries.images/message/%3Cweb.5709a3a7287170380403a200%40news.povray.org%3E/#%3Cweb.5709
a3a7287170380403a200%40news.povray.org%3E

I forgot to add the origin to the first one.   It's up at the top of the
vertical line portion.

Post a reply to this message

"Bald Eagle" <cre### [at] netscapenet> wrote:
> Plots of your camera paths:
>
http://news.povray.org/povray.binaries.images/message/%3Cweb.5709a3a7287170380403a200%40news.povray.org%3E/#%3Cweb.57
09
> a3a7287170380403a200%40news.povray.org%3E
>
> I forgot to add the origin to the first one.   It's up at the top of the
> vertical line portion.


Nice! The lower image looks good until my code wants it to rotate around the
center 360 degrees.

Because I tell the code to 'look_at <the center>', the coordinate system isn't
doing what I want.

Lets say we are looking at the animation in plan view as if the center is the
middle of a clock. Looking directly down the center, the camera drops vertically
at 6'oclock -location <0,-15,-65>- and starts to rotate anti-clockwise to 5
oclock (something like -location <30,-15,-65>- (moves to the right but stays at
same elevation and distance from center))...Still while the camera is locked to
viewing the center. What are my location coordinates if I want the camera to be
at 3 oclock, 12oclock and 9oclock?...while all the time locked into viewing the
center. (I would of course add intermediate points but I think this clock
analogy works)

Without being locked to viewing the center, the coordinates would be:
6oclock location <0,-15,-65>
3oclock location <65,-15,0>
12oclock location <0,-15,+65>
9oclock location <-65,-15,0>

This would create the points on a spleen to rotate around the centre, but my
camera wouldnt be focused on the center. The look_at command causes the z-value
to act like a zoom-in/out tool.

Post a reply to this message

"SecondCup" <nomail@nomail> wrote:

> Nice! The lower image looks good until my code wants it to rotate around the
> center 360 degrees.

"Until the code I wrote that I think will rotate it around..."
Don't anthropomorphize POV-Ray, SDL, or your computer.
Only YOU _want_ something to happen.  Then you follow the rules of the puzzle to
get the OS to run POV-Ray which interprets the SDL and then makes a Cartesian
grid of colored pixels.

> Because I tell the code to 'look_at <the center>', the coordinate system isn't
> doing what I want.

The coordinate system is a static "thing"  It doesn't "do" anything.
Look_at just determines what direction the camera is pointing when it's at a
given location ("vector").


> Without being locked to viewing the center, the coordinates would be:
> 6oclock location <0,-15,-65>
> 3oclock location <65,-15,0>
> 12oclock location <0,-15,+65>
> 9oclock location <-65,-15,0>
>
> This would create the points on a spleen to rotate around the centre, but my
> camera wouldnt be focused on the center. The look_at command causes the z-value
> to act like a zoom-in/out tool.

Those would be the coordinates regardless of where the camera is looking, or if
there is even a camera at all.   The clock still exists even if a blind man or
no one at all is looking at it.  (Let's not get into quantum delayed-choice
gedanken experiments....)

If those are your cardinal points on the clock, go back, draw it out on a piece
of paper (or preferably on a unit-circle diagram) and then double-check any
intermediate points you have in your spline.
An easy way to do this without paper or a spreadsheet or trig, is to just do
what I just did with the camera path(s) and place some yellow spheres at the
points where you want the camera to pass through, and see if it lines up with
where your spline gets interpolated to be.

I would start out with something VERY simple, like your top-down view of a
clock, with the first 4 points, and then start progressively adding points -
then you can see where things start to go wrong.

I'm on the road all day today - I'll look at this again some time after I get
back in, sleep, go to work, get back, etc.  ;)

Good luck   :)

Post a reply to this message

On 4/10/2016 1:37 PM, Bald Eagle wrote:
> The coordinate system is a static "thing"  It doesn't "do" anything.
> Look_at just determines what direction the camera is pointing when it's at a
> given location ("vector").

Just one thing to mention. There are two coordinate systems*, Y up and Z 
up. Depends if you are a mathematician or an engineer. Moray used Z up. 
There is also left hand and right hand versions too.
One of the reasons I use a modeller I cannot visualise scenes well 
enough to be a true Pover.


* Not counting all the fancy ones like Polar, Plücker, cylindrical etc.

-- 

Regards
     Stephen

Post a reply to this message