Installing and Using Persistence of Vision (POV-Ray)

POV is the industry standard ray-tracing program and it is freely (and legally!) downloadable from the Internet from the company that produced it. To download POV-Ray, visit www.povray.org/download

You can choose a Windows version, a Mac version or a Linux version. The windows version comes as a compressed file called povray.exe that installs itself when it is run. The installation file itself is 8 MB long, so it cannot be copied easily to floppy disk.

  1. Double click on the installation program. The icon for this program is the symbol Povray icon. This causes the program to activate.
  2. The installation is basically a question of clicking on the Next > icon that you see at the bottom of the window that appears several times.
  3. After asking you all the questions, the file extraction begins (you see moving bars across the window). This should take about a minute. When the installation is complete, a tick box appears at the bottom of the window saying "Run a short test render". This lets you see a sample rendered picture when the installation process has finished.

If you simply want to make a few changes to a picture file without needing to see the picture there and then, you can always edit the file using a simple text editor (such as Notepad). You only need to activate POV-Ray when you want to turn this file into a picture.

Using POV-Ray

The information contained in this short document has been gleaned from the tutorial that forms part of POV-Ray itself. Click on the Help menu and select the Help on POV-Ray option from the drop-down menu. The menu that appears contains options for the Beginning Tutorial and the Advanced Tutorial.

When you activate the program you will see a blank screen on which you write the instructions to create the objects. The screen may not be blank - there may be files already open. Each file is represented by a tab near the top of the screen as shown:

In this case, the file testrun4.pov is open. You can close it by clicking on the testrun4 tab, and then on the Close icon above it. All windows can be closed except the Messages window which is permanently open.

To look at a file which has been created previously (for instance, those in the scenes folder), use the Open icon shown. It works as for any other program by opening a dialogue box. To create a new blank screen on which you can specify objects, click on the New icon.

Before you can turn a sequence of instructions into a picture, you must save the instructions to a file. If you forget to save the file, or to re-save it after you have made changes, then you will be prompted with a reminder.

If you choose not to save at this point, then the latest changes are not included in the final picture. You can save the currently selected picture at any time by clicking on the Save icon.

Once you have entered the instructions, loaded them from a file, or edited them, you will want to view the result as a picture. This is done by clicking on the Run icon at the top of the screen. This will create the picture and also automatically save it as a BMP file (Bitmap format - the same format as used by Paint) in the same folder as the file of instructions (Remember, you must save the instructions before you can run them).

Terminology

Here I describe the way various simple concepts are specified in the file.

Co-ordinates
(Co-ordinates can be negative!)
Co-ordinates: The file will contain several references to individual points in 3D space. Co-ordinates are specified as three numbers, firstly the x co-ordinate (how far to the right/left the point is), then the y co-ordinate (how far up/down the screen the point is) and lastly the z co-ordinate (how far into the screen the point is). The numbers are included in angle brackets < > and separated by commas (and as many spaces as you like):

< 1, 4, 0 >

Blocks of statements: Often it is necessary to group several statements together, in much the same way as one would in a computer program. The way in which statements can be grouped is by enclosing them within curly brackets { }. POV-Ray is tolerant of exactly how the program is laid out, so you can put the curly brackets on separate lines, or on the same lines as the instructions enclosed - POV-Ray doesn't mind! Here's an example:

sphere { <0, 0, 0> 0.5
         pigment {color rgb 0.7}
         finish {brilliance 2.5 
                 phong 1 reflection {0.5}}
       }

This example shows the code to draw a sphere. Outside the main set of brackets is the word sphere and everything inside the brackets is part of the sphere. The section marked finish contains 3 items, which are also enclosed within brackets. Note that the brackets don't need to line up with each other. Go back over that example and check to see which closing bracket matches each of the opening brackets.

Colours: Colours can be specified in one of two ways. If the colour has a standard name, such as White, Red or Yellow, then you can specify it as a word. The name of the colour must start with an upper case letter! If you are not sure whether POV-Ray will recognise a colour name, try it!

