Tutorial: POV-Ray (and great discussion)

[CJ Swartz]

Since Chuck was nice enough to tell us how to run a POV-ray scene, I copied a POV scene into Photoshop and added Sunny, the sleeping cat. Added a shadow and a bit of lighting, then figured that was enough -- at least for now. I don't understand POV-Ray, and I can't create a POV scene, but it's fun just to use the program to run the scenes included with it.

P.S.
DannyR (moderator) changed the thread title after VisualEyes (Truman) responded to my pleading for help and wrote a tutorial to help us get started in using the POV-Ray program. (The program contains a tutorial, but it isn't "user friendly" in my opinion.)

Thanks so many times, Truman!

Folks -- look below to Truman's 3rd post with the tutorial.

[VisualEyes]

C.J. - fantastic composite! Very nicely done. The kitty looks really comfy.

POVRay can be very intimidating, I know, but if you take some of the simple scene description files and analyze them, I'm sure you'll see that there are really just a few necessities that are needed to create a basic scene:

1. lights
2. a camera
3. something to point the camera at

Everything else is just bells and whistles.

Attached is a raytraced take on mini-challenge 34.

[VisualEyes]

And here is the .pov description. Take away all the gobbledy-gook and you basically have a camera, 3 light sources, a disc, a couple of donuts and cylinders, some lathes, and a fancy-schmancy b-spline sphere-sweep.

If you look at the Insert menu on POVRay, you'll see almost everything you can use in a scene, along with an explaination of what the different parameters are. Real handy, even if you sorta know what you're doing already.

Truman

[CJ Swartz]

Truman, thanks for the nice comment on my composite, and thanks even more for the POV data. Hmmm, it still looks very intimidating, but maybe... I'm glad that there are some scenes already written up that I can use and look at to see if I can figure it out.

Makes me even more respectful of those of you who can use it to create new environments -- my hat's off to you (if I wore a hat)

Your rendition of the image is just mind-blowing -- beautiful, strange, intriguing.

[VisualEyes]

Quick POV-Ray Intro Tutorial

C.J. - here's my attempt at a quick tutorial thrown together over left-overs and soda tonight. I hope this might be of some benefit to you and others trying to get over the initial hurdle of approaching POV-Ray. Please excuse any typos or other strangeness - I'm bouncing back and forth between training Dragon NaturallySpeaking and good old fashioned typing.

POV-Ray

OK, so you were browsing through some of the forums here on RP and you happened to run across a few threads discussing an odd program called POV-Ray. This got you curious, so you went to www.povray.org and downloaded the 8MB Windows setup file and installed it. Now what?

Of course, first, it might be really nice to know what POV-Ray is. POV-Ray stands for the Persistence of Vision Raytracer. Hmmm, OK, so now what’s a raytracer you ask? Simply put, a raytracer is a program that acts like a virtual camera. It reads a description of a scene and renders (draws) it in vivid three-dimensional reality. You’ve seen raytracing examples practically every time you turn on the TV (think flying 6:00 News logo or even the Terminator II blob guy).

Every raytraced scene is composed of at least three basic components: a camera, a light, and an object to be rendered. In order to describe these components, we need to tell the raytracer some important facts including, but not limited to, the location, the size and the texture of the component. POV-Ray needs to know where the camera is, where the light source is, what color the light source is, what and where the object to be rendered is, and the color of the object.

Coordinates
Before we can describe the location of an object, however, we need to understand the 3D coordinate system of the POV-Ray world. Remember high-school algebra and number lines? A coordinate system describes the location of a point on a number line. A number line consists of an origin, usually 0 (zero), with points emanating out left and right from there. Going to the right you get positive values, while going to the left gives you negative values.

<- - - - - - - - - - - - - - >
-2 -1 0 1 2 3 4 5 6 7

Now let’s imagine you have three number lines. One points left and right, like the one above, while another points up and down with the positive numbers going upwards, and the last number line points front to back (in and out) with the positive numbers going towards the front. The left-right line is the x-axis, the up-down line is the y-axis, and the in-out line is the z-axis. This is POV’s 3D coordinate system, typically called a left-handed coordinate system. If you hold your left hand out and make a fist with your thumb sticking out (like you’re hitchhiking) and point your thumb along an axis, your fingers naturally curl in the positive rotation of that axis.

So how do we describe a location? POV-Ray understands 3D locations as a set of xyz values, bracketed by less-than and greater-than signs (<x,y,z>). For example, a point at the origin would be <0,0,0>. A point 5 units to the right, 3 units up, and 2 units forward would be <5,3,2>. A point 10 units in back of that would be <5, 3, -8> (2 minus 10 = -8).

Syntax
Now that we understand the coordinate system, we can begin describing our objects. Every POV Ray object has a specific syntax. The syntax describes the unique characteristics of an object. If you bring up the POV Ray help file you will see explanations of the syntax of all the language components.

Let's look at the syntax for a camera object. To describe a camera we need to know where it is located, which way is it tilted, what is its depth of field, what is the anticipated aspect ratio of the computer screen on which the image will be rendered, and what 3D coordinate is the camera looking at. The syntax therefore is like this:
camera {
location <x, y, z>
direction <x, y, z>
up <x, y, z>
right <x, y, z>
look_at <x, y, z>
}

Location positions the camera in 3D space. For example, location <0, 0, -100> means that the camera is 100 units behind the origin.

Direction is a vector that indicates the direction the camera is pointing. The magnitude of this vector impacts the depth-of-field of the camera. Larger values give a narrower field of view. Typically, a z-value of 1-2 is appropriate (i.e., <0,0,2>).

Up tells the raytracer the direction to the sky. Normally, a y-value of 1 is appropriate. Playing around with this vector will tilt the camera.

Right indicates where a vector coming out the right side of the camera is pointing and also adjusts the horizontal magnification. An x-value of 1.3333 (4/3) is appropriate for most PC monitors that have an aspect ratio of 4:3.

Look_at tells the camera what to look at (duh). I won’t go into how this is different from “direction”, but suffice it to say that it is.

So, for a sample camera description, describing a camera located 10 units to the right, 15 units up, and 120 units back, looking at an object at the origin, we would say:

camera {
location <10, 15, -120>
direction <0,0, 2>
up <0,1,0>
right <1.3333, 0,0>
look_at <0,0,0>
}

Lights
OK, so now we need a light source. The light_source syntax requires a position description and a color description. Similar to position vectors, colors are described by three values: red, green, and blue (RGB) values. These values range from 0 to 1. The color description for black would be “color rgb <0,0,0>” and the description for white would be “color rgb <1,1,1>”. Absolute red: “color rgb <1,0,0>”. Absolute green: “color rgb <0,1,0>”. 50% gray: “color rgb <0.5, 0.5, 0.5>”. So now our light_source description might go something like this:

light_source {
<100, 400, -1000>
color rgb <1, 1, 1>
}

Objects
Finally, we need an object to render. The simplest primitive is a sphere, so let’s try that. The syntax for a sphere is:

sphere {
<x,y,z> radius
}

So, a sphere located at the origin, with a radius of 10 would be:

sphere {
<0,0,0> 10
}

In order for an object to be visible, it needs a texture. A texture describes what an object looks like. The simplest texture description is a pigment (what color is it?). The texture syntax is:

pigment {
color rgb <r,g,b>
}

The texture statement is placed within the description of the object, so our sphere description might look like this:

sphere {
<0,0,0> 10
pigment {
color rgb <.5, .2, .34>
}
}

Put it all together
And there you have it, the basic components of a POV scene: a camera, a light, and an object. Put them together:
camera {
location <10, 15, -120>
direction <0,0, 2>
up <0,1,0>
right <1.3333, 0,0>
look_at <0,0,0>
}
light_source {
<100, 400, -1000>
color rgb <1, 1, 1>
}
sphere {
<0,0,0> 10
pigment {
color rgb <.5, .2, .34>
}
}

Press alt-G and the next thing you know, you have your first raytraced image! Needless to say, there’s lots of room for improvement on this image, but that's where the fun of experimenting and learning comes in.

[DannyRaphael]

Great stuff, Truman!

Really appreciate you taking the time to put this mini-tutorial together.

Wunderful stuff...
~Danny~

[DJ Dubovsky]

Well, from what I can see of it you need a knowledge of Visual C++. It's definately intimidating to the max for someone like me. But I definatly like the results. It would be nice if they made it more user friendly.
DJ

[CJ Swartz]

Truman -- you ROCK!

Truman , the folks here work together to help each other on a daily basis, but explaining POV in clear terms is a fantastic offering even on this forum.

Thank You for providing us the keys to a new artistic vehicle -- it's waiting for anyone who wants to take a test drive -- bet I'm not going to be the only one...

[clare]

Cool

I've had not heard of this until today and thanks to your tutorial have a sphere and everything!! Thanks for the introduction to this program.

I tried a version of another render program a few years back but the thing was too much of a leap for my brain at the time and soon lost interest and went back to PS.

I am going to play now and see what I can create

Thanks again Truman

[jerry]

Truman,,Now I'm Mad..

I had been avoiding your program saying just too hard to try..Now your forcing me to go download it..

Thanks for the time you invested in this explanation..

Here I go, wish me luck.

Jerry

[Marlene DeGrood]

I might be missing something here, not uncommon for me, especially after a late Sat. night, but.....isn't this just a less user friendly type of Bryce program?

Marlene
www.thedigitalspectrum.com

[VisualEyes]

I shudder to make comparisons between Bryce and POV-Ray, mainly because they are two very different programs aimed at two very different audiences. But I’m gonna anyway:

Bryce
Bryce was designed from the beginning to be a commercial, albeit unconventional 3D product marketed to the low-end, non-professional graphic market with a few hundred bucks of discretionary income. Alone, Eric Wenger spent seven years developing Bryce which would later be licensed to a company called MetaCreations. Eric brought in his associate Kai Krause to design the user interface. Eric and Kai’s European backgrounds strongly influenced the interface, crossing over into other MetaCreation products such as Kai’s PowerTools, Carrara, etc. The key words to note in the previous sentence are “Eric and Kai’s.” Two people. Count em. Two.

POV-Ray
POV-Ray began life in 1986 as a port of a simple Amiga program that rendered an untextured sphere on a plane. The guy who executed the port, college student David K. Buck, was so impressed by the possibilities that he decided to create his own program to do something similar. With a solid mathematical/calculus background, David began his program’s feature-set with quadric surfaces such as spheres, cylinders, and planes and went on to add other cool stuff such as constructive solid geometry and extensive texturing options. The end product was a free, mid-1980’s DOS-based program written in C called DKBTrace. Because it was written in C and designed for portability, the program was easily distributed to other platforms including UNIX, the Mac, and the original Amiga.

To make a long story short, in 1991 David decided to give the program over to a group of enthusiastic Compuserve users who were eager to take the program further than any one man could alone. That group eventually renamed the program the Persistence of Vision Raytracer, and went on to became a world-wide association of contributing programmers, testers, artists and designers. I personally had much fun being one of the early testers/artists.

True to it’s roots, POV-Ray has always remained free, with open source code and a strong support base. While it never developed a graphic user interface itself, there are several third-party graphic modellers that fill that void (i.e., Moray: http://www.stmuc.com/moray/ ).

Back to comparing Bryce & POV-Ray
OK, what differences have we noted? (1) Cost: Bryce is a commercial program with an appropriate commercial price tag. POV-Ray is a non-commerical program with an extremely reasonable non-existent price tag. (2) Design input: Bryce, until Corel bought it, was the brain-child of one man, and it’s interface was the brain-child of another man. POV-Ray on the other hand has had hundreds of contributors over the years. Apparently, it is approachable to some large segment of the cyberworld. And while it has stuck to it’s text-based roots, that hasn’t stopped others from designing 3rd-party graphic modelers for POV-Ray.

Techy stuff
Finally, and most importantly to me at least, under the hood there is a very basic fundamental difference between POV-Ray and Bryce, 3D Studio, Lightwave, TrueSpace, and all the other popular 3D graphic rendering engines: polygons. Let me quote from the Bryce User Guide: “All 3D objects in Bryce 3D are built from multiple-sided (in Bryce, we use 4 sides) geometric surfaces, and are therefore inherently polygonal in nature.” POV-Ray, on the other hand, is a mathematical rendering engine and as such renders true primitives rather than polygons. What does this mean in English? It means that when you tell Bryce to render a sphere, you are actually telling it to render a collection of 4-sided polygons that connect to look something like a sphere. The more polygons you use, the smoother and more realistic the sphere looks. This is true of most 3D modelers, and they can get away with it because it often doesn’t take a whole of polygons to fool the human eye, and rendering tricks such as normalizing polygon faces make creased surfaces appear smoothly connected. POV-Ray however, as I said, renders true primitives. A sphere is a perfect sphere. This goes hand-in-hand with the mathematical versatility of POV-Ray. Because it is programmatically text-based, and because it renders mathematically perfect primitives, it naturally lends itself to the accurate modeling of everything from architecture to molecules.

Oh well
I could go on and on and probably meander even further beyond anyone’s real interest, but I won’t. I won’t deny that the initial learning curve of POV-Ray is high, but so is Photoshop’s. You didn’t just jump right in and understand histograms, levels, layers, contrast-masking, alpha channels, and the anisotropic diffuse filter right off the bat did you? No, you started out slow, learned how to do a few simple things and then proceeded to learn everything you needed to become the great Photoshop/retouching wizard that you are today. The same holds true for POV-Ray – you have to start slow and give it a chance, ugly interface and all. For what it’s worth, I’ve owned several commercial 3D modelers over the years, including Bryce, Carrara, and Hash AnimationMaster, and I continue to come back to POV-Ray because of its text-based interface. Once you get into the programmatic possibilities of the POV script language, you might find yourself actually having some incredible fun.

[VisualEyes]

POV-Ray Basics continued

POV-Ray Tutorial (continued)

Recap
Last time, if you recall, you learned how to make a very simple raytraced scene composed of a camera, a single light source, and a sphere. Some of you might have been really thrilled to render your first raytraced scene. Others of you probably found it pretty boring. I know I did. A single purple sphere? Geeez.

OK, so what’s missing? This time we’re going to take a closer look at textures. Textures are what make everything come to life, both on your monitor and in real life. When light is emitted from a light source, it travels in a straight line, hits a surface, and then bounces into our eyeballs. As it strikes a surface, the light reflects the qualities of that surface into our eyes, transmitting information such as color, opacity, and shading. Without light, we see nothing. Without textures, we see nothing different.

In our last discussion, we created a very simple texture statement specifying the color of the sphere:
pigment { color rgb <.5, .2, .34> }

You recall that this meant that the color is composed of RGB values amounting to .5 red, .2 green, and .34 blue where these RGB values range from 0 to 1. A color description of <0, 0, 0> would be black while a description of <1,1,1> would be white.

So why didn’t this sphere look very interesting? Because it was only textured by a color. For all you Photoshop experts, think about the Color blending mode. Have you ever painted on a Color layer and then looked at it by itself? Pretty worthless as an image, huh?

Texture statement components
To bring our sphere to life, we need to look at the basic components of the texture statement. Just like every scene needs a camera, a light source, and an object, almost every object’s texture needs at least two components: a pigment and a finish. The pigment statement defines a the coloration of the object, while the finish statement defines the look and feel of the object. Is it shiny? Is it matte? Is it transparent? Is it opaque? We structure the basic texture block like this:

texture {
pigment { color rgb <.5, .2, .34> }
finish {
…
}
}

Finish, ambient, and diffuse
Let’s take a look at what goes into a finish. In real life, light not only radiates from a light source, it also radiates from all objects such as walls, sidewalks, people, whatever. We call this sort of lighting, ambient lighting. Open your drapes and light probably floods into your home as it bounces off of your neighbors’ houses, the trees, the clouds, and the dog running across the street. Some direct rays of sunlight may streak into your window, but unless you’re outside, the vast majority of the light will probably be ambient.

POV tries to accomplish this type of natural lighting by providing the ambient statement. This statement specifies the minimum brightness of this object, regardless of a light source. Like the RGB values, this value ranges from 0 to 1. Zero means that there is absolutely no ambient lighting, while 1 means complete ambient lighting. Usually, a value of .1 to .3 is appropriate.

OK, so how do we specify the amount of lighting provided by a direct light source? That’s our diffuse statement. Diffuse specifies the amount of diffuse reflection. A simple rule of thumb (though not necessarily 100% of the time) is that ambient + diffuse should equal 1. Therefore our texture statement may look like this now:

texture {
pigment { color rgb <.5, .2, .34> }
finish {
ambient 0.3
diffuse 0.7
}
}

If you plug this into our previously defined sphere and render it, you’ll see a much more realistic sphere drawn.

What else can you define with the finish statement? Want to make the sphere shiny? Add some specular highlights:

finish {
ambient 0.3
diffuse 0.7
specular 0.6
roughness 0.001
}

Specularity is defined by an overall amount (0-1) and a surface roughness. Rough surfaces (values closer to 1) will create rough specular highlights, while smooth surfaces (values closer to 0) will create smaller, tighter specular highlights.

Want to make the sphere reflective? Add some reflection:

finish {
ambient 0.3
diffuse 0.7
specular 0.6
roughness 0.001
reflection 0.4
}

Reflection also ranges from 0 to 1. You won’t see the impact of this until you have something to reflect, so let’s change our camera angle and add another object to our scene:

camera {
location <10, 15, -120>
direction <0, 0, 2>
up <0,1,0>
right <1.3333, 0, 0>
look_at <10, 0, 0>
}
light_source {
<100, 400, -1000>
color rgb <1, 1, 1>
}
sphere {
<0,0,0> 10
texture {
pigment {
color rgb <.5, .2, .34>
}
finish {
ambient 0.3
diffuse 0.7
specular 0.6
roughness 0.001
reflection 0.6
}
}
}
box {
<10, -10, -10>, <30, 10, 10>
texture {
pigment {
color rgb <.3, .4, .1>
}
finish {
ambient 0.3
diffuse 0.7
}
}
}

The box definition specifies two points in space representing the diagonal ends of two of the box corners. In this case we position the box to the right of the sphere. Now when we press alt-G, we should see our purplish sphere reflecting a bit of the green box next to it.

Pigment
OK, we’ve talked a lot about the finish statement, now what about the pigment statement? Trust me, there’s tons of cool stuff you can do with it.

Want to make your object semi-transparent? Add a filter value to the RGB color statement like this: color rgb <r, g, b, f>. An f-value of 0 means no light filters through it, while an f-value of 1 means the object is totally transparent. The following is 50% transparent:
pigment { color rgbf <.3, .4, .1, .5> }

How about checkerboards:
pigment { checker color rgb <0,0,0>, color rgb <1,1,1> }

That’s just a light scratch on the surface. Pigments can be overlaid, mapped, transformed, and made to look like everything from wood to gaseous explosions. I don’t think I’ll go into any detail on that sort of stuff though.

My fingers are tired
Oh well, that’s probably more than enough for now. Have fun playing around with the texture statement, and please don’t be afraid to look at the POV-Ray documentation and experiment with other options!