Appendix F
Tips and Hints

Appendix F.1
Scene Design Tips

There are a number of excellent shareware CAD style modelers available on the DOS platform now that will create POV-Ray scene files. The online systems mentioned elsewhere in this document are the best places to find these.

Hundreds of special-purpose utilities have been written for POV-Ray: data conversion programs, object generators, shell-style launchers and more. It would not be possible to list them all here, but again, the online systems listed will carry most of them. Most, following the POV-Ray spirit, are freeware or inexpensive shareware.

Some extremely elaborate scenes have been designed by drafting on graph paper. Raytracer Mike Miller recommends graph paper with a grid divided in tenths, allowing natural decimal conversions.

Start out with a boilerplate scene file, such as a copy of basicvue.pov, and edit that. In general, place your objects near and around the origin with the camera in the negative z-direction, looking at the origin. Naturally, you will break from this rule many times, but when starting out, keep things simple.

For basic, boring, but dependable lighting, place a light source at or near the position of the camera. Objects will look flat, but at least you will see them. From there, you can move it slowly into a better position.

Appendix F.2
Scene Debugging Tips

To see a quick version of your picture, render it very small. With fewer pixels to calculate the ray-tracer can finish more quickly. -W160 -H100 is a good size.

Use the +Q quality switch when appropriate.

If there is a particular area of your picture that you need to see in high resolution, perhaps with anti-aliasing on (perhaps a fine-grained wood texture), use the +SC, +EC, +SR and +ER switches to isolate a window.

If your image contains a lot of inter-reflections, set max_trace_level to a low value such as 1 or 2. Don't forget to put it back up when you're finished!

Turn off any unnecessary lights. Comment out extended light keywords when not needed for debugging. Again, don't forget to put them back in before you retire for the night with a final render running!

If you've run into an error that is eluding you by visual examination it's time to start bracketing your file. Use the block comment characters /* ... */ to disable most of your scene and try to render again. If you no longer get an error the problem naturally lies somewhere within the disabled area. Slow and methodical testing like this will eventually get you to a point where you will either be able to spot the bug, or go quietly insane. Maybe both.

If you seem to have lost yourself or an object (a common experience for beginners) there are a few tricks that can sometimes help:

1)Move your camera way back to provide a long range view. This may not help with very small objects which tend to be less visible at a distance, but it's a nice trick to keep up your sleeve.
2)Try setting the ambient value to 1.0 if you suspect that the object may simply be hidden from the lights. This will make it self-illuminated and you'll be able to see it even with no lights in the scene.
3)Replace the object with a larger, more obvious "stand-in" object like a large sphere or box. Be sure that all the same transformations are applied to this new shape so that it ends up in the same spot.

Appendix F.3
Animation Tips

When animating objects with solid textures, the textures must move with the object, i. e. apply the same rotate or translate functions to the texture as to the object itself. This is now done automatically if the transformations are placed after the texture block like the following example

shape { ... pigment { ... } scale < ... > }

will scale the shape and pigment texture by the same amount.

shape { ... scale < ... > pigment { ... } }

will scale the shape but not the pigment.

Constants can be declared for most of the data types in the program including floats and vectors. By writing these to include files you can easily separate the parameters for an animation into a separate file.

Some examples of declared constants would be:

#declare Y_Rotation = 5.0 * clock #declare ObjectRotation = <0, Y_Rotation, 0> #declare MySphere = sphere { <0, 0, 0>, 1.1234 }

Other examples can be found scattered throughout the sample scene files.