Of course, you may not like the exact shade of blue or yellow. The second way of specifying colours gives you complete control over the exact shade. Colours can be specified as a mixture of red, green and blue light (the three primary colours in human vision). The figures used are the fractions of each colour used (where 1 represents the maximum value and 0 indicates that the colour is totally absent). There are different ways of writing this. For instance, all the following specify a shade of orange:

color rgb <1, 0.5, 0>
color red 1.0 green 0.5 blue 0.0
color red 1.0 green 0.5
color Orange

(The word color is optional, but if you include it, you must spell it the American way, i.e. without u)

Including files: You may find that the particular set of instructions that you want have already been written and are included in some other file. You do not have to type in the instructions again - you can simply include a reference to that original file, using the #include statement, as shown below:

#include "metals.inc"
#include "colors.inc"

The file colors.inc includes various definitions of colours (for instance, it defines the colour White to be the same as rgb <1, 1, 1> - if you didn't include this file, the computer wouldn't understand what White meant!) The second files defines various textures involved in the use of "metal" options. Other files are used to give access to wood textures etc. As shown below, you can even create your own "include" files containing code which you use often and don't want to have to re-write.

Errors: Inevitably, when you enter instructions, they will contain some errors. When you try to run the file, POV-Ray will highlight the first line containing an error with a yellow high-light. The error will then be explained on the status bar at the bottom of the window:
Error messages

Basic objects

This section of the tutorial describes basic objects that must be included in a file for you to see any sort of picture at all.

Let there be light! - Adding a Light Source

Every picture must have at least one light source (although it can have more than one). Light sources aren't really objects as such - they are simply points which emit light. The simplest light source is specified by its co-ordinates in space and its colour:

light_source { <-10, 4, -3> color White }
light_source { <2, 4, -3> rgb <2,2,2> }

The first light source is at <-10, 4, -3> and is white. The second is at <2, 4, -3> and is also white. Normally, a white light would have the maximum value of all the components, i.e. it would be <1, 1, 1> specifying 100%, red, green and blue. However, you can increase these numbers above 1 (as in this case) in order to get a particularly bright light. In this case, the light is <2, 2, 2> indicating 200% red, green and blue, so the light is twice as bright as normal. Note that the word light_source contains an underscore and no spaces!

A camera

Every scene must have a camera, which represents the position of your eyes. The camera has a location and a look-at point which indicates the direction that the camera is pointing:

camera {
        location <1, 6, 1>
        look_at  <7, 0, 5>
       }
Camera

A background colour

Actually this isn't an essential item, but it is useful. The background colour simply represents the colour of the "wall" behind all the other objects. It is specified using the word background:

background { color Cyan }

(Cyan is a colour which is sky-blue)

So far we have met the things that you really should have in order to get some sort of picture - but it's a rather boring one! We need to include some other objects. Here are some other simple objects that you can include:

A sphere

A sphere is a ball. It is defined by its radius (the distance from the centre to the outside) and the co-ordinates of its centre. You can also specify the colour of the sphere using the texture and pigment instructions as shown. The example shows a yellow sphere of radius 1.5 units with its centre at <0, 2, 2>. The comma between the co-ordinate and the radius is optional.

sphere
 { <0, 2, 2>, 1.5
   texture
     { pigment { color Yellow }
     }
 }

A plane

A plane is a flat surface that extends infinitely (i.e. to the horizon) in all directions. The diagram on the left shows only part of a plane - imagine it extending in all four directions without any limit.

A plane is defined by its perpendicular vector, which is a line at 90o to the plane as shown. The direction of the vector is defined using three numbers. You will notice by looking at the example below that it has a co-ordinate <0, 1, 0> which indicates that the perpendicular vector points in the y direction, i.e. the plane is horizontal.

plane
 { <0, 1, 0>, -1
   pigment { checker color Red, color White
           }
 }

