Knowledgebase:Miscellaneous

Topic 1

Will POV-Ray render faster if I buy the latest and fastest 3D videocard?

3D-cards are not designed for raytracing. They read polygon meshes and then scanline-render them. Scanline rendering has very little, if anything, to do with raytracing. 3D-cards can't calculate typical features of raytracing as reflections etc. The algorithms used in 3D-cards have nothing to do with raytracing.

This means that you can't use a 3D-card to speed up raytracing (even if you wanted to do so). Raytracing makes lots of float number calculations, and this is very FPU-consuming. You will get much more speed with a very fast FPU than a 3D-card.

What raytracing does is actually this: Calculate 1 pixel color and (optionally) put it on the screen. You will get little benefit from a fast videocard since only individual pixels are drawn on screen.

End of Topic: Go Back to the Table of Contents

Topic 2

How do I increase rendering speed?

This question can be divided into 2 questions:

1) What kind of hardware should I use to increase rendering speed?

(Answer by Ken Tyler)

The truth is the computations needed for rendering images are both complex and time consuming. This is one of the few program types that will actualy put your processors FPU to maximum use.

The things that will most improve speed, roughly in order of appearance, are:

1. CPU speed
2. FPU speed
3. Buss speed and level one and two memory cache - More is better. The faster the buss speed the faster the processor can swap out computations into it's level 2 cache and then read them back in. Buss speed therefore can have a large impact on both FPU and CPU calculation times. The more cache memory you have available the faster the operation becomes because the CPU doesn't have to rely on the much slower system RAM to store information in.
4. Memory amount, type, and speed. Faster and more is undoubtably better. Swapping out to the hard drive for increasing memory should be considered the last possible option for increasing system memory. The speed of the read/write to disk operation is like walking compared to driving a car. Here again is were buss speed is a major player in the fast rendering game.
5. Your OS and number of applications open. Closing open applications, including background items like system monitor, task scheduler, internet connections, windows volume control, and all other applications people have hiding in the background, can greatly increase rendering time by stealing cpu cycles. Open task manager and see what you have open and then close everything but the absolute necessities. Other multi-tasking OS's have other methods of determining open application and should be used accordingly.
6. And lastly your graphics card. This may seem unlikely to you but it's true. If you have a simple 16 bit graphics card your render times, compared to other systems with the same processor and memory but better CG cards, will be equal. No more no less. If you play a lot of games or watch a lot of mpeg movies on your system then by all means own a good CG card. If it's rendering and raytracing you want to do then invest in the best system speed and architecture your money can buy. The graphics cards with hardware acceleration are designed to support fast shading of simple polygons, prevalent in the gaming industry, and offer no support for the intense mathematical number crunching that goes on inside a rendering/raytracing program like Pov-Ray, Studio Max, and Lightwave. If your modeling program uses OpenGl shading methods then a CG card with support for OpenGL will help increase the speed of updating the shading window but when it comes time to render or raytrace the image it's support dissapears.

2) How should I make the POV-Ray scenes so that they will render as fast as possible?

These are some things which may speed up rendering without having to compromise the quality of the scene:

