Advanced Lighting documentation

Transcription

Lightworks Author
9.1
Advanced Lighting
Advanced Lighting
Master Doc
Title Page
Contents
First
Last
J
I
Page 1 of 70
Go Back
Part No: D207-800-1409
Search This Doc
July 10, 2014
Search All Docs
Full Screen
Copyright of Lightwork Design Ltd. 2014. All Rights Reserved.
Reproduction of any part of this document in any form may only be undertaken with the written
permission of Lightwork Design Ltd.
Lightwork Design Ltd. reserves the right to make changes in specifications at any time and without notice. The
information furnished by Lightwork Design Ltd. in this publication is believed to be accurate; however, no
responsibility is assumed for its use, nor for any infringement of patents or other rights of third parties resulting
from its use.
Lightworks, the Lightworks logo, LWA and LWA-Enabled are registered trademarks of Lightwork Design Ltd.
The LWA-Enabled logo, Interactive Image Regeneration, IIR, A-Cubed, Feature-Following Anti-Aliasing and
FFAA are all trademarks of Lightwork Design Ltd. All other trademarks, images and logos remain the property
of their respective owners.
Lightworks Author
9.1
Advanced Lighting
Credits
Master Doc
Title Page
Contents
Lightwork Design
Rutledge House
78 Clarkehouse Road
Sheffield
S10 2LJ
United Kingdom
Tel.
Fax
(0114) 266 8404
(0114) 266 1383
First
Last
J
I
Page 2 of 70
UK
+44 114 266 8404
+44 114 266 1383
International
Go Back
Search This Doc
Electronic mail:
[email protected]
World Wide Web:
(General)
(Support)
http://www.lightworkdesign.com
http://www.lightworkdesign.com/support/
Search All Docs
Full Screen
Contents
Lightworks Author
9.1
Advanced Lighting
I
Overview
5
1 Lightworks Advanced Lighting
1.1 Shaders provided by Lightworks Advanced Lighting . . . . . . . . . . . . . . . . . . . .
6
7
Contents
II
Programming Guide
10
2 Volumetric Shading
11
2.1 The scattering medium foreground shader . . . . . . . . . . . . . . . . . . . . . . . . . 11
3 Physically-based Lights
3.1 Shader arguments for physically-based lighting . . . . . . . . .
3.2 Units of length . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3 The sun light source shader . . . . . . . . . . . . . . . . . . . . .
3.3.1 Lighting interior spaces with sun and portal light sources
3.4 Goniometric light sources . . . . . . . . . . . . . . . . . . . . . .
3.4.1 The line goniometric light source shader . . . . . .
3.4.2 The area goniometric light source shader . . . . . .
3.5 Area light sources . . . . . . . . . . . . . . . . . . . . . . . . . .
3.6 Sky light source shaders . . . . . . . . . . . . . . . . . . . . . .
3.6.1 The sky light source shader . . . . . . . . . . . . . . . .
3.6.2 The area sky light source shader . . . . . . . . . . . . .
3.6.3 The simple sky light source shader . . . . . . . . . . .
3.7 Usage hints and tips for the sky light source shader . . . . . . .
4 Tone Mapping
4.1 Tone mapping and sub-images . . . . . . . . . . . . . .
4.2 Deferring tone mapping . . . . . . . . . . . . . . . . . .
4.3 Accelerating tone mapping . . . . . . . . . . . . . . . .
4.4 Tone Mapping Shaders . . . . . . . . . . . . . . . . . .
4.5 Example . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.6 White balancing using tone mapping . . . . . . . . . . .
4.6.1 What is white balance? . . . . . . . . . . . . . .
4.6.2 Performing white balancing in Lightworks . . . .
4.6.3 About colour spaces . . . . . . . . . . . . . . . .
4.6.4 API functions to convert between colour spaces
5 High Dynamic Range Images
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
15
16
20
22
24
24
28
30
31
34
34
37
39
40
.
.
.
.
.
.
.
.
.
.
45
46
46
47
48
50
51
52
52
53
55
57
Master Doc
Title Page
Contents
First
Last
J
I
Page 3 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
5.1 Where can HDRIs be obtained? . . . . . . . . .
5.2 Image based lighting (using HDRI) . . . . . . . .
5.2.1 Using HDR images as environments . . .
5.2.2 Using an HDR environment for reflections
5.2.3 Using an HDR environment for lighting .
5.3 Usage hints and tips for image based lighting . .
5.3.1 Troubleshooting . . . . . . . . . . . . . .
5.4 HDRIs as goniometric data . . . . . . . . . . . .
Index
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
58
59
59
60
60
61
65
67
68
Lightworks Author
9.1
Advanced Lighting
Contents
Master Doc
Title Page
Contents
First
Last
J
I
Page 4 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
Lightworks Author
9.1
Advanced Lighting
Part I
Overview
Master Doc
Title Page
Contents
First
Last
J
I
Page 5 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
Chapter 1
Lightworks Advanced Lighting
Lightworks Author
9.1
Advanced Lighting
Lightworks Advanced
Lighting
Lightworks Advanced Lighting builds on the lighting capabilities provided in the Foundation to
provide physically accurate lighting simulation, including:
Master Doc
Title Page
• Perceptually-based tone-mapping, allowing images which contain extremes of light and dark
to be rendered in a natural-looking way.
Contents
• Physically accurate light scattering for volumetric lighting and atmospheric effects.
First
Last
J
I
Page 6 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
• Lighting values can be specified using the real-world values for intensity (lumen, lux, candela,
etc.) and colour (colour temperature in Kelvin) which are normally used by architects and
lighting designers.
• White balance functionality to enable the colour cast of images produced under realistic lighting
conditions to be accounted for.
• API functions to allow the exact specification of colour spaces, allowing very accurate colour
reproduction throughout Lightworks.
Lightworks Author
9.1
• "sun" and "sky" light source shaders for accurate simulation of sunlight and daylight for
given time, location and atmospheric conditions.
Advanced Lighting
• "simple sky" light source shader provides a faster alternative to the "sky" light source and
is suitable for less complex situations.
• "area" light source shaders, defined by geometry and material.
• "goniometric" light sources to define accurate light emission distributions using manufacturers' data.
Lightworks Advanced
Lighting
Support for CIE, IESNA, CIBSE and EULUMDAT goniometric formats.
Additionally, users can provide their own emission distribution functions.
• High Dynamic Range Images (HDRIs) are supported via the following formats; OpenEXR (.exr)
and HDR (.hdr). Images stored in such formats can represent a much higher range of intensity
values than traditional image formats which are restricted to the dynamic range typically
displayable on a computer monitor. High Dynamic Range Images have several advantages;
they can be used as backgrounds in brightly lit scenes prior to tone mapping,
they provide a way to store images which have been rendered using physically based
realistic lighting values, without loss of information,
they can be used as environments (via the "environment" light shader) which illuminate
a scene (allowing digitally created objects to be rendered with lighting conditions exactly
matching some real world scene).
• "lit appearance" reflectance shader combines physically accurate dielectric-like scattering
with a user-defined glow. This gives the effect of a surface which is internally as well as externally
lit (such as a lampshade).
Master Doc
Title Page
Contents
First
Last
J
I
Page 7 of 70
Go Back
1.1.
Shaders provided by Lightworks Advanced Lighting
Search This Doc
The following shaders are provided:
Search All Docs
Full Screen
Lightworks Author
9.1
Advanced Lighting
Figure 1.1: An example of Image Based Lighting from an HDRI environment map. HDRI map courtesy
of Paul Debevec.
Light shaders in Lightworks Advanced Lighting
library
Name
Description
lishclas
"projector"
Projects a supplied image onto illuminated objects.
lishclas
"sun"
Light source designed to mimic sunlight.
lishpro
"area"
Area light source.
lishpro
"environment"
Light source which provides lighting effects from the current environment (by
treating the environment texture as a
light source). For best results a high dynamic range image should be used as
the environment texture.
lishpro
"goniometric"
Goniometric (industry standard light
emission data) light source.
lishpro
"simple sky"
Light source which provides a simple
approximation to a true skylight.
lishpro
"sky"
Light source which mimics skylight in an
accurate way.
lishpro
"area goniometric"
Goniometric emission from an area light
source.
lishpro
"area sky"
Skylight emission from an area light
source.
lishpro
"line goniometric"
Goniometric emission from a polyline
light source.
lishpro
"simple environment"
An alternative environment light source
which may in some cases be slightly
quicker than the "environment" light,
at the cost of reduced quality.
lishpro
"portal"
Parallel light from a distant source, coming through a window.
Lightworks Advanced
Lighting
Master Doc
Title Page
Contents
First
Last
J
I
Page 8 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
Reflectance shaders in Lightworks Advanced Lighting
library
Name
Description
lishclas
"lit appearance"
Physically accurate dielectric-like scattering, combined with a user-defined
glow. Gives the effect of a surface which
is internally as well as externally lit (such
as a lampshade).
lishpro
"radiosity stepped
Supports false colour renderings of rafalse"
diosity solutions or other high dymanic
range images.
Foreground shaders in Lightworks Advanced Lighting
library
Name
Description
lishpro
"scattering medium"
Simulation of
medium.
dense
Lightworks Author
9.1
Advanced Lighting
participating
Tone shaders in Lightworks Advanced Lighting
library
Name
Description
lishslte
"scale"
Simple, linear, tone mapping.
lishpro
"brighten up"
Quick and simple, "S" curve, tone mapping.
lishpro
"polynomial approxiAdvanced, piecewise polynomial, tone
mation"
mapping.
lishpro
"white balance"
Performs white balance operations to
remove colour casts from images created using realistic lighting.
Postprocess shaders in Lightworks Advanced Lighting
library
Name
Description
lishpost
"tone"
Generic post-process shader for tonemapping.
lishpost
"tone contrast
Post-process shader for "scale" tonescale"
mapping.
lishpost
"tone linear ceilPost-process shader for "polynomial
ing"
approximation" tone mapping.
Lightworks Advanced
Lighting
Master Doc
Title Page
Contents
First
Last
J
I
Page 9 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
Lightworks Author
9.1
Advanced Lighting
Part II
Programming Guide
Master Doc
Title Page
Contents
First
Last
J
I
Page 10 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
Chapter 2
Volumetric Shading
Lightworks Author
9.1
Advanced Lighting
Volumetric Shading
Volumetric shading allows effects such as the scattering of light, by fog or smoke, in a scene.
Lightworks includes two foreground shaders that enable rendering of these phenomena: "fog
light" and "scattering medium". The shaders utilize different models of the medium and
apply different rendering strategies, and thus have different areas of applicability.
The simplest and fastest is the "fog light" shader, which is provided as part of the Lightworks
Main Toolbox and can be used with "point" and "spot" light source shaders only. This shader is
based on the assumption that the light is scattered in an isotropic medium, illuminated by sources
which have a known light distribution, with an inverse square fall off function and without volume
shadows being taken into account. These conditions are quite restrictive, but if they are met then
the shader presents the `best value for computation time'.
Lightworks Advanced Lighting provides a more advanced shader; the "scattering medium"
foreground shader.
2.1.
The scattering medium foreground shader
This shader is also based on volume sampling, but the sampling scheme does not make any specific
assumptions about which (non-ambient) light sources are illuminating the volume, and is thus
applicable to all types of light source. The accuracy of the calculations can be explicitly controlled by
the definition of an allowed error. The shader applies randomised sampling so it does not produce
aliasing artifacts. The worst that can occur is the noisy appearance of scattered light, which is in
most cases more acceptable than crude aliasing and can even serve to produce sought-after artistic
effects. Extra sampling can always be employed to remove objectionable noise.
Master Doc
Title Page
Contents
First
Last
J
I
Page 11 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
Lightworks Author
9.1
Advanced Lighting
(a) point light
(b) spot light
Volumetric Shading
Figure 2.1: "scattering medium" with different light types
The functionality of the shader includes everything that may be needed to model light transfer in a
participating medium:
• Physically correct calculation of first-order light scattering for all non-ambient types of light
sources, including customised light shaders that may be written by licencees.
Master Doc
Title Page
• Choice of (anisotropic) phase functions for modelling the light scattering inside the medium .
• Light attenuation and attenuation-dependent light filtration by medium colour.
• Ambient factor to simulate secondary scattering effects.
Contents
First
Last
J
I
• Simulation of variable (non-homogeneous) medium density defined by a solid colour shader.
The usage of the shader is relatively simple. It is sufficient to create the shader, set it as the
foreground using LiForegroundSet and set the "scattering" parameter, of the light sources
that should participate, to TRUE. The properties of the medium are defined by default, but the
"medium density" parameter, which specifies the intensity of scattered light, and the "medium
ambient" parameter, which sets the overall veiling effect, are basic parameters that can be changed
to alter the default behaviour.
Optionally, a "density shader" may be set to any solid (not wrapped) colour shader, to create
the effect of a non-uniform (non-homogeneous) medium. Examples of shaders that can be used
are "blue marble" and "solid clouds". A shader that has been designed explicitly for this
purpose is the "turbulent" shader.
The accuracy of calculation may be controlled via the "error bound" parameter, which describes
the allowable relative error (in the range [0, 1]; 0.1 means 10 percent). The accuracy of initial sampling,
which is important to identify all areas of shadow, can be controlled by the "min lod" parameter.
The default accuracy settings, however, are sufficient for most applications, unless very fine shadow
Page 12 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
Lightworks Author
9.1
Advanced Lighting
(a) goniometric light
(b) solid clouds as density shader
Volumetric Shading
Figure 2.2: Further "scattering medium" example images
details are to be rendered. In the latter case, the "min lod" parameter will perhaps have to increase
and "error bound" to decrease.
The best visual results for this shader can be achieved using physically based (LI_FALL_OFF_ISL_NO_CLAMP) "fall off" for the scattering lights. With this setting, however, the dynamic
range of brightness produced by the renderer may be too big to be reproduced on your display
device. The problem may be easily solved by the application of a tone shader. The simple non-linear
tone mapping produced by "brighten up" tone shader is usually sufficient.
Master Doc
Title Page
Contents
The key points when using the "scattering medium" foreground shader are:
• remember to set "scattering" parameter of light sources to TRUE if you want to see their
volumetric effects.
• use "medium density" and "medium colour" to define brightness and colour of the lit
medium.
First
Last
J
I
Page 13 of 70
• use a solid colour shader set as "density shader" for simulation of density variations in the
medium.
• decrease "error bound" if image appears spotty outside shadow areas.
• increase "min lod" parameter if areas with volumetric shadows appear spotty.
Go Back
Search This Doc
• set high "error bound" and small "min lod" for fast previews.
• use LI_FALL_OFF_ISL or LI_FALL_OFF_ISL_NO_CLAMP for lights and tone mapping for
best results.
Search All Docs
Full Screen
A code example showing basic shader set up is given in Listing 2.1.
LtData
LtShader
LtSref
LtShader
LtPoint
LtVector
data;
spot_light;
lights_list;
medium, density;
location, view_from, view_to;
view_up;
/* Create a spot light, and list of lights... */
spot_light = LiShaderCreate( LI_SHADER_CLASS_LIGHT, "spot" );
Lightworks Author
9.1
Advanced Lighting
LiPointInitialise( location, (LtFloat)0.0,
(LtFloat)6.0, (LtFloat)0.0 );
LiDataSetPoint( &data, location );
LiShaderSetArg( spot_light, "location", &data );
LiDataSetEnum( &data, LI_FALL_OFF_ISL );
LiShaderSetArg( spot_light, "fall off", &data );
Volumetric Shading
LiDataSetFloat( &data, (LtFloat)40.0 )
LiShaderSetArg( spot_light, "cone angle", &data);
lights_list = LiShaderReferenceCreate( spot_light );
LiLightListSet( lights_list );
Master Doc
/* Switch light scattering on for this light... */
LiDataSetBoolean( &data, TRUE );
LiShaderSetArg( spot_light, "scattering", &data );
Title Page
/* Create and set "scattering medium" shader with variable
* medium density via "turbulent" shader */
medium = LiShaderCreate( LI_SHADER_CLASS_FOREGROUND,
"scattering medium" );
LiDataSetFloat( &data, 7.00 );
LiShaderSetArg( medium, "medium density", &data );
density = LiShaderCreate( LI_SHADER_CLASS_COLOUR, "turbulent" );
LiDataSetShader( &data, density );
LiShaderSetArg( medium, "density shader", &data );
LiExecute( LI_EXECUTE_REN_PREVIEW );
Listing 2.1: Basic shader set up
First
Last
J
I
Page 14 of 70
LiForegroundSet( medium );
/* Set view and render... */
LiVectorAssign( view_from,
(LtFloat)6.0, (LtFloat)0.0, (LtFloat)0.0
LiVectorAssign( view_to,
LiVectorAssign( view_up,
LiViewSetPinhole( LI_VIEW_CURRENT, view_from, view_to,
LI_PROJ_PERSPECTIVE, (LtFloat)50.0 );
Contents
Go Back
);
);
Search This Doc
);
view_up,
Search All Docs
Full Screen
Chapter 3
Physically-based Lights
Lightworks Author
9.1
Advanced Lighting
Physically-based
Lights
As outlined in Section 3 of the Foundation Lighting documentation, Lightworks relies on light source
shaders to illuminate the geometry that populates its scenes. Light source shaders are designed to
illuminate a given point in object space, whose surface orientation is known. The same shader will
illuminate the same point in the same way, whether called from within a scan-line renderer, such as
the PREVIEW execution method, or from within the Radiosity Processor Module.
Using Lightworks, it is possible to define light sources based on their true physical attributes. In the
lighting and architectural industries, photometric data is the norm, and the lights can be specified
accordingly.
In addition, there are advanced light sources provided for modelling further physical attributes.
Goniometric light sources can emit widely varying amounts of light energy in different directions.
The emission distribution function for such lights can be defined using an industry-standard file. The
"sky" light source represents the light from the sun which has been scattered by the atmosphere
(i.e., light from the "sky dome"). The use of these lights and their derivatives: "area goniometric",
"line goniometric", "area sky", are discussed in this section.
A physically accurate simulation of lighting conditions can be achieved by using the Radiosity
Processor Module, described in the Global Illumination documentation. Important Note: All light
sources (with the exception of "ambient" ) are supported in both standard rendering methods
and radiosity simulation, and can be specified in the same way for both. It is worth noting that the
radiosity technique is well-suited to modelling some light types and the effects of indirect diffuse
lighting, whereas standard rendering is better suited to modelling effects such as specular highlights.
Combining the results of the two methods is covered in Section 14 of the Global Illumination
documentation.
Master Doc
Title Page
Contents
First
Last
J
I
Page 15 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
3.1.
Shader arguments for physically-based lighting
Those arguments which govern the colour and brightness of the emitted light, are common to many
of the sources. Before going on to describe these arguments, let us first describe the difference
between an empirical lighting interface, and a physically-based lighting interface.
If you are an application developer, whose users expect an interface where each light can be
assigned any colour and a simple slider is used to let them control a light's brightness, then an
empirical lighting interface is probably going to be sufficient.
Lightworks Author
9.1
Advanced Lighting
If you are an application developer whose users expect an interface where each light can be assigned
real-world values, so that the final result can be held-up as a fair representation of reality, then a
physically-based lighting interface sounds more appropriate.
For the sake of simplicity, we define an empirical interface as being one where only the following
two light source shader arguments are used to control a light's emissive characteristics:
Physically-based
Lights
• "intensity" a positive LtFloat, and
• "colour"
an LtColour.
Master Doc
In contrast, a physically-based lighting interface will generally make use of the following two
arguments, in addition to those listed above:
• "intensity units"
an enumerated type, and
• "colour temperature"
Title Page
Contents
a positive LtFloat.
These four arguments, "intensity", "intensity units", "colour" and "colour temperature". combine to determine the colour and "brightness" of the light which the shader "emits".
"intensity units":
This defines the units which are associated with the "intensity" argument. The argument
expects an LtEnum, and can accept any of the values listed in Table 3.1.
All of the values listed are photometric, or luminous quantities. A photometric lighting value is
one which weighs the importance of any light source by its effect on the human eye. The light
from a low-pressure sodium street light appears yellow-orange to a human observer, and might
be measured as having a total power output of 10, 000 lumen, say. Another, bright blue light
source, could also have a total power output of 10, 000 lumen. Similarly for any other source, of
any other combination of visible, or non-visible, wavelengths. Photometric measures allow us
to put a scalar value on what is clearly a quantity in many dimensions (wavelengths); the only
metric is `how bright does a human observer find the source?'
In order to convert between photometric units and radiometric units (which relate to the actual
light energy emitted by a source at various wavelengths), Lightworks provides two utility
functions; LiPhotoConvertToPhoto, which converts radiometric values to photometric
First
Last
J
I
Page 16 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
Pre-defined values accepted by intensity units
Name
Explanation
LI_INTEN_UNITS_EMPIRICAL
The default value. The user has no interest
in intensity units and they wish it to have
no effect on the brightness of the emitted
light.
LI_INTEN_UNITS_LUMEN
The unit of luminous power: the lumen (lm).
LI_INTEN_UNITS_KILOLUMEN
kilolumen (klm); each of these is 1000 lumen.
LI_INTEN_UNITS_LUX
The unit of luminous power per square
metre: the lux (lm/m2 ) .
LI_INTEN_UNITS_KILOLUX
kilolux; each of these is 1000 lux.
LI_INTEN_UNITS_FOOTCANDLE
The unit of luminous power per square
foot: the footcandle (lm/f t2 ) .
LI_INTEN_UNITS_CANDELA
The unit of luminous intensity (i.e., power
per unit solid angle): the candela (lm/sr).
LI_INTEN_UNITS_KILOCANDELA kilocandela; each of these is 1000 candela.
LI_INTEN_UNITS_NIT
The unit of luminance, used to describe the
zenith brightness in the "sky" shader.
Lightworks Author
9.1
Advanced Lighting
Physically-based
Lights
Table 3.1: Pre-defined values accepted by intensity units
Master Doc
ones, and LiPhotoConvertToRadio, which converts photometric values to radiometric
ones. Both of these functions encode radiometric values using LtColour and photometric
values using LtFloat, so that the differing response of the human eye to different wavelengths
of light is accounted for.1
Not all values for "intensity units" are acceptable to all light sources. For example, we
cannot assign a lux value to a "point" light source, since we can never determine its area.
However, we can specify its total emitted power (in lumen or kilolumen) or the power it emits
per unit solid angle (in candela or kilocandela). All light sources which carry the "intensity
units" shader argument can accept empirical intensity units, and by default, most do (the
exception being the "sky" light, which uses nit by default). The specifics of which lights can
accept which units are covered in the reference pages for the individual light source shaders.
Title Page
Contents
First
Last
J
I
"intensity":
This defines how much light is leaving the source. Value must be a non-negative LtFloat.
The bigger this value, the brighter the light will appear, all other parameters being constant.
"colour":
This is one of the arguments which controls the colour of the light leaving the source. This
expects an LtColour value, which defaults to white (1, 1, 1).
If the "colour temperature" argument is inactive, then the final emission colour is controlled entirely by this "colour" argument. If the "colour temperature" argument is
active, then the final emission colour is found by combining the colour defined here, with the
colour derived from the "colour temperature".
1 Note: Some caution is advised when undertaking such conversions. Generally speaking, the wattage quoted by the
manufacturer of a light source will relate to the electrical power consumption, which is not the same as the light energy
output a great deal of energy is lost as heat and/or vibration. A white paper on the subject is available from Lightwork
Design Ltd. See our support web site.
Page 17 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
Pre-defined values accepted by "colour temperature"
Name
Comment
LI_D55
5500K. Often used for daylight.
LI_D65
LI_D75
LI_WARM_WHITE_FLUORESCENT
3020K. Warm means slightly red.
LI_WHITE_FLUORESCENT
3450K
LI_COOL_WHITE_FLUORESCENT
4250K. Cool means slightly blue.
LI_DAYLIGHT_FLUORESCENT
6250K
LI_CLEAR_MERCURY
5710K
LI_IMPROVED_COLOUR_MERCURY 4430K
LI_LOW_PRESSURE_SODIUM
1740K
LI_HIGH_PRESSURE_SODIUM
2100K
LI_TUNGSTEN_HALOGEN
3190K
Table 3.2: Pre-defined values accepted by "colour temperature"
Lightworks Author
9.1
Advanced Lighting
Physically-based
Lights
"colour temperature":
Most people in the lighting industry are accustomed to specifying light colour via a colour
temperature, which encapsulates an exact description of the spectral distribution of the light in
question. The colour temperature is a positive number which defines a temperature in Kelvin;
the temperature refers to that of an ideal black body emitter, glowing `red hot' or `white hot',
depending on the value. A formula known as the Planck black body distribution (which we
shall not dwell on here) is used by the software to derive an LtColour value from the positive
LtFloat which the argument expects.
Values smaller than LI_CL_CIE_MIN_TEMP (defined in licolour.h) will be ignored by the
light source, whilst values larger than LI_CL_CIE_MAX_TEMP will be clamped to that upper
limit.
The default value for "colour temperature" is zero, which is less than LI_CL_CIE_MIN_TEMP, and means that by default, this argument is ignored. If given a sensible value, one can
use this argument to entirely control the colour of the emitted light. By leaving the "colour"
argument at its default value, or by explicitly setting it to white (1, 1, 1), we can control the
emission colour by the "colour temperature" only, should we so wish.
Table 3.2 lists some pre-defined values which will accepted by the "colour temperature".
Master Doc
Title Page
Contents
First
Last
J
I
Page 18 of 70
Examples of specifying these parameters for the basic light types follow, starting with a "point"
light.
Go Back
A "point" light emits equal amounts of (constant colour) light, in all directions away from its
specified "location", in world space. The "intensity units" argument will accept any
of the values listed in Table 3.1, except those which involve a `per unit area' quantity, such as
LI_INTEN_UNITS_FOOTCANDLE.
Search This Doc
The following code is an example of the creation of a red point light source, with a luminous intensity
of 900 candela, located at the origin.
Search All Docs
Full Screen
light = LiShaderCreate( LI_SHADER_CLASS_LIGHT, "point" ) ;
LiColourInitialise( colour, 1.0, 0.0, 0.0 ) ;
LiDataSetColour( &data, colour ) ;
LiShaderSetArg( light, "colour", &data ) ;
LiVectorInitialise( point, 0, 0, 0 ) ;
LiDataSetVector( &data, point ) ;
LiShaderSetArg( light, "location", &data ) ;
Lightworks Author
9.1
LiDataSetEnum( &data, LI_INTEN_UNITS_KILOCANDELA );
LiShaderSetArg( light, "intensity units", &data );
Advanced Lighting
LiShaderSetArg( light, "intensity", &data );
Unlike a "point" light, a "spot" light emits unequal amounts of (constant colour) light, in directions
away from its specified "location" in world space. The light from a "spot" light source will
radiate differently in different directions. The intensity is brightest nearest the axis of the spot light,
but falls off as one moves away from this axis, at a rate determined by the user.
The "spot" light will accept the same "intensity units" values which were acceptable to the
"point" light. However, if we utilise a luminous intensity (such as LI_INTEN_UNITS_CANDELA)
then one should be aware that your intensity is now referring to the maximum intensity emitted by
the source (i.e., the intensity down its axis).
The following code is an example of the creation of a white spot light source, with an intensity of 2.0,
located at the origin, pointing down the positive x-axis.
Physically-based
Lights
Master Doc
Title Page
Contents
light = LiShaderCreate( LI_SHADER_CLASS_LIGHT, "spot" ) ;
LiDataSetFloat( &data, 2.0 ) ;
LiShaderSetArg( light, "intensity", &data ) ;
LiPointInitialise( from, 0, 0, 0 ) ;
LiDataSetPoint( &data, from ) ;
LiShaderSetArg( light, "location", &data ) ;
LiPointInitialise( to, 10, 0, 0 ) ;
LiDataSetPoint( &data, to ) ;
LiShaderSetArg( light, "to", &data ) ;
A "distant" light can be used to represent a light that is located far away, such as the sun (all
rays of light from such a source will be parallel). Unlike the two previous lights, a "distant" light
has no location, in world space. Admittedly, the "incoming direction" of the light is specified via
its "location" and "to" arguments, for convenience, but one should not think of the source as
actually having a location, which one object can be lie closer to, than some other.
The "intensity units" can only be either empirical or power per unit area quantities, such as
LI_INTEN_UNITS_KILOLUX. The "intensity" then specifies the amount of energy incident on a
unit area of a scene object which is facing directly towards the incoming light.
First
Last
J
I
Page 19 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
Use of LI_CONTROL_LEN_UNITS
Control Parameter
Length Units
LI_UNITS_INCHES inches
LI_UNITS_FEET
feet
LI_UNITS_YARDS
yards
LI_UNITS_MILES
miles
LI_UNITS_MILLI
millimetres
LI_UNITS_CENTI
centimetres
LI_UNITS_METRES metres (the default value)
LI_UNITS_KILOMS kilometres
Lightworks Author
9.1
Advanced Lighting
Table 3.3: Values that can be taken by LI_CONTROL_LEN_UNITS
The following code illustrates the creation of a green distant light source which causes 10.0 lumen of
light to fall on every (projected) square metre of each surface that can see it.
light = LiShaderCreate( LI_SHADER_CLASS_LIGHT, "distant" ) ;
LiColourInitialise( colour, 0, 0.8, 0 ) ;
LiDataSetColour( &data, colour ) ;
LiShaderSetArg( light, "colour", &data ) ;
Physically-based
Lights
Master Doc
LiDataSetFloat( &data, 10 ) ;
LiShaderSetArg( light, "intensity", &data ) ;
Title Page
LiDataSetEnum( &data, LI_INTEN_UNITS_LUX ) ;
LiShaderSetArg( light, "intensity units", &data ) ;
Contents
3.2.
Units of length
One important point to note when using physically-based lights (including lights inside the Radiosity
Processor Module) is that, by default, all dimensions are assumed to be presented in metres.
Therefore, if an application uses other units of length in its modelling, Lightworks needs to be told
explicitly what these units are. This is done via control variables, which are described both here (for
convenience) and in Section 3.5 of the Foundation Geometry documentation 2
First
Last
J
I
Page 20 of 70
Go Back
LI_CONTROL_LEN_UNITS
This is an enumerated type. Table 3.3 shows the different values that it can take, and how
these values relate to the units in which the scene has been modelled. The default value is
LI_UNITS_METRES.
If a solution is obtained without setting any units of length, and then re-run with LI_CONTROL_LEN_UNITS set to LI_UNITS_FEET, everything will get markedly brighter. If the first
2 Note that, prior to Lightworks 4.5, the control variables and pre-defined values for the manipulation of length units, were
local to the Radiosity Processor Module. For backwards compatibility, these old variables and values are still supported, but
are not covered in this manual, which only describes the most recent and most correct naming conventions.
Search This Doc
Search All Docs
Full Screen
scene is re-run with LI_CONTROL_LEN_UNITS set to LI_UNITS_KILOMS then everything will
get very much darker.
The following code segment illustrates setting the LI_CONTROL_LEN_UNITS control variable,
so that the radiosity processor recognises that the scene it is dealing with has been modelled
in inches:
LtData
data;
LiDataSetEnum( &data, LI_UNITS_INCHES );
LiControlSet( LI_CONTROL_LEN_UNITS, &data );
LI_CONTROL_LEN_SCALE
Lightworks Author
9.1
Advanced Lighting
If the LI_CONTROL_LEN_UNITS control variable proves insufficient for your needs (perhaps
your scene has been modelled with òne unit = 2.5 inches') then you can utilise the LI_CONTROL_LEN_SCALE control variable. Rather than specifying feet, inches or whatever, you give
a LtFloat which specifies what one modelling unit is, in metres.
So, for the òne unit = 2.5 inches' example, use:
LtData
data;
Physically-based
Lights
/* 0.0635 = 2.5 * LI_INCHES_SCALE */
LiControlSet( LI_CONTROL_LEN_SCALE, &data );
Master Doc
It is possible to quickly and easily scale between the length units currently being used and metres
(or vice versa). The following functions can be used for this purpose (note that in all cases the value
passed as the argument is modified):
LtVoid
LiUnitsLinearScale(LtFloat *length)
This function scales the length passed as argument from whatever length units are currently being
used into metres. For example, if the length units have been set to LI_UNITS_KILOMS and the
value of length is 1.0 then calling this function will result in length being converted from kilometres
into metres and so its value is changed to 1000.0.
Title Page
Contents
First
Last
J
I
Page 21 of 70
LtVoid
LiUnitsInverseLinearScale(LtFloat *length)
As its name suggests, this function is the inverse of the previous one: it scales from metres into
the current length units. If the above example is followed by a call to this function then the value of
length will be reset to 1.0.
Go Back
Search This Doc
Search All Docs
LtVoid
LiUnitsSquareScale(LtFloat *area)
This function can be used to scale between areas defined using current length units squared and
Full Screen
metres squared. For example, if the value of area on input is 128.0 square feet (and hence the current
length units are LI_UNITS_FEET), then on output the value will be 11.89 metres squared.
LtVoid
LiUnitsInverseSquareScale(LtFloat *area)
This function is the inverse of LiUnitsSquareScale, given an area in metres squared it will scale
the area to the current length units squared.
Lightworks Author
9.1
Advanced Lighting
3.3.
The sun light source shader
Lightworks provides a shader which can mimic the effect of sunlight, taking into account the position
on Earth of the scene being rendered, the time of day, and the date. The shader also takes account
of atmospheric effects such as pressure, particles in the air, and so on.
Physically-based
Lights
This allows, for example, the production of very realistic renderings of proposed buildings at different
times of the day, and in different seasons.
The shader may be given either the position of the sun in the sky (in terms of an angle over the
horizon and a compass direction), or you may specify the position of the location on the globe (with
grid references) along with a time and date, in which case the shader will calculate the position of the
sun in the sky. Pre-defined values of latitude and longitude for a number of world cities are provided
(as symbols defined in lishclas.h).
Master Doc
Title Page
Contents
Note: Sunlight is very bright, and so you will most likely need to apply a suitable tone-mapping
operation in order to get useful images. See Section 4 for details about tone mapping.
Figure 3.1 shows the use of the sun shader with a scene of a simple sundial
move around the dial, and change length, at different times of the day.
First
Last
J
I
note how the shadows
The images were produced using the latitude and longitude of London and a date of 22nd June.
We've ignored daylight saving here for clarity, so you can see that at 12.00pm precisely the sun is
at its highest point and directly in the south.
Various utility functions and macros are provided to simplify the calculation of, for example, sun
position given a time and a set of map reference coordinates (latitudes and longitudes for a number
of important cities around the world have been pre-defined in the software). Other macros are to
enable convenient handling of time/date and atmospheric information, which are encoded in data
types (LtTimeDate and LtSkyType).
Page 22 of 70
Go Back
Search This Doc
An LtSkyType object with sensible default values can be created using LiSkyTypeCreate (the
object is destroyed after use with LiSkyTypeDestroy).
Search All Docs
A number of access macros and pre-defined values are provided to allow the creation, and querying,
of appropriate LtSkyType values.
Full Screen
Lightworks Author
9.1
Advanced Lighting
(a) 5.00 am
(b) 9.00 am
Physically-based
Lights
Master Doc
Title Page
Contents
(c) 12.00 pm
(d) 4.00pm
Figure 3.1: Sun light shader with sundial
Generally, these effects are pretty subtle, and only the values for cloudiness will need attention;
choose between `clear', òvercast', and ìntermediate' (for which enumerated values have been
pre-defined), which are values in the range 0.0 to 1.0 (0.0, 0.5 and 1.0 respectively).
For example, the following code shows how to create a new LtSkyType record and setting the
cloudiness to be òvercast'.
First
Last
J
I
Page 23 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
LtSkyType sky_type;
LtData value;
sky_type = LiSkyTypeCreate();
LiDataSetFloat( &value,
(LtFloat)LI_SKY_TYPE_OVERCAST );
LiSkyTypeSetArg( sky_type,
LI_SKY_TYPE_ARG_CLOUDINESS,
&value );
Lightworks Author
9.1
Advanced Lighting
This record could then be passed to the "sun" shader as argument "sky type". You do not have
to define a sky type record, of course if you pass a NULL pointer to this shader argument then a
sensible default value is used. For more details please see the On-line Reference information for the
shader itself.
Physically-based
Lights
3.3.1.
Lighting interior spaces with sun and portal light sources
If you are wishing to use the "sun" light shader to illuminate an interior space, with sunlight coming
through a window, then performance can be improved by using the "portal" light source shader.
This calculates only the light coming through a specified area (for example, the window) from a
specified parallel light source ("distant" or "sun").
Master Doc
Title Page
Note that the "area sky" shader can be used in similar circumstances to improve the performance
of a "sky" light see Section 3.6.
3.4.
Goniometric light sources
Goniometric light sources are a powerful tool for providing illumination which has a complex spatial
distribution. A goniometric source could behave exactly like a point light source or exactly like a
spot light source, but more commonly represents lights with widely varying amounts of light energy
in different directions. Typically a goniometric light source is used when an accurate representation
is needed of the illumination provided by a complex light fixture.
As well as the basic "goniometric" light source shader, Lightworks also provides two derived
shaders, "line goniometric" and "area goniometric". These both take a "goniometric"
shader as an argument, with the goniometric characteristics of the derived shaders being defined by
the parameters of the "goniometric" shader.
The emission characteristics of a goniometric light are governed by a two-dimensional function,
defined over the unit sphere. Typically, this function is a linear interpolation of data which is read
from a text file, whose format is an industry-wide standard.
The files accepted by the "goniometric" light can be in any of four formats:
Contents
First
Last
J
I
Page 24 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
• CIE (Commission Internationale de l'Éclairage). An international standard. Details of the file
format may be found in the CIE Technical Report CIE-102, 1993, `Recommended File Format
for Electronic Transfer of Luminaire Photometric Data', ISBN 3-900-734-40-2.
• IESNA (Illuminating Engineering Society of North America). A North American standard. Details
can be found in the technical report IESNA LM-63-95, ÌESNA Standard File Format for
Electronic Transfer of Photometric Data'.
• CIBSE (Chartered Institution of Building Services Engineers). A British standard. Details can be
found in CIBSE Technical Memorandum 14 (TM14, 1988), `CIBSE Standard File Format for the
Electronic Transfer of Luminaire Photometric Data'.
Lightworks Author
9.1
Advanced Lighting
• EULUMDAT. A German format; not an official standard, but widely used.
All of these formats are formatted ASCII text files (`flat files') containing various keywords to identify
the data which follows.
As an alternative way of specifying the emission characteristics, advanced users can write their own
call-backs to define the function, or they can pass in arrays of values for linear interpolation, as if
they had been read from a file. The API for accomplishing this is outlined in a technical document,
available from Lightwork Design Ltd. Interested readers should explore the LiEmissionSetCreate
API function, and its siblings.
Physically-based
Lights
Master Doc
Goniometric data can also be stored within a high dynamic range image (HDRI), via the LtImage
data type.
Title Page
The following function extracts an emission set from an HDRI LtImage:
Contents
LtStatus
LiEmissionSetFromImage(LtImage image,
LtEmissionSet * emission_data)
Emission data which has been obtained from other sources can be converted into an HDRI LtImage
using the following function:
First
Last
J
I
Page 25 of 70
LtStatus
LiEmissionSetToImage(LtEmissionSet emission_data,
LtImage * image)
Go Back
HDRIs are discussed in more detail in Section 5.
Search This Doc
Figure 3.2 is an illustration of a goniometric function which has been read from a file and shows a
luminous intensity distribution graph for a luminaire with a `winged' emission profile. Such emissions
are ideal for luminaires which are arranged side by side; the 'wings' of one source filling in the 'dark
spots' of its neighbour.
Search All Docs
Like the "spot" light, the "goniometric" light does not (typically) emit equal amounts of light
in every direction, so when one defines its "intensity" using candela or kilocandela one should
Full Screen
Lightworks Author
9.1
Advanced Lighting
Figure 3.2: An example luminous intensity distribution, showing two slices through the sphere of
emission.
Physically-based
Lights
Master Doc
Title Page
Contents
(a) Point source
(b) Goniometric source
Figure 3.3: Comparing an (anisotropic) goniometric source with an (isotropic) point source
be aware that it is the maximum luminous intensity leaving the source, which is being defined, in
whatever direction that might be.
Since the "goniometric" light emits from a single point in world space, its "intensity units"
argument will accept any of the values listed in Table 3.1, except those which correspond to a `per
unit area' quantity, such as LI_INTEN_UNITS_KILOLUX.
Figure 3.3 shows the difference between a "point" light and a "goniometric" light.
First
Last
J
I
Page 26 of 70
Go Back
Search This Doc
The following shader arguments are relevant here:
Search All Docs
• "location". The location of the light, in world coordinates.
• "to". The point which defines where the South Pole of the (polar) intensity distribution should
be. Again, world coordinates.
Full Screen
• "equator zero". The point which defines a reference point on the equator of the (polar)
intensity distribution
• "file name". A file specifying, via a spherical polar distribution, how much light is emitted in
different directions.
• "rotation". A float which rotates the light emission data around the "location" to "to"
axis in a clockwise direction in degrees from the point at "equator zero".
Once the "location", "to" and "equator zero" arguments have been initialised, we have
defined a reference framework within which our 2D function, defined over the sphere, can be utilised
to illuminate the scene.
Lightworks Author
9.1
Advanced Lighting
The following code segment illustrates use of the "goniometric" light source shader, positioned
at its default location, with default orientation:
light = LiShaderCreate( LI_SHADER_CLASS_LIGHT,
"goniometric" ) ;
/* street light */
LiDataSetFloat( &data, LI_LOW_PRESSURE_SODIUM );
LiShaderSetArg( light, "colour temperature", &data ) ;
Physically-based
Lights
Master Doc
LiDataSetEnum( &data, LI_INTEN_UNITS_KILOLUMEN );
Title Page
LiDataSetFloat ( &data, 10 );
Contents
LiDataSetString( &data, "my_lamp.cie" );
LiShaderSetArg( light, "file name", &data );
One parameter of the "goniometric" light source shader that is particularly popular with users of
photometric data files is the "power from file" parameter. Whilst the shader will always look
to its "intensity" argument to decide how bright it should be, some users wish that it would
use the (integral of the) raw emission data that it has been provided with. In order to expose this
functionality, the "power from file" parameter is provided; once the shader has been suitably
initialised, with a call to LiShaderPrerender, a call to LiShaderGetArg can be made, to grab
the "power from file" parameter. Without a call to LiShaderPrerender, to allow the shader
to carry out the necessary integration, and assign the integral value to the relevant internal variable,
LiShaderGetArg will return rubbish.
The following code segment illustrates such an interaction with the shader:
First
Last
J
I
Page 27 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
light = LiShaderCreate( LI_SHADER_CLASS_LIGHT,
"goniometric" ) ;
/* A cosine lobe IESNA file */
LiDataSetString( &data, "Cosine.ies" );
LiShaderSetArg( light, "file name", &data ) ;
status = LiShaderPrerender( light );
if ( status )
/* error */
Lightworks Author
9.1
Advanced Lighting
/* grab integral of cosine lobe */
LiShaderGetArg( light, "power from file", &data );
/* "power from file" is in lumen */
LiDataSetEnum( &data, LI_INTEN_UNITS_LUMEN );
3.4.1.
Physically-based
Lights
The line goniometric light source shader
Master Doc
The "line goniometric" light source shader models `neon lights', `strip lights', and other
sources which emit light from a line-like object. The shader accepts a `line' primitive as input (via
its "primitive" argument); this defines the (poly)line from which light will be emitted. A `line'
primitive is either an LI_PRIM_TYPE_POLY_LINE primitive, an LI_PRIM_TYPE_POLY_LINE_SET
primitive, or some primitive that expands into a non-trivial collection of such primitives.
Once a sample point on the (line) emitter has been found, it is the "goniometric" shader (specified
via the shader's "goniometric shader" argument) which determines how much light, of what
colour, will arrive at the point being illuminated.
Much of the "line goniometric"'s functionality is defined via the attached "goniometric"
light source shader. In fact, the line goniometric takes note of all the arguments passed
to the "goniometric" shader. The following shader arguments control the rest of the line
goniometric's behaviour:
"min lod": The light will always do as much work as is specified by "min lod", for every
point being illuminated. Small values (e.g., 0.0) will result in a fast, coarse sampling of the light
source, whilst large values (e.g., 1.0) will result in a slow, very fine, sampling. Different sources
and scenes require different starting points, for optimal speed/quality trade-off.
"max lod": The "max lod" shader argument delimits the maximum amount of work we are
willing to let the shader carry out, for any point being illuminated. If the "max lod" is smaller
than the "min lod", the shader will assume that the user is in error, and will reverse their
values. If set to the same value as "min lod", no adaptive sampling is performed and the
shader may fail to sample densely enough in regions of rapidly-varying irradiance (such as
inside penumbrae).
Title Page
Contents
First
Last
J
I
Page 28 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
"error bound":
The "error bound" shader argument specifies how keen we are to do
more work, given the results we have collected thus far. The "error bound" parameter
represents the total error acceptable, when illuminating a point of interest. If the "error
1
bound" is 0.1, say, then the result is guaranteed to be the true result, ± 10
of the source power.
Only setting the "max lod" or "min lod" too small, would prevent this being the case.
"noise factor": Allows us to trade under-sampling aliasing artifacts, for noise. Not suitable
for animations, but often very useful for speeding up static images.
The following code sample illustrates the creation of a "line goniometric" light source shader.
LtShader gonio_light,
line_gonio ;
LtData
data ;
LtPrim
line_prim ;
LtStatus status = LI_STATUS_OK ;
gonio_light = LiShaderCreate( LI_SHADER_CLASS_LIGHT,
"goniometric" ) ;
line_gonio = LiShaderCreate( LI_SHADER_CLASS_LIGHT,
"line goniometric" ) ;
Lightworks Author
9.1
Advanced Lighting
Physically-based
Lights
Master Doc
LiDataSetShader( &data, gonio_light ) ;
status = LiShaderSetArg( line_gonio, "goniometric shader"
&data ) ;
LiDataSetGenericPtr( &data, line_prim );
status = LiShaderSetArg( line_gonio, "primitive", &data ) ;
status = LiShaderSetArg( line_gonio, "error bound", &data ) ;
Title Page
Contents
First
Last
J
I
Page 29 of 70
Go Back
Search This Doc
(a) (point) "goniometric"
(b) "line goniometric"
Figure 3.4: Comparing the "goniometric" and "line goniometric" lights
Figure 3.4 shows the same scene rendered with a "goniometric" light and a "line goniomet-
Search All Docs
Full Screen
ric" light.
3.4.2.
The area goniometric light source shader
An "area goniometric" light is one which allows emission from an area in space rather than a
single point. That is, it emits light from the surface of a primitive resident in the Lightworks Geometry
Repository Module, and the contribution of each sample, on the surface of the primitive, to the point
being illuminated, is evaluated using a "goniometric" light.
Use of this shader is relatively straightforward, as the "area goniometric" light only takes two
shaders as its arguments; an area light and a goniometric light. Simply create an area light to
define the geometry that is emitting light, then create a "goniometric" light to define the emission
at each point on the surface of the emitter. Once this is done, create an area goniometric light and
pass it pointers to the two previous lights. The "area goniometric" then combines the area
and the "goniometric" to provide the desired light source. It is the (parameters of the) area
light which determine how the emitter is sampled, but the (parameters of the) "goniometric" light
which specify the colour and brightness of the light leaving any part of the emitter, in any direction.
Area lights are covered in detail in Section 3.5.
The following code sample illustrates the creation of an "area goniometric" light source shader.
LtShader area_gonio ,
area_light,
gonio_light ;
LtData
data ;
area_light = LiShaderCreate( LI_SHADER_CLASS_LIGHT,
"area" ) ;
gonio_light = LiShaderCreate( LI_SHADER_CLASS_LIGHT,
"goniometric" ) ;
area_gonio = LiShaderCreate( LI_SHADER_CLASS_LIGHT,
"area goniometric" ) ;
LiDataSetShader( &data, area_light ) ;
status = LiShaderSetArg( area_gonio, "area shader", &data );
LiDataSetShader( &data, gonio_light ) ;
status = LiShaderSetArg( area_gonio, "goniometric shader",
&data );
Lightworks Author
9.1
Advanced Lighting
Physically-based
Lights
Master Doc
Title Page
Contents
First
Last
J
I
Page 30 of 70
Go Back
Search This Doc
Figure 3.5 shows the same scene rendered with a "goniometric" light and an "area goniometric" light.
Search All Docs
Full Screen
Lightworks Author
9.1
Advanced Lighting
(a) regular "goniometric"
(b) "area goniometric"
Figure 3.5: Comparing the "goniometric" and "area goniometric" lights
3.5.
Physically-based
Lights
Area light sources
Master Doc
Area light sources are those which emit light from the surface of some primitive resident in the
Lightworks Geometry Repository Module. Not all primitives are acceptable; for example, LI_PRIM_TYPE_POLY_LINE primitives are not acceptable, because they have no àrea' to emit from.
Primitives of type LI_PRIM_TYPE_POLY, LI_PRIM_TYPE_MESH and LI_PRIM_TYPE_SURFACE
are perfectly acceptable. Groups and instances of such primitives, are also acceptable. Notice
that light will only leave the front face(s) of the polygon, even if it is double-sided. Poorly-defined
polygons, with near-zero surface area, will be ignored.
Unlike sources that emit their light from a single point in world space, there is no limit to the size of
the region from which area light sources emit their light. If a large enough primitive is created, the
resulting illumination will vary very slowly across the scene. If a small enough primitive is created, the
resulting illumination will vary so quickly across the scene, that the user should be asking themselves:
`Why have I gone to the expense of using an area light, when a simpler source would do the same
job, just as well, more quickly?'
For this reason, we typically assume that the contribution from an area light varies slowly, across
the surfaces that it illuminates. This makes area lights very well suited to the Radiosity Processor
Module, which will only sample the light's contribution at the vertices of a mesh, and then successfully
interpolate the slowly-varying quantity, at render time. This contrasts to the use of area lights in
standard renders, where no (time saving) interpolation takes place. To conclude, it is often worth
considering whether the Radiosity Processor Module might be of use, when utilising area light
sources even when a full lighting simulation is not required. This is discussed in greater depth in
Section 14 of the Global Illumination documentation.
Also, whilst all area light sources have LI_SHADOW_TYPE_SOFT shadows, by default, the user
should remember that shadow maps will not always give the best results for these lights, because
the light is no longer being simply emitted from a point.
Title Page
Contents
First
Last
J
I
Page 31 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
The following code sample gives an example of the creation of an area light source, outputting 1200
lumen of yellow-orange light, from a sphere which is located at the origin. The area light will accept
any of the "intensity units" values listed in Table 3.1, except those which correspond to a
power per unit solid angle quantity, such as LI_INTEN_UNITS_KILOCANDELA.
light = LiShaderCreate( LI_SHADER_CLASS_LIGHT, "area" ) ;
sphere = LiPrimitiveCreateSphere(origin, radius);
LiDataSetGenericPtr( &data, sphere ) ;
LiShaderSetArg( light, "primitive", &data ) ;
Lightworks Author
9.1
Advanced Lighting
LiDataSetFloat( &data, LI_LOW_PRESSURE_SODIUM );
LiShaderSetArg( light, "colour temperature", &data );
LiDataSetEnum( &data, LI_INTEN_UNITS_KILOLUMEN );
LiShaderSetArg( light, "error bound", &data );
There follows a brief outline of the shader arguments which will be of relevance:
"primitive":
from.
Physically-based
Lights
Master Doc
Title Page
This is used to tell the light source which primitive it is meant to be emitting light
"min lod": Minimal level of detail for area source decomposition. The usual range is in the lower
end of [0.0, 1.0], although values greater than 1.0 are allowed. This parameter determines the
initial sampling for lighting calculation and visibility analysis no matter what the value of any
other argument, the light will always do as much work as is specified by "min lod", for every
point being illuminated.
If "min lod" is too low, then shadow boundaries may not be reproduced correctly, or
a rapidly-varying goniometric emission (part of an "area goniometric" light) may be poorly
sampled. If it is too big, then rendering times will be excessive. Practical values are between
0.0 and 0.5.
Contents
First
Last
J
I
Page 32 of 70
Go Back
"max lod": Maximal level of detail for area source decomposition. This delimits the maximum
amount of work we are willing to let the shader carry out, for any point being illuminated. If
set to the same value as "min lod", no adaptive decomposition is performed and the shader
may fail to sample densely enough in regions of rapidly-varying irradiance (such as inside
penumbrae). If the "max lod" is smaller than the "min lod", the shader will assume that the
user is in error, and will reverse their values. The suggested range for "max lod" is [0.0, 1.0]
although values greater than 1.0 are allowed. The practical range is [0.5, 1.0].
Search This Doc
"error bound": Whilst "min lod" specifies the minimum amount of work we always do, and
"max lod" specifies the maximum amount of work we ever do, "error bound" specifies
how keen we are to do more work, given the the work we have done thus far. So, the shader
Full Screen
Search All Docs
will evaluate as many samples as are implied by "min lod" and will then examine the error
associated with each sample. If the largest error is less than "error bound" ± "estimated
illuminance (at point being lit)" then no further sampling will take place. If the largest error
is too large, the offending region of the light source will be more densely sampled, and the
(new) largest error will be evaluated. This process continues until either the "error bound"
criterion is satisfied, or "max lod" sampling is reached.
Note that refinement will only take place when "shadows" is TRUE and shadow maps are not
being used. In such cases, the shader will generate a set of samples using "min lod" only,
and these will either be not shadowed at all, or will be shadowed using the shadow map code.
Lightworks Author
9.1
The default value for "error bound" is 0.2; this will not probably not encourage very much
adaptive sampling. Smaller values force heavier work loads, larger values lead to lighter work
loads.
Advanced Lighting
"noise factor": Allows the user to add noise to the visibility sampling. A value of 0.0 means
no noise; a value of 1.0 means maximal noise. The range is strictly [0.0, 1.0]. The noise may
be used as cheaper alternative for anti-aliasing penumbral regions than adaptive refinement
(controlled by "max lod" parameter).
"colour filtering": This parameter controls whether the colour of the light’s "primitive"
is considered when determining the output light colour. If it is set to FALSE (the default) then the
colour of the geometry is ignored and the light colour is determined solely from the "colour"
and "colour temperature" parameters. This maintains the behaviour up to and including
release 5.6 of Lightworks. If this parameter is set to TRUE then the colour shader attached
to the light's geometry will be used to filter the light being emitted. This allows, for example,
different coloured light to be emitted from different faces of a single area light source by having
different colours on each face. It also allows for complex colour distributions to be modelled
by applying an appropriate colour shader to the material of the geometry.
To obtain the desired illumination results when "colour filtering" is set to TRUE it may be
necessary to modify the level of detail parameters of the area light. The following list describes
some of the issues related to performance and the quality of the generated results.
• For simple, slowly-varying colour patterns, small values (in the range 0.0 to 0.3) for the
light's "min lod" parameter should be sufficient to provide good results.
Physically-based
Lights
Master Doc
Title Page
Contents
First
Last
J
I
• For rapidly changing colour patterns it may be necessary to increase the "min lod"
parameter (typically to values greater than 0.5) in order to see all the colours on the surface
of the light in the generated illumination.
Page 33 of 70
• When the "min lod" parameter is varied it may also be necessary to increase the "max
lod" parameter to obtain the desired image quality This will be more commonly required
in scenes where a coloured area light casts shadows.
Go Back
• In general if some of the detailed colour variations of the area light are not accounted
for, or if the quality of shadows is insufficient, the user should try combinations of the
following:
1. reduce the "error bound",
2. increase the "min lod",
3. increase the "max lod".
Further details of the use of coloured area lights are provided as a white paper available from
Lightwork Design.
Search This Doc
Search All Docs
Full Screen
3.6.
Sky light source shaders
Lightworks Advanced Lighting provides three shaders which can be used for representing the lighting
conditions of an overcast sky:
• "sky" a complex shader which is capable of handling all situations and producing high
quality results, but which requires some knowledge to use effectively.
Lightworks Author
9.1
• "area sky" a version of the "sky" shader which is suited to a those cases where only a
fraction of the sky is actually contributing to the illumination of the scene (for example, interiors
scenes lit by daylight through a window).
Advanced Lighting
• "simple sky" a simplified "sky" shader which is significantly easier to use than the full
"sky" shader, and can be markedly faster, when correctly set-up for the right scene.
The following subsections explain each of these shaders, and there then follows (in Section 3.7) a
worked example of how to use the "sky" shader in practice.
3.6.1.
The sky light source shader
The "sky" source represents light from the sun which has been scattered by the atmosphere; a
hemisphere of sky. The source does not include light arriving directly from the sun, although this can
be modelled with a sun source, if you are not modelling a cloudy sky.
Like a "distant" source, the sky source shader is oriented relative to a scene, rather than being
positioned somewhere within it. The orientation of the sky is specified by setting the shader
parameters "north" and "up", whilst the direction of the sun is specified by the "sun altitude"
and "sun azimuth" parameters.
The shader parameter "type" specifies whether your sky is clear, overcast, or somewhere in
between. Essentially, this is the `which bit of the sky is brightest?' control. If it is an overcast
day, then the brightest part of the sky is directly overhead, regardless of where the sun is. If it is a
clear day, then the brightest part of the sky will follow the sun around the sky. The "type" shader
argument chooses between a number of mathematical models which mimic this behaviour. Table 3.4
shows the seven possible (enumerated) values that this parameter may take. Three values specify
the Commission Internationale de l'Éclairage's formulae for clear, cloudy and intermediate skies; a
further three values specify the corresponding formulae used by the Illuminating Engineering Society
of North America; the final value lets you specify your own sky model by supplying appropriate
call-backs to define the sky distribution and zenith luminance. (Details available on request from
Lightwork Design.)
Figure 3.6 shows a simple scene illuminated by the CIE's clear sky.
The following code segment illustrates the creation of a "sky" light source shader, and initialising
its parameter settings to match those that were used to obtain Figure 3.6.
Physically-based
Lights
Master Doc
Title Page
Contents
First
Last
J
I
Page 34 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
Sky Light Source Shader types
LI_PO_SKY_TYPE_CIE_OVERCAST
LI_PO_SKY_TYPE_CIE_CLEAR
LI_PO_SKY_TYPE_CIE_INTERMEDIATE
LI_PO_SKY_TYPE_IESNA_OVERCAST
LI_PO_SKY_TYPE_IESNA_CLEAR
LI_PO_SKY_TYPE_IESNA_INTERMEDIATE
LI_PO_SKY_TYPE_CUSTOM
Lightworks Author
9.1
Advanced Lighting
Table 3.4: Possible values for the "sky"'s "type" argument.
Physically-based
Lights
Master Doc
Title Page
Contents
First
Last
J
I
Page 35 of 70
Go Back
Search This Doc
Figure 3.6: A scene illuminated by daylight.
Search All Docs
Full Screen
light = LiShaderCreate( LI_SHADER_CLASS_LIGHT, "sky" ) ;
LiDataSetFloat( &data, LI_D65 ) ;
LiShaderSetArg( light, "colour temperature", &data ) ;
LiDataSetEnum ( &data, LI_PO_SKY_TYPE_CIE_CLEAR );
LiShaderSetArg( light, "type", &data );
LiDataSetFloat ( &data, 40 );
LiShaderSetArg( light, "sun altitude", &data );
Lightworks Author
9.1
Advanced Lighting
LiDataSetFloat ( &data, 0.2 );
LiShaderSetArg( light, "min lod", &data );
LiShaderSetArg( light, "max lod", &data );
LiShaderSetArg( light, "error bound", &data );
LiShaderSetArg( light, "noise factor", &data );
For further details of the "sky" light's parameters, see the on-line reference page for the shader.
Suffice to say here that the shader's "shadows" and "shadow transparency" parameters are
exactly what you might expect, from exposure to other light source shaders. One caveat to note is
that all shadows are established using ray casting; using shadow maps is not an option. However as
you can see from the example image, shadows will still appear `soft' as long as sufficient samples
are taken. Sampling is fine-tuned via the "min lod", "max lod", "error bound" and "noise
factor" shader parameters. "min lod" specifies the minimum amount of work you are willing to
let the shader do, for every point of interest, whilst "max lod" specifies the maximum amount of
work you are willing to let the shader do, for any point of interest. The "error bound" parameter
specifies how keen you are to let the shader increase its sampling from "min lod" towards "max
lod"; the smaller the "error bound", the more accurate the image. Noise can be used to replace
regular sampling artifacts, using the "noise factor" parameter.
Figure 3.7 shows different samplings of the sky hemisphere. Figures 3.7(a), (b) and (c) show how
the hemisphere is subdivided when "min lod" and "max lod" are (both) set to 0.0, 0.4 and 0.8
respectively. Figure 3.7(d) shows an adaptive sampling of the sky hemisphere.
The "sky" shader can be quite hard to use successfully in practice, because of the way that the
large number of arguments interact with each other.
In many cases the "simple sky" shader (see Section 3.6.3) will provide a simpler to use alternative
which produces perfectly acceptable results.
Physically-based
Lights
Master Doc
Title Page
Contents
First
Last
J
I
Page 36 of 70
Go Back
Search This Doc
Search All Docs
For those advanced users who really do require the advanced capabilities of the full "sky" shader,
Section 3.7 provides some tips which should help users get the best results.
Full Screen
Lightworks Author
9.1
Advanced Lighting
Physically-based
Lights
Master Doc
Figure 3.7: Different samplings of the sky hemisphere
3.6.2.
The area sky light source shader
The "area sky" light allows users to simulate the lighting contribution from the sky hemisphere,
without having to go to the trouble of sampling the entire hemisphere, every time a point is illuminated
by the shader. Instead, the user specifies the window or, skylight, or door-frame that the skylight is
known to pass through, so that only this primitive is sampled, when trying to establish which parts
of the sky are visible to the point being illuminated.
The "area sky" light source shader takes two other light source shaders as its arguments; one
area light, and one "sky" light. The idea is that the two argument shaders are created but not
added onto the active lights list. Instead, they are used to build an area sky shader, which is
added to the active lights list.
The area light source is used to define the window or, skylight, or door-frame through which the
skylight is known to pass. It is also used to control the sampling rate and shadowing, exactly as it
would have been if no sky were present. As long as the area light's "primitive" is not included
in the active primitive list, it will never be rendered; it is only used to define the gap through which
the sky light can enter the scene.
Once the area light has been used to decide where the "sky" light is to be sampled, it is the "sky"
light's arguments which determine the colour and brightness of the light, and it is the "sky" light's
"min lod" argument that determines the resolution of the (step) function that is being sampled.
The following code sample illustrates the creation of an "area sky" light source shader.
Title Page
Contents
First
Last
J
I
Page 37 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
Lightworks Author
9.1
Advanced Lighting
(a) regular "sky"
(b) "area sky"
Figure 3.8: Comparing the "sky" and "area sky" lights
LtShader area_sky ,
area_light,
sky_light ;
LtData
data ;
Physically-based
Lights
Master Doc
Title Page
area_light = LiShaderCreate( LI_SHADER_CLASS_LIGHT,
"area" ) ;
sky_light = LiShaderCreate( LI_SHADER_CLASS_LIGHT,
"sky" ) ;
area_sky = LiShaderCreate( LI_SHADER_CLASS_LIGHT,
"area sky" ) ;
LiDataSetShader( &data, area_light ) ;
status = LiShaderSetArg( area_sky, "area shader", &data );
LiDataSetShader( &data, sky_light ) ;
status = LiShaderSetArg( area_sky, "sky shader", &data );
Figure 3.8 shows the same scene rendered with a "sky" light and an "area sky" light. Using
ray-cast shadows, Figure 3.8(a) took 28 times longer to render, than Figure 3.8(b). Using shadow
maps, the speed-up increases to 87 times! Note that the "sky" light source has no "shadow
type" parameter, and only ray traced shadows may be generated for this light source, whereas
this parameter can be set for the "area sky" light source, (indirectly via the parameter of the
referenced area light source). However it should be emphasised that, as for the area light source,
although there is this performance advantage, shadow maps may not give the best results.
Contents
First
Last
J
I
Page 38 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
3.6.3.
The simple sky light source shader
The "simple sky" light provides a fast approximation to a true sky light. It is simpler to use, and
usually faster to execute, than the "sky" shader, but is still capable of providing good results, so
long as modelling an actual sky distribution (such as "cloudy" or "clear") is not a concern.
The "simple sky" light models the sky as a simple, uniform dome, rather than attempting to
model the non-uniform distribution of light across a real sky, and the only control over the sampling
is the "number of samples". This means it presents a much more intuitive user interface than the
full "sky" light source shader; users can simply increase the "number of samples" to obtain a
better image (contrast this with the more sophisticated approach needed to get the best out of the
"sky" shader as described in Section 3.7).
The shader has arguments for "intensity", "intensity units", "colour", "colour temperature", "shadows", "shadow type", "shadow transparency", "shadow acceleration", "shadow resolution", "shadow quality", "shadow softness", and "shadow
tolerance" which are all pretty standard for light source shaders, with the notable exception that
the default value for "shadow type" is LI_SHADOW_TYPE_HARD, rather than LI_SHADOW_TYPE_SOFT as is the case with most light source shaders.
Lightworks Author
9.1
Advanced Lighting
Physically-based
Lights
The arguments which are specific to the "simple sky" light source shader are as follows:
Master Doc
"up": The "up" vector defines the orientation of the sky hemisphere with respect to the scene.
Specifically, it is a vector that joins any point in your scene to the zenith (highest point) of the
sky hemisphere.
"number of samples": This argument provides an easy to understand and predictable tradeoff between accuracy and speed. The shader works by creating "number of samples"
distant light source shaders, scattered uniformly about the hemisphere defined by the "up"
vector. Typically, less samples can be used with soft shadows.
"noise factor": This control has no effect if soft shadows are requested, but when hard
shadows are being calculated the sample directions are varied (`jittered') slightly in an effort to
replace sampling artifacts with noise. Unlike the "sky" shader, every sample will be jittered if
the "noise factor" is set to a large enough value. Values can vary from 0.0 (no jittering) to
1.0 (maximum jittering).
Acceptable results for a scene with some shadowing can normally be obtained using hard shadows
(the default), a fairly low number of samples, and a sufficient amount of noise to smooth the shadows
out. If true soft shadows are required, remember that there will be a delay prior to rendering as a
number of seperate shadow maps are built (if a large number of samples have been requested in
such a situation the delay could well be confusing to novice users3 ).
Also, generally speaking it will require more samples to accurately capture the subtle lighting cues
that are present with a completely overcast sky. For example, Figure 3.9 shows a the "simple
sky" light source shader with full jittering and 200 samples.
3 Hence
soft shadows are not the default. Setting "shadow type" to LI_SHADOW_TYPE_SOFT may be useful in two
situations; where many images of a single scene are required it may make sense to spend the time once to calculate the
Title Page
Contents
First
Last
J
I
Page 39 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
Lightworks Author
9.1
Advanced Lighting
Physically-based
Lights
Figure 3.9: The "simple sky" light source shader
3.7.
Usage hints and tips for the sky light source shader
This section guides an end-user through a usage scenario for a "sky" light source shader. If you are
an application developer this section may give you some ideas about how best to expose the "sky"
in your application; alternatively you may simply make a similar explanation or tutorial available to
your users.
There are a large number of inter-dependent shader arguments for the "sky" light shader, which
can make use of the shader awkward unless a sensible strategy to finding suitable values for the
arguments is taken.
Users of the "sky" light shader may ask the following questions;
• ``What settings do I use to get a good image?''
Master Doc
Title Page
Contents
First
Last
J
I
Page 40 of 70
• ``What settings do I use to get a fast image?''
Go Back
In what follows, we take a scene that many users have attempted to illuminate with a "sky" light,
and guide the reader through the process of reaching a ``good image''.
Search This Doc
Because of the large percentage of the sky that is occluded, for most points in the image, an "area
sky" light source would be a better choice for this scene, but a "sky" light can still be used
effectively as long as the issues are understood.
A large class of common scenes may not be so obviously more suited to the "area sky" light
shadow maps prior to quickly rendering each image; and secondly in some situations where the noise from the sample
jittering would otherwise be visible.
Search All Docs
Full Screen
source, and yet still require a similar approach to get good results with the "sky" light. For example,
rather than an interior scene, you may have a scene which consists of only partially enclosed
geometry; or where the particular area of the scene being rendered is partly enclosed.
The following image shows what happens when we set both the "min lod" and "max lod"
parameters to 0.2, whilst leaving most of the other parameters at their default values (except for
setting "shadows" to TRUE and "colour temperature" to 7500).
Lightworks Author
9.1
Advanced Lighting
Physically-based
Lights
Master Doc
Title Page
Since "min lod" is equal to "max lod", "error bound" plays part in the sampling. It is clear
that most points in the image have a very poor view of the sky; most attempts to sample the sky
hemisphere encounter a wall, or the ceiling. Those places that manage to sample through a window
appear lit, but they do not appear to be `lit by several windows' so we know that only one of their
sky samples made it through.
Until all points in the image are `lit by several windows' we know that adaptive sampling will fail,
since we have insufficient initial samples to work with. So, let's increase both the "min lod" and
"max lod" parameters to 0.4, in an effort to find what the ideal initial sampling level should be:
Contents
First
Last
J
I
Page 41 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
Lightworks Author
9.1
Advanced Lighting
The situation has clearly improved. If we moved to adaptive sampling now, we would find that some
parts of the scene (most of the floor) would appear ``good'', but others parts (such as the walls
between the windows) would never appear good, since they are lit by zero or one sky samples; not
enough for the adaptive sampling to do anything with.
Let's continue to search for a correct initial sampling level. If we set both the "min lod" and "max
lod" parameters to 0.6, and the following image results:
Physically-based
Lights
Master Doc
Title Page
Contents
First
Last
J
I
Page 42 of 70
Go Back
Search This Doc
Now we see that most (if not all) points in the scene are managing to see more than one sky sample.
So we can now leave "min lod" alone, and work on increasing "max lod" (so that we work hard
to get rid of sampling artifacts, but only where we have to). Our first effort sets "max lod" to 1.0
and "error bound" to 0.1. The following image results:
Search All Docs
Full Screen
Lightworks Author
9.1
Advanced Lighting
This image does not look much better than the previous image, and yet we are supposed to be
sampling really heavily ("max lod"=1.0) where the initial samples disagree about how the point of
interest is being lit.
The problem is that "error bound" is too large. An "error bound" of 0.1 means that it is
acceptable that the maximum error associated with the illumination of the point of interest is less
than 10% of the energy associated with the illumination arriving at the point. It looks like 10% is too
large an error. Let's try the same "min lod" and "max lod" but with an "error bound" of 0.01:
Physically-based
Lights
Master Doc
Title Page
Contents
First
Last
J
I
Page 43 of 70
Go Back
Search This Doc
The image quality is now much improved. A smaller "error bound" will probably improve the
image even further, at the cost of extra processing. When "error bound" is too small, we will
end up sampling as much as "max lod" almost everywhere, and we might as well then simply set
"min lod" equal to my large "max lod" value, and miss out the expense of adaptive sampling
altogether.
The final image uses the same settings as the previous one, but uses a "noise factor" of 1.0 in
Search All Docs
Full Screen
an effort to replace those regular sampling artifacts that remain, with noise:
Lightworks Author
9.1
Advanced Lighting
Physically-based
Lights
This produces a perfectly acceptable result, and will be much quicker to render than the brute-force
alternative of setting a higher "min lod" value.
Master Doc
The approach taken above can be summarised as follows:
Title Page
1. set "min lod" and "max lod" equal to each other, at a moderately low value
2. gradually increase these values (keeping them identical) until the initial sampling level seems
to be suitable
3. then keep "min lod" fixed at this value, and vary "max lod" and "error bound" until the
desired result is obtained.
As long as these steps are followed, it should be possible to discover the settings for the "sky"
light which will produce good quality results in the minimum rendering time.
Contents
First
Last
J
I
Page 44 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
Chapter 4
Tone Mapping
Lightworks Author
9.1
Advanced Lighting
Tone Mapping
In the real world, the human eye is capable of resolving images in extremely varied lighting conditions,
ranging from bright sunshine reflecting off snow to a room lit only by a single candle.
In computer graphics on the other hand, we need to produce an image on a display device which
has a very limited range of luminance values. Therefore it is necessary to compress the range of
luminance values found in a real world scene into the displayable range in such as way as to produce
a realistic looking image.
Photography, of course, has exactly the same problem. If a photographer (or camera) does not take
into account the light levels in a scene before calculating the exposure of the shot, the likely result
will be an image which is either over-exposed (everything is too bright) or under-exposed (everything
is too dark). A professional photographer will also use different speeds of film for different lighting
conditions. The aim is to produce an image on film that is representative of how that scene would
have looked to a human observer.
The simplest mapping from real-world to display luminance values could be something like this: the
brightest part of the scene corresponds to the highest displayable luminance value, and the darkest
to the lowest displayable value, with a linear mapping between. In practice this might mean that,
where a light source is visible, that is rendered as white, whilst everything else is almost black.
In fact the response of the human visual system to light is not linear, which is why we are able to
see in such a wide range of different lighting conditions. The perception of brightness is related
logarithmically to the amount of light energy entering the eye.
This is very important when we wish to render a scene which has been calculated using realistic
lighting values (such as a radiosity scene). If we do not choose a sensible mapping from the real
world luminance values contained in the radiosity solution to the luminance values available on the
display device, then the resulting image will not be representative of the scene, and so the hard work
Master Doc
Title Page
Contents
First
Last
J
I
Page 45 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
of producing a radiosity solution will be wasted.
A classic problem which occurs when using a naive mapping from real-world to display luminances
is this: imagine a sports arena is first lit using a single light bulb, and then using a powerful floodlight.
The two scenes should not look identical!
Lightworks provides a mechanism to allow you to solve this problem. Tone mapping allows the user
to control the way in which the mapping from real world to display luminances is done.
Sections 4.4 and 4.5 deal with the usage of tone mapping via the core API level. Users of the Session
Manager should note that to use tone mapping via Session Manager it is simply necessary to set a
suitable value for LI_SESSION_VAR_TONE_MODE before rendering; the Session Manager handles
everything else automatically (see Section 5.5.1.1 of the Foundation Rendering documentation).
Session Manager users may wish to treat the following discussion of tone mapping shaders simply
as useful background reading.
Lightworks Author
9.1
Advanced Lighting
Tone Mapping
4.1.
Tone mapping and sub-images
If you are rendering sub-images using tone mapping, then you can use the following control variable:
Master Doc
• LI_CONTROL_TONE_IGNORE_SUBIMAGES
Title Page
to specify whether the tone mapping should be carried out on the whole image, or the currently
specified sub-image. By default this variable is FALSE, meaning that the tone mapping operation
will operate on the sub-image only, if one is set.
This is important, since you may may have a scene which contains some bright and dark regions;
if the sub-image you are rendering contains a dark region with no bright areas, then by default the
tone mapping will brighten up this sub image.
If you are using sub-images just to update a region of a larger picture, then this may not be desirable.
Setting the control variable to TRUE will mean that tone mapping is calculated on the basis of the
view specification, in other words the whole image viewport, not the sub-image currently being
rendered.
Contents
First
Last
J
I
Page 46 of 70
Go Back
4.2.
Deferring tone mapping
Search This Doc
The following LtBoolean control variable controls whether tone mapping occurs during shading
(FALSE) or after the scanline data has been written to the screen buffer (TRUE). This allows a screen
buffer to store un-tonemapped values during rendering which is then suitable to be tone mapped
after rendering.
• LI_CONTROL_DEFERRED_TONE_AND_CLAMP
Search All Docs
Full Screen
It should be noted that in certain cases deferred tone mapping may produce slightly different images
than when applied during rendering:
• Empirical based objects (e.g Image backgrounds, RPC objects etc). When applying tone
mapping during rendering, we don't tone map empirical objects as we assume they are already
in a displayable range. However, when we defer the tone mapping operation, so we can write
the raw values to the screen buffer, we need to apply an inverse tone map function to empirical
objects, so when we eventually tone map the data, we get back the original value.
• Transparent objects may appear different when deferring tone mapping. Deferred tone mapping
applies the tone mapping operation to the final pixel colour value, whereas when tone mapping
is applied during rendering, it is applied for each shaded sample which are then combined to
make the final pixel colour.
4.3.
Accelerating tone mapping
Lightworks Author
9.1
Advanced Lighting
Tone Mapping
The following LtBoolean control variable specifies whether various optimisations which allow tone
map set up to be performed quicker are used:
Master Doc
• LI_CONTROL_ACCELERATE_TONE_MAPPING
Title Page
Setting this control to TRUE will allow the following optimisations to improve the performance of the
tone map setup step:
Contents
• The size of the thumbnail image used during set up is reduced from 1/4 image size to 1/8
image size, which should still prove adequate in many cases.
First
Last
• During the tone map setup phase only, any 'blurred shaders' used ("blurred mirror",
"blurred glass", "glossy dielectric" and "glossy metal") will, if this control is
set, ignore all quality settings and shoot a single ray only, i.e., act like a non blurred or glossy
shader (since the blurred effect will not affect the degree of tone mapping required in the final
image).
J
I
• If final gather is being used, then the "maximum radius" and "interpolation quality"
settings are reduced so that the tone map setup completes as quickly as possible (since such
settings are unlikely to influence the amount of tone mapping needed).
Page 47 of 70
Go Back
Search This Doc
By default the control is set to FALSE, i.e., no acceleration (this is to maintain backward compatibility
with older versions of Lightworks by default). Generally speaking we recommend turning this control
variable on.
Search All Docs
Full Screen
4.4.
Tone Mapping Shaders
A class of shaders, LI_SHADER_CLASS_TONE, has been provided to address the tone mapping
problem. They may be used either during rendering or as a post-processing step.
The reason for a whole class of tone mapping shaders is to allow various different solutions to be
applied, and indeed it is possible to write new tone mapping shaders (see the Lightworks Plug-in
SDK (Custom Shaders) documentation).
Returning to the analogy of a photographer calculating a suitable exposure for a photograph,
remember that the first task is to use a light meter to establish the amount of light in the scene.
This is also the first task in using tone mapping before applying a tone mapping shader to a scene,
we should first examine the scene to find out how brilliantly lit it is, and how much contrast it
contains. It will then be possible to choose an appropriate tone mapping shader, and provide it with
the right input values.
This is done by rendering the scene into the screen buffer (possibly at reduced resolution, to save
time), and using a post-processing shader to analyse the screen buffer. The results of this analysis
can then be fed into an appropriate tone mapping shader (which may actually be applied to the
image in a number of ways).
Tone mapping shaders may be applied either during rendering, or during post-processing. Lightworks
maintains a current list of tone map shaders to be applied during rendering, in a similar way to the
current list of light shaders. Tone shaders can be built into a list in the normal way, and the list set to
be current using LiToneListSet.
Alternatively, a post-process shader is provided which takes as its argument a list of tone shaders
which are then applied during post-processing.
Which of these two methods should be used will depend on the particular situation. Generally
best results will be obtained if tone mapping is performed during rendering, as tone mapping and
anti-aliasing will work together. However in some situations you may wish to render once, then
perform several different tone mapping operations during post-processing, for example by allowing
the user to choose the tone mapping. An interface which allows the user to set a tone mapping
manually using a slider, for example, would be best implemented in this way, since it would give
quicker feedback to the user (it would of course be possible to perform a `final' render using the tone
settings decided by the user).
Lightworks Author
9.1
Advanced Lighting
Tone Mapping
Master Doc
Title Page
Contents
First
Last
J
I
Page 48 of 70
Go Back
The following shaders are provided:
"tone contrast scale" post process shader Examines the image in the screen buffer and
calculates a suitable scale factor for the "scale" tone shader.
Search This Doc
"scale" tone shader Tone mapping shader which converts luminance values to RGB colour values
based on a scale factor calculated using the "tone contrast scale" shader.
Search All Docs
"tone linear ceiling" post process shader Examines the image in the screen buffer and
calculates a suitable piecewise linear function (to approximate a curve), for the "polynomial
approximation" tone shader.
Full Screen
"polynomial approximation" tone shader Tone mapping shader which converts luminance
values to RGB colour values based on a table of polynomial functions (to approximate a curve),
calculated using the "tone linear ceiling" shader.
"tone" post process shader This shader takes a list of tone map shaders as its parameter, allowing
any tone map shader(s) to be used on the contents of the screen buffer, rather than re-rendering.
"brighten up" tone shader Tone mapping shader which converts luminance values to RGB
colour values using a simple, intuitive, logarithmic curve with appropriate control arguments.
Lightworks Author
9.1
"perceptual setup" post process shader Examines the image in the screen buffer and calculates a suitable tone curve, for the "perceptual" tone shader.
Advanced Lighting
"perceptual" tone shader Tone mapping shader which converts luminance values to RGB colour
values based on a tone curve, calculated using the "perceptual setup" shader.
An example of how you might use these shaders in practice is given below:
Tone Mapping
1. render image to a screen buffer
2. post-process using "contrast scale" shader
3. read scale parameter
4. create "scale" tone shader (class LI_SHADER_CLASS_TONE), set scale argument as indicated by "contrast scale" shader.
Master Doc
Title Page
5. specify that "scale" tone shader is used during rendering (using LiToneListSet).
6. render the image
Alternatively, the tone mapping can be done as a post process:
1. render image to a screen buffer
Contents
First
Last
J
I
2. post-process using "contrast scale" shader
3. read scale parameter
4. create "scale" tone shader (class LI_SHADER_CLASS_TONE), set scale argument as indicated by "contrast scale" shader.
5. create "tone" post-shader and set the newly created "scale" tone shader as argument.
Page 49 of 70
Go Back
Search This Doc
6. post-process the image
Search All Docs
Full Screen
4.5.
Example
By way of an example, let us examine an application of the "brighten up" tone map shader.
There is no accompanying post-process shader, specifically tailored for use with this tone shader,
but that does not prevent its simple and useful application.
The example scene consists of a simple scene which has been greatly over-illuminated by an
"area" light source shader, whose "intensity" argument has been set to 5000, whilst leaving its
"intensity units" at their default LI_INTEN_UNIT_EMPIRICAL value. The result can be seen
in Figure 4.1(a); almost all pixels are washed out.
The following code snippet illustrates how one might set up a "brighten up" tone shader to attend to
the washed-out appearance of Figure 4.1(a). The "max world luminance" value has been set to
the intensity of the brightest light source in the scene (5000). This works well for empirical intensity
units, but clearly a scaling factor would have to be introduced if kilolumen, say, had been used.
Lightworks Author
9.1
Advanced Lighting
Tone Mapping
tone_shader = LiShaderCreate(LI_SHADER_CLASS_TONE, "brighten up");
LiDataSetFloat(&data, 5000);
LiShaderSetArg(tone_shader, "max world luminance", &data);
t_list = LiShaderReferenceCreate(tone_shader);
LiToneListSet(t_list);
LiDataSetBoolean( &data, FALSE);
LiControlSet( LI_CONTROL_CLAMP_VERTEX_SHADE, &data);
LiExecute LI_EXECUTE_REN_FULL
Note: it is important to make sure that colour vertex clamping is off before rendering an image
on which you intend to perform tone mapping. This is done by setting the control variable
LI_CONTROL_CLAMP_VERTEX_SHADE to FALSE, as is shown in the example listing.
The resultant image can be seen in Figure 4.1(b).
Master Doc
Title Page
Contents
First
Last
J
I
Whilst this image is greatly improved, we still have a great deal more dark regions than light regions.
To shift this balance, we set the value of the "brighten up" shader's "shift" argument to 0.3
(values less than 0.5 tend to brighten up dark regions; values greater than 0.5 tend to darken down
bright regions). The resultant image can be seen in Figure 4.1(c). Now we have a fairly good balance
between bright regions and dark regions, but the overall image brightness is still probably a little low.
Page 50 of 70
To remedy this last fault, we change the default value of the "brighten up" shader's "brightness" argument to 0.8; the final image being Figure 4.1(d).
Search This Doc
The following code snippet illustrates the setting of the shader's "shift" and "brightness"
arguments to 0.3 and 0.8, respectively.
Search All Docs
Go Back
Full Screen
Lightworks Author
9.1
Advanced Lighting
(a) No tone mapping.
(b) "shift"= 0.5.
Tone Mapping
Master Doc
Title Page
Contents
(c) "shift"= 0.3.
(d) "brightness"= 0.8.
Figure 4.1: Use of "brighten up" tone shader.
First
Last
J
I
Page 51 of 70
LiDataSetFloat(&data, 0.3);
LiShaderSetArg(tone_shader, "shift", &data);
Go Back
LiDataSetFloat(&data, 0.8);
LiShaderSetArg(tone_shader, "brightness", &data);
Search This Doc
4.6.
White balancing using tone mapping
When using realistic lighting values you may find there is a colour cast in rendered images; for
example an orange tint to images lit by electric lighting, and conversely a blue tint to images lit by
Search All Docs
Full Screen
overcast skies.
The same things happens in photography, and digital cameras provide mechanisms to alter the
white balance of the image to remove the colour cast.
Lightworks provides the capability to address this issue via the "white balance" tone map
shader.
4.6.1.
What is white balance?
Most people will be aware that, when you take a photograph of an indoor scene lit by regular light
bulbs, the picture will look quite orange unless some adjustment is made; in the case of a digital
camera this can be done either on the camera itself or afterward in photo editing software, in the
case of a film camera during the developing process. Many digital cameras will actually perform a
white balancing operation automatically.
The reason that the colours would look wrong without white balancing is that the human eye
performs this function itself without you being aware of it; a white sheet of paper under electric light
will actually be a very different colour than the same sheet of paper under sunlight, but because your
eye adjusts to its surroundings so well you rarely notice this.
In order to account for this effect with a digital camera, you would normally tell the camera
something about the lighting conditions, often by setting a mode for common conditions, or possibly
by specifying an estimated colour temperature for the lighting in Kelvin as shown below:
Typical colour temperatures for lighting conditions
Colour Temperature Light Source
1000-2000K
Candlelight.
2500-3500K
Incandescent Lamp.
3000-4000K
Sunrise/Sunset (clear sky).
4000-5000K
Fluorescent Lamps.
5000-5500K
Electronic Flash.
5000-6500K
Daylight with Clear Sky (sun overhead).
6500-8000K
Moderately Overcast Sky.
9000-10000K
Shade or Heavily Overcast Sky.
Lightworks Author
9.1
Advanced Lighting
Tone Mapping
Master Doc
Title Page
Contents
First
Last
J
I
Page 52 of 70
Go Back
Note that Lightworks allows you to specify lighting using Kelvin colour temperatures, and several
common lighting types are specified in Table 3.2 in Section 3.
4.6.2.
Performing white balancing in Lightworks
In order to perform white balancing on a Lightworks rendering, you just need use the "white
balance" tone map shader and tell it two things;
Search This Doc
Search All Docs
Full Screen
• The (rough) colour temperature of the lighting in the scene (normally via the "rendered white
temperature" argument, although the shader can optionally work with CIExyY chromaticity
coordinates see Section 4.6.3 for more information).
• The colour temperature that should correspond to white (normally via the "target white
temperature" argument unless you are working with CIE xyY coordinates). In other words,
if this is set to a temperature corresponding to a sunlit day then the white balance operation
will make all images tend toward this feel; if you want your white balanced images to look like
an overcast day then alter this argument accordingly. Often you may leave this at something
neutral like 6500K (the standard used for 'daylight').
Lightworks Author
9.1
Advanced Lighting
There is also a third argument, "balance factor", which allows fine tuning of the result by varying
between the full white balancing effect (1.0) and not performing any white balancing (0.0).
Most user interfaces will probably expose the "rendered white temperature" argument (possibly as a selection of pre-sets for 'incandescent', 'fluorescent', 'sunlit', and 'cloudy' as is common
with digital cameras) and possibly the "balance factor" argument to allow the user to override
the effect to suit their taste. The "target white temperature" may in many cases be left set to
6500K or similar to simulate daylight; however advanced users may wish, for example, that pictures
of sunny days do not look like images of cloudy days, in which case altering this argument slightly
may be appropriate.
The "auto setup shader" argument allows the "white balance" tone map to work together
with a "tone diagnostic" tone map to automatically set a value for "rendered white" /
"rendered white temperature". In this way you can provide the sort of automatic white
balance feature found on most digital cameras (you could still expose the "balance factor"
argument in the UI to allow the user to vary the automatic effect).
Tone Mapping
Master Doc
Title Page
Contents
Of course, the "white balance" tone map shader only concerns itself with colours, not with
overall brightness or contrast, so you would generally want to combine it with another tone map
shader in any case.
4.6.3.
About colour spaces
Not all possible colours can be represented as a colour temperature as described above, since
hot objects emit a certain range of colours only. However, for most lighting conditions colour
temperature is a useful way of specifying a colour, since lights sources do generally emit light from
this limited range.
More generally in computer graphics, colours are often specified in terms of RGB values, i.e., the
proportion of red, green and blue. However this involves a degree of uncertainty, since it relies on
the exact definition of 'red', 'green' and 'blue' being constant, and in fact different display devices,
printers, etc., may in practice vary slightly from each other.
In order to reliably reproduce an exact colour, a more accurate representation is needed. Lightworks
therefore provides the ability to specify colours in terms of the CIE 1931 XYZ colour space.
The Commission Internationale de l'Éclairage (CIE) is the international authority on light, illumination,
First
Last
J
I
Page 53 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
colour, and colour spaces. The CIE 1931 XYZ colour space is spanned by 3 spectral sensitivity
curves known as x, y and z. Different amounts of each curve can be combined to produce a
particular colour. Unlike some other colour spaces, CIE XYZ space is not dependent on a particular
display device, so it is ideal for defining absolute colours, regardless of whether or where they are to
be displayed.
The CIE XYZ colour space is ideal for describing absolute colours, which might vary in intensity as
well as hue, but is less well suited when it is only the hue (and not the intensity) that is of interest.
The CIE xyY space is essentially the space of all CIE XYZ colours, normalised (i.e., all the same
intensity). CIE xyY space uses a pair of positive numbers, less than 1, to describe hue (also called
chromaticity) in a device-independent manner (see Figure 4.2). Note how not all x,y pairs map to an
observable colour. The line around the outside of the space of observable colours relates to single
wavelength colours (with the wavelength in nm being marked in blue), and the black curve marked
Tc(K) is shows the limited range of colours that can be specified as colour temperatures. White is
at the centre of the diagram where the reds, greens and blues meet, as you can see the colour
temperature scale passes through this central area at around 6500K.
Lightworks Author
9.1
Advanced Lighting
Tone Mapping
It is also worth noting that the space represented by RGB on most monitors will be a triangle inside
the area shown in this diagram (obviously the colours reproduced as you look on screen will therefore
not match the set of possible colours that the diagram is attempting to represent).
Master Doc
Title Page
Contents
First
Last
J
I
Page 54 of 70
Go Back
Search This Doc
Search All Docs
Figure 4.2: The CIE 1931 colour space xyY chromaticity diagram.
Full Screen
4.6.4.
API functions to convert between colour spaces
Lightworks provides the following API functions to convert into CIE XYZ from RGB values, colour
temperatures, and CIE xyY coordinates:
• LiColourTemperatureToXYZ
Lightworks Author
9.1
• LiColourxyYToXYZ
Advanced Lighting
• LiColourRGBFloatToXYZ
Also provided are API functions to convert from CIE XYZ back into RGB and xyY coordinates (note
that no function is provided to convert from XYZ to a colour temperature this is because colour
temperatures are such a small subset of the possible colours that can be represented in XYZ that
any such conversion would be quite arbitrary):
Tone Mapping
• LiColourXYZToRGBFloatClampFull
• LiColourXYZToRGBFloatClampNonNegative
• LiColourXYZToxyY
Note that, because the range (gamut) of colours that can be represented by XYZ is larger than can
be represented by RGB, two API functions are provided which do the calculation slightly differently;
neither function will produce negative values for R G or B, and ...ClampFull will in addition ensure
that no values greater than 1 are produced. Note however that this will mean that some possible
XYZ colours will not be accurately reproduced in RGB space.
In order to perform conversions between the CIE colour space and RGB reliably, it is necessary to
know the exact definition of the red, green and blue channels, since this can vary from one device
to another. Lightworks allows you to alter the way this conversion is done va the following control
variable:
• LI_CONTROL_COLOUR_SPACE
Master Doc
Title Page
Contents
First
Last
J
I
Page 55 of 70
This control variable describes an LtInterface "colour space" which defines a known white
point in CIE xyY chromaticity coordinates.
Go Back
By altering the colour space to suit different display devices it is therefore possible to ensure perfect
colour reproduction by storing colour values as CIE values wherever possible and only converting to
and from RGB when a known colour space can be defined.
Search This Doc
By default Lightworks works with a default colour space which has a white point coordinate of
(0.313076, 0.329046). The table below gives some common white point values which you may wish
to use; the manufacturers of printers and monitors should publish similar data for their equipment.
Search All Docs
Full Screen
Common white points (colour spaces)
CIExyY (x,y)
Description
(0.4512, 0.4059)
Illuminant A, CIE 1964.
(0.44757, 0.40745)
Illuminant A, CIE 1931.
(0.3498, 0.3527)
Illuminant B, CIE 1964.
(0.34842, 0.35161)
Illuminant B, CIE 1931.
(0.3362, 0.3502)
Direct Sunlight, CIE 1931.
(0.3333, 0.3333)
Illuminant E, both CIE 1931 and CIE 1964.
(0.3138, 0.3310)
Illuminant D65 (CIE 1964).
(0.3134, 0.3275)
Light from Overcast Sky, CIE 1931.
(0.313076, 0.329046) Lightworks default white.
(0.313, 0.329)
Illuminant D65 (Glassner).
(0.312713, 0.329016) Illuminant D65(ii), CIE 1931.
(0.3127, 0.3291)
Illuminant D65, CIE 1931.
(0.3104, 0.3191)
Illuminant C, CIE 1964.
(0.31006, 0.31616)
Illuminant C, CIE 1931.
(0.304, 0.329)
EIZO F784/MA-21A1.
(0.303, 0.309)
DAEWOO 17inch (2).
(0.289, 0.304)
DAEWOO 17inch (1).
(0.284, 0.276)
AXION 17inch CL-1766 (1).
(0.2773, 0.2934)
Light from North Sky on a 45deg plane, CIE 1931.
(0.271, 0.287)
GVC 14 inch.
(0.268, 0.307)
AXION 17inch CL-1766 (2).
(0.264, 0.289)
DAEWOO 14inch CMC-1502B.
(0.258, 0.291)
Hewlett-Packard HPA4033A.
For example the following code will alter the current Lightworks colour space to suit an HP A4033A
printer:
LtInterface cspace;
LtData data;
LtVector xyY = {(LtFloat)0.258, (LtFloat)0.291, (LtFloat)1.0};
LiDataSetVector(&data, xyY);
cspace = LiInterfaceCreate "colour space";
LiInterfaceSetArg(cspace, "white", &data);
LiDataSetInterface( &data, cspace );
LiControlSet( LI_CONTROL_COLOUR_SPACE, &data );
Lightworks Author
9.1
Advanced Lighting
Tone Mapping
Master Doc
Title Page
Contents
First
Last
J
I
Page 56 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
Chapter 5
High Dynamic Range Images
Lightworks Author
9.1
Advanced Lighting
High Dynamic Range
Images
Lightworks Advanced Lighting provides support for images which can represent a much higher
range of possible intensity values than traditional image formats, which only represent the range of
intensity values which can be displayed on a computer display.
These high dynamic range image store brightness values as floating point numbers, and can
represent the brightness levels visible in the real world, rather than as a number between 0 and 255.
Such images may be captured photographically (either by using specialised equipment, or by taking
a series of identical digital photographs at different light exposure levels and combining them using
software), or they can be produced by rendering using realistic lighting values.
Lightworks supports the following high dyanamic range image formats:
• OpenEXR
OpenEXR is a high dynamic range image format which was developed and made freely
available by Industrial Light and Magic (ILM). OpenEXR uses 16 bit floating point values rather
than 32 bit floating point values since this easily provides sufficient range for image data (an
approximate range of [0, 109 ] for light intensity levels represents the equivalent of well over 30
f-stops in photographic terms), yet can be supported natively on the latest generation graphics
cards
• HDR
The HDR format represents each pixel is represented by at most four bytes. The first three
bytes are the red, green and blue mantissas (in that order), and the fourth byte is a common
exponent. The floating point colour (R,G,B)=(1.,.5,.25) would be represented by the bytes (128,
64, 32, 129). This provides slightly less accuracy than OpenEXR, but is still sufficient for many
applications, and a larger number of images are currently available in this format.
Master Doc
Title Page
Contents
First
Last
J
I
Page 57 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
Two new drivers are provided to support these formats:
• lidrvexr1
• lidrvhdr
These drivers are used in the same way as the other image archive drivers provided within Lightworks.
5.1.
Where can HDRIs be obtained?
High dynamic range images could be created using Lightworks rendering (Lightworks Global
Illumination users may want to consider using HDRI as a way to store radiosity solutions), or by using
specialised photographic equipment to capture real-world scenes.
Lightworks Author
9.1
Advanced Lighting
High Dynamic Range
Images
Several party software tools exist to allow HDRIs to be created from multiple photographs taken at
different light exposure levels:
• HDRShop (www.debevec.org/HDRShop/) A Windows only tool which is free for noncommercial use only; if you ship an academic product you could recommend this application
to academic users, but commercial users should not be encouraged to download the software.
• Photosphere (www.anywhere.com)
can be used freely.
Master Doc
Title Page
A Macintosh image browsing and cataloging tool which
Contents
• hdrgen (www.anywhere.com) The HDR composition engine used within Photosphere is also
available as a command-line tool for Linux as well as Macintosh.
• Photogenics HDR from Idruna Software (www.idruna.com) A commercial paint and photo
editing package for Windows and Linux which supports high dynamic range images, and can
create them from multiple photographs.
• There are also some web sites offering an HDR creation service, such as WebHDR
(www.luminance.londonmet.ac.uk/webhdr)
First
Last
J
I
Page 58 of 70
As interest in, and knowledge of, high dynamic range image formats and their usefulness grows, it
is likely that more and more such tools will appear in the market.
Go Back
In addition, a growing number of companies and web sites can provide HDRIs in different formats,
sometimes for a fee. For example:
Search This Doc
• http://debevec.org/Probes/ Provides images in .hdr vertical cross form which can
be used for testing purposes but which should not be published or distributed in any way
without permission from the web site author.
1 The
OpenEXR driver uses code that is copyright 2002, Industrial Light and Magic, a division of Lucas Digital Ltd. If you
use the EXR driver in your product you should include this acknowledgement in your own documentation.
Search All Docs
Full Screen
• http://realtexture.com
available for purchase.
Provides a large number of images in .hdr vertical cross form,
• http://doschdesign.com Provides a large number of images in .hdr vertical cross form
(amongst others), available for purchase.
You may like to create or obtain a set of suitable HDRIs to distribute with your product, or to
ensure that your users know where they can obtain them. A good place to start is the `HDRI
Starter Pack' which we have put together for you; this is available for end-users to download from
www.lightworks-user.com or you can obtain the whole pack from the support web site and
distribute it with your application.
5.2.
Lightworks Author
9.1
Advanced Lighting
Image based lighting (using HDRI)
A major application of HDRI is to use a high dynamic range image as a light source. This provides
a straightforward way to specify lighting environments which would otherwise be quite complex to
define.
High Dynamic Range
Images
Master Doc
5.2.1.
Using HDR images as environments
Title Page
Lightworks Advanced Lighting allows high dynamic range images to be used as environments. The
advantages of using HDR images rather than regular images for this purpose are;
Contents
• reflections will have much greater range of intensity, giving a more `deep' and realistic image,
• it is possible to use HDR environments to light an object or a scene, so that it matches the
lighting conditions present when the environment image was captured.
The creation of an LtEnvironment, and how to set an environment for a scene, is covered in the
Scenes and Scenery documentation (Section 5 covers core details and 2.4 covers Session Manager
implementation details).
Lightworks supports environment maps created in the following ways;
1. a cubic map created directly from Lightworks (by rendering six images, north, south, east,
west, up, and down from a point in the scene),
2. a cubic map created by reading six (possibly photographic) images,
First
Last
J
I
Page 59 of 70
Go Back
Search This Doc
Search All Docs
3. a cubic map created by reading a single image which consists of six sub images laid out in the
form of an unfolded cube (both `vertical' and `horizontal' versions are supported),
4. a cubic map created by reading a single image which consists of six sub images laid out in the
form of an unfolded cube (also known as a `vertical cross' layout),
Full Screen
5. a latitude/longitude map (sometimes known as a panorama) where the entire environment is
flattened into a single flat panoramic image, rather like a map of the globe,
6. a `spherical' map, usually created by photographing a reflective sphere with a telephoto lens,
7. an àngular' map (sometimes known as a `light probe' image) is similar to a spherical map from
a reflective sphere, except that the radial dimension is mapped linearly with the angle, instead
of being squashed towards edge of the circle. This gives more accurate sampling around the
edges of the image.
HDR images suitable for use as environments within Lightworks can often be found in several of
these forms.
Lightworks Author
9.1
Advanced Lighting
Reading such images and converting them to environment maps for use within Lightworks is covered
in Section 5.1.4 of the Scenes and Scenery documentation.
5.2.2.
Using an HDR environment for reflections
The "environment" reflection shader, when applied to geometry, causes the currently set environment to be reflected in that geometry. Lightworks Advanced Lighting allows high dynamic range
images to be used, which results in improved depth of intensity in reflections.
For example, consider a photograph of a room containing a shiny object such as a table, and a
window which is reflected in the table. On a bright day, a photograph which is correctly exposed
to capture the interior of the room would lead to the view through the window being over-exposed
and `white-ing out'. However, as the reflection of the window on the table would be darker than
the window itself, more detail of the outside scene may be visible in the reflection. This would be
impossible to capture without using a high dynamic range image.
Sometimes applying the "environment" reflection shader to your model may not be appropriate,
in which case an alternative approach would be to use the "ray cube" background shader.
This background shader has four arguments, each of which is a pointer to another shader; use
the "environment" reflection shader as the value of each of these arguments. This technique
enables you to keep all the existing reflectance settings of the materials in your scene (allowing
the environment background to be visible both by reflection and refraction with glass materials, for
example).
High Dynamic Range
Images
Master Doc
Title Page
Contents
First
Last
J
I
Page 60 of 70
Go Back
5.2.3.
Using an HDR environment for lighting
Search This Doc
By using an HDR image as the scene's environment, this allows highly realistic and subtle lighting
effects to be created. Effectively it is possible to render a computer generated object and place it
against a photographic scene, and the computer generated object will be lit in such a way that it
appears to be part of the scene, as both the colours and brilliance will match.
This technique is commonly used for special effects sequences in movies to make computer
generated objects and actors merge with a real-world scene in a believable way, but it would be
Search All Docs
Full Screen
equally useful as a way to produce a realistic rendering showing how a new building would look in
its surroundings.
Sometimes it may not be possible to obtain an environment map (whether HDRI or not) of the
particular scene against which an object is to be rendered, but image based environment lighting
may still be used to create lighting effects of a particular `mood' by using an environment which is
similar to the conditions in which the object being rendered will be placed. For example, an HDRI
environment of an outdoor scene in certain weather conditions or at certain times of day may be
used simply to illuminate the geometry being rendered, even if it is not used as a background or
reflection map. As such, the environment light and a set of representative scenes provides a highly
effective alternative to providing complex light studio setups.
Lightworks Author
9.1
Advanced Lighting
High Dynamic Range
Images
Master Doc
Title Page
Two light shaders, "simple environment" and "environment" are provided which allow a
scene to be illuminated using supplied environment map. By default they use the current global
environment, but you can if you wish specify a different environment to be used by the light.
Despite providing similar functionality, they behave a bit differently; the "environment" light
shader is more advanced and gives far better results than "simple environment" with the same
"number of samples". This is especially true in the case of environment maps which contain
lighting details, or small bright areas (which can be missed by "simple environment"). Generally
we recommend that the "environment" light is used in most cases.2
5.3.
Usage hints and tips for image based lighting
To light a scene with an environment map you should do the following:
1. Create and set the background.
Contents
First
Last
J
I
Page 61 of 70
Go Back
Search This Doc
Search All Docs
2 However,
there are cases when the "simple environment" will be useful. The "environment" shader performs
precomputations, which allow for faster renderings, but take some time before first rendering for a given set of parameters.
The "simple environment" shader, due to its simplicity, doesn't require many preliminary operations, and so may be a
better choice when trying different environment maps with small number of samples. It may give nearly as good results as
"environment" when using almost uniform environment maps, such as an overcast sky.
Full Screen
2. Create and set the environment.
3. Add the environment light to a scene ("environment" suggested).
Listing 5.1 shows how to set up an environment with a suitable image and light the scene using an
environment light. Note that in this example the output driver is set to output floating point RGB
values by setting LI_CONTROL_SCAN_OUTPUT to LI_OUTPUT_RGB_FLOAT this is recommended
when using HDRI lighting.
More details of how to use backgrounds can be found in the Scenes and Scenery documentation
(Section 4 covers core details and 2.3 covers Session Manager implementation details). Use of
environments is also discussed in the Scenes and Scenery documentation (Section 5 for core and
2.4 for Session Manager).
When using a HDRI background you may need to correct its intensity; for example, the background
may appear too dark, or may `white-out' due to being too bright. This can be fixed in two ways:
Lightworks Author
9.1
Advanced Lighting
High Dynamic Range
Images
• Changing the background intensity the "intensity" parameter of the background shader
determines how bright the background is. Values greater than 1 make it brighter and smaller
make it dimmer. This may be done using the following code:
Master Doc
LiShaderSetArg( background, "intensity", &data );
Title Page
• Using tone mapping you may use tone mapping to adjust high dynamic values to the range
used by traditional displays. One of the possible ways to set it up is shown below:
Contents
LtShader tone_shd;
LtSref tone_list;
tone_shd = LiShaderCreate( LI_SHADER_CLASS_TONE,
"polynomial approximation" );
tone_list = LiShaderListCreate( 1, [tone_shd] ) ;
LiToneListAutoSetup tone_list
LiToneListSet tone_list
Tone mapping is the preferred solution. The rest of this section focuses mainly on adjusting the
environment light so that it gives the best results. If you want to set the environment shader from
scratch, you should use the procedure presented below.
1. Render with default values of shader parameters
By default, the "environment" light uses a small "number of samples" (10) and most
parameters tuned off or not affecting the results (for example, "shadows" turned off,
"saturation" set to 0). These values are a good starting point for adjustment and make
rendering fast. During the next few steps some parameters will be modified. By default
the environment light shaders use the global environment, but this can be altered by setting
First
Last
J
I
Page 62 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
/* load an hdr image... */
LtImage img1;
img1 = LiImageRead( "myenvironment_cross.hdr" );
/* create and set environment... */
LtEnvironment env;
env = LiEnvironmentCreateCross( img1 );
LiEnvironmentSet( env );
/* create and set background shader... */
LtShader background;
background = LiShaderCreate( LI_SHADER_CLASS_BACKGROUND,
"environment" );
LiBackgroundSet(background );
/* Create a light shader to perform IBL... */
LtShader ibl_light;
ibl_light = LiShaderCreate( LI_SHADER_CLASS_LIGHT, "environment" );
/* set desired number of samples */
LiDataSetNat32( &data, 100 );
LiShaderSetArg( ibl_light, "number of samples", &data );
/* setting intensity of lights */
LiShaderSetArg( ibl_light, "intensity", &data );
/* enable shadows for this light */
LiDataSetBoolean( &data, LI_TRUE );
LiShaderSetArg( ibl_light, "shadows", &data );
/* create light list */
LtSref
my_light_list;
my_light_list = LiShaderListCreate( 1, [ibl_light] ) ;
Lightworks Author
9.1
Advanced Lighting
High Dynamic Range
Images
Master Doc
Title Page
Contents
First
Last
J
I
/* setting current lights list */
LiLightListSet( my_light_list ) ;
Page 63 of 70
Go Back
/*
* render
*/
Search This Doc
/* set output to use floating point values... */
LiDataSetEnum(&data, LI_OUTPUT_RGB_FLOAT);
LiControlSet(LI_CONTROL_SCAN_OUTPUT, &data);
Search All Docs
LiExecute(LI_EXECUTE_REN_FULL);
Full Screen
Listing 5.1: Using the "environment" light
the "use global environment" parameter to FALSE and an environment interface as
"environment". This may be useful when objects should be lit with a different map than i
used for the background.
2. Set the light intensity
The "intensity" parameter decides how strong are lights which are lighting a scene and
how bright will be the rendered image. Typically you will want to match brightness of lit objects
with brightness of the environment, i.e., if the environment is bright objects lit by it should be
bright also. Choosing a value which will make lit object match the background needs some
experiments.
3. Set the saturation
The environment light source shaders provide control over the degree of colour saturation in
the lighting. This enables the user to reduce (or increase, if necessary) the degree of colouration
of the scene caused by the environment lighting. In the case of some HDRI environments this
effect can seem more extreme than expected, so giving users the option to tone it down is
sensible; however it would in general be wrong to de-saturate too much, as this subtle colour
shift is precisely what makes the objects in the scene seem to match the colour and lighting
conditions in the HDRI environment.
Lightworks Author
9.1
Advanced Lighting
High Dynamic Range
Images
The value to be used for the "saturation" parameter therefore depends on the environment
map being used and the effect which is desired.
4. Set lighting quality
The quality of lighting decides how good the lighting seen on objects will correspond to the
environment. It depends mostly on the "number of samples", i.e., the number of lights
used to simulate environment lighting. The more samples used, the more accurate the lighting.
On the other hand, increasing the number of samples makes rendering longer. Some common
artifacts that may suggest you are using too few samples are:
• Objects appear to be lit from directions which don't correspond to bright areas in the
environment map.
Master Doc
Title Page
Contents
First
Last
J
I
• Bright areas of the background seem not to be influencing the lighting sufficiently.
• Lighting of objects changes rapidly.
The value for "number of samples" which will give good results can be different for different
environments. If there are many small and bright areas then more samples may be needed. If
an environment is more or less uniform then a smaller number of samples will suffice. Finding
the correct value depends on the desired quality of lighting, and on the environment. The
best approach is usually to use a few tens of samples whilst experimenting to get the correct
settings for the other arguments, and then to increase the number of samples, possibly to as
much as several hundred, for final rendering.
5. Set shadows
Page 64 of 70
Go Back
Search This Doc
HDRI lighting is usually used to make objects look like they were really in the places represented
by environment maps. Realistic shadows are therefore important.
Search All Docs
Increasing the number of samples introduces additional shadows (probably caused by weaker
light sources) and makes stronger ones more accurate, for example by softening their boundaries. The quality of shadows obtained with the same number of samples changes from one
environment map to another. If there are many relatively small bright areas then usually more
Full Screen
samples are needed. On the other hand, large bright areas like windows are easier to simulate
and in most cases require fewer samples.
The number of samples which makes lighting of objects look good may be not sufficient to get
nice shadows. If you see one of the following:
• there are no shadows from some bright areas in the environment
• shadows consist of visible layers
...it suggests that the shadows are not accurate. If there are some shadows missing, the only
thing you can do is to increase the number of samples. The second artifact is called `shadow
banding' and there are two ways to reduce or eliminate it either change the way shadows are
calculated, or increase the number of samples.
Environment light shaders support both hard and soft shadows. If hard shadows are used,
noise may be applied to shadow boundaries by setting "noise factor" parameter to the
value greater than 0, which makes the layers of shadows less visible. This method doesn't
increase rendering time and can reduce banding (the amount of noise needed depends on
the scene and environment). The disadvantage is that the noise can cause visible effects,
especially when the shadows are being viewed from a short distance.
Lightworks Author
9.1
Advanced Lighting
High Dynamic Range
Images
If soft shadows are used banding may be reduced by increasing "shadow softness"
parameter. Noise is not introduced and rendering time is only slightly increased.
In general, best results are obtained by using hard shadows with high number of samples but
increasing the number of samples always makes shadows more accurate regardless of the
shadow type. The obvious drawback is the longer rendering time.
However, for some scenes it is difficult to eliminate banding even with many samples. This
happens when an environment map contains many small bright areas. In such cases, a mixed
approach may be used. Good results may be obtained by increasing the number of samples
and when banding is weak switching to soft shadows and smoothing them slightly. Similarly,
some noise may be added when hard shadows are used.
5.3.1.
Troubleshooting
Master Doc
Title Page
Contents
First
Last
J
I
1. Objects insufficiently lit
If objects in a scene are black (or white) then the first thing you should check is the
"intensity" parameter. If you have previously used an environment map with very bright
colours you probably have set the "intensity" to a small value. If you then changed the
environment the value of "intensity" may be not appropriate for a new one. If objects are
black and changing "intensity" doesn't make objects lit, you should check whether the
environment map is set to a valid image.
Page 65 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
Lightworks Author
9.1
In the image on the left you may see all objects black. It turns out that the "intensity"
was set to 0 (probably by accident) and after setting it to a reasonable value like 0.75 it looks
correct. The result is shown on the right.
Advanced Lighting
2. Improper colours
If environment lighting colours the image too much, use the "saturation" parameter to
reduce the effect. The image on the left has a blue tint from blue in the environment image
used. The result after setting "saturation" to −0.6 is visible on the right.
High Dynamic Range
Images
Master Doc
Title Page
Contents
3. Shadow artifacts
If you get shadows which noticeably consist of layers ('shadow banding' artifact) use one of
the solutions described earlier.
First
Last
J
I
Page 66 of 70
Go Back
Search This Doc
Search All Docs
The image on the left shows shadows which are not smooth, which is caused by too few
samples (100). The image on the right shows the result of increasing the "number of
samples" to 500. So for this scene it was possible to eliminate banding without the need to
apply noise or to switch to soft shadows.
Full Screen
5.4.
HDRIs as goniometric data
HDRIs can also be used as a way to store goniometric light source data (emission sets); see
Section 3.4 for details.
Lightworks Author
9.1
Advanced Lighting
High Dynamic Range
Images
Master Doc
Title Page
Contents
First
Last
J
I
Page 67 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
Index
Lightworks Author
9.1
area light source shader, 31
"area goniometric" light source shader, 30
"area sky" light source shader, 37
CIE, 34
colour space
table, 56
colour temperature, 18, 52
maximum value, 18
minimum value, 18
pre-defined values, 18
control variable
length
units of, 20, 21
LI_CONTROL_LEN_SCALE, 21
LI_CONTROL_LEN_UNITS, 20, 21
LI_CONTROL_CLAMP_VERTEX_SHADE, 50
LI_CONTROL_LEN_UNITS, 20
LI_CONTROL_LEN_SCALE, 21
LI_CONTROL_TONE_IGNORE_SUBIMAGES, 46
LI_CONTROL_ACCELERATE_TONE_MAPPING, 47
LI_CONTROL_COLOUR_SPACE, 55
LI_CONTROL_DEFERRED_TONE_AND_CLAMP, 46
LI_CONTROL_SCAN_OUTPUT, 62
LI_CONTROL_SCAN_OUTPUT, 63
data types
LtColour, 16 18
LtEnum, 16
LtEnvironment, 59
LtFloat, 16, 18
LtImage, 25
LtInterface, 55
LtSkyType, 22, 23
LtTimeDate, 22
daylight, 34
entity attributes
session
LI_SESSION_VAR_TONE_MODE, 46
goniometric light source shader, 24
IESNA, 34
intensity units
candela, 17
footcandle, 17
kilocandela, 17
kilolumen, 17
kilolux, 17
lumen, 17
lux, 17
nit, 17
pre-defined values, 17
interior lighting, 24
LI_UNITS_FEET, 20, 22
LI_UNITS_KILOMS, 21
LI_CL_CIE_MAX_TEMP, 18
LI_CL_CIE_MIN_TEMP, 18
LI_CLEAR_MERCURY, 18
LI_COOL_WHITE_FLUORESCENT, 18
LI_D55, 18
LI_D65, 18
LI_D75, 18
LI_DAYLIGHT_FLUORESCENT, 18
LI_HIGH_PRESSURE_SODIUM, 18
LI_IMPROVED_COLOUR_MERCURY, 18
LI_INTEN_UNIT_EMPIRICAL, 50
LI_INTEN_UNITS_CANDELA, 17
LI_INTEN_UNITS_FOOTCANDLE, 17
LI_INTEN_UNITS_KILOCANDELA, 17
LI_INTEN_UNITS_KILOLUMEN, 17
LI_INTEN_UNITS_KILOLUX, 17
LI_INTEN_UNITS_LUMEN, 17
LI_INTEN_UNITS_LUX, 17
LI_INTEN_UNITS_NIT, 17
LI_LOW_PRESSURE_SODIUM, 18
LI_PRIM_TYPE_MESH, 31
LI_PRIM_TYPE_POLY, 31
LI_PRIM_TYPE_POLY_LINE, 28, 31
LI_PRIM_TYPE_POLY_LINE_SET, 28
LI_PRIM_TYPE_SURFACE, 31
LI_SHADOW_TYPE_SOFT, 31
LI_TUNGSTEN_HALOGEN, 18
LI_UNITS_CENTI, 20
LI_UNITS_FEET, 20
LI_UNITS_INCHES, 20
LI_UNITS_KILOMS, 20
LI_UNITS_METRES, 20
LI_UNITS_MILES, 20
LI_UNITS_MILLI, 20
LI_UNITS_YARDS, 20
LI_WARM_WHITE_FLUORESCENT, 18
LI_WHITE_FLUORESCENT, 18
LiColourRGBFloatToXYZ, 55
LiColourTemperatureToXYZ, 55
LiColourxyYToXYZ, 55
LiColourXYZToRGBFloatClampFull, 55
LiColourXYZToRGBFloatClampNonNegative, 55
Advanced Lighting
Index
Master Doc
Title Page
Contents
First
Last
J
I
Page 68 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
LiColourXYZToxyY, 55
LiEmissionSetCreate, 25
LiEmissionSetFromImage, 25
LiEmissionSetToImage, 25
LiForegroundSet, 12
light sources
area, 31
"area goniometric", 30
"area sky", 37
colour, 18
colour temperature, 18
goniometric, 24
"line goniometric", 28
"distant", 19
"point", 18
"spot", 19
"simple sky", 39
"sky", 34, 35, 40
types, 35
lighting
interiors, 24
"line goniometric" light source shader, 28
LiPhotoConvertToPhoto, 16
LiPhotoConvertToRadio, 17
LiShaderGetArg, 27
LiShaderPrerender, 27
LiSkyTypeCreate, 22
LiSkyTypeDestroy, 22
LiToneListSet, 48, 49
LiUnitsInverseLinearScale, 21
LiUnitsInverseSquareScale, 22
LiUnitsLinearScale, 21
LiUnitsSquareScale, 21, 22
photometry
colour temperature, 18
Planck
black body distribution, 18
portal light, 24
shader
colour
blue marble, 12
solid clouds, 12
turbulent, 12
foreground
fog light, 11
scattering medium, 9, 11 13
light source
ambient, 15
area, 7, 8
area goniometric, 8, 15, 24, 30, 31
area sky, 8, 15, 34, 37, 38, 40
distant, 19, 34
environment, 8
goniometric, 7, 8, 24 31
line goniometric, 8, 15, 24, 28, 29
point, 11, 17 19, 26
portal, 8
projector, 8
simple environment, 8
simple sky, 7, 8, 34, 36, 39
sky, 7, 8, 15, 17, 34 41
spot, 11, 19, 25
sun, 7, 8, 24
post process
tone, 9
tone contrast scale, 9
tone linear ceiling, 9
reflectance
lit appearance, 7, 9
radiosity stepped false, 9
tone
brighten up, 9, 13
polynomial approximation, 9
scale, 9
white balance, 9
"simple sky" light source shader, 39
"portal" light source shader, 24
"sky" light source shader, 34, 40
"sun" light source shader, 22
sun light, 22
Lightworks Author
9.1
Advanced Lighting
Index
units
of length, 20
white point
table, 56
Master Doc
Title Page
Contents
First
Last
J
I
Page 69 of 70
Go Back
Search This Doc
Search All Docs
Full Screen
Lightworks Documentation Feedback
Please help us to improve our documentation by taking the time to complete and return this form,
once you are familiar with the product. You may photocopy this page.
Your name:
Date:
Your job title:
Company:
Lightworks Author
9.1
How many years programming experience do you have?
C:
C++:
Advanced Lighting
Other (please specify):
How would you rate your level of knowledge and experience of 3D computer graphics?
2 Relative novice 2 Competent 2 Expert
Name of manual:
Part No. (given on first page of each manual) :
How would you rate the clarity of the manual? 2 Good
2 Satisfactory
2 Poor
Do you feel that the manual is pitched at the right level technically?
2 Yes 2 No, it's too simple 2 No, it's too technical
How would you rate the use of examples in the manual? 2 Good
Master Doc
2 Satisfactory
2 Poor
Were there any sections or concepts which could be made clearer by the use of more examples?
2 No 2 Yes If `Yes', give details:
Title Page
Contents
Were there any sections or concepts where the explanation given in the text was confusing or
lacking? 2 No 2 Yes If `Yes', give details:
How would you rate the overall standard of the manual?
2 Excellent 2 Good 2 Satisfactory 2 Below average
Additional comments (attach additional sheets if required):
2 Poor
First
Last
J
I
Page 70 of 70
Go Back
Search This Doc
Search All Docs
Full Screen

Advanced Lighting documentation

Transcription

Similar documents

modern designs - Resene Paints

A Powerpoint Presentation by Astronomer Robert Gillette

BevMo! - Bill Brown Sales

`Tyci Tavoli series of tables` product card

features

Alfredo De Vido Architects Kate`s Paperie

Introduction to the DirectX 9 Shader Models

resources - Old

0845 SKY 11 BBWF C - Sky Lake Sions Loft

EPC-A-1 Emergency Power Relay