If the vector had been <1, 0, 0> then it would have pointed in the x direction, i.e. the plane would have been like a vertical wall. Similarly, you can specify different numbers, such as <1.2, -4, 100>, in which case you get a plane at a peculiar angle. Experiment with different angles.

The co-ordinate defines the direction of the plane. There is also a number which indicates its position. The number is the distance from the origin, the theoretical zero point (0, 0, 0) which marks the centre of our "universe". In this case, the closest point on our plane to the origin is 1 unit away, as shown in the diagram, and the plane is 1 unit below (hence the minus sign) the origin. Again, experiment with different numbers.

The plane is given a colour, and the example shows that cliché common to ray-traced pictures - the checker-board (similar to a chess board, but extending to the horizon in all directions). You could easily use a simple colour for the plane as shown with the sphere - or indeed create a sphere with a checker-board pattern, for that matter. In this case, the checker-board consists of red squares on a white background (or is it made of white squares on a red background?)

A Simple Picture

Let's put these basic concepts together to form a simple picture. Activate (or re-install if you are at Bellerbys) POV-Ray and enter the following instructions into a new file.

#include "colors.inc"                         

camera { location <0, 2, -3>
         look_at  <0, 1,  2>
       }
background { color Cyan }
sphere { <0, 2, 2> 1  texture { pigment { color Yellow } } }
plane { <0, 1, 0>, -1   pigment { checker color Red, color White } }
light_source { <2, 4, -3> color White}

I have chosen to include a blank line - feel free to put in blank lines wherever you like! Apart from that, I have put most of the objects on one single line each in order to save space. This should show you how tolerant POV-Ray is of the layout. As long as it finds the items it expects to find in the order it expects to find them as it reads through the file, it is happy. It really doesn't care about extra spaces or line breaks!

The #include "colors.inc" gives access to all the colour names, such as Yellow and White. If you didn't include the #include (!) the program would object when it came across these names.

So what should we expect when we save and run these instructions?

Well, clearly we have a sphere and a plane, which must be horizontal due to its perpendicular vector being <0, 1, 0>, so we expect to see a yellow ball sitting on or hovering over a flat surface. The colour ("pigment") of the plane is set to a red and white checker-board surface. Indeed, this is exactly what we do see.

You will notice that the sphere casts a black shadow on the plane even though we didn't specify one. This happens automatically as the sphere blocks out the light.

More Basic Objects

Of course, we want to add different things apart from spheres. Later we will learn how to glue these basic objects together to form more complex ones.

Boxes

A box is a rectangular shape, like a shoe-box. The technical name is a "cuboid". A box is defined by two co-ordinates, which are the co-ordinates of any two directly opposite corners.

box { <2, 1, 0>, <5, 6, 4>
      texture { pigment { color Green } }
    }

There is a comma between the two co-ordinates that specify the corners of the box. Using just two numbers means that the edges of the box must be parallel to the axes - you will notice that the green box above lines up perfectly with the three lines forming the axes. You may well want a rectangular box which is at a different angle. This is done by adding a rotate statement to the box, as follows:

box { <2, 1, 0>, <5, 6, 4>
      texture { pigment
                   { color Green }
              }
      rotate <0, 35, 0>
    }

The rotate statement is explained in a later section. Basically it rotates the shape a certain number of degrees about each axis. In the example above, the shape is rotated 35° about the y axis (i.e. as though turning on a horizontal turn-table). The rotation is done about the centre of the object.

Cones

A cone is a shape similar to an ice-cream cone. The cone does not have to rest on its circular base (like a road-cone) and does not need to end in a sharp point. It can have a flat top (like a lamp-shade) as shown. The cone is defined by the centre co-ordinates of its base and its top and the radii of the base and the top. If you want the cone to end in a sharp point, set the radius of the top to 0.

Here are two cones, the first one points vertically upwards and ends in a sharp point. The second is the code for the cone in the diagram above:

