| POV-Ray for Unix version 3.8 | ||||
|
|
||||
| Home | POV-Ray for Unix | POV-Ray Tutorial | POV-Ray Reference | |
This document provides a tutorial for the Persistence of Vision Ray-Tracer™ (POV-Ray). The documentation applies to all platforms to which this version of POV-Ray is ported. The platform-specific documentation is available for each platform separately.
The tutorial is divided into five main parts:
The current release of POV-Ray runs on 32 and 64-bit versions of Microsoft Windows from XP through Windows 8, Mac OS X, Linux/UNIX, and numerous other platforms (when compiled from source).
If you do not yet have POV-Ray installed or are not sure you have the official version or the latest version, see appendix What to do if you don't have POV-Ray.
This book covers only the generic parts of the program which are common to each version.
Note: Each version has platform-specific documentation not included in this section.
We recommend you finish reading this introductory section then read the platform-specific information before reading the rest of the tutorial. The platform-specific docs will show you how to render a sample scene and will give you detailed descriptions of the platform-specific features.
The Windows version documentation is available on the POV-Ray program's Help menu or by pressing the F1 key while in the program.
The Unix / Linux version documentation can be found at the same place as
the platform independent part. Usually that is
/usr/local/share/povray-3.?
The Persistence of Vision Ray-Tracer creates three-dimensional, photo-realistic images using a rendering technique called ray-tracing. It reads in a text file containing information describing the objects and lighting in a scene and generates an image of that scene from the view point of a camera also described in the text file. Ray-tracing is not a fast process by any means, but it produces very high quality images with realistic reflections, shading, perspective and other effects.
Ray-tracing is a rendering technique that calculates an image of a scene by simulating the way rays of light travel in the real world. However it does this simulation backwards; in the real world, rays of light are emitted from a light source and then strike objects. Some of the light rays then bounce off the objects and enter our eyes (or perhaps a camera). However, most of the rays never reach anything that 'observes' them; they either leave the area of interest or are absorbed by objects within it.
Because the vast majority of rays never reach an observer, it would take a very long time for software to trace even a simple image if the rays were cast as they were in the real world (because almost all of the calculations would end up going to waste). For the purposes of drawing a representation of a scene as viewed from an imaginary camera, we are generally only interested in rays that reach that camera's lens.
A 'scene' is the virtual world which you wish to take a 'picture' of with our simulated camera. There can be (and usually are) objects in the scene that do not appear in the final image, just as objects outside the field of view of a real camera do not directly appear in the final image. (They can still cast shadows or be seen as reflections, though).
Accordingly, ray-tracing programs like POV-Ray start with their simulated camera and trace rays backwards out into the scene. The user specifies the location of the camera and the type of lens it is using, the light sources that illuminate the scene, the objects within it, as well as the surface texture properties of objects, their interiors (if transparent) and any atmospheric media such as fog, haze, or fire.
For every pixel in the final image one or more viewing rays are shot from the camera into the scene to see if it intersects with any of the objects in the scene. These "viewing rays" originate from the viewer (represented by the camera), and pass through the viewing window (representing the pixels of the final image).
Every time an object is hit, the color of the surface at that point is calculated. For this purpose rays are sent from that point to each light source to determine the amount of light coming from that source. These "shadow rays" are tested to tell whether the surface point lies in shadow or not. If the surface is reflective or transparent new rays are set up and traced in order to determine the contribution of the reflected and refracted light to the final surface color.
Special features like inter-diffuse reflection (radiosity), atmospheric effects and area lights make it necessary to shoot a lot of additional rays into the scene for every pixel.
POV-Ray™ is short for the Persistence of Vision Raytracer™, a tool for producing high-quality computer graphics. POV-Ray is Free Software (as per the definition of the Free Software Foundation) as its source code is licensed under the Affero General Public License (AGPL).
POV-Ray was developed from DKBTrace 2.12 (written by David K. Buck and Aaron A. Collins) by a bunch of people (called the POV-Team™) in their spare time. The headquarters of the POV-Team is on the internet (see Where to Find POV-Ray Files for more details).
The POV-Ray package includes detailed instructions on using the ray-tracer and creating scenes. Many stunning scenes are included with POV-Ray so you can start creating images immediately when you get the package. These scenes can also be modified so you do not have to start from scratch.
In addition to the pre-defined scenes, a library of pre-defined shapes and materials is provided. You can include these shapes and materials in your own scenes by just including the library file name at the top of your scene file, and by using the shape or material name in your scene.
Here are some highlights of POV-Ray's features:
The following sections cover changes and new features that apply no matter what platform you are using. Changes and information pertaining to your particular installation are covered in the platform specific documentation that's included with the distribution.
The categorized lists below outline the additions, changes and improvements along with links (when appropriate) to their relevant passages in the Reference Section.
These changes (in no particular order) pertain to the version 3.8 release.
General Changes
Language Basics and Directives
tau as a Built-in Constant has been addedmacro directive has been extended. See Optional Parameters for detailsarray functionality allows the creation of dictionary container typesCreate_Continue_Trace_Log option allows for greater resource controlgray in keywords or INI file options can now alternatively be spelled greyversion pseudo-variable will now evaluate to the effective language version at the time the expression is parsed. See: Built-in Variables and Version DirectivePatterns Pigments and Textures
ambient has changedrepeat option has been added to Crackle Patterncone, cylinder and lemon was added and ovus mapping has been improveduse_alpha has been added to suppress highlights and reflections depending on pigment transparencyuser_defined has been added to define the pigment color directly in terms of a set of functionspotential has been added to aid in creating a pattern based on the potential field of a blob or isosurface objectbrilliance setting of a surfacecolors.incImages and Image Related
up vector has changed. See: Aspect Ratiomax_extent function has been extendedmap_type keyword now supports the angular map projection for use with light probestransmit all and filter all with an image's alpha channel has been changedObjects and Object Related
lemon object was addedovus object has been extended and uv mapping has been improvedtorus was addedblob is no longer artificially limiteduser_defined camera type was addedThese version 3.7 items definitely deserve your attention, because some of them represent key changes or enhancements to the way POV-Ray operates or behaves.
mesh_camera permits simulation of arbitrary lenses and makes texture baking possible.assumed_gammasrgb keyword and its kin can be used to specify gamma pre-corrected colorsFile_Gamma feature has been addedAntialias_Gamma feature has been addedgamma for individual input filesmaximum_reuse parameter nearest_count parameteruv_mappingpoly, cubic and quartic objects. Alternate syntax is also available.Draw_Vistas, Vista_Buffer and Light_Buffer options have been deprecated. Look here for additional details.
Patterns Pigments and Textures
This category deals with items that are the building blocks of materials and textures and their appearance.
diffuse backside illumination capability.area_light diffuse and specular illumination was implemented.aoi patterncubic patterncubic warppavement patternsquare patterntiling patterntriangular patternslope pattern extensioniterations and two new exterior types were added. See Fractal Patterns for more details.emission keyword.sky_sphere layered pigment related behavior change.finish attribute.Images and Image Related
Image formats and handling issues are covered in this section.
gamma handling tutorial.interpolate option now supports bicubic interpolation.hf_gray_16 keyword has been deprecated in the global_settings block.Language Basics and Directives
A macro, a few functions and some programming directives completes this summary.
deprecated.datetime() has also been added.input_file_name.#write capability, see the ARRAYS_WriteDF3 macro for usage.#break directive behavior has changed.atand function has been added to the math.inc file.max_extent function can now return the pixel resolution of an image map.#version directive requirement has been added.#if directive now supports an #elseif clause.#for loop directive has been added.+GP option. See the section: Directing Text Streams to Files for more information.The terms 'POV-Ray', 'Persistence of Vision Ray Tracer', and 'POV-Team' are trademarks of Persistence of Vision Raytracer Pty. Ltd. All other trademarks are acknowledged as being the property of their respective owners.
Here's how POV-Ray came to be, as described by David Buck:
Back in 1986 or so, I had an Amiga. A friend who also has an Amiga downloaded the C code for a raytracer for Unix from the Internet and brought it over. I thought it looked interesting and I ported it to the Amiga and wrote the drivers to display it with Amiga graphics. The program only rendered untextured spheres with a planar floor in black and white, but I was still impressed by it. I played with it a bit adding support for color, but I eventually decided that I could do a better job writing a raytracer from scratch, so I scrapped the C program and started my own - DKBTrace had begun.
I decided to start with general quadric surfaces since they could represent spheres, ellipsoids, cylinders, planes, and more. I worked out the ray-quadric intersection calculations and used some calculus to work out the surface normal to a quadric surface at a point. For the program structure, I decided to use an object-oriented style since I had learned Smalltalk at university and it fit nicely. To make modeling more flexible, I added CSG and procedural textures. In the end, I had an interesting little raytracer and I decided to release it as freeware since I was planning to return to university to start my Master's degree and didn't have time to develop a commercial raytracer. Besides, there were already commercial renders for the Amiga that had user interfaces (not just text files) and I felt I couldn't sell it as a commercial product. I called it DKBTrace and released it to local BBS'es and to the Internet.
DKBTrace was an Amiga-only program, but it attracted quite a lot of interest. I released several versions of it adding in new features, better primitives, more texturing options, etc. Eventually I released version 2.01.
Sometime around 1987 or 1988, I was contacted by Aaron Collins. He had found the C code for DKBTrace and ported it to the PC. He also added a Phong lighting model and a few more goodies. I was interested in what he had done, so I contacted him to see if he wanted to help develop a new version of the program. This one would be portable across more platforms (at university I had access to Unix workstations). We eventually came up with version 2.12 which was the last version of DKBTrace ever released (1989).
While Aaron and I were working up to version 2.12, there was a group of people on CompuServe who were very excited about DKBTrace and were creating all sorts of neat scenes for it. They were also expressing frustration that Aaron and I weren't able to add new features into DKBTrace fast enough. They started talking about building a whole new raytracer from scratch that they could control and add the features they wanted. At that time, I was starting to pursue other areas and was starting to drift away from raytracing. So, I posted a message on CompuServe with the following offer: We could form a team to develop a new raytracer using DKBTrace as a base. I had three requirements for this team. The resulting code had to be freeware with the source code freely available, it had to remain portable between different platforms, and it had to have a different name than DKBTrace.
The name DKBTrace was, of course, based on my initials: David Kirk Buck (there's some little known trivia for you). With a package developed by a team of people, it was inappropriate to use my initials. I was also starting to drift away from raytracing (as I mentioned) and I didn't want people thinking that I was the head of the team forever. The name that was proposed was "Persistance Of Vision Raytracer" which was shortened to POV-Ray. It worked in three ways. It was the result of a persistent vision of the developers, it was a reference to the Salvador Dali work which depicted a distorted but realistic world, and the term "persistance of vision" in biology referred to the ability to see an image that was presented briefly - almost an after image.
In 1989, then, DKBTrace 2.12 was officially released and the POV-Ray project had begun. I worked with the team for a few years after that. I was responsible for the Amiga port among other things. Drew Wells was the project leader. Aaron Collins dropped out of the project around that time as well. Other early members included Chris Young, Steve Anger, Tim Wegner, Dan Farmer, Bill Pulver (IBM drivers), and Alexander Enzmann (quartics and cool math stuff). Chris Cason joined shortly after (my apologies if I left anyone out - lots of people were involved). The reference to Robert Skinner in the credits for POV-Ray was because we had a hard time finding a good noise function. In another raytracer, he had a great noise function written by Robert Skinner, so we asked for and received permission to use it in POV-Ray.
There was so much demand for us to release a new version that we created POV-Ray 0.5 and released it. It was basically an enhanced DKBTrace with a similar grammar but many more features. Eventually, we released POV-Ray 1.0 which had the new grammar and lots of new stuff. Drew dropped out later and Chris Young took over as project leader.
It was around that time that I started to drift away from the POV-Ray team. The project had momentum and could continue on without me. I was getting into different areas (physically based modeling and animation) and no longer had the time to continue with POV-Ray. Around the release of version 2.0, I left the project and the POV-Ray team developed it to its current state. Chris Cason is now the project leader.
Even though I'm no longer on the POV-Ray development team, I still like to follow its progress. I haven't built my own scene by hand for years now (although I occasionally use Moray). I still enjoy the one thing that drove me back in the DKBTrace days - I love seeing the works of other people who used my software. Even though I can no longer call POV-Ray "my software", I still enjoy admiring the artwork people create with it. I'm constantly amazed at what people can do. It was always the feedback from user community that drove me.
David Buck,
david [at] simberon.com
august 2001
11906 S16/Raytraced Images
07-Mar-91 18:56:37
Sb: DKB Development
Fm: David Buck 70521,1371
To: All
Greetings all. This is my first posting to this group, so you'll
have to excuse me if I make any mistakes in this post.
Finally, after several weeks of waiting, I've received my CompuServe
account. It's nice to see that people are enjoying my raytracer
(DKB, of course). I have noticed, however, that you are less than
satisfied at the support I've been able to provide <grin>.
True, I'm the first to admit that the support is poor. I have
little time these days to work on graphics - it takes long enough
to answer all the questions I get asked on a daily basis from all
across the world.
My motivation for releasing the raytracer as Freely Distributable
software in the first place was to allow people to have some fun
with a program I'd developed for just that purpose. I don't
consider it to be a professional package - I know it's nowhere near
that good. I didn't make it shareware, however, because I knew I
wouldn't have much time for support. I didn't want the hassles of
maintaining user lists, sending updates and notices, etc.
There has recently been a proposal in this forum that you write
your own raytracer to use instead of DKB. Perhaps I can make that
prospect a little bit easier. Suppose we take DKB and use it as a
base for a completely new system (the name "Renderdog" has
been tossed around, but I'm not fond of that one <g>). I would
like to propose the name "Software Taskforce on Animation and
Rendering" or STAR. I would imagine that there would be
several packages developed such as:
STAR Light - the raytracer
STAR Guider - an animation system
STAR Maker - a user interface for StarLight
If you decide to do this, I would like to place a few rules on the
packages (or at least those developed from DKB):
- they will remain freely distributable
- support and maintenance of this new product will be undertaken
by the STAR team (including but not limited to myself)
- the programs will remain as portable as possible
What do you think of this proposal?
David Buck
More on how POV-Ray came to its name.
**************************************************************
from Chris Young, to whom I asked if POV's name was related
to the title of a sci-fi book I had just found on a flea market.
**************************************************************
Varley is one of my favorite authors and I've owned that book
long before POV-Ray existed. POV-Ray was originally going to be
called Starlight or StarLite or something similar but somebody
else, I don't know who, said we'd get in trademark trouble over
some existing product. Drew Wells was team leader and he picked
Persistence of Vision based on the properties of the human visual
system. I also felt there was a double meaning in that POV-Ray
was the continuation (or persistance) of David K. Buck's DKB-Trace.
I warned Drew about Varley's book but book titles aren't as messy
as product names. Note also that Public Broadcasting System has
a documentary series called POV but that stands for Point Of View
which is the filmmaking term for hand-held camera, cinema-verite
style used in many documentaries.
I wanted to take our team name from the Fractint Stone Soup Group
and call us the Crystal Soup Group but I got voted down.
Chris Young, POV-Team Coordinator
************************************************************** from unknown source ************************************************************** After the recent thread on the starting time of POV-Ray I did a search and found this post to this very news group from David Buck himself. The message places the birth of the POV-Ray project to be in May of 1991. A very historic event! I hope I'm not stepping on toes by re-posting it :-) Harold Sun, 19 Feb 1995 19:14:44 GMT (STEERPIKE) says: >I had always presumed that Persistance of Vision was a pun on >the name of Salvador Dali's painting "The Persistance of >Memory". Is this right, and if not, how did POV-Ray come to > have such a poetic name? :) The POV-Ray project started in May 1991 when I first proposed the idea to a group of people on CompuServe. They liked my DKBTrace raytracer but didn't like the fact that I was too slow adding new features to it. They were going to re-write a raytracer from scratch, but I suggested that after version 2.12 of DKBTrace, they could take the code as is and develop it from there into a new raytracer. The first name was STAR - an acronym for something or other. Then someone in the group came up with "Persistance of Vision". We liked it because of its reference to Dali (I believe the painting was actually called Persistance of Vision - am I mistaken?). Moreover, it seemed to symbolize the team who "Persisted" to achieve their "Vision". The third reference was to the phychological effect that seeing an image flashed on a screen causes you to retain that image in short term memory. Thus, your memory was a representation of reality but not really reality. They all seemed to fit together to make a nice name. Early on, we were abbreviating the name to PVRay, but we were concerned about a commercial product called PV-Wave. We agreed to change the abbreviation to POV-Ray and standardize on the spelling. >David Buck
The version history as it was included in PV-Ray 0.5 BETA. Notice the name changes...
Persistence of Vision Raytracer Version History
-------------------------------------------------
PV-Ray was originally DKBTrace Ver. 2.12 written by David Buck. He
donated the rights to his source code so the PV-Team could enhance
this raytracer as a group project similar to Fractint. The source
code for PV-Ray will always be freely distributable subject to the
restrictions in the header files. Thanks David, for your generous
gift!
Version 0.02 BETA Release 7/29/91 (as STAR-Light)
----------------------------------
First version is still basically DKBTrace 2.12 with a few new
features.
- Materials mapping added by Drew Wells.(see matmap.dat)
- ONION & LEOPARD textures added by Scott Taylor.
- Time to trace display added by Bill Pulver.
- Grayscale display (+g) for IBM-PC's added by Scott Taylor.
- Small wood texture bug fixed to create true cylinders.
- Verbose now displays more info including file being traced.
- Option +vO added to enable old-style terse verbose.
- Texture.c broken into smaller modules.
- PAINTED1, 2, & 3 added for developers.
- BUMPY1, 2, & 3 added for developers.
PvRay Version 0.5 BETA Release 9/07/91
----------------------------------
Many more changes this time around, including...
- Many enhancements from Alexander Enzmann
- Bezier bicubic subpatches
- Polynomial surfaces
- New mapping types (sphere, etc.)
- Sturmian sequences
- Clipping shapes
- (have I forgotten anything??)
- Lots of hard work and enhancements by Aaron Collins
- Height fields by Doug Muir
- Bump Mapping by Doug Muir and Drew Wells
- Interpolation by Girish T. Hagan adapted for mapping by Drew Wells
- # and ; are now ignored.
- case_sensitive keywords and commandline option added by Drew Wells
> case_sensitive_yes -- All words checked for exact case.
Keywords must be in upper case.
(*Old DKB Style*)
> case_sensitive_no -- Case is ignored for all words.
> case_sensitive_opt -- DEFAULT - All words checked for exact
case except keywords. Keywords will be
accepted in upper and/or lower case.
> command line -- /ty = yes, /tn = no, /to = opt
- cnvdat.c to convert old dat files included with pvsrc.
- C++ style commenting - // ignore to end of line.
and /* ignore between braces */ nesting not allowed.
- New default style verbose trace info (+v1)
- Old-new style verbose (+v0)
- Verbose trace info outputs to stderr so that stats can be
redirected to file.
- New stats display outputs to stdout for better redirection.
- New lighting routines by David Buck.
- The declared colors Red, Green, and Blue in colors.dat are now
CRed, CBlue, CGreen.
- The declared quadric Sphere in shapes.dat is now QSphere.
- Textures.dat has been cleaned up and commented.
POV-Ray scenes are described in a special text language called a scene description language. You will type commands into a plain text file and POV-Ray will read it to create the image. The process of running POV-Ray is a little different on each platform or operating system. You should read the platform-specific documentation as suggested earlier in this introduction. It will tell you how to command POV-Ray to turn your text scene description into an image. You should try rendering several sample images before attempting to create your own.
Once you know how to run POV-Ray on your computer and your operating system, you can proceed with the tutorial which follows. The tutorial explains how to describe the scene using the POV-Ray language.
Throughout the tutorial and reference sections, a consistent notation is used to mark keywords of the scene description language, command line switches, INI file keywords and file names.
For example:
Scene description language keywords and command-line switches:
sphere, 4.0 * sin(45.0)+W640 +H480Syntax, optional syntax, multiple syntax, and zero or more syntax items allowed respectively:
SYNTAX_ITEM[SYNTAX_ITEM]SYNTAX_ITEM...[SYNTAX_ITEM...]A float value or expression, and a vector value or expression:
Value_1<Value_1>Choices are represented by a vertical bar between syntax items:
ITEM1 | ITEM2 | ITEM3Certain lists and arrays also require square braces as part of the language rather than the language description:
[ ITEM ]New in version 3.8 these additional annotations appear throughout the documentation:
vX.y.z of the version number and it's short form vX.y currently v3.8.0 and
v3.8 respectivelyNote: POV-Ray is available as a command-line program on some platforms and as a GUI on others. Some of these platforms use folders to store files while others use directories. Some separate the folders and sub-folders with a slash character (/), back-slash character (\), or others. We have tried to make this documentation as generic as possible but sometimes we have to refer to folders, files, options etc., and rather than try to represent all possible combinations
we sometimes simplify the documentation by referring to a hypothetical 'standard installation' of POV-Ray upon a Microsoft Windows computer.
Here are some additional assumptions to be found in the documentation:
c:\Program Files\POV-Ray\vX.y and include/scene files in My Documents\POV-Ray\vX.y.
If we say 'include files are stored in the include directory', we mean the directory called 'include' located immediately within the folder which was used for documents, in the above case, it would be My Documents\POV-Ray\vX.y\include. We assume you can translate that to something like /usr/local/share/povray/vX.y/include for Linux or whatever is appropriate for your platform, operating system and personal installation.