Section 7.7.2
Background

A background color can be specified if desired. Any ray that doesn't hit an object will be colored with this color. The default background is black. The syntax for background is:

background { colour <COLOUR> }

Section 7.7.3
Fog

Fog is defined by the following statement:

fog { fog_type FOG_TYPE distance DISTANCE colour <COLOUR> [ turbulence <TURBULENCE> ] [ turb_depth TURB_DEPTH ] [ omega OMEGA ] [ lambda LAMBDA ] [ octaves OCTAVES ] [ fog_offset FOG_OFFSET ] [ fog_alt FOG_ALT ] [ up <FOG_UP> ] [ TRANSFORMATION ] }

The optional up vector specifies a direction pointing up, generally the same as the camera's up vector. All calculations done during the ground fog evaluation are done relative to this up vector, i. e. the actual heights are calculated along this vector.

The up vector can also be modified using any of the known transformations described in "Transformations". Though it may not be a good idea to scale the up vector - the results are hardly predictable - it is quite useful to be able to rotate it. You should also note that translations do not affect the up direction (and thus don't affect the fog).

Currently there are two fog types, constant fog and ground fog. The constant fog has a constant density everywhere while the ground fog has a constant density for all heights below a given point on the up axis and thins out along this axis. The height below which the fog has constant density is specified by the fog_offset keyword. The fog_alt keyword is used to specify the rate by which the fog fades away. At an altitude of fog_offset+fog_alt the fog has a density of 25%. The density of the fog at a given height y is calculated by the formula:

           /
           |                  1
           | -------------------------------------, y > fog_alt
           |  (1 + (y - fog_offset) / fog_alt) ^2
density = -|
           |
           |                  1,                   y <= fog_alt
           |
           \

The total density along a ray is calculated by integrating from the height of the starting point to the height of the end point.

Two constants are defined for easy use of the fog types in the file const.inc:

// FOG TYPE CONSTANTS #declare Constant_Fog = 1 #declare Ground_Fog = 2

The color of a pixel with an intersection depth d is calculated by

C_pixel = exp(-d/D) * C_object + (1-exp(-d/D)) * C_fog

where D is the fog distance. At depth 0 the final color is the object's color. If the intersection depth equals the fog distance the final color consists of 64% of the object's color and 36% of the fog's color.

The fog color that is given by the color keyword has three purposes. First it defines the color to be used in blending the fog and the background. Second it is used to specify a translucency threshold. By using a transmittance larger than zero one can make sure that at least that amount of light will be seen through the fog. With a transmittance of 0.3 you'll see at least 30% of the background. Third it can be used to make a filtering fog. With a filter value larger than zero the amount of background light given by the filer value will be multiplied with the fog color. A filter value of 0.7 will lead to a fog that filters 70% of the background light and leaves 30% unfiltered.

Fogs may be layered. That is, you can apply as many layers of fog as you like. Generally this is most effective if each layer is a ground fog of different color, altitude and with different turbulence values. To use multiple layers of fogs, just add all of them to the scene.

You may optionally stir up the fog by adding turbulence. The turbulence keyword may be followed by a float or vector to specify an amount of turbulence to be used. The omega, lambda and octaves turbulence parameters may also be specified. See section "Pattern Modifiers" for details on all of these turbulence parameters.

Additionally the fog turbulence may be scaled along the direction of the viewing ray using the turb_depth amount. Typical values are from 0.0 to 1.0 or more. The default value is 0.5 but any float value may be used.

You should note that the fog feature will not work if the camera is inside a non-hollow object (see section "Empty and Solid Objects" for a detailed explanation).


Section 7.7.4
Sky Sphere

The sky sphere is used create a realistic sky background without the need of an additional sphere to simulate the sky. Its syntax is:

sky_sphere { pigment { PIGMENT1 } pigment { PIGMENT2 } pigment { PIGMENT3 } ... [ TRANSFORMATION ] }

The sky sphere can contain several pigment layers with the last pigment being at the top, i. e. it is evaluated last, and the first pigment being at the bottom, i. e. it is evaluated first. If the upper layers contain filtering and/or transmitting components lower layers will shine through. If not lower layers will be invisible.

The sky sphere is calculated by using the direction vector as the parameter for evaluating the pigment patterns. This leads to results independent from the view point which pretty good models a real sky where the distance to the sky is much larger than the distances between visible objects.

If you want to add a nice color blend to your background you can easily do this by using the following example.

sky_sphere { pigment { gradient y color_map { [ 0.5 color CornflowerBlue ] [ 1.0 color MidnightBlue ] } scale 2 translate -1 } }

This gives a soft blend from CornflowerBlue at the horizon to MidnightBlue at the zenith. The scale and translate operations are used to map the direction vector values, which lie in the range from <-1, -1, -1> to <1, 1, 1>, onto the range from <0, 0, 0> to <1, 1, 1>. Thus a repetition of the color blend is avoided for parts of the sky below the horizon.

In order to easily animate a sky sphere you can transform it using the known transformations described in "Transformations". Though it may not be a good idea to translate or scale a sky sphere - the results are hardly predictable - it is quite useful to be able to rotate it. In an animation the color blendings of the sky can be made to follow the rising sun for example.

You should note that only one sky sphere can be used in any scene. It also will not work as you might expect if you use camera types like the orthographic or cylindrical camera. The orthographic camera uses parallel rays and thus you'll only see a very small part of the sky sphere (you'll get one color skies in most cases). Reflections in curved surface will work though, e. g. you will clearly see the sky in a mirrored ball.