cone { <10, 0, 10>, 6
       <10, 5, 10>, 0
       texture
         { pigment { color Red }
         }
     }
cone { <3, 1.5, 6>, 2
       <5, 4, 7.5>, 1
       open
       texture
        { pigment { color Blue } }
     }

The second example contains the word open which indicates that the cone should be drawn with open ends. If you miss out this word, then the cone is drawn with the circles at the end filled in. If you are going to include the word open, then you must put it after the second radius (after the number 1 in that second example).

Cylinders

A cylinder is defined in a similar way to a cone, except that the radius of the cylinder remains the same throughout its length. For this reason, we only have to specify the radius once, after the second co-ordinate. As before, the two co-ordinates are the centre points of the two ends, and the word open can be included to produce an open-ended cylinder.

cylinder { <1, 4, 2>, <1, 6, 2>, 3
           texture { pigment { color Red } }
         }

Reusing object definitions

It is possible to reuse a definition of an object once we have already defined it. This saves us quite a lot of duplication. For instance, the following definition defines a sphere with a shiny grey metallic texture (i.e. like a silver ball bearing):

sphere { <0, 0, 0>, 0.3
         texture { pigment { color rgb <0.8,0.8,1.0> }
                   finish { diffuse 0.3  ambient 0.0  specular 0.6 
                            reflection { 0.8 metallic }
                            conserve_energy
                          }
                 }
       }

This is a complex object involving a texture with many parts. It produces a small (radius 0.3) sphere at the point (0, 0, 0) on the screen. If we want several such spheres, we don't want to have to type all that code four times! Instead, we define the special word silverBall to stand for that sphere using the #declare command:

#declare silverBall =
     sphere { <0, 0, 0>, 0.3
              texture { pigment { color rgb <0.8,0.8,1.0> }
                        finish { diffuse 0.3 ambient 0.0 specular 0.6 
                                 reflection { 0.8 metallic }
                                 conserve_energy
                               }
                      }
            }

Please note that there is nothing special about the word silverBall. It is just a name that we chose, and we could just as easily have called it lampost or paperweight. Now we can easily produce a metallic sphere identical to the previous one using the object command and giving it the word silverBall.

The first call to object produces the silver ball at the position where it was defined. The definition of silverBall above contains the central co-ordinate <0, 0, 0> which specifies where the silver ball's centre is. Clearly, we don't want all the other silver balls to appear at the same place, as you would only ever see one of them! We can move the different copies of the object by adding the translate command to the object. This moves the copy of the object by a certain distance in the x, y and z directions, the total distance being represented as a vector, as shown.

object { silverBall }
object { silverBall translate <1, 0, 2> }
object { silverBall translate <2, 1, 3> }

The scene below shows these three silver balls rendered. I have taken the liberty of adding a checker-board floor, and, of course, a light source! The dark blemish in the bottom right of the picture is the shadow from the middle ball. Note the reflective nature of the balls. You can even see the shadows of the balls reflected in their silvery surfaces!

Compound objects

So far the only objects we have used have been basic ones, but we can use commands to build more complex objects from them, and assign these compound objects names so that they can be reused. There are various commands that do this. They are union, difference, intersection, blob and merge.

Union

This joins two objects together to form a single unit that consists of both of them. Consider these two objects, a sphere and a cone, which forms a "hat" on top of it. There is no problem with the fact that the two objects overlap. I have included these items in another block with the instruction union which glues them together.

The picture shows three such objects placed above a blue plane. The union command allows the compound object to be included in a #declare instruction so that it can be re-used.

#declare oddBall =
union
 { sphere { <0, 0, 0>, 0.5 texture { pigment { color Yellow } } }
   cone { <0, 0.3, 0>, 0.5 <0, 0.7, 0>, 0.1
          texture { pigment { color Green } } }
 }  
 
