312 © 2015 Open Geospatial Consortium
Figure 6-1: General OpenFlight Tree Structure
The CDB Specification uses Group Nodes to arrange Models in a hierarchical manner. This way of organizing models helps identify components of interest.
The CDB Specification refers to a number of OpenFlight nodes to store meaningful data for simulation client-devices. For a complete list of nodes supported by the CDB Specification, see
Appendix C. The nodes listed here are the ones referred to by one or more CDB conventions.
An example of an ancillary record is the OpenFlight comment record. A comment record may appear once, anywhere after a node’s primary record. The CDB Specification relies on comment
records to extend the definition of OpenFlight nodes. Instead of using the Extension Record to create new primary and ancillary records, the CDB Specification uses comments to store the
extra attributes required by the specialization of existing OpenFlight nodes
46
. Comment records were chosen over OpenFlight extensions in order to minimize any changes to the Creator tool or
the need to develop a plug-in to Creator. Using this approach, anybody can create CDB- compliant models using a plain version of Creator. Nevertheless, the development of Creator
CDB plug-ins would improve modeler’s efficiency. Such plug-ins could, for instance, offer a
46
CDB-compliant readers must ignore all OpenFlight extension records.
Group node 1
LOD node 1
LOD node 2
Header node
DOF node 1
Object node 1
DOF node 2
Object node 3
Object node 4
Object node 2
Switch node
Light Point
313 © 2015 Open Geospatial Consortium
menu-based GUI to allow modelers to enter and edit CDB comments, while ensuring that syntax and conventions are fully adhered to.
The text contained in the comment record is formatted using the XML notation.
6.2.1 CDB Model Tree Structure
Based on Figure 6-1 above, the internal structure of CDB Models resemble this one:
Global Zone
Other nodes
db
...
Figure 6-2: Internal Structure of CDB Models
All CDB Models have a global zone as their root node. This node identifies the model. Global zones are defined in section 6.5.2 below.
6.2.2 T2DModel Tree Structure
A T2DModel being a collection of 2DModels, each individual 2DModel occupies its own subtree of the graph. The general structure of a T2DModel is as follow:
314 © 2015 Open Geospatial Consortium
Optional
Global
Zone
...
Zone
odel n
Object
ace
onformal ...
Zone
odel
sh
n
sh Group
er ...
Group
er
db
Group
er n
Figure 6-3: Internal Structure of T2DModels
Each 2DModel is implemented as a Model Zone section 6.5 with its own subgraph. 2DModels are disjoint and non-overlapping. A 2DModel is comprised of multiple layers; the layer number
is expressed by the group’s relative priority section 6.3.4. Each layer has an optional LOD node followed by a fixed hierarchy of regular OpenFlight Object, Face, and Mesh nodes.
315 © 2015 Open Geospatial Consortium
6.2.2.1 Restrictions
T2DModels being an alternate representation of the terrain and its imagery and materials, a number of restrictions are necessary to ensure client devices can consume the dataset efficiently.
1. A 2DModel has at least two layers, layer 0 and layer 1. 2. Layer 0 is always empty because it represents the terrain on top of which
subsequent layers are applied. 3. Each layer is composed of exactly one OpenFlight Object node.
4. All Face and Mesh nodes share exactly the same set of graphic attributes color, textures, material, and other flags. Stated differently, the Face and
Mesh nodes provide the shape of the layer while the Object node controls its appearance.
5. Subfaces are not permitted because coplanar geometry is implemented through layers.
6.2.2.2 Node Attributes
For T2DModels, node attributes section 6.12 are permitted only at the zone levels; that is, at the global zone or at the individual 2DModel zones. Node attributes are not permitted at the
Group, LOD, Object, Face, and Mesh node levels.
6.2.3 The Use of Node Names
Although the CDB Specification defines naming conventions for objects stored in an OpenFlight file, the Specification does not constrain the OpenFlight node names themselves. Instead, the
CDB Specification defines names that are assigned via XML tags stored in the comment record.
The following question arises, “Why not establish a set of CDB conventions around node names?” The answer lies primarily around constraints imposed by tools used to editcreate
OpenFlight files. Tools such as Creator require unique node names throughout the OpenFlight file. The OpenFlight format Specification itself does not state that node names must be unique;
however, a tool such as Creator prevents the modeler from entering the same node name twice.
To circumvent this limitation, the CDB Specification provides naming conventions through XML tags inserted in the comment record following a node’s primary record. This way of doing
things leaves modelers with the needed freedom in naming nodes. The CDB Specification defines how to organize a model; all extra object attributes that do not fit in the current
OpenFlight records are stored in the comment record, including object names.
Here is an example of XML tags stored in the comment record for a Group Node.