Section 7.7.5
Rainbow

Rainbows are implemented using fog-like, circular arcs. Their syntax is:

rainbow { direction <DIR> angle ANGLE width WIDTH distance DISTANCE color_map { COLOUR_MAP } [ jitter JITTER ] [ up <UP> ] [ arc_angle ARC_ANGLE ] [ falloff_angle FALLOFF_ANGLE ] }

The direction vector determines the direction of the (virtual) light that is responsible for the rainbow. Ideally this is an infinitely far away light source like the sun that emits parallel light rays. The position and size of the rainbow are specified by the angle and width keywords. To understand how they work you should first know how the rainbow is calculated.

For each ray the angle between the rainbow's direction vector and the ray's direction vector is calculated. If this angle lies in the interval from ANGLE-WIDTH/2 to ANGLE+WIDTH/2 the rainbow is hit by the ray. The color is then determined by using the angle as an index into the rainbow's colormap. After the color has been determined it will be mixed with the background color in the same way like it is done for fogs.

Thus the angle and width parameters determine the angles under which the rainbow will be seen. The optional jitter keyword can be used to add random noise to the index. This adds some irregularity to the rainbow that makes it look more realistic.

The distance keyword is the same like the one used with fogs. Since the rainbow is a fog-like effect it's possible that the rainbow is noticeable on objects. If this effect is not wanted it can be avoided by using a large distance value. By default a sufficiently large value is used to make sure that this effect does not occur.

The color_map keyword is used to assign a color map that will be mapped onto the rainbow. To be able to create realistic rainbows it is important to know that the index into the color map increases with the angle between the ray's and rainbow's direction vector. The index is zero at the innermost ring and one at the outermost ring. The filter and transmittance values of the colors in the color map have the same meaning as the ones used with fogs (see section "Fog").

The default rainbow is a 360 degree arc that looks like a circle. This is no problem as long as you have a ground plane that hides the lower, non-visible part of the rainbow. If this isn't the case or if you don't want the full arc to be visible you can use the optional keywords up, arc_angle and falloff_angle to specify a smaller arc.

The arc_angle keyword determines the size of the arc in degrees (from 0 to 360 degrees). A value smaller than 360 degrees results in an arc that abruptly vanishes. Since this doesn't look nice you can use the falloff_angle keyword to specify a region in which the rainbow will smoothly blend into the background making it vanish softly. The falloff angle has to be smaller or equal to the arc angle.

The up keyword determines were the zero angle position is. By changing this vector you can rotate the rainbow about its direction. You should note that the arc goes from -ARC_ANGLE/2 to +ARC_ANGLE/2. The soft regions go from -ARC_ANGLE/2 to -FALLOFF_ANGLE/2 and from +FALLOFF_ANGLE/2 to +ARC_ANGLE/2.

The following example generates a 120 degrees rainbow arc that has a falloff region of 30 degrees at both ends:

rainbow { direction <0, 0, 1> angle 42.5 width 5 distance 1000 jitter 0.01 color_map { Rainbow_Color_Map } up <0, 1, 0> arc_angle 240 falloff_angle 60 }

It is possible to use any number of rainbows and to combine them with other atmospheric effects.


Section 7.8
Global Settings

The global_settings statement is a catch-all statement that gathers together a number of global parameters. The statement may appear anywhere in a scene as long as its not inside any other statement. You may have multiple global_settings statements in a scene. Whatever values were specified in the last global_settings statement override any previous settings. Regardless of where you specify the statement, the feature applies to the entire scene.

Note that some items which were language directives in previous versions of POV-Ray have been moved inside the global_settings statement so that it is more obvious to the user that their effect is global. The old syntax is permitted but generates a warning.

global_settings { adc_bailout FLOAT ambient_light COLOR assumed_gamma FLOAT hf_gray_16 BOOLEAN irid_wavelength COLOR max_intersections INTEGER max_trace_level INTEGER number_of_waves INTEGER radiosity { RADIOSITY_ITEMS... } }

Each item is optional and may appear in and order. If an item is specified more than once, the last setting overrides previous values. Details on each item are given in the following sections.


Section 7.8.1
ADC_Bailout

In scenes with many reflective and transparent surfaces, POV-Ray can get bogged down tracing multiple reflections and refractions that contribute very little to the color of a particular pixel. The program uses a system called Adaptive Depth Control (ADC) to stop computing additional reflected or refracted rays when their contribution is insignificant.