object { oddBall translate <1, 0.3, 0> }
object { oddBall translate <-1, -0.2, 0.3> }   
object { oddBall translate <-0.4, 0.2, 1> }

In this example, we have shown two items being included in a union. You can, of course, include as many as you like.

Intersection

If you have a background in mathematics, you may notice that we use these words to describe areas in sets. The union of two sets is the entire area covered by the sets including the overlap. The intersection of the sets is the overlap itself.


Union

Intersection

The same thing applies to ray-traced objects. We can replace the word union in the declaration of oddBall above with the word intersection, and it will only give us the part of the objects which overlap. In this case, it is the top half of the sphere - the part that overlaps with the cone, as shown in the picture. Just changing one word has reduced each of the compound objects to small dome-like structures. Even the shadows have adjusted to match.

Difference

A variation on intersection is difference. This just displays the first object listed but subtracts from it any part of the object that would overlap with the second. If we replace the word union in the example above with the word difference, you get the picture shown:

In this case, the first listed object is the sphere and the second is the cone. The sphere is the only one displayed, but the top of the sphere (the part that overlaps with the cone) is missing. Note that the "cut" surface is the same colour as the subtracted object, (the cone in this case), i.e. green.

In the case of difference, the order in which the component objects are specified is important. If we had specified the cone first, and then the sphere, we would have seen a series of cones with small partly-spherical indentations in their bases. However, the indentations would not have been noticeable from the current camera angle.

A word of warning about difference

The computer cannot represent floating-point (decimal) numbers exactly, and this can lead to some strange effects. The diagram on the right shows a cyan box with an orange cylinder subtracted from it using difference. The end surface of the cylinder is supposed to coincide exactly with the surface of the box, but because the numbers are stored inexactly inside the computer, some remaining pixels of the subtracted cylinder still appear. At these points, the computer thinks that the surface of the cylinder is just beneath that of the box and so it draws the inside surface of the subtraction in the colour of the cylinder. The solution to this problem is to make the subtracted object just slightly bigger than the object from which is it being taken, so that the program doesn't get confused between the two surfaces.

Blob

This is quite a complex operation that can produce some interesting effects if handled correctly. It only applies to compound objects made from spheres, cylinders or a mixture of these, and "smoothes" the edges between them, to give a more organic feel.

The example shows two spheres, firstly joined in a simple union, and then joined in a blob. This involves changing the word union for the word blob, and adding a few extra numbers to specify thresholds and various other things. The best thing to do is to experiment to produce the desired effect. The Help option on POV-Ray simply does not explain what these other numbers are, so you can only experiment on them.

blob { threshold .65
       sphere { <.5,0,0>, .8, 1
                pigment {Blue} }
       sphere { <-.5,0,0>,.8, 1 
                pigment {Pink} }
     }
union
 { sphere { <.5,0,0>, .8
            pigment {Blue} }
   sphere { <-.5,0,0>,.8
            pigment {Pink} }
 }

An example of a real-life scene

In this section we are going to create a scene containing a simple building similar to a temple, in order to demonstrate the concepts of union and declare. Here's the entire file, which we will then investigate in detail:

#include "colors.inc"
#include "stones.inc"

camera { location <0, 2, -10>
         look_at <0, 0, 0>
       }

light_source { <50, 50, -50>
               rgb <2, 2, 2>
             }

background { color Cyan }

plane { <0, 1, 0> 0
        texture { pigment { rgb <0, 0.5, 0> } }
      }

#declare column =
 union { cylinder { <0, 0, 0> <0, 0.1, 0> 0.6 }
         cylinder { <0, 0, 0> <0, 3, 0> 0.5 }
         cylinder { <0, 3, 0> <0, 2.9, 0> 0.6 }
         texture { T_Stone1 }
       }

#declare roof =
 union { box { <-1, 0, -1> <6, 0.2, 6> }
         box { <-0.8, 0.2, -0.8> <5.8, 0.4, 5.8> }
         box { <-0.6, 0.4, -0.6> <5.6, 0.6, 5.6> }
         texture { T_Stone2 }
       }