• Bounding boxes: Sometimes POV-Ray's automatic bounding is not perfect and considerable speed may be achieved by bounding objects by hand. These kind of objects are, for example, CSG differences and intersections, blobs and poly objects. See also: CSG speed
• Number of light sources: Each light source slows down the rendering. If your scene has many light sources, perhaps you should see if you can remove some of them without loosing much quality. Also replace point light sources with spotlights whenever possible. If a light source only lights a little part of the scene, a spotlight is better than a point light, since the point light is tested for each pixel while the spotlight is only tested when the pixel falls into the cone of the light.
• Area lights are very slow to calculate. If you have big media effects, they are extremely slow to calculate. Use as few area lights as possible. Always use adaptive area lights unless you need very high accuracy. Use spot area lights whenever possible.
• When you have many objects with the same texture, union them and apply the texture only once. This will decrease parse time and memory use. (Of course supposing that it doesn't matter if the texture doesn't move with the object anymore...)
• Things to do when doing fast test renderings:
  • Use the quality command line parameter (ie. +Q).
  • Comment out (or enclose with #if-statements) the majority of the light sources and leave only the necessary ones to see the scene.
  • Replace (with #if-statements) slow objects (such as superellipsoids) with faster ones (such as boxes).
  • Replace complex textures with simpler ones (like uniform colors). You can also use the quick_color statement to do this (it will work when you render with quality 5 or lower, ie. command line parameter +Q5).
  • Reflection and refraction: When an object reflects and refracts light (such as a glass object) it usually slows down the rendering considerably. For test renderings turning off one of them (reflection or refraction) or both should greatly increase rendering speed. For example, while testing glass objects it's usually enough to test the refraction only and add the reflection only to the final rendering. (The problem with both reflecting and refracting objects is that the rays will bounce inside the object until max_trace_level is reached, and this is very slow.)
  • If you have reflection/refraction and a very high max_trace_level, try setting the adc_bailout value to something bigger than the default 1/256.

End of Topic: Go Back to the Table of Contents

Topic 3

How do the different kinds of CSG objects compare in speed? How can I speed them up?

There is a lot of misinformation about CSG speed out there. A very common allegation is that merge is always slower than union. This statement is not true. Merge is sometimes slower than union, but in some cases it's even faster. For example, consider the following code:

global_settings { max_trace_level 40 }
camera { location -z*8 look_at 0 angle 35 }
light_source { <100,100,-100> 1 }
merge
{ #declare Ind=0;
  #while(Ind<20)
    sphere { z*Ind,2 pigment { rgbt .9 } }
    #declare Ind=Ind+1;
  #end
}

There are 20 semitransparent merged spheres there. A test render took 64 seconds. Substituting merge with union took 352 seconds to render (5.5 times longer). The difference in speed is very notable.

So why is merge so much faster than union in this case? Well, the answer is probably that the number of visible surfaces play a very important role in the rendering speed. When the spheres are unioned there are 18 inner surfaces, while when merged, those inner surfaces are gone. POV-Ray has to calculate lighting and shading for each one of those surfaces and that makes it so slow. When the spheres are merged, there's no need to perform lighting and shading calculations for those 18 surfaces.

So is merge always faster than union? No. If you have completely non-transparent objects, then merge is slightly slower than union, and in that case you should always use union instead. It makes no sense using merge with non-transparent objects.

Another common allegation is difference is very slow; much slower than union. This can also be proven as a false statement. Consider the following example:

camera { location -z*12 look_at 0 angle 35 }
light_source { <100,100,-100> 1 }
difference
{ sphere { 0,2 }
  sphere { <-1,0,-1>,2 }
  sphere { <1,0,-1>,2 }
  pigment { rgb <1,0,0> }
}

This scene took 42 seconds to render, while substituting the difference with a union took 59 seconds (1.4 times longer).

The crucial thing here is the size of the surfaces on screen. The larger the size, the slower to render (because POV-Ray has to do more lighting and shading calculations).

But the second statement is much closer to the truth than the first one: differences are usually slow to render, specially when the member objects of the difference are very much bigger than the resulting CSG object. This is because POV-Ray's automatic bounding is not perfect. A few words about bounding:

Suppose you have hundreds of objects (like spheres or whatever) forming a bigger CSG object, but this object is rather small on screen (like a little house for example). It would be really slow to test ray-object intersection for each one of those objects for each pixel of the screen. This is speeded up by bounding the CSG object with a bounding shape (such as a box). Ray-object intersections are first tested for this bounding box, and it is tested for the objects inside the box only if it hits the box. This speeds rendering considerably since the tests are performed only in the area of the screen where the CSG object is located and nowhere else.

Since it's rather easy to automatically calculate a proper bounding box for a given object, POV-Ray does this and thus you don't have to do it by yourself.

But this automatic bounding is not perfect. There are situations where a perfect automatic bounding is very hard to calculate. One situation is the difference and the intersection CSG operations. POV-Ray does what it can, but sometimes it makes a pretty poor job. This can be specially seen when the resulting CSG object is very small compared to the CSG member objects. For example:

intersection
{ sphere { <-1000,0,0>,1001 }
  sphere { <1000,0,0>,1001 }
}

(This is the same as making a difference with the second sphere inversed)

In this example the member objects extend from <-2001,-1001,-1001> to <2001,1001,1001> although the resulting CSG object is a pretty small lens-shaped object which is only 2 units wide in the x direction and perhaps 10 or 20 or something wide in the y and z directions. As you can see, it's very difficult to calculate the actual dimensions of the object (but not impossible).

In this type of cases POV-Ray makes a huge bounding box which is useless. You should bound this kind of objects by hand (specially when the it has lots of member objects). This can be done with the bounded_by keyword.

Here is an example:

camera { location -z*80 look_at 0 angle 35 }
light_source { <100,200,-150> 1 }
#declare test =
difference
{ union
  { cylinder {<-2, -20, 0>, <-2, 20, 0>, 1}
    cylinder {<2, -20, 0>, <2, 20, 0>, 1}
  }
  box {<-10, 1, -10>, <10, 30, 10>}
  box {<-10, -1, -10>, <10, -30, 10>}
  pigment {rgb <1, .5, .5>}
  bounded_by { box {<-3.1, -1.1, -1.1>, <3.1, 1.1, 1.1>} }
}
 
#declare copy = 0;
#while (copy < 40)
  object {test translate -20*x translate copy*x}
  #declare copy = copy + 3;
#end

This took 51 seconds to render. Commenting out the bounded_by line increased the rendering time to 231 seconds (4.5 times slower).

End of Topic: Go Back to the Table of Contents

Topic 4

Does POV-Ray support 3DNow for faster rendering?

No, and most likely never will.

There are several good reasons for this:

• 3DNow uses single precision numbers while POV-Ray needs (yes, it needs) double precision numbers. Single precision is not enough (this has been tested in practice). (To better understand the difference between single and double precision numbers, imagine that you could represent values between 0 and 1000 with single precision numbers. With double precision numbers you don't get a scale from 0 to 2000 (as one might think), but from 0 to 1000000. The difference is enormous and single precision is not precise enough for what POV-Ray does.)
• Adding support for 3DNow (or any other CPU-specific feature) to POV-Ray would make it platform-dependant and not portable. Of course one could make a separate binary for AMD supporting 3DNow, but there are only two ways of doing this:
  1. Compiling POV-Ray with a compiler which automatically can make 3DNow code from C. As far as I know, no such compiler exists which converts double precision math used in POV-Ray to single precision math needed by 3DNow. I don't event know if there's any compiler that supports 3DNow at all.
  2. Changing the source code by hand in order to use 3DNow instructions. This is a whole lot of work (specially because you'll probably have to use inline assembler). The source code of POV-Ray is not very small. Would it be worth the efforts?

Note: There are a few things in POV-Ray that use single precision math (such as color handling). This is one field where some optimization might be possible without degrading the image quality.

End of Topic: Go Back to the Table of Contents

Topic 5

I would like to suggest some new features for the program. Who should I talk to?

This is best discussed on the POV-Ray news groups (news.povray.org) in both the general news group and the windows news group. The POV-team does skim through the message posted there and occasionaly impliment ideas that have been posted by users.

You may also contact any of the POV-Ray T.A.G. members with suggestions, comments, or ideas for improvements to POV-Ray. To learn more about the POV-Ray T.A.G. and their contact information go here: POV-TAG.

End of Topic: Go Back to the Table of Contents

Topic 6

When I render a height field I get lots of warning messages Illegal grid value in dda_traversal(). How can I correct that?

(Answer by Jerry Anning)

Basically, you have a ray going between the cracks of the height field due to an arithmetic accuracy problem. Sometimes it does no harm. Sometimes you get black dot or line artifacts. I know of no successful patch so far. I also know no completely reliable workaround. The best bet is to slightly joggle the camera position and/or angle.

End of Topic: Go Back to the Table of Contents

Topic 7

How can I get rid of the beep after POV-Ray has calculated the image?

Usually using the -P command-line option should help (POV-Ray will not pause after it has calculated the image). If you are using the windows version of POV-Ray, you can try Render -> On Completion -> Remove [v] in front of Beep.

End of Topic: Go Back to the Table of Contents

Topic 8

Are there any POV-Ray viruses out there? Can one be done?

At the time of writing this documentation, no known viruses or trojans made with the POV-Ray Scene Description Language (SDL) are known to exist.

Due to the properties of the POV-Ray SDL, writing a working virus (that is, a piece of code which spreads, without the user knowing, by copying itself to non-infected files) is very difficult, if not impossible to do. The main obstacle in making a POV-Ray virus is that there's no way for the SDL code to reside in memory, infecting files when it sees them; another problem is that there's no way to get file listings in the POV-Ray SDL, so the code can't infect other .pov files at parse time.

However, trojans (i.e. a malicious piece of code which attempts to harm the system, but won't infect other files) are much more likely. It is possible with the POV-Ray SDL to open a file and write practically anything to it. This can be used to cause severe damage to an unprotected file system.

Note, however, that in POV-Ray 3.5 the concept of I/O restrictions was introduced in order to protect the user from these kinds of malicious scripts. Setting the I/O restrictions properly will prevent the SDL from being able to open files for writing (and optionally even for reading). You should check that your copy of POV-Ray has these restrictions properly set, especially if you render files not made by you. Note, however, that not all versions of POV-Ray for different platforms may have these restrictions implemented. Consult the section 1 of the POV-Ray documentation for more details about the I/O restrictions.

Regardless of this, it's always a good idea to run only scripts which you have received from trusted sources. This is particularly true if you are using a version of POV-Ray older than 3.5.

The POV-Ray community consists mostly of benevolent people and it is generally safe to try POV-Ray scripts made by them. However, it is often better to be safe than to be sorry.

End of Topic: Go Back to the Table of Contents

Topic 9

I'm getting a "error in Help file - contact your vendor" error.

This is a known problem which happens to some people (although not all) and not easy to fix. The following is a tip from the povray.org page:

Note: If, after installing POV-Ray for Windows - when attempting to
read the manual - you get a message about an error in the help file,
please find and delete the file POVRAY31.GID in the <installdir>\help
folder, where <installdir> is where you chose to install POV-Ray
for Windows (default C:\Program Files\POV-Ray for Windows v3.1\). This
file will probably be hidden (it is created by Microsoft's windows
help that way), so unless you have told Windows to show hidden files,
you won't see it. In that case, you'll need to alter your folder
options to show hidden files. If you don't know how to do this, just
delete the entire HELP directory and re-install POVWIN on top of the
old install.

This is an article by Rob Rippengale giving more tips:

Been using POV-Ray for some time now, but just got
into the newsgroups, and cannot see a better solution
to a problem I have been having, so I offer my own
workaround for the mysterious "error in Help
file - contact your vendor" situation.

If you don't know what I am talking about you can
happily ignore the rest of this post.

I am running the latest POV-Ray for Windows
Version 3.1g.msvc.win32 (Pentium II optimized).

I got tired of re-installing and finally discovered that the
GID file associated with the helpfile seems to somehow
get corrupted.

Remove the GID file and it wll be recreated the next time
you access the help file, but there is a twist - you have to
also reboot before you try to use Help again. Don't ask
me why. It's dark in there. Anyway I added some lines to my
autoexec.bat file to clean away that GID file every time I boot.

I seem to get the error much less often, and when I do get
it, I just reboot and autoexec.bat cleans up. Put the following
lines in your autoexec.bat file without the leading quote used
here. Of course, you should also edit the path to reflect your
own installion directory.

"IF NOT EXIST F:\POVRAY\HELP\POVRAY31.GID GOTO AFTERPOV
"ATTRIB -H F:\POVRAY\HELP\POVRAY31.GID
"DEL F:\POVRAY\HELP\POVRAY31.GID
":AFTERPOV

Note the leading colon on that last line. It marks a GOTO destination.
and should be the first character on that line.

In case you can't guess, the "IF NOT EXIST" test avoids the error
message that would happen if you try to remove the file when it isn't
there (the file is only recreated when the help file is accessed), and
the "ATTRIB" line makes the GID file "unhidden" so the "DEL"
command can find it.

Pretty simple, and it works, but I still have to reboot when I get the
annoying "error in help file" message. It's a pain, but not so bad
as re-installing POV-Ray.

If a more permanent solution has been found and I have just not read
enough newsgroup material, please enlighten me.

Thanks,
Rstudio (aka Probity, aka Rob Rippengale)

End of Topic: Go Back to the Table of Contents

Topic 10

Does POV-Ray for Unix have a GUI like in Windows?

No.

POV-Ray has always been a command-line utility. Even the core code of POV-Ray for Windows is exactly the same as the generic command-line POV-Ray. The graphical interfaces of the Windows and Mac versions of POV-Ray are exclusive to them (and non-portable). They are much like separate add-ons.

There's no official GUI done for the Unix version of POV-Ray. Some third-parties have tried to make some GUIs for it (and you might find them from the POV-Ray Links page) but it seems to be a general phenomenon that Unix people like to use just the command-line version with a proper and powerful text editor (such as Emacs).

I'm sorry but there's no advice right now here about how to configure Emacs in order to smoothly handle POV-Ray file editing, but I might write a page about that some day, when I have the time.

If you are interested in how a properly set system might look like:

End of Section: Go Back to the Table of Contents