A tip for MS-Dos users: Get ahold of dta.exe (Dave's Targa Animator) for creating .FLI/.FLC animations. aaplay.exe and play.exe are common viewers for this type of file.

When moving the camera in an animation (or placing one in a still image, for that matter) avoid placing the camera directly over the origin. This will cause very strange errors. Instead, move off center slightly and avoid hovering directly over the scene.

Appendix F.4
Texture Tips

Wood is designed like a log with growth rings aligned along the z-axis. Generally these will look best when scaled down by about a tenth (to a unit-sized object). Start out with rather small value for the turbulence too (around 0.05 is good for starters).

The marble texture is designed around a pigment primitive that is much like an x-gradient. When turbulated, the effect is different when viewed from the side or from the end. Try rotating it by 90 degrees on the y-axis to see the difference.

You cannot get specular highlights on a totally black object. Try using a very dark gray, say Gray10 or Gray15 (from, instead.

Appendix F.5
Height Field Tips

Try using POV-Ray itself to create images for height fields: camera { location <0, 0, -2> } plane { z, 0 finish { ambient 1 } // needs no light sources pigment { bozo } // or whatever. Experiment. }

That's all you'll need to create a .tga file that can then be used as a height field in another image!

Appendix F.6
Converting "Handedness"

If you are importing images from other systems you may find that the shapes are backwards (left-to-right inverted) and no rotation can make them correct.

Often, all you have to do is negate the terms in the right vector of the camera to flip the camera left-to-right (use the right-hand coordinate system). Some programs seem to interpret the coordinate systems differently, however, so you may need to experiment with other camera transformations if you want the y- and z-vectors to work as POV-Ray does.

Appendix G
Frequently Asked Questions

This is a collection of frequently asked questions and their answers taken directly from messages posted in the POVRAY Forum on Compuserve and the newsgroup.

This version of the FAQ is heavily biased towards the CompuServe user of the IBM PC version of POV-Ray. Hopefully later revisions will remove some of this bias, but at present time, that is the largest audience.

Appendix G.1
General Questions

Appendix G.2
POV-Ray Options Questions

Q: How can I set mosaic preview to go from 8*straight to final render without going to 4*and then 2*first? A: Use the +SPn or Preview_Start_Size option to set the starting resolution and the +EPn or Preview_End_Size option to set the ending resolution. With +SP8 and +EP8 it will go from 8*8 down to 8*8 (just one pass) then immediately drop into the final pass at 1*1.

Q: Should the +MB switch be used in very small scenes, i. e. with a low number of objects. A: That depends on the number of objects and their type. Normally it doesn't hurt to always use the bounding box hierarchy (+MB0). If you have just one or two objects it may be better to not use automatic bounding.

Q: Does the +MB switch affect the quality of the image? A: No. It only affects the speed of the intersection tests.

Q: How do I avoid that the options screen scrolls off when error messages are generated? A: Use the +P switch. Everytime POV-Ray is interrupted or the tracing finishes you can use the cursor keys to scroll-back the options text.

Appendix G.3
Include File Questions

Q: In the file textures.v2, the glass textures are commented out. Why? A: The old glass textures are duplicated in The old texture names didn't fit in with the new naming scheme. Glass is now T_Glass1, Glass2 is now T_Glass2 and Glass3 is now T_Glass3. While you can easily un-comment the old names you're strongly encouraged to use the newer naming scheme.

Appendix G.4
Object Questions

Appendix G.4.1
Height Field Questions

Q: I have a lowly 8 meg of RAM on my computer and I ran out of memory trying to use a 1024x768 pot file and a gif of the same resolution as height fields (two different scenes). Is it my memory thats low or is that resolution crazy? A: Smoothed heightfields will consume a lot more memory (about three times as much) as one that isn't smoothed. Since smoothing really isn't neccessary at those resolutions don't smooth (if you're smoothing).

Q: I want to use the same image for an image map and a height-field (which gives some meaningful relationship between the height and colors). Does that only work when using a gif or bmp format? I couldn't get the pot file to map (format not supported). A: pot files are not supported as image maps. Their purpose to POV-Ray is as heightfields. That doesn't prevent you from making a matching gif in fractint that uses the continuous potential coloring that you used for the 16 bit pot file, and using that as the image map. Remember that both image maps and height fields are initialized in a 1*1(*1) area, with the lower-left of the image situated at the origin. The image map is initiated in the x-y-plane while the height field is in the x-z plane. Thus you'll have to rotate the image map by 90 degrees around the x-axis (use rotate x*90) to get the image map to line up.

Next Section
Table Of Contents