131
© 2016 Open Geospatial Consortium
Note that light code numbering need not be consecutive. Light codes have a one-to-one association with light types; consequently, the light codes are unique among all light types.
5.1.1.1 Client Specific Lights Definition Metadata
Client-devices use the light type code as an index to lookup the client-specific properties and characteristics of each light type. This approach is client-device independent because the
device-specific client’s rendering parameters are local to its implementation. As a result, modelers need not bother setting or even understanding the many parameters specific to each
light type and to each client-device type.
The CDB standard also offers a complementary approach to modifying the appearance of lights. This approach provides basic control over light intensity, color, lobe width and aspect, frequency
and duty cycle to client devices. The approach also permits a modeler to add new light types to the CDB light hierarchy.
Example:
As an example, we will create a client-specific lights definition metadata file for a hypothetical client-device. The information would be held in the Lights_xxx.xml metadata file corresponding
to the client-device for which lights are to be tuned. There can be one file per client-device and the file for each client-device is optional. The file is not required if the modeler does not wish to
adjust the basic characteristics of one or more light types for the associated client-device, or heshe doesn’t require new light types to be added to the CDB light hierarchy. The metadata file
would be loaded by the client-device whose name matches the “xxx” character string of the Lights_xxx.xml file. As for the Lights, the file would be located at the top of the CDB storage
hierarchy in directory \CDB\Metadata\ as described in Section 3.1.1, Metadata Directories.
Nominally, the Lights_xxx.xml consists of light type entries corresponding to the light types the modeler wishes to addmodify. Each entry in the Lights_xxx.xml file consists of one or optional
fields.
Consider the case of a simulator equipped with a client-device rendering simulated imagery for model “A” NVG goggles and a second client-device rendering simulated imagery for model “B”
NVG goggles. After viewing the CDB on the simulator, the modeler wishes to diminish the intensity of the \Lights\Cultural\Line-based\Highway lights for model “A” NVG goggles to 90
of the intensity calculated by the simulator. To do this, the modeler creates a Lights_NVG_A.xml, creates a light type entry for \Lights\Cultural\Line-based\Highway and
provides an intensity field with value of 0.9. Note that all other characteristics of the light type in this client-device are unaffected since the modeler did not provide additional fields.
Furthermore, the characteristics of the light type in all other client-devices remain unaffected since the modeler did not provide other Lights_xxx.xml files.
The XML schema for the fields of the Lights_xxx.xml is delivered with the standard in \CDB\Schema\Lights_Tuning.xsd. The fields are:
132
© 2016 Open Geospatial Consortium
• Intensity: When a light type is non-native to the CDB standard, which means that
it is without a corresponding entry in Annex J Intensity represents the light point intensity for the client-device range normalized from 0.0 to 1.0. When the light
entry is native to the CDB standard, Intensity is used as a floating-point intensity modifier that multiplies the intensity calculated by the client-device. In both cases,
Intensity defaults to a value of 1.0.
•
Color: When a light type is non-native to the CDB standard, Color is a floating- point RGB triplet that represents the color of the light type for the client-device
range normalized from 0.0 to 1.0. When the light entry is native to the CDB specification, Color is a floating-point RGB triplet that multiplies the RGB value
calculated by the client-device. Color applies only to visual system client-device types. If absent in a light type entry, Color defaults to a value of white 1.0, 1.0,
1.0.
•
Directionality: A string that categorizes the light type as “Omnidirectional”, “Directional” or “Bidirectional”. If absent in a light type entry, Directionality
defaults to the value “Omnidirectional”.
• Lobe_Width: Represents the identifying section for the light’s lobe width
characteristics, which can have a horizontal and vertical attribute.
o Horizontal: When a light type is
non-native to
the CDB
specification, the
Horizontal field represents the light point’s
half-intensity horizontal lobe width for the client-device
range from 0.0 to 360.0. When the light entry is native to the
CDB standard, Horizontal field is used as a floating-point modifier that multiplies the horizontal lobe width calculated by the client-device. Applies
only to Directional and Bidirectional light types. If absent in a light type entry, Horizontal field defaults to a value of 1.0.
o Vertical: When a light type is non-native to the CDB standard, Vertical
field represents the light point’s half-intensity vertical lobe width for the client-device range from 0.0 to 360.0. When the light entry is native to
the CDB standard, Vertical field is used as a floating-point modifier that multiplies the vertical lobe width calculated by the client-device. This
applies only to Directional and Bidirectional light types. If absent in a light type entry, Vertical field defaults to a value of 1.0.
•
Residual_Intensity: When a light type is non-native to the CDB standard, Residual_Intensity represents the residual intensity of the light. Residual intensity
is the intensity of the light range normalized from 0.0 to 1.0 outside of the lobe defined by Lobe_Width:Horizontal and Lobe_Width:Vertical fields. When the
light entry is native to the CDB specification, Residual_Intensity is used as a
133
© 2016 Open Geospatial Consortium
floating-point modifier that multiplies the residual intensity calculated by the client-device. This applies only to Directional and Bidirectional light types. If
absent in a light type entry, Residual_Intensity defaults to a value of 1.0.
• Frequency: A floating-point value greater than or equal to 0.0 that sets the blink or
rotating frequency of the light in Hertz cycles per second. A value of 0.0 disables all blinking and rotating properties. If absent in a light type entry, Frequency
defaults to a value of 0.0.
•
Duty_Cycle: A floating-point value ranging from 0.0 to 1.0 that sets the duty cycle of the light. Duty cycle is defined as the percentage of time the light is turned on
over a complete cycle. A value of 0.0 permanently turns the light off. A value of 1.0 turns it on. The value is ignored if Frequency = 0.0. If absent in a light type
entry, Duty_Cycle defaults to a value of 0.5.
Here is a sample of a Lights_xxx.xml file where a modeler has exercised explicit control over the properties of an anti-collision light and a landing light.
Lights_Tuning Light type=\Light\Platform\Air\Aircraft_Helos\Anti-collision
DescriptionTuned for MH-47 CMSDescription Intensity0.75Intensity
Color1.0 0.0 0.0Color DirectionalityOmnidirectionalDirectionality
Frequency0.5Frequency Duty_Cycle0.2Duty_Cycle
Light Light type=\Light\Platform\Air\Aircraft_Helos\Landing
Description...Description Intensity1.0Intensity
Color1.0 0.9 0.9Color DirectionalityDirectionalDirectionality
Residual_Intensity0.05Residual_Intensity Lobe_Width
Horizontal30.0Horizontal Vertical25.0Vertical
Lobe_Width Light
Lights_Tuning
134
© 2016 Open Geospatial Consortium
5.1.2 Model Components Definition File