You may use the global setting adc_bailout keyword followed by float value to specify the point at which a ray's contribution is considered insignificant.

global_settings { adc_bailout FLOAT }

The default value is 1/255, or approximately 0.0039, since a change smaller than that could not be visible in a 24 bit image. Generally this setting is perfectly adequate and should be left alone. Setting adc_bailout to 0 will disable ADC, relying completely on max_trace_level to set an upper limit on the number of rays spawned.

See section "Max_Trace_Level" for details on how ADC and max_trace_level interact.


Section 7.8.2
Ambient Light

Ambient light is used to simulate the effect of inter-diffuse reflection that is responsible for lighting areas that partially or completely lie in shadow. POV-Ray provides an ambient light source to let you easily change the brightness of the ambient lighting without changing every ambient value in all finish statements. It also lets you create interesting effects by changing the color of the ambient light source. The syntax is:

global_settings { ambient_light COLOR }

The default is a white ambient light source set at rgb < 1,1,1>. The actual ambient used is:

AMBIENT = FINISH_AMBIENT * GLOBAL_AMBIENT

See section "Ambient" for more information.


Section 7.8.3
Assumed_Gamma

Many people may have noticed at one time or another that some images are too bright or dim when displayed on their system. As a rule, Macintosh users find that images created on a PC are too bright, while PC users find that images created on a Macintosh are too dim.

The assumed_gamma global setting works in conjunction with the Display_Gamma INI setting (see section "Display Hardware Settings") to ensure that scene files render the same way across the wide variety of hardware platforms that POV-Ray is used on. The assumed gamma setting is used in a scene file by adding

global_settings { assumed_gamma FLOAT }

where the assumed gamma value is the correction factor to be applied before the pixels are displayed and/or saved to disk. For scenes created in older versions of POV-Ray, the assumed gamma value will be the same as the display gamma value of the system the scene was created on. For PC systems, the most common display gamma is 2.2, while for scenes created on Macintosh systems should use a scene gamma of 1.8. Another gamma value that sometimes occurs in scenes is 1.0.

Scenes that do not have an assumed_gamma global setting will not have any gamma correction performed on them, for compatibility reasons. If you are creating new scenes or rendering old scenes, it is strongly recommended that you put in an appropriate assumed_gamma global setting. For new scenes, you should use an assumed gamma value of 1.0 as this models how light appears in the real world more realistically.

The following sections explain more thoroughly what gamma is and why it is important.


Section 7.8.3.1
Monitor Gamma

The differences in how images are displayed is a result of how a computer actually takes an image and displays it on the monitor. In the process of rendering an image and displaying it on the screen, several gamma values are important, including the POV scene file or image file gamma and the monitor gamma.

Most image files generated by POV-Ray store numbers in the range from 0 to 255 for each of the red, green and blue components of a pixel. These numbers represent the intensity of each color component, with 0 being black and 255 being the brightest color (either 100% red, 100% green or 100% blue). When an image is displayed, the graphics card converts each color component into a voltage which is sent to the monitor to light up the red, green and blue phosphors on the screen. The voltage is usually proportional to the value of each color component.

Gamma becomes important when displaying intensities that aren't the maximum or minimum possible values. For example, 127 should represent 50% of the maximum intensity for pixels stored as numbers between 0 and 255. On systems that don't do gamma correction, 127 will be converted to 50% of the maximum voltage, but because of the way the phosphors and the electron guns in a monitor work, this may be only 22% of the maximum color intensity on a monitor with a gamma of 2.2. To display a pixel which is 50% of the maximum intensity on this monitor, we would need a voltage of 73% of the maximum voltage, which translates to storing a pixel value of 186.

The relationship between the input pixel value and the displayed intensity can be approximated by an exponential function

obright = ibright ^ display_gamma

where obright is the output intensity and ibright is the input pixel intensity. Both values are in the range from 0 to 1 (0% to 100%). Most monitors have a fixed gamma value in the range from 1.8 to 2.6. Using the above formula with display_gamma values greater than 1 means that the output brightness will be less than the input brightness. In order to have the output and input brightness be equal an overall system gamma of 1 is needed. To do this, we need to gamma correct the input brightness in the same manner as above but with a gamma value of 1/display_gamma before it is sent to the monitor. To correct for a display gamma of 2.2, this pre-monitor gamma correction uses a gamma value of 1.0/2.2 or approximately 0.45.

How the pre-monitor gamma correction is done depends on what hardware and software is being used. On Macintosh systems, the operating system has taken it upon itself to insulate applications from the differences in display hardware. Through a gamma control panel the user may be able to set the actual monitor gamma and MacOS will then convert all pixel intensities so that the monitor will appear to have the specified gamma value. On Silicon Graphics machines, the display adapter has built-in gamma correction calibrated to the monitor which gives the desired overall gamma (the default is 1.7). Unfortunately, on PCs and most UNIX systems, it is up to the application to do any gamma correction needed.


Next Section
Table Of Contents