Open Geospatial Consortium

Submission Date: 2020-01-21

Approval Date:   2020-08-24

Publication Date:   2021-02-26

External identifier of this OGC® document: http://www.opengis.net/doc/BP/CDB/openflight/1.2

Internal reference number of this OGC® document:    16-009r5

Version: 1.2

Category: OGC® Best Practice

Editor:   Carl Reed

Volume 6: OGC CDB Rules for Encoding CDB Models using OpenFlight (Best Practice)

Copyright notice

Copyright © 2021 Open Geospatial Consortium

To obtain additional rights of use, visit http://www.ogc.org/legal/

Warning

This document defines an OGC Best Practice on a particular technology or approach related to an OGC standard. This document is not an OGC Standard and may not be referred to as an OGC Standard. It is subject to change without notice. However, this document is an official position of the OGC membership on this particular technology topic.

Document type:    OGC® Best Practice

Document subtype:   

Document stage:    Approved

Document language:  English

License Agreement

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD.

THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications. This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

Table of Contents

i. Abstract

This volume defines the OpenFlight implementation requirements for a CDB conformant data store. Please also see Volume 1 OGC CDB Core Standard: Model and Physical Structure for a general description of all of the industry standard formats specified by the CDB standard. Please read section 1.3.1 of that document for a general overview.

ii. Keywords

The following are keywords to be used by search engines and document catalogues.

ogcdoc, OGC document, cdb, openflight

iii. Preface

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

iv. Submitting organizations

The following organizations submitted this Document to the Open Geospatial Consortium (OGC):

Organization name(s)

  • CAE Inc.

  • Carl Reed, OGC Individual Member

  • Envitia, Ltd

  • Glen Johnson, OGC Individual Member

  • KaDSci, LLC

  • Laval University

  • Open Site Plan

  • University of Calgary

  • UK Met Office

v. Submitters

All questions regarding this submission should be directed to the editor or the submitters:

Name

Affiliation

Carl Reed

Carl Reed & Associates

David Graham

CAE Inc.

1. Scope

This volume of the CDB standard defines a set of conventions to represent 2D and 3D models based on version 16.0 of the OpenFlight Scene Description Database Specification as annotated in Appendix C of this document.

For ease of editing and review, the standard has been separated into 16 Volumes, one being a schema repository.

  • Volume 0: OGC CDB Companion Primer for the CDB standard (Best Practice).

  • Volume 1: OGC CDB Core Standard: Model and Physical Data Store Structure. The main body (core) of the CDB standard (Normative).

  • Volume 2: OGC CDB Core Model and Physical Structure Annexes (Best Practice).

  • Volume 3: OGC CDB Terms and Definitions (Normative).

  • Volume 4: OGC CDB Rules for Encoding CDB Vector Data using Shapefiles (Best Practice).

  • Volume 5: OGC CDB Radar Cross Section (RCS) Models (Best Practice).

  • Volume 6: OGC CDB Rules for Encoding CDB Models using OpenFlight (Best Practice).

  • Volume 7: OGC CDB Data Model Guidance (Best Practice).

  • Volume 8: OGC CDB Spatial Reference System Guidance (Best Practice).

  • Volume 9: OGC CDB Schema Package: http://schemas.opengis.net/cdb/ provides the normative schemas for key features types required in the synthetic modeling environment. Essentially, these schemas are designed to enable semantic interoperability within the simulation context (Normative).

  • Volume 10: OGC CDB Implementation Guidance (Best Practice).

  • Volume 11: OGC CDB Core Standard Conceptual Model (Normative).

  • Volume 12: OGC CDB Navaids Attribution and Navaids Attribution Enumeration Values (Best Practice).

  • Volume 13: OGC CDB Rules for Encoding CDB Vector Data using GeoPackage (Normative, Optional Extension).

  • Volume 14: OGC CDB Guidance on Conversion of CDB Shapefiles into CDB GeoPackages (Best Practice).

  • Volume 15: OGC CDB Optional Multi-Spectral Imagery Extension (Normative).

2. Conformance

