Animation
Yes, this animated GIF was originally made for the movies page. What - did you expect another?
A short, aimless tutorial on animation technique in POV-Ray. This assumes a basic knowledge of command-line parameters, or, if used, INI file codes; and knowledge of POV-Ray's Scene Description Language. Read the help that comes with POV-Ray for instructions regarding those. Also, in order not to cover the same ground twice, some of this information will point you in the right direction, while more in-depth information on certain things should be looked up in POV-Ray's documentation.

Basics of Animation
All animation in POV-Ray is based on the clock variable and other variables related to it. The trick to POV-Ray's easy creation of fluid animation is that it allows use of normalized clock variables. For most single-part animations, the clock variable will go from 0 to 1, allowing any of an object's parameters to be modified at a set speed over the course of the animation. For example, to rotate an object from 0 to 90 degrees along the X axis over the course of the animation, it is no more a mysterious trick than to tell it to rotate <90*clock,0,0>. Then it can be rendered for ten frames or a thousand frames and it will still rotate from 0 to 90 degrees, just rotate more or less per frame creating a smoother or bumpier animation.

Of course, the clock variable doesn't need to go from 0 to 1, but it's most useful that way. Another nice thing about the clock variable is that there's practically nothing it can't modify in the scene and no equation it can't be involved in. Lights can dim and grow, objects can shrink, rotate, and move, and, my favorite, the camera can be modified in various ways.

Compilation of the resulting series of images created by POV-Ray is achieved with various still-to-movie-format compilers. I list quite a few on the Conversion Page.

Back to Top
Multipart Animation
There are three ways to make multipart animations. The first, most obvious, and most time-consuming is to make more than one rendering of the same scene, changing what you want to move during each set of renderings. Another, recommended by the POV-Ray tutorial because it's the easiest way to make real multipart animations, is to make the clock go not from 0 to 1 but from 0 to 2 (or more, depending on how many stages the animation has). Then, using POV-Ray's programming language, you can do things like this:
 #switch (clock)
  #range (0,1)
   #declare ball_location = <-5 + (10*clock), 0, 0>;
  #break
  #range (1,2)
   #declare fixed_clock = clock - 1;
   #declare ball_location = <5, -5 + (10*fixed_clock), 0>;
  #break
 #end
