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.
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.
| 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). | ![]() |
![]() (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):
|
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: | ![]() |
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.
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 cameraEvery 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>
}
|
![]() |
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:
sphere
{ <0, 2, 2>, 1.5
texture
{ pigment { color Yellow }
}
}
![]() |
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?)
#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.
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.

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).
cylinder { <1, 4, 2>, <1, 6, 2>, 3
texture { pigment { color Red } }
}
|
![]() |
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!


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.
![]() 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.


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.


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} }
}
|
#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:

// 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
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. |
![]() |
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. |
|
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. | ![]() |
lathe
{ linear_spline
6, <1,1>, <6,1>, <4,2>,
<4,5>, <6,6>, <1,6>
pigment { rgb <1.5,0,0> }
// Bright red
}
|
![]() |
![]() |
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. |
![]() |
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
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.
![]() |
![]() |
![]() |