Endless POVabilities

- By Sonya Roberts

The Sixth Lesson - Animating with Clock Values

Clock values are use to create animations in POV by varying the position, shape, colour, and texture of objects over time. By using clock values in the description of a scene, and then rendering out a sequential series of images, it is possible to create animations that range from the very simple to the very complex.

In this lesson, we'll start by looking at several very simple implementations of the clock value as a way of changing an image. To make our examples as "net friendly" as possible, single frames will be shown at our normal size and colour range, but actual animations will be rendered out at a much smaller resolution and converted into animated GIFs.

The files for all the examples used here are included in this zip file. As usual, the examples shown here skip over the "lights, camera, background" part of these sample files. As mentioned in the previous lesson, I've switched over to a new system of measurement. I'm using a file (units.inc) in which I've pre-defined a number of units of measure in terms of how many POV units they equal, and my measurements will be expressed in terms of these units, i.e., "4 inches by 1 foot by 3 cm" will be expressed as "<4*inches,1*foot,3*cm>".

Part 1 - Working with Clock Values

The "clock value" is one of the more difficult concepts in POV usage to explain. It is a variable that, by default, varies from the value "0" to the value "1" over the course of an animation, the number of frames of which is set using external command-line parameters. This means that the value of the clock value in any given frame is dependant on the number of frames in the animation; it's value at frame 6 of a 10-frame animation will be substantially different than that at frame 6 in a 200-frame animation. It is easiest, under these conditions, to think of the clock value as a percentage of the animation.

Let's take a look at a simple example of using the clock value. We'll take the image-mapped globe created in the previous lesson, centre it in our view, and use the clock value to rotate it over the course of the animation. To render out the individual frames, we must use some command-line parameters to specify the number of frames to POV; it'll then render out the frames as individual numdered TGA files, which we can then assemble into an animation using the tools of our choice (N.B. - most of the better animation programs and utilites can read in sequential TGA's as a native format).

Now, here comes a moderately tricky bit; if we just wanted run the animation once, we could use a rotate value of y*(clock*360) to create our revolving planet with, allowing it to turn a full 360 degrees during the animation. However, if we want the animation to loop endlessly, this would cause a slight stutter in the animation, as the planet's position would be identical in the first and last frames (0 and 360 degrees being essentially the same position). What we need to do is have the planet turn one frame less than the distance required. There are several simple ways to achieve this.

First, we could use command line parameters to set up our animation for one frame more than is needed, but instruct POV to only render the needed frames. This method has the advantage that, if we decide to re-render the animation as a longer or shorter sequence, no changes need to be made to the code, but only to the command line parameters. Alternatively, if we're quite sure that we're only going to render out the animation at a specific length, we can perform some math using the number of frames to ensure that the planet will only revolve the needed amount. For example, if we were going to render out 16 frames, we could specify the rotation as y*(clock*(360-(360/16))) (or even declare a "frames" variable at the beginning of our scene description file, and use that in place of the explicit "16").

In this case, we will in fact use the first-named method, as it allows me to introduce you to the majority of the command line parameters used in creating an animation. We begin by defining the number of frames in total that we wish to render. Let's create this as a 12-frame animation. Since we want to set up as if we're rendering one frame more than is actually needed, we'll define our number of frames as 13 (+KFI1 +KFF13), then use some additional commands to tell POV to render only a subset of the animation, consisting of frames 1 to 12 (+SF1 +EF12).

planet.pov

object {

sphere {<0,0,0>,2*inches}

texture {

pigment {

image_map {

gif "world.gif"

map_type 1

}

finish {ambient .3}

}

rotate y*(clock*360)

}

POVRAY +Iplanet.pov +V +W60 +H60 +KFI1 +KFF13 +SF1 +EF12

Let's review what the switches used in rendering the frames for this animation meant; +KFI1 +BFF13 sets the total length as the animation as 13 frames (frames 1 through 13). Our clock will, by default, vary in value from 0 to 1 over the course of these frames. +SF1 +EF12 says we want to render a subset of these frames, with a start frame of 1 and an end frame of 12, basically everything except the final frame of the defined animation, which in this case would be identical to our first frame.

A Little More Complex

Now let's try something a little more complex. Let's do something that varies in both shape and colour over the course of our animation. There's a special primitive called a superquadratic ellipsoid, or superellipsoid, that can vary in shape from a cube with rounded edges though a cylinder with rounded edges, to a sphere, to a vaguely football-like shape, depending on the values of two numbers passed to it as variables. These numbers must be greater than 0, but less than or equal to 1. We can animate smoothly between the four extremes of the superellipsoid's shape by starting with both values at near-zero, increasing the first value to 1, then the second value to 1, then returning the first number to it's original near-zero value, and then doing the same with the second number.

For this experiment, let's use the values from .1 up to 1, as required, using 10 frames per segment. This will create a forty-frame animation. For added interest, let's animate the colour of our object, cycling it through the colours of the rainbow - red, orange, yellow, green, blue, purple, and back to red. This animation will require us to test the clock value in order to determine where in the animation we are, and then transform and apply the clock value in different ways depending on the result. To simplify the math involved in this, let's use another command line switch, +KF, to change our clock so that it varies from 0 to 4 instead of 0 to 1,

superell.pov

#switch (clock)

#range (0,1)

#declare NClock=clock

object {superellipsoid {<.1+(NClock*.9),.1>}

pigment {rgb <1,NClock,0>} rotate y*30}

#break

#range (1.0000001,2)

#declare NClock=clock-1

object {superellipsoid {<1,.1+(NClock*.9)>}

pigment {rgb <1-NClock,1,NClock>} rotate y*30}

#break

#range (2.0000001,3)

#declare NClock=clock-2

object {superellipsoid {<1-(NClock*.9),1>}

pigment {rgb <0,1-NClock,1>} rotate y*30}

#break

#range (3.000001,4)

#declare NClock=clock-3

object {superellipsoid {<.1,1-(NClock*.9)>}

pigment {rgb <NClock,0,1-NClock>} rotate y*30}

#break

#end

POVRAY +Isuperell.pov +V +W60 +H60 +KFI1 +KFF40 +KH4

The Next Lesson

In the next lesson, we'll look further at the use of POV's "clock" feature.

The Rendering Times: Design and Copyright & © 1998 -- David Chandler Spake. All rights reserved. Reproduction in whole or in part in any form or medium without the express written permission of DCS is prohibited.