89 Copyright © 2017 Open Geospatial Consortium
convention. This convention permits clients to internally derive all of the properties and parameters needed to render the light. The approach is entirely device-independent. Modelers
need not concern themselves with hundreds of parameters, many of which are often specific to underlying algorithms within the client. The naming convention ensures that the client has all of
the information needed to capture the modeler’s intent. Because the approach is device- independent, the rendering is limited only by the client’s capabilities, not by the database itself.
As a result, lights in OpenFlight are defined by inserting an Indexed Light Point record into the OpenFlight scene graph. A vertex and a normal are stored in a Vertex List record that defines
the position and direction of the light. The name of the light type is stored in the Light Point Appearance Palette record.
The light type’s name fully defines the appearance, animation and other characteristic relevant to the field of simulation. It is the responsibility of the client to supply the internal parameters that
correspond to each of the light types supported by the CDB standard.
Light type naming conventions are defined in Section 2.3 of the Volume 1: OGC CDB Core Standard:Model and Physical Database Structure, CDB Core Model, Light Naming, and the list
of names is presented in Annex J, Volume 2: OGC CDB Core: Model and Physical Structure: Annexes formerly CDB Best Practice Volume 2 Appendix E.
Requirement 35
Req 35 reqopenflightlight-vertex-list
A Vertex List record SHALL follow the OpenFlight Indexed Light Point record. .
The list of vertices contains one vertex if a single light point is defined. The list contains several vertices when multiple independent light points are defined. An optional matrix and replication
count permits the definition of a light string.
Table 6-32: OpenFlight Records for a Light Point
INDEXED LIGHT POINT MATRIX optional
REPLICATE optional PUSH LEVEL
VERTEX LIST POP LEVEL
6.12 Model Attributes
This section defines a general attribution mechanism to add CDB and Vendor-specific attributes to any OpenFlight nodes. These attributes follows the rules of inheritance; they are
automatically propagated from higher levels through lower levels of the OpenFlight graph. A child node inherits the attribution of its parent node.
90 Copyright © 2017 Open Geospatial Consortium
6.12.1 Definition
Model attributes are added to OpenFlight nodes through a Comment record containing XML tags. The general format is as follow:
CDB:node name=... ns:Attribute name=... value=...
... other attributes CDB:node
CDB:node
identifies the node to which the attributes are added. The
node
token can take the following values:
• Zone
• Point
• Group
• Object
• Switch
• Face
• Mesh
• Articulation
• Light
• XRef
• LOD
The XML namespace
ns
of the attribute is optional; when present it identifies the owner of the attribute. When not specified, the default namespace is CDB.
Any Error Reference source not found. that are listed in section Error Reference source not found. can be used as node attributes. The name of the attribute is the key to search for the
matching symbol into the metadata file named CDB_Attributes.xml; this file is described in section Error Reference source not found. and provides the means to interpret the value of the
attribute.
6.12.2 Vendor Attributes
A vendor attribute is identified by its XML namespace. The standard uses the CDB namespace; a vendor may use any other string to identify itself.
Requirement 36
Req 36 reqopenflightmodel-vendor-attributes
The definition of vendor attributes SHALL be stored in Vendor_Attributes.xml
91 Copyright © 2017 Open Geospatial Consortium
It is understood that vendor attributes are not interpreted by any other client-devices other than those supported by the vendor. Reliance by a vendor on Vendor Attributes can reduce the
interoperability of the CDB with other vendors.
6.12.3 Examples
To add the LPH attribute to a CDB Light node, use the following comment:
CDB:Light Attribute name=LPH value=300
CDB:Light
Assume a T2DModel contains the Los Angeles International Airport as one of its 2DModels; the zone associated with the airport could use the APID attribute in the following manner:
CDB:Zone name=Los Angeles International Airport Attribute name=APID value=KLAX
CDB:Zone
A company named “Acme Inc.” uses the string “Acme” as the namespace qualifying its vendor- specific attributes. If the company wants to add the MyAttr attribute to a CDB Articulation, it
could do so by using the following XML tags:
CDB:Articulation name=Primary Gun 1 id=4416 Acme:Attribute name=MyAttr value=-1.23
CDB:Articulation
To interpret the attribute, a client application searches the file Vendor_Attributes.xml for an attribute whose symbol is
MyAttr
. When found, the application knows how to parse and interpret the attribute’s
value
. Furthermore, if the client application recognizes the identification of the vendor
Acme:
, it knows what to do with
MyAttr
.
6.13 Model Textures Requirements Class – Model Textures