This standard defines requirements for implementing OpenFlight content in a CDB compliant data store.

Requirements for 1 standardization target types are considered.

Conformance with this standard shall be checked using all the relevant tests specified in Annex A (normative) of this document. The framework, concepts, and methodology for testing, and the criteria to be achieved to claim conformance are specified in the OGC Compliance Testing Policies and Procedures and the OGC Compliance Testing web site [1].

In order to conform to this OGC™ interface standard, a software implementation shall choose to implement:

  1. Any one of the conformance levels specified in Annex A (normative).

All requirements-classes and conformance-classes described in this document are owned by the standard(s) identified.

3. References

The following normative documents contain provisions that, through reference in this text, constitute provisions of this document. For dated references, subsequent amendments to, or revisions of, any of these publications do not apply. For undated references, the latest edition of the normative document referred to applies.

OpenFlight Specification version 16.4

http://www.presagis.com/products_services/standards/openflight/

4. Terms and Definitions

This document uses the terms defined in Sub-clause 5.3 of [OGC 06-121r8], which is based on the ISO/IEC Directives, Part 2, Rules for the structure and drafting of International Standards. In particular, the word “shall” (not “must”) is the verb form used to indicate a requirement to be strictly followed to conform to this standard.

For the purposes of this document, the additional terms and definitions provided in the OGC CDB Terms and Definitions document (Volume 3) apply.

4.1. A note on OpenFlight

OpenFlight (or .flt) [2] is a 3d geometry model file format originally developed by Software Systems Inc. for its MultiGen [3] real-time 3d modeling package in 1988. Originally called Flight, the format was designed as a nonproprietary 3D model format for use by real-time 3d visual simulation image generators. The format was later renamed to OpenFlight to denote its nonproprietary image generation (IG) usage. The MultiGen modeling package (known now as Creator [4]) and the OpenFlight format were rapidly adopted by the early commercial flight simulation industry in the later 80’s and early 90’s. NASA Ames was the first customer for the MultiGen modeling package.

The early advantage OpenFlight held over many 3d geometry model file formats (.obj, .dxf, .3ds) was its specific real-time 3d graphics industry design. This means that the format is polygon based (rather than NURB surfaces), and provides a real-time tree structure essential for real-time IG systems. Most early graphics file formats worried more about visual esthetics for non-real-time based rendering graphics packages such as Wavefront Technologies, or Alias Systems Corporation.

The OpenFlight file format is still widely used today in the high end real-time visual simulation industry as the standard interchange format between different IG systems, and is currently administrated by Presagis.

5. Conventions

This sections provides details and examples for any conventions used in the document. Examples of conventions are symbols, abbreviations, use of XML schema, or special notes regarding how to read the document.

5.1. Identifiers

The normative provisions in this standard are denoted by the URI

http://www.opengis.net/spec/CDB/1.1/openflight/{requirement}

All requirements and conformance tests that appear in this document are denoted by partial URIs that are relative to this base.

For the sake of brevity, the use of “req” in a requirement URI denotes the literal:

http://www.opengis.net/spec/core/cdb/1.1/openflight

An example might be:

req/openflight/crs

5.2. Schemas

The following XML Schemas can be found in the OGC CDB Standard schema repository:

  1. Base_Material_Table.xsd

  2. Composite_Material_Table.xsd

  3. Configuration.xsd

  4. Defaults.xsd

  5. Feature_Data_Dictionary.xsd

  6. Lights.xsd

  7. Lights_Tuning.xsd

  8. Model_Components.xsd

  9. Model_Metadata.xsd

  10. OpenFlight_Model_Extensions.xsd

  11. Vector_Attributes.xsd

  12. Version.xsd

6. CDB OpenFlight Models

This volume of the CDB standard defines a set of conventions for representing 2D and 3D models based on version 16.0 of the OpenFlight Scene Description Database Specification as annotated in Appendix C of this document. The conventions presented here address the needs of several types of simulation clients including OTW, FLIR, NVG, CGF, radar, and laser, acoustic, magnetic, visual and thermal sensors.

