|
OverviewOne 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. Changes1. 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. 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 TipsYou might notice that I use 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. |