During the first part of this animation, the ball would move along the X axis from <-5,0,0> to <5,0,0>. During the next part of the animation, the ball would move along the Y axis from <5,-5,0> to <5,5,0>. Notice I created a variable called fixed_clock. This is to insure that the ball goes from -5 to 5 along the Y axis; if the clock was used while it was going from 1 to 2, the ball would actually move from 5 to 15 instead of from -5 to 5 and would be rather difficult to control. (Obviously, later on in the code the ball_location variable would be used with translate to move the ball to where it's supposed to be.)

The third method of multipart animation is the one I prefer, because the segments of animation are of any size and any object can move anywhere from any time to any time. It is simply to use the regular clock going from 0 to 1, and using switches in various locations inside the POV-Ray code. I like working with the camera, so here's a section of code from Journey to the Moon which, in the last scene, partly controls the panning and zooming of the camera. The macro it uses will be introduced later:
#switch (clock)
 #range (0,0.1)
  #declare camera_direction = <0,0,normalizer(clock,0,0.1,1.7498,1.4514)>;
  #declare camera_lookat = <17.931,-1.365,3.62>;
 #break
 #range (0.1,0.9)
  #declare camera_direction = <0,0,normalizer(clock,0.1,0.9,1.4514,2.9531)>;
  #declare camera_lookat = 
    < normalizer(clock,0.1,0.9,17.931,-32.887),
      normalizer(clock,0.1,0.9,-1.365,-13.318),
      normalizer(clock,0.1,0.9,3.620,4.194) >
 #break
 #range (0.9,0.95)
  #declare camera_direction = <0,0,2.9531>;
  #declare camera_lookat = <-32.887,-13.318,4.194>;
 #break
 #else
  #declare camera_direction = <0,0,2.9531>;
  #declare camera_lookat = <2.412,-21.998,-27.763>;
#end
There are four distinct areas of camera movement in certain time intervals: [0,0.1], [0.1,0.9], [0.9,0.95], and everything else (which is anything above 0.95 or [0.95,1]).

You may be wondering how anything is controlled with such weird time intervals (making something go from 17.931 to -32.887 over the interval [0.1,0.9]???). Using a macro I wrote, it's actually easier and less math-involved than the simple code for moving the ball above. The normalizer macro is introduced in the next section.
Back to Top
The Normalizer
I couldn't think of a better name for it! POV-Ray's powerful new macro functions allows you to do almost anything math- and object-related in its scripting language that you could do in other languages.

But anyway, during my work on an animation I found I needed an easy way to move variables smoothly from point A to point B during unusual time intervals. So, I wrote a macro to do it for me. Introducing the Normalizer:
 #macro normalizer(clocknow,fromclock,toclock,fromvalue,tovalue)
  #local diff = tovalue - fromvalue;
  #local modclock = ((clocknow - fromclock) / (toclock - fromclock));
  #local fixed = fromvalue + (diff * modclock);
  #warning concat("\nGoing from ",str(fromvalue,1,3)," to ",str(tovalue,1,3),"\n")
  #warning concat("Clock values going from: ",str(fromclock,1,3)," to ",str(toclock,1,3),"\n")
  #warning concat("Current clock value: ",str(clocknow,1,3),"\n")
  #warning concat("Returning: ",str(fixed,1,3),"\n")
  fixed
 #end
This is rather simple, but it makes things infinitely easier; I don't even need to worry about how distant an ending point is from a starting point. Not only that, but it's easy to write a macro based on this to process a whole vector instead of a single number; in that way you can have an object go from point A to point B smoothly in 3-D space. Its usage is simple: Say you you want an object to go from -6.3 to 13.4 on the X axis through time interval [0.1,0.3], just use it like this:
 #switch (clock)
  #range (0.1,0.3)
  #declare object_location = <normalizer(clock,0.1,0.3,-6.3,13.4),0,0>;
  #break
 #end
And there you have it: technically, a linear interpolation routine, but who cares? (I'm sure most POV-Ray animators use something like this.) Notice you do still need to check to make sure the clock is in the right range. If it isn't, what would you expect the macro to return? To suppress the text it would normally output about what it's doing, just put two slashes // in front of each line which starts with #warning.

The equation this is based on looks like this:
Lnow = Current value. The value the macro returns; could refer to a translation, rotation, etc.
L0 = Starting value. (fromvalue in the macro)
Ln = Ending value. (tovalue in the macro)
Cnow = Current clock value. (clock)
C0 = Starting clock value. (fromclock in the macro)
Cn = Ending clock value. (toclock in the macro)
(Notice the fraction at the end involving clock values goes from 0 to 1 as the current clock value goes from C0 to Cn.)
Back to Top
The Camera
There are some who use scene modellers (Moray, POVLab) with POV-Ray and there are other, more patient people who use POV-Ray's scene description language to do everything. I am not patient. I find the best way to do camera work is a blend of using the language and using the modeller, and it is difficult to do tricks with zooming and panning using the scene description language alone. Combinations of panning and zooming are pretty impressive, as well as using focal blur to simulate a real camera (not recommended for slow computers!). I find I'm pleasantly surprised most of the time when I tell the camera to go from one position, lookat and zoom and move over to a completely different position, lookat and zoom - you never know how it's going to get there!

A quick and easy method for getting the camera from point A to point B in style is to:
  1. Position the camera at the zoom, position, and lookat you want. (When I speak of "zoom," I'm referring to either the camera's direction vector or the angle value, depending on what your modeller uses. Speaking of which, it seems odd to me to refer to the zoom as "direction," but I'm sure they have a very good reason for it!)
  2. Export the POV-Ray file from your modeller. It should give a nice block of camera settings which you can then cut and paste into a text editor.
  3. Back in the modeller, move the camera to the other zoom, position and lookat you want.
  4. Export the POV-Ray file again with the new camera settings. Copy these new settings to a text file as well.
  5. Then, using something like the Normalizer (or if you have a macro which can handle whole vectors at once, even better!), #declare your own variables to handle each of the camera's parameters over whatever time value you want. See Multipart Animations above for an example.
Some tricks:
Back to Top
Web Animation
Raytracing and 3-D modelling are definitely the best tools for creating web graphics. But, there are a few difficulties with the animation part of it:

About POV-Ray's cyclic_animation option: This is very useful for creating web animations. In fact, the animation at the top of this page was made using it.

For anyone unfamiliar with it, the way cyclic_animation works is this. Imagine you have a rotating object that spins on its axis 360 degrees. Then, when the clock goes from 0 to 1, the animation will start at 0 degrees and end at 360 degrees. But, the first and last frames will be identical since 0 and 360 degrees are equivalent - this means that every time the animation cycles, there will be a small pause every time it repeats because it will in effect be playing the same frame twice. The way POV-Ray gets around this is to modify the clock variable so that it doesn't go exactly from 0 to 360 but stops the equivalent of one frame short. (It doesn't really stop one frame short but modifies the clock so it appears this way.)

To compile the series of images POV-Ray creates into a single animated GIF, a conversion program is required (my Conversion Page lists a couple good ones). Another important item with GIF animations is:

TRANSPARENCY
In the spinning "M" animation at the top of this page you'll notice that where there's no M you can see the background behind the animation. For all the problems with GIF animations, the major benefit is that you are allowed to make certain colors of the image transparent. The way to make the files themselves so that transparency can be done, though, requires some modification of the scene in POV-Ray.

The best way to do this is to, for one thing, not use an object (a plane, for example) as the background in your animation. What you're going for is a completely solid-colored background as differently colored as possible from every object in your scene. Just set POV-Ray's background to a weird color you won't possibly use. (In television I believe they call this Chroma Key.) If you accidentally choose a color which coincides with another in the scene, you may get transparent speckles or bands which completely ruin it. Remember that GIFs use only 256 colors. If you use a color for the background even close to another in the scene, they may end up as the same color in the end after the colors are reduced.

So, since you have a single, solid-colored background to your animation, it's a simple matter to set the transparency with whatever program you use to compile your animated GIF. (By the way, in creating the diagram above I used a bright purple background as the transparent color, which you can see if you load it into an image editor.)

But, as with all things, there are problems with this method:

If you don't want to work with transparency, have an animation which can't use it, or want to use anti-aliasing for a smoother image, it's always possible to set the background color to the same one as on your web page and hope for the best. But, it won't work for textured backgrounds and the chances are pretty good that the colors won't blend. Most of the colors in a scene will change slightly when reduced from 16 million colors to 256 colors when converted to a GIF.

Back to Top
Advanced
There isn't any one trick to doing advanced animations; the major part of animation is finding the right equation to use for each movement. The topic is way too large to cover here, but the "easiest" way to make smooth curves and transitions is if you become familiar with trigonometric functions.

There are tools to assist with production of animations. If you've ever used a professional-quality renderer/animation program, you may notice it uses something called splines for controlling movement. If you draw a straight line connected to another straight line for something to move in, it may smooth the line out for you to make the animation less jarring. POV-Ray doesn't have anything built-in to help with this, but Chris Colefax (who by the way has written the most amazing POV-Ray plugins I've ever seen) wrote a spline editor which makes it easy to create splines by defining points and then including them in animations. Click here to visit his plugin page. He also has a "clock modification" plugin which can assist with different kinds of animation and is worth looking into.

My own humble POV-Ray plugin is also available here which, if I do say so, can make some pretty weird animated meshes and graphs. Try out MATH.INC.

One last thing: Use macros. They're infinitely useful and can be used over and over again to do things you're too lazy to do over and over again. After all,

Laziness is the Mother of Invention

Back to Top

Return to the Tech Page

This page created and maintained by Sean O'Malley.