2.4.6 Rendering speed Will POV-Ray render faster with a 3D card?

"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 cannot calculate typical features of raytracing as reflections etc. The algorithms used in 3D-cards have nothing to do with raytracing.

This means that you cannot 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. 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 its 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 does not 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 is 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 is 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 its 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: CSG speed

"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 is 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 }
{ #declare Ind=0;
    sphere { z*Ind,2 pigment { rgbt .9 } }
    #declare Ind=Ind+1;

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 is 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 }
{ 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 is rather easy to automatically calculate a proper bounding box for a given object, POV-Ray does this and thus you do not 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:

{ 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 is 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 =
{ 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;

This took 51 seconds to render. Commenting out the 'bounded_by' line increased the rendering time to 231 seconds (4.5 times slower). Does POV-Ray support 3DNow?

No, and most likely never will.

There are several good reasons for this:

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.