#declare temple =
 union { object { column translate <0, 0.66, 0> }
         object { column translate <5, 0.66, 0> }
         object { column translate <0, 0.66, 5> }
         object { column translate <5, 0.66, 5> }
         object { roof translate <0, 3.66, 0> }
         object { roof scale 1.1 translate <-0.3, 0, -0.3>
                  texture { T_Stone15 }
                }
       }

object { temple translate <-2, 0, 0> rotate <0, 35, 0> }

There are one or two things in this code that you haven't encountered before. For example, the file stones.inc has been included in order to get access to the large number of textures that imitate stone. These are expressed by T_Stone1, T_Stone2 etc. (Note the upper case T and S. It doesn't work if you specify it as t_stone1 or T_stone2 etc.)

The plane has been given the texture { pigment { rgb <0, 0.5, 0> } }, which means that its colour is specified as a mixture of red (r), green (g) and blue (b). By mixing these three colours, any colour that the computer is capable of displaying can be produced. In this case, there is no red (the first number is 0) and no blue (the last number is also 0), but the green has been set to 50% (0.5) of its maximum value, which corresponds to a dark-green colour. The plane therefore appears as a dark-green surface.

The temple will consist of four identical columns, one at each corner. A single column is defined, being a union of three cylinders. The main part of the column is a cylinder 3 units high with its centre at <0, 0, 0> and its top at <0, 3, 0> (it is 3 units high). The two thinner, flatter cylinders cover the top and bottom part of the main cylinder (they overlap) and have a height of 0.1 units. The larger cylinder is 0.5 units in radius, and the thinner cylinders are each 0.6 units in radius, so that they stick out slightly at the top and bottom.

Instead of giving each cylinder a texture, they are grouped together in a union, and the entire union, called column, is given a stone texture.

One glance at the code will show you that the temple appears to have two roofs! In fact, one of these is actually a floor, but we can re-use the same object.

Each roof consists of 3 blocks forming a stepped pyramid as shown. Each block is 0.2 units high and they are all placed symmetrically with the lowest block being 7 units wide and each of the others being 0.4 units narrower than the one below it. These dimensions were chosen to cover the four columns with a generous overlap.

The temple is defined as an object containing four columns and two roofs. Although all the columns are defined as having their bases at <0, 0, 0>, the inclusion of the translate instruction moves them to the appropriate corners of the temple. Similarly, the columns are all translated vertically upwards 0.66 units in order to make room for the second roof which acts as a floor.

The roof acting as the floor must be slightly bigger than the one acting as the real roof. For this reason, I have included the scale 1.1 instruction in the second roof, which stretches all the dimensions (x, y and z) by a factor of 1.1 (i.e. instead of the base of this roof being 7 units, it becomes 7.7 units, with both the other dimensions stretching by the same proportion). The value of 1.1 was found through trial and error.

You will notice that the declaration of roof included a texture { T_Stone2 } instruction. This gives the roof its texture. However, the object { roof } that forms the floor also contains a texture instruction, which overrides the one inside the declaration of roof, so texture in the picture below is different. This shows that you can override one instruction with another at an outer level.

Once the temple has been declared as an object called temple, it can be called with the object { temple } command. At this stage you can, of course, add rotate, scale or translate instructions to move the entire temple around, stretch or compress it, or rotate it around any of the three axes.

The following picture shows the result of these instructions:

Comments

Occasionally it is useful to be able to include a comment in the code to generate a picture. This is a piece of text which the POV-Ray program ignores, but which provides some extra information for any human that happens to be reading the file. Perhaps you want to explain exactly which part of a picture is produced by a certain piece of code, or you wrote a piece of code in a particular way because when you tried it another way you encountered problems, and you want to record this. These are both valid reasons for including a comment

