|
| ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Shader | Light Source
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Synopsis |
Simulates illumination by the sky hemisphere.
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Location | lishpro | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Description |
A light source to account for the illumination from the sky
(but not the direct contribution due to the sun itself).
This shader can produce some subtle effects including accounting
for the fact that some areas of the sky are brighter than others,
even on overcast days. However some users may find that the
simpler and quicker "simple sky" shader will be an
acceptable alternative.
The "sky" shader models the sky as a hemisphere with an infinite radius, positioned above the current scene. The orientation of the sky is specified by the "north" and "up" shader arguments; the latter defines the horizon for every point being illuminated. The position of the sun is specified via the "sun altitude" and "sun azimuth" arguments. Whilst the actual contribution of the sun is not modelled by the shader, its location will determine the appearance of the sky hemisphere, whose contribution is modelled by the shader. The "sun altitude" is the angle, in degrees, of the sun above the horizon. The "sun azimuth" is the angle, in degrees, of the sun around the horizon. An azimuth of 0 means that the sun is in the North (defined by the "north" shader parameter); an azimuth of 90 puts the sun in the East, and an azimuth of 270 puts the sun in the West.
The "type" argument specifies how the illumination is distributed over the sky. Six standard models are provided; three are from the Commission Internationale de L'Éclairage (CIE), and three are from the compatible North American body, the Illuminating Engineering Society of North America (IESNA).
Name
CIE_OVERCAST
The CIE standard skies are described in CIE publication CIE 110-1994 and the IESNA standard skies are described in the IESNA Lighting Handbook. Essentially, the `clear' skies will model the sky as if it were a sunny, cloudless, day (the brightest part of the sky surrounds the sun location) whilst the `overcast' skies model the sky on a cloudy day (where the brightest part of the sky is straight up). An `intermediate' sky models a sky that is neither clear nor cloudy. The more complex the sky illumination (`clear' is most complex, `overcast' is least complex) the more expensive (compute-power) the light source shader. That said, the differences should only be noticable when adaptive sampling is being utilised. To specify the brightness of the light emitted by the sky, use the "intensity" argument. This gives the luminance at the sky's zenith (in units of cd/m^2, as long as the "intensity units" argument remains equal to its default value of LI_INTEN_UNITS_NIT). If the "intensity units" argument is set to LI_INTEN_UNITS_EMPIRICAL, then the zenith `brightness' is still defined by the "intensity" argument, but the units are arbitrary. If "intensity" is set to 0, then a standard model (based on sky type and sun position) will be used to calculate the zenith luminance, automatically. If the "intensity" is set to some positive value, then the user may note that overcast skies do not vary in brightness, as the sun position is varied. This is because such skies have a distribution function that does not rely on the sun position. This distribution is scaled by the zenith luminance to find out how bright any one part of the sky is, but if the zenith luminance has been supplied by the user, ignoring the sun position, the varying "sun altitude" and "sun azimuth" will not be productive. For clear and intermediate skies, the distribution function does care about sun position, so images will vary with sun position, even when the "intensity" is positive. There are two ways to specify the colour of the sky. Either the "colour" argument can be used (which is simply an LtColour value), or the "colour temperature" argument can be used.
Further details of what is meant
by a colour temperature can be found in the LightWorks
`Lighting' manual. The value itself is given as an LtFloat, representing
a temperature value in Kelvin. A number of standard values are
defined in licolour.h, three of which are commonly used to
describe the colour of the sky:
Name
LI_D55
If the "colour" argument is left at its default value of (1.0, 1.0, 1.0) (white) then it will be ignored and the "colour temperature" argument is used to decide the sky's colour. Similarly, if "colour temperature" is set to 0.0, only the "colour" argument is used when evaluating the sky colour. If valid values are provided for both "colour" and "colour temperature", the final colour of the sky will be calculated by filtering the "colour" with the LtColour derived from the "colour temperature". Once the sky type, orientation, colour and brightness have been established, it remains only to detail how shadows should be handled, and how the sky should be sampled, to ensure an optimum speed/quality trade-off. The "shadows" parameter specifies whether or not the sky will cast shadows on the scene. Due to the complexity of sky light illumination, shadow maps cannot be used with the "sky" light source shader; ray casting will be used, if "shadows" is TRUE. If transparent objects make up part of the scene, then the { "shadow transparency"} parameter can be utilized to ensure that appropriate shadows result. A value of 0 means that the light will not cast transparent shadows. The default "shadow transparency" value is LI_TRANS_SHADOW_GLOBAL, which means that the shader will look at the value of LI_CONTROL_TRANSPARENT_SHADOW when deciding whether to cast transparent shadows. Three other "shadow transparency" values are possible:
The sampling of the sky is controlled via the "min lod", "max lod", "error bound" and "noise factor" parameters. A unit hemisphere, orientated by the shader's "up" and "north" parameters, is constructed around each point of interest and is split into (spherical) triangles, each of which represents a portion of the sky, visible from the point of interest. These triangles are sampled to establish not only how the point is illuminated, but also the error associated with accepting that level of sampling. The "min lod" parameter specifies the minimum amount of work the shader should perform, for every point being illuminated. The "max lod" parameter specifies the maximum amount of work the shader should perform, for any point being illuminated. Both parameters accept any floating-point non-negative value; values greater than 1.0 are acceptable, but it is difficult to envisage a scenario in which such intense sampling would be necessary, or desirable. If "max lod" is less than "min lod", the shader will swap their values. If { "max lod"} is equal to, or only slightly larger than, "min lod", then adaptive sampling will not be possible; the resultant image will be generated relatively rapidly, but may suffer from artefacts in regions where the minimal sampling of the sky hemisphere was insufficient to capture to the true irradiance across the surfaces being illuminated. When "max lod" is sufficiently bigger than "min lod", the shader will perform adaptive sampling, once its initial sampling is complete; the "error bound" parameter then dictates the accuracy of the solution. An error bound of 0.1 means that the maximum error associated with the illumination of a particular point of interest is less than 10 energy associated with the illumination arriving at the point. Values of "error bound" much smaller than 0.1 are not unusual; the default value, of 0.5, discourages adaptive sampling. If the "noise factor" parameter is greater than 0.0, then noise will be added to the sampling directions. This can be very useful for replacing (spacial) aliasing artefacts, with (less visually objectionable) noise. Consider the following case: horizontal ground, with a vertical pipe sticking out of the ground, illuminated by a clear sky. We decide to take a small number of initial samples ( "min lod" = 0.2) but to refine heavily where we feel we are in the shadow of the pipe ( "max lod" = 0.9, "error bound" = 0.1). Now, when one of our initial ( "min lod") sample rays hits the pipe, we detect the shadow, and refine accordingly. Unfortunately, a nearby point might miss the pipe with all of its "min lod" rays, so the first point has laboured to establish exactly how it is shadowed, but its neighbour has quickly decided that it is fully lit. This can lead to artefacts in the resulting shadow. Possible solutions include:
A similar, but different, case is a room illuminated by a sky through a skylight in the ceiling. If we start with the same settings that we tried for the pipe case, above, we will find that all of our (few) initial samples will miss the skylight, most of the time. This will result in some parts of the scene appearing lit, and other parts appearing (erroneously) dark. In such cases the user is encouraged to use an "area sky" light source shader, instead. However, if the opening(s) are too complex for that, then options (1) and (3) from the list, above, could be opted for. Note how the two example cases differ: In the first case, we are looking for hard-to-find shadows, at what would otherwise be a completely lit point of interest; in the second case we are looking for hard-to-find chinks of daylight, at what would otherwise be a completely dark point of interest. One final reminder: the "sky" shader only simulates the illumination from the sky hemisphere, and does not account for the direct contribution of the sun, as might be seen on a clear day.
Previous page alphabetically (simplewood) | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Copyright © 1990-2004, 2005 LightWork Design Limited. All rights reserved | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||