Radiosity
Home Up UV Mapping Patterns Meshes Radiosity Photons Misc. Changes Media

 

Overview

One part of POV that gets a lot of complaints is its radiosity.  But when it is used correctly, you can usually produce some very nice images.  Unfortunately, there are a few bugs and limitations to the implementation of radiosity in the official release of POV-Ray 3.1.

First, I guess I should say that, as the POV-Ray manual points out, POV-Ray does not use "real" radiosity.  True radiosity renderers convert the entire scene to polygons, and then compute a lighting solution by approximating a solution to a huge set of linear equations.

POV's solution to radiosity is sometimes known as monte-carlo ray-tracing.  When an eye ray hits an object and POV wants to know how much indirect light is hitting the surface, it shoots out a bunch of random rays into the scene and "gathers" light from the other objects.

Obviously, it would be very bad to do this for every intersection.  One assumption that can generally be made about indirect diffuse light is that it doesn't change very quickly.  So a good approximation is to shoot lots of rays from a small percentage (usually between 1 and 5%) of the intersections and then interpolate between those values.

Changes

1. Radiosity is orthogonal to the ambient component of a surface.

In Warp's radiosity tutorial, his first rule is, "Choose your ambient light carefully."  Warp's explanation demonstrates how, in the official POV 3.1, the brightness of radiosity is greatly affected by ambient_light settings.

So what does orthogonal mean?  That just means that the two features are independent and affect each-other in well-defined and expected ways.  This is not the case of the official release of POV-Ray 3.1.

The brightness of radiosity in UVPov is based on two things:  1) the amount of light "gathered"; and 2) the 'diffuse' property of the surface finish.

An object can have both radiosity and an ambient term.  However, I suggest that if you use radiosity in a scene, you either set ambient_light to 0 in global_settings, or use ambient 0 in each object's finish.  This lighting model is much more realistic, and POV will not try to adjust the overall brightness of the radiosity to match the ambient level specified by the user.

To use exaggerated radiosity, increase the 'brightness' in the radiosity section of global_settings, instead of turning up ambient_light.

2. nearest_count is a minimum, not a maximum.

First, in order to get good interpolation, you should get a bunch of points and interpolate those.  POV-Ray allows you to specify a "nearest_count" which, according to the documentation, is the "maximum number of old ambient values blended together".   Unfortunately, this means that sometimes you might end up blending only one value.   Averaging one value with itself can lead to a bad approximation.

Therefore, in UVPov, use nearest_count to specify the minimum number of old values blended together.  The total number blended will vary depending on error_bound.   All previous values that fit within the specified error_bound will be used in the average.

3a. distance_maximum is automatically computed.
3b. Radiosity works with any sized rooms.

I always thought the explanation of distance_maximum in the documentation was difficult to understand.  When looking in the code, I noticed that if you don't specify a distance_maximum, POV will estimate based on the distance from the camera to the first intersection.  I extended this concept and compute distance_maximum for every intersection automatically based on the distance from the camera.  It's worked wonderfully in all of my tests.  If you specify a distance_maximum, it will be ignored.

Warp's second rule in his radiosity tutorial is, "Don't make your room too big."  The reason that any sized rooms will work is because of this auto-computation of distance_maximim as well as a big bug fix relating to error_bound and the first radiosity pass.  Together, these work to remove much of the splotchiness that plagued radiosity in the past.

4. Radiosity recursion_limit is not limited to 2.

You can specify any recursion_limit that you wish (after about 5 or 6, it gets pointless, though... well, except for maze-like scenes).

5. Radiosity is computed on reflected and refracted/transmitted rays.

If you have a clear object, you'll get radiosity on the other side.  If you have a mirror, the reflected image will show radiosity.

6. Miscellaneous changes & bug fixes

You can specify an adc_bailout for radiosity rays.  Use adc_bailout = 0.01 / brightest_ambient_object for good results.

Fixed a bug relating to error_bound and samples stored during the first radiosity pass.

So, what are good settings for radiosity now?

This code works for most scenes:

#declare high_quality=no; // or yes
#if(high_quality)
  // High Quality - slow rendering
  ini_option "+QR"
  ini_option "Preview_Start_Size=8"
  ini_option "Preview_End_Size=4"
  
  radiosity{
    count 80             // CHANGE range from 20 to 150
    nearest_count 5      // CHANGE range from 3 to 10
    error_bound 1        // CHANGE - range from 1 to 3 - should correspond with Preview_End_Size
                         //   1 : preview_end_size = 4
                         //   3 : preview_end_size = 8
                         //   use preview_start_size = 16 (or 8 for high quality)
                         // you can go lower than 1, but then you probably will want to set
                         // preview_end_size to 2, which is really slow
    recursion_limit 4    // CHANGE
    
    low_error_factor .5  // leave this
    gray_threshold 0.0   // leave this
    minimum_reuse 0.015  // leave this
    brightness 1         // leave this
    
    max_sample 2         // CHANGE - this should be the same as the brightest object
    adc_bailout 0.01/2   // CHANGE - use adc_bailout = 0.01 / brightest_ambient_object
  }
#else
  // Medium Quality - works for most scenes
  ini_option "+QR"
  ini_option "Preview_Start_Size=16"
  ini_option "Preview_End_Size=8"
  
  radiosity{
    count 35             // CHANGE range from 20 to 150
    nearest_count 5      // CHANGE range from 3 to 10
    error_bound 2.25     // CHANGE - range from 1 to 3 - should correspond with Preview_End_Size
                         //   1 : preview_end_size = 4
                         //   3 : preview_end_size = 8
                         //   use preview_start_size = 16
                         // you can go lower than 1, but then you probably will want to set
                         // preview_end_size to 2, which is really slow
    recursion_limit 3    // CHANGE
    
    low_error_factor .5  // leave this
    gray_threshold 0.0   // leave this
    minimum_reuse 0.015  // leave this
    brightness 1         // leave this
    
    max_sample 2         // CHANGE - this should be the same as the brightest object
    adc_bailout 0.01/2   // CHANGE - use adc_bailout = 0.01 / brightest_ambient_object
  }
#end
      

Tips

You might notice that I use
  ini_option "Preview_Start_Size=8"
  ini_option "Preview_End_Size=4"
in the high-quality settings above.  Although this is not totally necessary, the default of start and end sizes both at 8 can cause splotchiness.  This is because extra samples are taken during the final rendering pass.  These newer samples can cause discontinuities in the radiosity in some scenes.  To decrease these artifacts, use a preview_end_size of 4 (or even 2 if you're really patient and picky).  This will cause the majority of the samples to be taken during the preview passes, and decrease the artifacts created during the final rendering pass.

If your scene uses ambient objects (especially small ambient objects) as light sources, you should probably use a higher count (around 100 is usually good, but for final renders probably 150).  For such scenes, an error_bound of 1.0 is usually good.  Higher causes too much error, but lower causes very slow rendering

The medium quality setting above is usually good for scenes with an average amount of diffuse illumination.  It renders fairly quickly and gives good results.

If things look splotchy in your scenes, increase the count and nearest_count.

 

This page was last updated October 25, 1999.

If you have any comments, please email me. My email address is Nathan at Kopp dot Com.