// The easiest way to include a comment is simply
// to put it on a line after a double forward slash
// as shown here. There are no spaces between the
// forward slash characters.
// The comment lasts until the end of that particular line
// so the program ignores anything after // on a line.

/* Alternatively, you can put comments after a forward
slash followed by a star (again, with no spaces). In this
case, the program ignores all the code in the file, even
if it extends over several lines, until it reaches the
same symbol with the characters reversed, i.e. a star
followed by a forward slash, like this one: */

In both cases, the comment needn't be the first item on the line, i.e. there can be spaces or even instructions on the line before it:

object { house } // Draw my house

Including your own files

We have used pre-defined styles and colours whose definitions are included in special files ending in the extension .inc. There is no reason why you can't create these files for yourself - indeed, they don't even need to end in .inc. They can end in any extension you like, and if you create them using POV-Ray itself, they will end in the extension .pov.

There is a folder automatically created under the main folder where you installed POV-Ray itself called \include. Any file stored in there can be included in the source code for your picture. If you look inside that folder, you will find both the colors.inc and the stones.inc files that we used previously.

What sort of things should you include in such a file? Well, it should only consist of #declare statements. You should not include any statements that actually call these declarations (such as the camera instruction, or the object instruction - unless it's included within a #declare instruction) as these would be called in any file that #included the file and the objects would actually be drawn. You just want to make the definitions of the objects available, in case you want to use them in other files.

An example might make this clear. I have created a file called traffic.inc containing a declaration to draw a Belisha beacon. It is available if you click on this link. When asked to save the file, navigate to the point on your hard disc where you have installed your version of POV-Ray, and then go into the include folder. Save it there.

To use the file, insert the statement

#include "traffic.inc"

at or near the start of your file. Then you can include a Belisha beacon at any time with the ordinary object instruction:

object { beacon }

You can, of course, embellish this instruction with translate, rotate or scale.