Requirements Class – CRS Metadata

/req/core/metadata

Target type

Operations

Dependency

OpenFlight Specification

Dependency

File Management system

Requirement 1

/req/core/openflight/header-crs

6.1. OpenFlight File Header

The OpenFlight Header Record contains descriptive coordinate reference system (CRS) metadata about the manner vertices are encoded, and how these vertices are applied to an earth model and a projection type. On the other hand, the CDB standard itself mandates a prescribed set of conventions in this regard.

Requirement 1

http://www.opengis.net/spec/CDB/1.1/openflight/header-crs

As a result; the following OpenFlight Header records SHALL be set as follows:

Projection Type:

• Flat Earth, value 0: This is the type of projection used by most CDB Models, GTModel, GSModel, and MModel.

• Geodetic, value 5: This is the type of projection used by T2DModels.

Earth Ellipsoid Model:

• WGS-84, value 0: This is the Earth model to use with T2DModels. The field is ignored with other CDB Models.

6.2. OpenFlight Model Tree Structure

The internal structure of OpenFlight models is a tree structure that consists of nodes having child nodes as well as sibling nodes [5]. This type of tree structure is called a directed acyclic graph, or DAG. The general tree structure of a Model resembles that of Figure 6‑1: General OpenFlight Tree Structure.

image1

Figure 6-1. General OpenFlight Tree Structure

The CDB standard uses Group Nodes to arrange Models in a hierarchical manner. This way of organizing models helps identify components of interest.

The CDB standard 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 standard, 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 standard 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 standard uses comments to store the extra attributes required by the specialization of existing OpenFlight nodes [6]. 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 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.

Requirements Class – tree structure

/req/core/tree-structure

Target type

Operations

Dependency

OpenFlight Specification

Dependency

CDB File Management system

Requirement 2

/req/core/openflight/model-global-zone

Requirement 3

/req/openflight/2dmodel

Requirement 4

/req/openflight/2dmodel-rules

Requirement 5

/req/openflight/2dmodels

Requirement 6

/req/openflight/xref

6.2.1. CDB Model Tree Structure

Based on Figure 6‑1 above, the internal structure of CDB Models resemble this one:

InternalStructureofCDBModels

Figure 6-2. Internal Structure of CDB Models

Requirement 2

req/model-global-zone

All CDB Models SHALL 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 follows:

InternalStructureofT2DModels

Figure 6-3. Internal Structure of T2DModels

Requirement 3

req/openflight/2dmodel

Each 2DModel SHALL be 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.

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.

Requirement 4

req/openflight/2dmodel-rules

A 2DModel SHALL have at least two layers, layer 0 and layer 1.

Layer 0 SHALL always empty because it represents the terrain on top of which subsequent layers are applied.

Each layer is composed of zero, one, or more OpenFlight Object nodes.

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.

Subfaces are not permitted because coplanar geometry is implemented through layers.

Node Attributes

Requirement 5

req/openflight/2dmodels

For T2DModels, node attributes (section 6.12) SHALL be 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 standard defines naming conventions for objects stored in an OpenFlight file, the standard does not constrain the OpenFlight node names themselves. Instead, the CDB standard 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 edit/create 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 standard 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 standard 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.

Table 6-1: Sample XML Tag Used in a Comment Record

<CDB:Zone

name = "zone name"

/>

All XML tags defined by the CDB standard belong to a single XML namespace that is appropriately named CDB [7].

6.2.4. Model Master File

A Model Master file is an OpenFlight file that contains only external references to other OpenFlight files. The purpose of the master file is to ensure a Model is seen as a single “object” even though its constituents are stored in separate files. The use of a model master file provides a convenient means for modelers to reference all of the constituent files that make up the model. There is no other purpose associated to the master file.

The concept of a Model Master file is used in a single case, to regroup all representations (all LODs) of a geotypical model into a single OpenFlight file. However, the concept applies to all types of CDB Models. The concept can also be used to regroup a model’s shell with its interior. For this reason, expect new usage of the Model master file in future version of the Standard.