(For those of you who don't live in Britain, a Belisha beacon is a black and white striped pole with a flashing yellow globe on the top that marks the position of a pedestrian crossing across a road.)

The code is heavily commented. There is some code at the end which I used to test the file. It draws the beacon on a dark green plane. This code has /* and */ placed round it to turn it into a comment, so the beacon doesn't automatically appear whenever you #include the traffic file.

Spline objects

There is a large category of object types, based on splines, which give us a high degree of control over the shapes that we can create. A spline is a line with several points on it, tracing out a path in 3-dimensional space, as shown in the diagram. Rather than building objects out of simple geometric shapes, we specify lines and mathematical equations and create the objects from those.

Lathe objects

A lathe is a device used for "turning" wood. A cylindrical piece of wood is rotated quickly and a chisel is brought to the surface so that it cuts a groove in the wood. Because the wood is continually turning, the groove is cut evenly all the way round the piece of wood so that it has rotational symmetry (in the same way that a conventional vase has symmetry).

The best way to explain a lathe object is to demonstrate one. The diagram shows a series of points defined on a two-dimensional (notice, no Z-dimension!) graph, so that each point is specified using only 2 numbers. There are 6 points altogether.

This shows the six points in a lathe object. We include the word linear_spline (note the underscore, and no spaces) to indicate that the lathe is defined using sections which are straight lines (as in the graph).

lathe
 { linear_spline
   6, <0,1>, <6,1>, <4,2>,
      <4,5>, <6,6>, <0,6>
   pigment { rgb <1.5,0,0> }
     // Bright red
 }
POV-Ray rotates the flat shape specified by the points round the Y-xis (the vertical axis) to produce a shape that, in this case, is similar to a cotton reel. The following diagram shows the result (I have added a camera and a light source, of course). Note that it includes the number 6 (the number of points) followed by each point in turn moving round the shape.
Please note that the camera was a quite a large distance in this shot (at <5, 60, -250> in fact!) to make the reel appear small! If you imagine the reel seen horizontally, you can see the original graph in its profile.
It occurs to me that cotton reels generally have a small hole in the middle, so I have adapted the spline a little. In the code below, two of the points have been moved so that the shape no longer touches the Y-axis. Now, when it is rotated, a small cylindrical hole is left in the middle. This is because the rotation is always done around the Y-axis, even if the shape doesn't touch it.

lathe
 { linear_spline
   6, <1,1>, <6,1>, <4,2>,
      <4,5>, <6,6>, <1,6>
   pigment { rgb <1.5,0,0> }
     // Bright red
 }

Animation

POV-Ray does not contain features that allow you to create an animated presentation directly. Animation itself is done by creating a series of images, in the same manner as the frames of a film. These images must then be stitched into a movie file such as an MPEG file, using some piece of software obtained from elsewhere. Although POV-Ray won't create the movie file directly, it does provide a feature that will create all the image files as a numbered sequence.

Suppose we want a sequence that shows a red sphere rolling across a surface. The hard way to do this is to create a series of images by altering the position of the sphere manually before rendering each picture individually. The file might look like this:

#include "colors.inc"                         

camera { location <0, 2, -3>
         look_at  <0, 1,  2>
       }
background { color Cyan }
sphere { <0, 1, 2> 2  texture { pigment { color Red } } }
plane { <0, 1, 0>, -1   pigment { checker color Blue, color White } }
light_source { <2, 4, -3> color White}

Having rendered this image, you could then change the position of the sphere to <0.5, 1, 2.5>, then to <1, 1, 3> etc. Each time you render the image, it produces an image with the same name as the POV-Ray file itself, so you must rename the image file produced to prevent them overwriting the previous one.

There must be an easier way, and there is. This is where the clock variable comes in. It is a built-in variable in POV-Ray (i.e. it doesn't need to be declared in any way) that will step its way at regular intervals from one image to the next from a starting value to a stopping value.

Before you can make use of the clock variable, you must make a few changes to a file called POVRAY.INI. This contains instructions that POVRAY reads when it starts up. You can change this file by finding it in the INI subfolder inside the folder in which Povray is sitting, but there is an easier way.

On the Tools menu, you will find the option to Edit master POVRAY.INI. Clicking this activates Notepad with the required INI file in it. Just add the lines shown below.
Edit master POVRAY.INI

You must specify the starting value for clock, the stopping value for clock and the number of frames (images) to create, for example:

Initial_Frame=1
Final_Frame=30
Initial_Clock=0.0
Final_Clock=1.0

In this case, 30 images will be produced, named XXX1.bmp to XXX30.bmp, where XXX represents the name of the original file. The first image corresponds to a clock value of 0.0, the last one to a clock value of 1.0, and each frame in between corresponding to equally spaced values of clock.

Now the file can be rewritten using clock:

#include "colors.inc"                         

camera { location <0, 2, -3>
         look_at  <0, 1,  2>
       }
background { color Cyan }
sphere { <clock * 15, 1, 2 + clock * 15> 2
         texture { pigment { color Red } } }
plane { <0, 1, 0>, -1   pigment { checker color Blue, color White } }
light_source { <2, 4, -3> color White}

Notice that clock is used in two mathematical expressions. As clock moves from 0 to 1, the first expression gives numbers equally spaced from 0 to 15, and the second equally spaced from 2 to 17. The files are named in sequence from 1 to 30, and in the case of a simple picture like this would be created fairly quickly. For more complicated pictures, the renderer could be left overnight.

Don't forget to remove the lines from the INI file afterwards. You don't want POV-Ray to waste time and disk space creating several identical images. Fortunately, POV-Ray makes editing the file fairly easy - just put semicolons in front of each line to turn them into comments (they will be ignored):

; Initial_Frame=1
; Final_Frame=30
; Initial_Clock=0.0
; Final_Clock=1.0

I have created a simple animation from the temple example that I showed you above. Click here to see it, and for an explanation of how I created it.


Housie
My Village
Main menu
Housie
My Village
Main menu