The master file is useful in two circumstances: when modelers create or edit Models, and when client devices want to discover at once all constituents of Models.

For modelers, it is useful (if not required) to edit a model using a single source file to present a coherent view of the model as a whole. For this reason, a master file with a set of LOD-XRef nodes is perfect to assemble and present a unified view of the model to edit.

Figure 6‑4: Typical Structure of a Model Master File presents the general structure of a master file.

TypicalStructureofModelMasterFile

Figure 6-4. Typical Structure of Model Master File

The value found in the Significant Size field of the above LOD nodes matches the values found in Table 3‑1 of Volume 1 CDB Core Standard: CDB LOD vs. Model Resolution. The next section provides details on XRef nodes themselves.

6.2.5. Referencing Other OpenFlight Files

Requirement 6

req/openflight/xref+

An OpenFlight external reference (XRef) node is used to refer to another OpenFlight file. The reference is made by specifying the filename and its path (absolute or relative). The CDB Standard requires that all references SHALL be made using a relative path.

The XRef node (and its External Reference record) supports a number of options: Override flags, View-As-Bounding-Box flag, and Target Node Name. The CDB standard supports none of these options.

Here are two cases to illustrate the use of XRef nodes.

Models Straddling Multiple Files

In the case of GTModels, GSModels, and MModels, the OpenFlight geometry can straddle multiple files. It could be seen in a moving model (e.g., a helicopter) whose pilot could be stored in a separate file. In that case, the file containing the pilot resides in the same directory as the file containing the helicopter itself. The helicopter would be stored in file 1:

\CDB\MModel\600_MModelGeometry\1_Platform\2_Air\225_United_States\21_Utility_Helo\1_2_225_21_x_x_x\D600_S001_T001_1_2_225_21_x_x_x.flt

The pilot would be stored in file 2:

\CDB\MModel\600_MModelGeometry\1_Platform\2_Air\225_United_States\21_Utility_Helo\1_2_225_21_x_x_x\D600_S001_T002_1_2_225_21_x_x_x.flt

The XRef node in file 1 would contain the following string:

.\D600_S001_T002_1_2_225_21_x_x_x.flt

where 1_2_225_21_x_x_x is the complete DIS code of the helicopter.

Models with Multiple Model-LODs

This is the case of the master file of a geotypical model. The master file (known as the GTModelGeometry Entry File) refers to all levels of details of the geometry files that reside in different sub-directories. Assuming a geotypical model representing a gothic church, the master file itself would reside in a directory such as this one:

\CDB\GTModel\500_GTModelGeometry\A_Culture\L_Misc_Feature\015_Building\D500_S001_T001_AL015_050_Church-Gothic.flt

The targets of the XRef nodes would all reside in directories such as these:

\CDB\GTModel\500_GTModelGeometry\A_Culture\L_Misc_Feature\015_Building\Lnn\D510_S001_T001_Lnn_AL015_050_Church-Gothic.flt

The resulting strings to use in the XRef nodes in the master file would resemble this:

.\Lnn\D510_S001_T001_Lnn_AL015_050_Church-Gothic.flt

where Lnn corresponds to the LOD the XRef file resides in.

6.3. Modeling Conventions

Requirements Class – Modeling Conventions

/req/model-conventions

Target type

Operations

Dependency

OpenFlight Specification

Requirement 7

/req/openflight/crs-models

Requirement 8

/req/openflight/model-origin

Requirement 9

/req/openflight/t2-model-coordinates

Requirement 10

/req/openflight/roll-pitch-yaw

Requirement 11

/req/openflight/geometry

Requirement 12

/req/openflight/geometry-layer-constraint

6.3.1. Model Coordinate Systems

Requirement 7

req/openflight/crs-models

CDB Models SHALL use the same coordinate system convention as OpenFlight[8]. The X-axis traverses the model from left to right, the Y-axis goes from the back to the front and the Z-axis extends from the bottom to the top of the model.

Figure 6- 5: Model Coordinate System is a screenshot [9] of Creator [10] showing a CAD view of a semi-transparent cube.