Open Geospatial Consortium
Submission Date: 2018-03-20
Approval Date: 2018-08-27
Publication Date: 2018-12-19
External identifier of this OGC® document: http://www.opengis.net/doc/BP/CDB/openflight/1.1
Internal reference number of this OGC® document: 16-009r4
Version: 1.1
Category: OGC® Best Practice
Editor: Carl Reed

Volume 6: OGC CDB Rules for Encoding Data using
OpenFlight
Copyright notice
Copyright © 2018 Open Geospatial Consortium
To obtain additional rights of use, visit http://www.opengeospatial.org/legal/.

Warning
This document defines an OGC Best Practices 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:
Document subtype:
Document stage:
Document language:

OGC® Best PracticeApproved
EnglishCopyright © 2018 Open Geospatial Consortium

1

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 copyrightnotices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms ofthis 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, ANDNONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOTWARRANT 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 COPYRIGHTHOLDER 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 WHATSOEVERRESULTING 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 whichis 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 heldby 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.

Copyright © 2018 Open Geospatial Consortium2

Contents
1.

Scope ....................................................................................................................................... 92.

Conformance ........................................................................................................................... 93.

References ............................................................................................................................. 10

4.

Terms and Definitions........................................................................................................... 10
4.1

5.

6.

A note on OpenFlight................................................................................ 10

Conventions .......................................................................................................................... 11
5.1

Identifiers .................................................................................................. 11

5.2

Schemas .................................................................................................... 11

CDB OpenFlight Models ...................................................................................................... 12
6.1

OpenFlight File Header............................................................................. 12

6.2

OpenFlight Model Tree Structure ............................................................. 13

6.2.1

CDB Model Tree Structure ....................................................................... 14

6.2.2

T2DModel Tree Structure ......................................................................... 15

6.2.3

The Use of Node Names ........................................................................... 18

6.2.4

Model Master File ..................................................................................... 18

6.2.5

Referencing Other OpenFlight Files ......................................................... 19

6.3

Modeling Conventions .............................................................................. 21

6.3.1

Model Coordinate Systems ....................................................................... 21

6.3.2

Geometry................................................................................................... 29

6.3.3

Roof Tagging ............................................................................................ 30

6.3.4

Relative Priority ........................................................................................ 30

6.4

Model Identifiers....................................................................................... 30

6.4.1

GSModel and GTModel Identifier............................................................ 31

6.4.2

MModel Identifier..................................................................................... 31

Copyright © 2018 Open Geospatial Consortium3

6.4.3
6.5

2DModel Identifier ................................................................................... 31
Model Zones ............................................................................................. 31

6.5.1

Definition .................................................................................................. 32

6.5.2

Global Zones ............................................................................................. 33

6.5.3

Zone Attributes ......................................................................................... 34

6.5.4

Implementation Guidelines ....................................................................... 36

6.5.5

Model Zone Naming ................................................................................. 39

6.5.6

Usages ....................................................................................................... 40

6.6

Model Points ............................................................................................. 56

6.6.1

Definition .................................................................................................. 56

6.6.2

Usages ....................................................................................................... 57

6.7

Model Conforming.................................................................................... 62

6.7.1

Non Conformal (Absolute) Mode ............................................................. 63

6.7.2

Point Conformal Mode ............................................................................. 63

6.7.3

Vertex Conformal Mode ........................................................................... 64

6.7.4

Line Conformal Mode............................................................................... 65

6.7.5

Plane Conformal Mode ............................................................................. 66

6.7.6

Surface Conformal Mode .......................................................................... 68

6.8

Model Levels-of-Detail ............................................................................. 69

6.8.1

Exchange LODs ........................................................................................ 71

6.8.2

Additive LODs .......................................................................................... 71

6.8.3

Significant Size ......................................................................................... 72

6.8.4

LOD Limits ............................................................................................... 73

6.8.5

LOD Generation Guidelines ..................................................................... 75

6.9

Model Switch Nodes ................................................................................. 75

Copyright © 2018 Open Geospatial Consortium4

6.9.1

Definition .................................................................................................. 76

6.9.2

Usage......................................................................................................... 77

6.10

Model Articulations .................................................................................. 82

6.10.1

Definition .................................................................................................. 83

6.10.2

Usage......................................................................................................... 85

6.11

Model Light Points ................................................................................... 85

6.12

Model Attributes ....................................................................................... 86

6.12.1

Definition .................................................................................................. 87

6.12.2

Vendor Attributes...................................................................................... 87

6.12.3

Examples ................................................................................................... 88

6.13

Model Textures ......................................................................................... 88

6.13.1

Handling of Multi-textures ....................................................................... 90

6.13.2

Default Gamma Corrections ..................................................................... 93

6.13.3

Texture Dimension.................................................................................... 93

6.13.4

Texture Palette .......................................................................................... 94

6.13.5

Usages ....................................................................................................... 96

6.14

Model Descriptor (Metadata) Datasets ................................................... 111

6.14.1Model Name............................................................................................ 112

6.14.2Model Identification................................................................................ 112

6.14.3Model Mass............................................................................................. 113

6.14.4Model Parts ............................................................................................. 113

6.14.5Model Textures ....................................................................................... 114

6.14.6

Model Configurations ............................................................................. 116

6.14.7

Model Composite Materials.................................................................... 119

A.1

Conformance class: CRS ........................................................................ 120

Copyright © 2018 Open Geospatial Consortium

5

A.2

Conformance Class: Tree Structure ........................................................ 120

A.3

Conformance Class: Modeling Conventions .......................................... 121

A.4

Conformance Class: Model Zones .......................................................... 123

A.5

Conformance Class: Model Points.......................................................... 126

A.6

Conformance Class: Model Points.......................................................... 127

A.7

Conformance Class: Model Switch Nodes ............................................. 127

A.8

Conformance Class: Damage Status ....................................................... 128

A.9

Conformance Class: Model Articulations............................................... 129

A.10

Conformance Class: Model Textures...................................................... 130

FiguresFigure 6- 1: General OpenFlight Tree Structure ......................................................................................... 13
Figure 6- 2: Internal Structure of CDB Models .......................................................................................... 15
Figure 6- 3: Internal Structure of T2DModels ............................................................................................ 16
Figure 6- 4: Typical Structure of Model Master File .................................................................................. 19
Figure 6- 5: Model Coordinate System ....................................................................................................... 22
Figure 6- 6: Coordinate System - Aircraft .................................................................................................. 23
Figure 6- 7: Coordinate System - Helicopter .............................................................................................. 24
Figure 6- 8: Coordinate System - Ship ........................................................................................................ 24
Figure 6- 9: Coordinate System - Ground Based Model............................................................................. 25
Figure 6- 10: Coordiante System - Lifeform ............................................................................................... 25
Figure 6- 11: Coordinate System - Cultural Feature ................................................................................... 26
Figure 6- 12: Coordinate System - Power Pylon......................................................................................... 27
Figure 6- 13: Model Global Zone ............................................................................................................... 34
Figure 6- 14: Simple Zone .......................................................................................................................... 36
Figure 6- 15: Articulated Zone .................................................................................................................... 36
Figure 6- 16: Zone Hierarchy ...................................................................................................................... 37
Figure 6- 17: Simple Zone Graphical Representation ................................................................................. 37
Figure 6- 18: Additive LOD to Control the Graphical Representation ....................................................... 38
Figure 6- 19: Exchange LODs to Select the Graphical Representation ...................................................... 38
Figure 6- 20: Switch Node to Select the Graphical Representation ............................................................ 39
Figure 6- 21: Footprint Zone Structure ....................................................................................................... 42
Figure 6- 22: Cutout Zone Structure ........................................................................................................... 44
Figure 6- 23: Model Shell Structure ............................................................................................................ 45
Figure 6- 24: Model Interior Structure ........................................................................................................ 46
Figure 6- 25: Interior Zone Structure .......................................................................................................... 47
Figure 6- 26: Floor Zone Structure ............................................................................................................. 50
Figure 6- 27: Room Zone Structure ............................................................................................................ 51
Figure 6- 28: Fixture Zone Structure........................................................................................................... 52
Figure 6- 29: Fixture Zone Structure........................................................................................................... 53

Copyright © 2018 Open Geospatial Consortium

6

Figure 6- 30: Partition Zone Structure ........................................................................................................ 54
Figure 6- 31: Aperture Structure ................................................................................................................. 55
Figure 6- 32: Surface Zone Structure .......................................................................................................... 55
Figure 6- 33: Orientation of the Chinook Helicopter .................................................................................. 58
Figure 6- 34: The Body of the Chinook Helicopter .................................................................................... 59
Figure 6- 35: The DIS Origon of the Chinook Helicopter .......................................................................... 60
Figure 6- 36: Conforming Vertices to Terrain ............................................................................................ 62
Figure 6- 37: Origon Conformal Mode ....................................................................................................... 64
Figure 6- 38: Vertex Conformal Mode Example ........................................................................................ 65
Figure 6- 39: Line Conformal Mode ........................................................................................................... 66
Figure 6- 40: Plane Conformal Mode ......................................................................................................... 67
Figure 6- 41: Application of Line and Plane Conformal Modes on 3d Roads............................................ 68
Figure 6- 42: Surface Conformal Mode ...................................................................................................... 69
Figure 6- 43: Echange and Additive LOD Nodes ....................................................................................... 72
Figure 6- 44: Exchange LOD Nodes ............................................................Error! Bookmark not defined.
Figure 6- 45: General Damage State Tree Structure .................................................................................. 78
Figure 6- 46: Damage States Ordering ........................................................................................................ 79
Figure 6- 47: Example of a Texture Representing a Rotor ......................................................................... 81
Figure 6- 48: Multiple Versions of Rotating Parts ...................................................................................... 81
Figure 6- 49: Using Shadow Polygons ........................................................................................................ 97
Figure 6- 50: Example of a Shadow Map in the XY Plane ......................................................................... 97
Figure 6- 51: The M1A2 Abrams with Desert Camouflage........................................................................ 99
Figure 6- 52: The M1A2 Abrams with a Forest Camouflage ..................................................................... 99

Copyright © 2018 Open Geospatial Consortium

7

i.

ii.

Abstract

This volume defines the OpenFlight implementation requirements for a CDB conformant datastore. Please also see Volume 1 OGC CDB Core Standard: Model and Physical Structure for ageneral 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.

Keywords
The following are keywords to be used by search engines and document catalogues.
ogcdoc, OGC document, cdb, openflightiii.

Preface

Attention is drawn to the possibility that some of the elements of this document may be thesubject 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 thatmight be infringed by any implementation of the standard set forth in this document, and toprovide supporting documentation.

iv.

Submitting organizations

The following organizations submitted this Document to the Open Geospatial Consortium(OGC):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
The OGC CDB standard is based on and derived from an industry developed and maintained
specification, which has been approved and published as OGC Document 15-003: OGC
Common Data Base Volume 1 Main Body. An extensive listing of contributors to the legacy
industry-led CDB specification is at Chapter 11, pp 475-476 in that OGC Best Practices
Document (https://portal.opengeospatial.org/files/?artifact_id=61935).

Copyright © 2018 Open Geospatial Consortium

8

v.

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

Affiliation
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 annotatedin Appendix C of this document.
For ease of editing and review, the standard has been separated into 12 Volumes and 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 CBD 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 Use of Shapefiles for Vector Data Storage (Best Practice).
● Volume 5: OGC CDB Radar Cross Section (RCS) Models (Best Practice).
● Volume 6: OGC CDB Rules for Encoding Data 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: provides the normative schemas for key
features types required in the synthetic modelling environment. Essentially, theseschemas 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)

2. ConformanceThis standard defines requirements for implementing OpenFlight content in a CDB compliant
data store.
Requirements for 1 standardization target types are considered.

Copyright © 2018 Open Geospatial Consortium

9

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 thecriteria to be achieved to claim conformance are specified in the OGC Compliance Testing
Policies and Procedures and the OGC Compliance Testing web site1.
In order to conform to this OGC™ interface standard, a software implementation shall choose to
implement:a) Any one of the conformance levels specified in Annex A (normative).
All requirements-classes and conformance-classes described in this document are owned by thestandard(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 bestrictly 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 OpenFlight2
OpenFlight (or .flt) is a 3d geometry model file format originally developed by Software
Systems Inc. for its MultiGen[2]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
1 www.opengeospatial.org/cite
2 From Wikipedia.

Copyright © 2018 Open Geospatial Consortium

10

Creator[3]) 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 theMultiGen 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-realtime 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 simulationindustry 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/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

Copyright © 2018 Open Geospatial Consortium

11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 3Dmodels 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 typeOperations

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 anda projection type. On the other hand, the CDB standard itself mandates a prescribed set of
conventions in this regard.
Requirement 1
Req 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:o Flat Earth, value 0: This is the type of projection used by most CDB

Copyright © 2018 Open Geospatial Consortium

12•Models, GTModel, GSModel, and MModel.
o Geodetic, value 5: This is the type of projection used by T2DModels.
Earth Ellipsoid Model:
o 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 childnodes as well as sibling nodes3. This type of tree structure is called a directed acyclic graph, orDAG. The general tree structure of a Model resembles that of Figure 6- 1: General OpenFlight
Tree Structure.
Headernode

Groupnode 1

LOD
node 1

DOF
node 1

Objectnode 1

LOD
node 2

Objectnode 3

DOF
node 2

Switchnode

Objectnode 4

Light
Point

Objectnode 2

Figure 6- 1: General OpenFlight Tree Structure
3 In Appendix C, the section called Database Hierarchy explains in details how OpenFlight organizes its graph.

Copyright © 2018 Open Geospatial Consortium

13

The CDB standard uses Group Nodes to arrange Models in a hierarchical manner. This way oforganizing models helps identify components of interest.
The CDB standard refers to a number of OpenFlight nodes to store meaningful data forsimulation 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 tocreate new primary and ancillary records, the CDB standard uses comments to store the extra
attributes required by the specialization of existing OpenFlight nodes4. Comment records werechosen over OpenFlight extensions in order to minimize any changes to the Creator tool or theneed 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 typeOperations

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: General OpenFlight Tree Structure
4 CDB-compliant readers must ignore all OpenFlight extension records.

Copyright © 2018 Open Geospatial Consortium

14

above, the internal structure of CDB Models resemble this one:db

Global
Zone

Other
nodes

...

Figure 6- 2: Internal Structure of CDB Models

Requirement 2
Req 2

req/model-global-zone

All CDB Models SHALL have a global zone as their root node. This node identifies themodel. 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:

Copyright © 2018 Open Geospatial Consortium

15

db

Global
Zone

Zone

...

Group

...

Group

...

Mesh

2DModel #1

Group
Layer #0

Layer #1

Zone

2DModel #nLayer #n

LOD

(Optional)

ObjectFace(Conformal)

Mesh
#1

#n

Figure 6- 3: Internal Structure of T2DModels

Requirement 3
Req 3

req/openflight/2dmodel

Copyright © 2018 Open Geospatial Consortium

16

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 fixedhierarchy of regular OpenFlight Object, Face, and Mesh nodes.
6.2.2.1 Restrictions
T2DModels being an alternate representation of the terrain and its imagery and materials, anumber of restrictions are necessary to ensure client devices can consume the dataset efficiently.
Requirement 4
Req 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 thelayer while the Object node controls its appearance.
Subfaces are not permitted because coplanar geometry is implemented through layers.

6.2.2.2 Node Attributes
Requirement 5
Req 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.

Copyright © 2018 Open Geospatial Consortium

17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 OpenFlightrecords 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 CDB5.
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 (allLODs) of a geotypical model into a single OpenFlight file. However, the concept applies to alltypes 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 whenclient devices want to discover at once all constituents of Models.

5 The syntax to specify a XML namespace is <ns:element> where ns is the namespace and element is the XML

element name (or simply tag).

Copyright © 2018 Open Geospatial Consortium

18

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-XRefnodes is perfect to assemble and present a unified view of the model to edit.

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

db

Group

LOD

(coarsest)

XRef

...

LOD
(finest)XRefFigure 6- 4: Typical Structure of Model Master File

The value found in the Significant Size field of the above LOD nodes matches the values foundin Error! Reference source not found.. The next section provides details on XRef nodes
themselves.
6.2.5 Referencing Other OpenFlight Files
Requirement 6
Req 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

Copyright © 2018 Open Geospatial Consortium

19

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 ofthese options.
Here are two cases to illustrate the use of XRef nodes.
6.2.5.1 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 thefile 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.
6.2.5.2 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 indifferent 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

Copyright © 2018 Open Geospatial Consortium

20

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 typeOperations

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 7

req/openflight/crs-models

CDB Models SHALL use the same coordinate system convention as OpenFlight6. The Xaxis traverses the model from left to right, the Y-axis goes from the back to the front andthe Z-axis extends from the bottom to the top of the model.

6 The DIS standard defines a different orientation for the axes of its coordinate system.

DIS defines the X-axis as
pointing to the front of the entity; the Y-axis pointing to its right and the Z-axis pointing down. Adoption of the DIS
convention for use in the CDB standard has been rejected due to the fact that the majority of models in existence
have been created using tools such as Creator. The CDB standard follows the same convention as the one used bythese commercial tools. Note that if the CDB standard were to follow the DIS convention, modelers would be
required to create and edit their models upside down with respect to the reference plane provided by their tool.

Copyright © 2018 Open Geospatial Consortium

21

Figure 6- 5: Model Coordinate System is a screenshot7 of Creator8 showing a CAD view of asemi-transparent cube.

Figure 6- 5: Model Coordinate System

6.3.1.1 Origin
The location of the model origin is defined in the following manner:
Requirement 8
Req 8

req/openflight/model-origin

In the XY plane, the origin SHALL be located at the center of the bounding rectangle.
Along the Z axis, the origin SHALL be selected to allow the model to be correctly
positioned on ground for ground-related models, or on a water plan for surface andsubsurface platforms.

7 Most figures in this chapter are actual screenshots from Creator.
8 Creator or CAD Creator is a Siemans product. Mention of Creator in the CDB standard IS NOT an endorsement ofthat product.

Copyright © 2018 Open Geospatial Consortium

22

The following examples will illustrate the above two rules.
Fixed wing aircraft – A KC-130 Hercules is illustrated below with its landing gears fully
extended.

Figure 6- 6: Coordinate System - Aircraft

Helicopter – An AH-1W Super Cobra is shown below. Note that no equipment ismounted on its winglets.

Copyright © 2018 Open Geospatial Consortium

23

Figure 6- 7: Coordinate System - Helicopter

Surface ship – Shown below is the Arleigh Burke DDG-51 guided missile
destroyer. Note how the XY plane defines the waterline.

Figure 6- 8: Coordinate System - Ship
Figure 6-1: Coordinate System – Ship

Land Platform – The M1A2 Abrams is a main battle tank shown here with its
desert skin.

Copyright © 2018 Open Geospatial Consortium

24

Figure 6- 9: Coordinate System - Ground Based Model

Lifeform – A human lifeform (a soldier) is presented here.

Figure 6- 10: Coordiante System - Lifeform

Copyright © 2018 Open Geospatial Consortium

25

Cultural Feature – When a Model represents a cultural feature, the origin is thepoint of insertion of the model into the ground. In general, the XY plane(at Z = 0) delimits the basement from the first floor.

Figure 6- 11: Coordinate System - Cultural Feature

Copyright © 2018 Open Geospatial Consortium

26

Power Pylon – In the case of an electricity pylon, the front (and back) of themodel is aligned with the general direction of the attached wires.

Figure 6- 12: Coordinate System - Power Pylon

6.3.1.2 Local Coordinate Systems
Most OpenFlight nodes can have a local transformation used to create a local coordinate system.
The origin and orientation of this coordinate system are expressed by a single transformation
matrix.
When a transformation is specified for a node’s primary record, only the matrix record (opcode49) is considered by CDB client-devices. All other transformation records (opcode 76, 78, 79,
80, 81, 82 and 94) are discarded9.
6.3.1.3 Units

6.3.1.3.1 GSModels and GTModels

The MODL attribute of the GSFeature and GTFeature datasets are used to reference GSModels
and GTModels. In turn, the position of GSModels and GTModels are obtained from thecoordinates of each point of the associated vector data set; these coordinates are interpreted as

9 Typically, these transformations are used by modeling editing tools only.

Copyright © 2018 Open Geospatial Consortium

27

the latitude (y), longitude (x), and elevation (z) coordinates that position the model within the
CDB10.
GSModels and GTModels are drawn to real-world dimensions using meters as their unit ofmeasurement.

6.3.1.3.2 MModels
MModels are usually internally activated and positioned by the client-devices in response to arunning simulation.
In the case of Moving Model location features, the MMDC attribute of the GTFeature dataset isused to reference a MModel. Otherwise, the MModel behaves exactly as a GTModel as
described in section 6.3.1.3.1 above.
MModels are drawn to real-world dimensions using meters as their unit of measurement.

6.3.1.3.3 T2DModels
Requirement 9
Req 9

req/openflight/t2-model-coordinates

Vertex latitude (y) and longitude (x) coordinates SHALL be expressed in decimaldegrees. The values SHALL be relative to the file’s (implicit) origin which is thesouth-west corner of the tile.

Note however, that the file’s origin and size are implicitly defined by the tile position and the tilelevel-of-detail. The absolute position of each vertex is obtained by adding the vertex relativevalue to the tile origin.
T2DModels are used to model features that have no significant height with respect to theneighboring terrain; they are generally conformed to the terrain using the “Surface Conformal
Mode” as explained in section 6.7, Model Conforming. Note that the vertices of T2DModels
need not have Z-coordinate values that are always zero. For example, it is permissible to modela road lineal that is modestly elevated with respect to the neighboring terrain. Client-devices
must be capable of handling T2DModels that are either perfectly surface-conformed to theterrain (all vertices have Z=0) or modestly elevated (vertices with Z>0) with respect to theterrain. Note that surface-conformed models with vertices with Z-coordinate values less thanzero are, by definition, below the terrain.
The local origin of the model is translated to the (lat, long) coordinates of the point feature. The elevation
component is either obtained from the point feature (AHGT=True) or obtained from the elevation of the terrain at(lat, long) coordinates of the point-feature (AHGT=False). The model’s XY plane is rotated in accordance to thefeature’s AO1 attribute. The model’s Z-axis is adjusted so that it is tangential to the WGS-84 earth model.
10

Copyright © 2018 Open Geospatial Consortium

28

6.3.1.4 Roll, Pitch, Yaw
Requirement 10
Req 10 req/openflight/roll-pitch-yaw

Pitch, Roll and Yaw angles refer to rotations around the X, Y, and Z axes, respectively.
Angles SHALL be measured in degrees. The Roll and Yaw angles vary from ±180
degrees while the Pitch angle is limited to the range ±90 degrees.

6.3.2 Geometry
Requirement 11
Req 11 req/openflight/geometry

Implementers of the CDB standard SHALL adhere to the following set of constraints,
rules and guidelines when creating the geometry of Models.
•
•
•
•
•

•

•

Create convex polygons. All lines joining any two points in the interior of thepolygon also lie in the interior.
Create coplanar vertices. All of the vertices defining a polygon should lie in thesame plane (required by virtually all rendering engines).
A polygon’s front face SHALL be defined by a counter-clockwise ordering of its
vertices.
Avoid T vertices. T-vertices occur when two or more adjacent polygons share anedge, and the polygons do not share a common vertex on that edge.
Avoid coplanar faces. A coplanar face is a polygon that lies directly on top of
another polygon. Z-buffer fighting can occur when a Z-buffer system cannot
resolve which polygon to display on top. The CDB standard strongly
recommends changing one of the coplanar faces to be a subface of the other in thehierarchy so that the client device such as an Image Generator can draw the faces
in the correct order. An alternative is to use the Relative Priority field toimplement layering (see section 6.3.4 below).
Favor mesh over individual polygons. The OpenFlight Mesh record allows thecreation of triangle fans, triangle strips, quadrilateral strips, and indexed face sets.
This construct is by far preferable to individual polygons built using the
OpenFlight Face record.
Make use of instancing. Avoid repeating identical pieces of geometry. Create
one object and repeat it by having multiple instances in different locations..

Copyright © 2018 Open Geospatial Consortium29

6.3.3 Roof Tagging
OpenFlight has a provision for tagging polygons that are part of a roof. The Roofline flag can befound in both the Face and Mesh records. This flag is useful to apply a geospecific texture to theroof. When the flag is set, the client-device can discard the texture referenced by the polygon
and use instead the geospecific texture that appears on the terrain.
More generally, the Roofline flag is used to tag any polygon whose texture can be replaced witha geospecific texture.
6.3.4 Relative Priority
The Relative Priority field appears in four OpenFlight primary records:
Face Record
Mesh Record
Object Record
Group Record
The field is required to implement layering, a method to handle coplanar geometry. By using theRelative Priority field, the modeler can construct more complex coplanar geometry than what is
possible with sub-faces.
Here is the definition of the field according to OpenFlight 16.0:
Relative priority specifies a fixed ordering of the node relative to its sibling nodes.
Ordering is from left (lesser values) to right (higher values). Nodes of equal priority may
be arbitrarily ordered. All nodes have an implicit (default) relative priority value of zero.
The CDB standard further restricts the use of the Relative Priority field for complex coplanar
geometry as follows. Using relative priorities, the modeler defines 'n' layers of coplanar
geometry. Layers are numbered from 0 to 'n-1'.
Requirement 12
Req 12 req/openflight/geometry-layer-constraint

Layer 0, the base layer, SHALL contain geometry that completely encompasses thegeometry of subsequent layers. Other layers SHALL be processed in order, one after
the other. A layer is made of one or more nodes; all nodes of a given layer SHALL
have the same relative priority.

6.4 Model Identifiers

Copyright © 2018 Open Geospatial Consortium30

6.4.1 GSModel and GTModel Identifier
Although the name of the global zone of a GS or GT model is arbitrary, it is strongly suggested
to use the value of their MODL attribute to name the global zone.
For instance, a GTModel stored in a file called
D500_S001_T001_AL015_004_Castle.flt

Would have its global zone identified like this:<CDB:Zone
name="Castle"/>

6.4.2 MModel Identifier
The MModel identifier is the common name of the moving model or the name of its part. The
actual name is not covered by the standard. An example of a MModel identifier is “M1A2” forthe M1 Abrams tank whose DIS Entity Type is 1_1_225_1_1_3_0.
For instance, a moving model stored in a file called
D600_S001_T001_1_1_225_1_1_3_0.flt

Would have its global zone identified like this:<CDB:Zone
name="M1A2"/>

6.4.3 2DModel Identifier
A T2DModel itself does not need to be identified per se. However, it is required to identify
individual 2DModels inside a T2DModel. This is done by assigning a unique zone name to each
2DModel. In addition, a 2DModel must have the same zone name across LODs and across tiles.
Note that when a 2DModel is clipped by tile boundaries, each of the clipped model fragments
will appear in distinct OpenFlight files of the T2DModel Dataset. When clipped, the 2DModel
Identifier must appear once, in each of the T2DModel Tile-LODs. This is necessary to identify
the parts of a 2DModel that straddle multiple Tile-LODs.
6.5 Model Zones

Requirements Class – Model Zones/req/core/model-zones
Target typeOperations

Dependency

OpenFlight Specification

Requirement 13 /req/openflight/model-zone-bounding-box

Copyright © 2018 Open Geospatial Consortium

31

Requirement 14 /req/openflight/zone-name
Requirement 15 /req/openflight/global-zone
Requirement 16 /req/openflight/hot-spot-temperature
Requirement 17 /req/openflight/model-footprint-zones
Requirement 18 /req/openflight/model-footprint-hierarchy
Requirement 19 /req/openflight/model-cutout-zones
Requirement 20 /req/openflight/model-cutout-geometry
Requirement 21 /req/openflight/model-pseudo-interior-zone
Requirement 22 /req/openflight/model-interior-zone
The concept of a model zone is of the utmost importance when creating models, particularly
those used in military simulation applications.
A model zone represents a component11 of interest on the Model. A model zone (as well as thecomponent it represents) occupies a certain volume and is delimited by a bounding box. At least
one simulator subsystem must be interested in a specific component to justify the creation of acorresponding zone. Examples of zones are a turret on a tank, or an engine on a platform, or an
entrance door on a building, etc.
Since the model itself is of interest to the simulation, it will have at least one zone, the global
zone. That will be the case for most Models used as cultural features; they will have a single
zone. However, Models used as moving models will typically be subdivided into several zones.
To implement the concept of model zones, the CDB standard uses the OpenFlight Group Node.
Firstly, a Group Node can have child nodes to represent its own geometry as well as other zones.
Secondly, a Group Node can have a bounding volume encompassing its child nodes and that canbe used to represent the volume corresponding to the zone.
6.5.1 Definition
A Model Zone is an OpenFlight Group Node with a mandatory Bounding Box and the following
XML tags in the comment field.
Requirement 13
Req 13 req/openflight/model-zone-bounding-box

11 A dictionary of CDB Component Names is provided in Appendix F.

Copyright © 2018 Open Geospatial Consortium

32

To be a OpenFlight Group Node a Model Zone SHALL have mandatory Bounding Box.

Table 6-2: XML Tags for Zones<CDB:Zone name="name" volume="closed|open">... zone attributes</CDB:Zone>

Requirement 14
Req 14 req/openflight/zone-name

The Zone Name is mandatory.

Remember that if the zone exists, it is because it has its importance for at least one client device.
In general, all client devices interested in a zone will use its name to identify and control it.
The volume attribute is optional and specifies whether the zone represents a closed or open
volume. By default, a zone represents a closed volume.
The following table lists the OpenFlight records required to represent a zone.
Table 6-3: OpenFlight Records for a ZoneGROUP
MATRIX (optional)
BOUNDING BOX (mandatory)
COMMENT (mandatory)

Note the use of the MATRIX record. It is necessary when the zone has a different position ororientation than its parent node. A zone can be thought of as a separate Model in itself. A zone
has a natural orientation and its local coordinate system must indicate where their front, right,
and back sides are. A zone is subject to the same convention as the model itself regarding theorientation of its coordinate system.
6.5.2 Global Zones
Requirement 15
Req 15 req/openflight/global-zone

A CDB-compliant Model SHALL have at least one zone that encompasses the whole

Copyright © 2018 Open Geospatial Consortium

33

model and that is called the model global zone. The global zone is mandatory.

Figure 6- 13: Model Global Zone

illustrates the location of the global zone in the graph hierarchy.

Figure 6- 13: Model Global Zone

The global zone contains the name of the Model contained in the OpenFlight file.
6.5.3 Zone Attributes
A Model Zone can have any number of attributes using the general mechanism described later insection 6.12, Model Attributes. However, two specific attributes are described here because of
their particular relevance to the concept of Model Zone.
6.5.3.1 Material
The Material attribute provides an indication of the principal material the zone is made of. Since
the majority of man-made models are made of one principal material as well as several lessimportant materials, it is strongly suggested to use the Material attribute in the model global zone
to specify what that principal material is.
The Material attribute is an index into the Composite Material Table located within the Model
Descriptor file described in section 6.14. The value of the Material attribute is a strictly positive
integer. The syntax of the XML tag is:<CDB:Zone><Material> index </Material></CDB:Zone>

Copyright © 2018 Open Geospatial Consortium

34

The Material attribute can also be assigned to OpenFlight Object, Face, and Mesh nodes. The
preferred syntax would be the following:<CDB:Object><Material> index </Material></CDB:Object><CDB:Face><Material> index </Material></CDB:Face><CDB:Mesh><Material> index </Material></CDB:Mesh>

However, for compatibility with version 3.1 and 3.0 of the CDB standard, a simplified (butdeprecated) syntax is still supported for Object, Face, and Mesh nodes when the Material is the
only attribute.

<CDB:Material>
index</CDB:Material>

6.5.3.2 Temperature
When the zone has a heat source, such as an engine, it is known as a Hot Spot. The maximum
temperature the zone can reach is specified using the Temperature attribute as shown here:
Table 6-4: XML Tags for Hot Spots<CDB:Zone><Temperature> maximum temperature </Temperature></CDB:Zone>

Requirement 16
Req 16 req/openflight/hot-spot-temperature

The temperature SHALL be expressed in Celsius degrees. Only integer values are
permitted.

supplies a comprehensive list of zones that are
candidates for hot spots. Typical hot spot names are Engine and Chimney to name only these\CDB\Metadata\Model_Components.xml

Copyright © 2018 Open Geospatial Consortium

35

two. Other zones that are of interest for hot spots simulation are wings leading edge andother surfaces subjected to friction.
6.5.4 Implementation Guidelines
This section provides a set of guidelines to implement the concept of model zones. The
guidelines provided here are also applicable to Model Points described in section 6.6.
A zone is made of at least one Group Node.

Figure 6- 14: Simple Zone

A zone may have an optional articulation by adding a DOF node.

Figure 6- 15: Articulated Zone

To simplify the following diagrams, we will use a single circle to represent a zone, whether thezone is a single Group Node, or a pair of group and DOF nodes.
In general, a zone has a graphical representation as well as other child zones.

Copyright © 2018 Open Geospatial Consortium

36

Figure 6- 16: Zone Hierarchy

The graphical representation of a zone is itself subject to several possible implementations using
various OpenFlight nodes.
The simplest way to associate a graphical representation to a zone is to use an Object node with a
combination of graphic primitives available in OpenFlight: polygons, triangles, quads, andmeshes.

Figure 6- 17: Simple Zone Graphical Representation

The modeler is also free to use a combination of LOD and Switch nodes to control the graphicalrepresentation of a zone.
For instance, an LOD node inserted before the object node is useful to inform the client device
on how significant the graphical representation is.

Copyright © 2018 Open Geospatial Consortium

37

Figure 6- 18: Additive LOD to Control the Graphical Representation

If the modeler wants to provide two (or more) graphical representations for a zone, he should use
two (or more) LOD nodes.

Figure 6- 19: Exchange LODs to Select the Graphical Representation

Levels of details are discussed in length in Section 6.8, Model Levels-of-Detail.
If the modeler has several distinct graphical representations for the zone, he is also free to use aswitch node to select between these representations.

Copyright © 2018 Open Geospatial Consortium

38

Figure 6- 20: Switch Node to Select the Graphical Representation

CDB Switches are discussed in depth in Sections 6.9, Model Switch Nodes.
6.5.5 Model Zone Naming
A Model Zone Node is uniquely and unambiguously identified by concatenating withbackslashes (‘\’) the names of all Model Zones traversed to reach it. When sibling CDB nodes
have identical names, their name is appended with a sequence number in square brackets. Nodes
are numbered starting with 1. Siblings are sorted in ascending order according to their X, Y, andZ coordinates. The leftmost sibling has the smallest XYZ coordinate while the rightmost siblingnode has the largest XYZ coordinate. As a result, identical sibling CDB nodes are sorted fromleft to right (X-axis), then back to front (Y-axis), then bottom to top (Z-axis).
The following example provides a sample of Model Zone and Model Point names that would be
used for a tactical fighter aircraft; the fighter has two pylons per wing, each pylon having 3
attach points. The resulting paths to each Model Zones and Model Points are as follows:\Fighter\Fighter\Wing[1]\Fighter\Wing[1]\Pylon[1]\Fighter\Wing[1]\Pylon[1]\Attach_Point[1]\Fighter\Wing[1]\Pylon[1]\Attach_Point[2]\Fighter\Wing[1]\Pylon[1]\Attach_Point[3]\Fighter\Wing[1]\Pylon[2]\Fighter\Wing[1]\Pylon[2]\Attach_Point[1]\Fighter\Wing[1]\Pylon[2]\Attach_Point[2]\Fighter\Wing[1]\Pylon[2]\Attach_Point[3]\Fighter\Fuselage\Fighter\Fuselage\Attach_Point\Fighter\Wing[2]\Fighter\Wing[2]\Pylon[1]\Fighter\Wing[2]\Pylon[1]\Attach_Point[1]\Fighter\Wing[2]\Pylon[1]\Attach_Point[2]\Fighter\Wing[2]\Pylon[1]\Attach_Point[3]Copyright © 2018 Open Geospatial Consortium

39

\Fighter\Wing[2]\Pylon[2]\Fighter\Wing[2]\Pylon[2]\Attach_Point[1]\Fighter\Wing[2]\Pylon[2]\Attach_Point[2]\Fighter\Wing[2]\Pylon[2]\Attach_Point[3]Here is how to interpret some of these paths:
The global zone is identified as \Fighter
The left wing is \Fighter\Wing[1]The leftmost attach point is \Fighter\Wing[1]\Pylon[1]\Attach_Point[1]The rightmost attach point is \Fighter\Wing[2]\Pylon[2]\Attach_Point[3]There is a single attach point on the fuselage, \Fighter\Fuselage\Attach_Point
The inner pylon on the left wing is \Fighter\Wing[1]\Pylon[2]The inner pylon on the right wing is \Fighter\Wing[2]\Pylon[1]6.5.6 Usages
6.5.6.1 Model Landing Zones
Landing zones are used primarily by the Computed Generated Forces (CGF) sub-system of thesimulator. The landing zone information can be used during the set-up of mission scenarios
since it provides CGF the location of known landing zones. Typically, landing zones are used to
specify the location and dimension of helipads, aircraft carrier decks, etc.
\CDB\Metadata\Model_Components.xml lists several CDB Components that can act as landingzones.
Landing zones must have a bounding box that tightly fits the landing area. If required by thegeometry of the landing zone, the modeler should create a local coordinate system that is axiallyoriented with the landing zone. Inserting a MATRIX record after the GROUP record does this.
The width and the length of the landing zone can be extracted by the client-device from thebounding box associated with the Group Node representing the zone. The landing zone
geometry must be located under the Group Node to obtain meaningful dimensions.
6.5.6.2 Model Footprint Zones
A Model Footprint12 conceptually represents the footprint (i.e., the terrain surface outline) of amodel on the ground. The Model Footprint is modeled as a set of OpenFlight Face or Meshrecords.
Requirement 17
Req 17 req/openflight/model-footprint-zones

Client-devices SHALL assume that the geometry that is associated with a Model Footprint
The OpenFlight Face and Mesh records both have a flag called Terrain Culture Cutout. This flag iscommonly designated as the Cultural Footprint flag within the simulation industry.

12

Copyright © 2018 Open Geospatial Consortium

40

Zone is hidden, regardless of the value of the OpenFlight Hidden flag of associatedgeometry. However, CDB content creation tools SHALL set the Hidden flag of theassociated geometry13.

The footprint geometry should be terrain conformed using the “Surface Conformal Mode” asexplained in section 6.7, Model Conforming. This instructs client-devices to conform thisfootprint to the underlying terrain altimetry, regardless of its level-of-detail.
The Model Footprint is the set of polygons or meshes that result from the intersection of themodel geometry with its XY plane14.
A polygon that is tagged as Model Footprint can be used by client-devices to identify the portionof the terrain that is covered by a model. The Cultural Footprint can be used by client-devices
such as:•••

Map generators that may not be interested in the full 3D geometry of a Model.
Procedural SE generation software that may use model footprints to automatically
extrude such footprints into 3D models.
Simulation of ground-based SAF entities that would use model footprints to avoid
collisions with features such as buildings and trees.

Requirement 18
Req 18 req/openflight/model-footprint-hierarchy

The CDB standard requires that the Model Footprint SHALL be placed under a CDB
Footprint Zone node.

This CDB node facilitates the identification and discovering of footprints by client-devices. The
subgraph representing the Footprint is presented here.

13

This increases compatibility with OpenFlight readers that are not CDB-compliant.

14
The Model Footprint polygon is not an absolute Z-positioned 3D polygon generated by the intersection of
the model with the specific terrain it sits on - that would make the footprint of the model specific to that terrain.
Furthermore, a different 3D polygon would be required for each possible terrain LOD.

Copyright © 2018 Open Geospatial Consortium

41Footprint(zone)

ObjectFace

MeshFigure 6- 21: Footprint Zone Structure

The Footprint zone is followed by an OpenFlight Object node with the necessary OpenFlight
Face or Mesh nodes containing the footprint itself. All Face/Mesh nodes must have their Terrain
Culture Cutout flag set. A Footprint zone is defined by the following XML tags.
Table 6-5: Footprint Zone XML Tags
<CDB:Zone name = "Footprint"/>

6.5.6.3 Model Cutout Zones
A Model Cutout Zone conceptually represents clipping geometry that is used to cut out theterrain from a 2DModel or a 3DModel. Cutouts are typically used in conjunction with modelinteriors and tunnels. The Model Cutout geometry defines a simple 3D convex volume (open or
closed). A typical implementation of a Model Cutout Zone for a modeled building would consistof a simple cube. Similarly, the Model Cutout Zone for a tunnel entrance would consist of asimple cylinder or a partially-open cube (see Error! Reference source not found.).
Requirement 19
Req 19 req/openflight/model-cutout-zones

The Model Cutout is modeled as a set of OpenFlight Face or Mesh records. Clientdevices SHALL assume that the geometry that is associated with a Model Cut-Out Zone ishidden and cut-out.

The Model Cutout is modeled as a set of OpenFlight Face or Mesh records. Client-devices are
required to assume that the geometry that is associated with a Model Cut-Out Zone is hidden and

Copyright © 2018 Open Geospatial Consortium42

cut-out. Client-devices should ignore the value of the OpenFlight Hidden and Terrain Culture
Cutout flags of associated geometry. However, CDB content creation tools are required to set
the Hidden and Terrain Culture CutOut flags of the associated geometry15.
The Model Cutout geometry should be terrain conformed using the “Surface Conformal Mode”
as explained in the 6.7, Model Conforming. This instructs the client-device to conform theModel Cutout to the underlying terrain altimetry, regardless of its level-of-detail.
It is specified using the following XML syntax:
Table 6-6: XML Tags for Landing Zones<CDB:Zone name="Cutout">

Polygons or meshes that are tagged as Model Cutout can be used by client-devices to identify the
portion of the terrain that needs to be removed in order to reveal the interior of the model (say abuilding interior or a tunnel interior). The Model Cutout is necessary for models straddling theterrain surface and whose interior is modeled and viewed from within. The reason for this is thatwhen the model is altitude-conformed onto the terrain, a hole must be cut into the terrain-LOD,
so that the terrain itself does not visually interfere with the modeled building or tunnel interior.
Requirement 20
Req 20 req/openflight/model-cutout-geometry

The CDB standard requires that the Cutout geometry SHALL be placed under a CDB
Model Cutout Zone node.

This CDB node facilitates the identification and discovery of model cutouts by client-devices.
The subgraph representing the cutout is presented here.

15

This increases compatibility with OpenFlight readers that are not CDB-compliant.

Copyright © 2018 Open Geospatial Consortium

43

Cutout(zone)

ObjectFace

MeshFigure 6- 22: Cutout Zone Structure

6.5.6.4 Model Interior Zones
This section focuses on how to represent the interior of Models for an intelligent use by clientdevices.
A Model is composed of 2 parts: a shell, and an optional interior. The shell contains both theexterior and the pseudo-interior. Client-devices need only access the shell if they do not need topenetrate and interact with the interior of the models; otherwise, they require both the shell andthe interior. The shell of a Model is stored in five (5) datasets:
ModelGeometry
ModelTexture
ModelSignature
ModelDescriptor
ModelMaterial
The optional model interior is stored in four (4) datasets:
ModelInteriorGeometry
ModelInteriorTexture
ModelInteriorDescriptor
ModelInteriorMaterial
Refer to CDB Standard Volume 7 OGC CDB Data Model Guidance section 6.5 for guidelines on
Handling of Model Interiors.

6.5.6.4.1 Model Pseudo-Interior Zone

The pseudo-interior is the portion of the shell that contains geometry also represented in theinterior dataset. This geometry represents what is visible from the outside and is necessary toensure the integrity and completeness of the shell.

Copyright © 2018 Open Geospatial Consortium

44

Requirement 21
Req 21 req/openflight/model-pseudo-interior-zone

Since the pseudo-interior is a placeholder for the real interior, it SHALL be placed under
its own subgraph and identified by a CDB zone whose name is “Interior”.

db

Shell

(global zone)

Footprint(zone)

Exterior(zone)

Interior(zone)

Figure 6- 23: Model Shell Structure

The name “Interior” is a reserved component name allowing a client-device to identify the nodethat is to be replaced by an entire dataset, namely the ModelInteriorGeometry dataset. The
pseudo interior is mutually exclusive with the real interior defined in section 6.5.6.4.2, Model
Interior Zone, below.

Figure 6- 23: Model Shell Structure
also illustrates how to structure the shell of a Model that has a real interior. The model isdivided in three components: the footprint of its exterior, the geometry of its exterior, and thegeometry of its pseudo-interior. Therefore the names of these three components are “Footprint”,“Exterior”, and “Interior” as illustrated by the following XML tags.

Copyright © 2018 Open Geospatial Consortium

45

Table 6-7: Shell Zones XML Tags
<CDB:Zone name = "Footprint"/><CDB:Zone name = "Exterior"/><CDB:Zone name = "Interior"/>

Footprints were discussed earlier in section 6.5.6.2, Model Footprint Zones.

6.5.6.4.2 Model Interior Zone
Requirement 22
Req 22 req/openflight/model-interior-zone

The Model interior itself SHALL have a global zone whose name is “Interior”.

The Model interior itself must have a global zone whose name is “Interior”. Accordingly, thegraph of the interior of the model will present the following structure. Note that real interior
must not include the modeled representation of the shell.
db

Interior(global zone)

Figure 6- 24: Model Interior Structure

The Interior zone contains one or more floors as well as the partitions separating these floors.
An Interior zone is defined by the following XML tags.
Table 6-8: Interior Zone XML Tags
<CDB:Zone name = "Interior"><Ground_Floor> index </Ground_Floor></CDB:Zone>

The <Ground_Floor> is optional. It contains the index of the Floor that represents the groundfloor of the model interior. By default, the ground floor is floor number 1.

Copyright © 2018 Open Geospatial Consortium

46

The subgraph representing the Interior zone has the following structure.

Interior

Floor

Partition

Figure 6- 25: Interior Zone Structure

The Interior zone has two (2) kinds of child nodes: Floor and Partition. The Interior has at least
one Floor. When the Interior has several Floors, the separating Partitions appear as siblings ofthe Floor nodes. These Partitions contain external Apertures that connect two Rooms on
different Floors. These external Apertures are later referenced by Rooms.
6.5.6.4.2.1 Model Interior Topology

To navigate through the interior of Models, simulator client-devices need to know theconnections between the elements composing the interior, such as floors, rooms, doors, or
fixtures. In addition, these elements must be identified and attributed for use by computer
generated forces (CGF) client-devices. For this reason, the CDB Standard has opted for reuse
and adoption of version 2 of the UHRB specification16.
The CDB standard maps the UHRB Object Model to the OpenFlight Scene Graph using theconcept of CDB nodes.
The UHRB object model proposes twelve (12) classes. Of these, four (4) are abstract baseclasses and one (1) is a provision for future expansion of the UHRB specification. The
remaining seven (7) concrete classes are mapped to CDB Zone nodes. The UHRB Class Names
and their corresponding CDB Zone Names are:Table 6-9: UHRB Class Names and corresponding CDB Zone Names

UHRB Class NameCDB Zone NameUHRB_TEMPLATEInterior

UHRB_FLOOR_LEVEL_COMPONENT

Floor

16 OneSAF Ultra High Resolution Building (UHRB) Object Model.

Copyright © 2018 Open Geospatial Consortium

47

UHRB_SURFACE_COMPONENTSurface

UHRB_ROOM_COMPONENTRoomUHRB_FIXTURE_COMPONENT

FixtureUHRB_APERTURE_COMPONENT

Aperture

UHRB_FIXED_PARTITION_COMPONENTPartition

The above CDB nodes are treated the same way as any other CDB nodes. In particular, Floor,
Room, Partition, Aperture, Fixture, and Surface nodes are numbered following the conventions
established in section 6.5.5, Model Zone Naming; they also have zone attributes such as theMaterial Index.
6.5.6.4.2.2 Model Interior Topology Attributes

This section describes the CDB mechanism that expresses the possible connections between
compartments and apertures. The definition of a CDB Zone is extended with the addition of one
XML tag indicating which other components are connected to this one.
The following table presents the revised syntax of the XML tags defining a CDB Zone. The
addition is highlighted in yellow.
Table 6-10: XML Tags for Zone Connections<CDB:Zone name="name" volume="closed|open"><Material> index </Material><Temperature> value </Temperature><ConnectTo> path </ConnectTo>...
</CDB:Zone>

The <ConnectTo> tag may appear zero or more times, allowing for the definition of any
number of connections to other components. The other tags (Material and Temperature) retain
their current definition. In particular, the use of the <Material> tag is encouraged to define thematerial the components are made of.
The presence of the <ConnectTo> tag is restricted to a set of three (3) components: global
zone, compartments and apertures. A connection is unidirectional; it goes from the zone that
contains the <ConnectTo> tag to the zone referenced by the path. The path is either relative or
absolute. When a relative path is used, it identifies a sibling of the current zone. Here are some
path examples.

Copyright © 2018 Open Geospatial Consortium

48

Table 6-11: Examples of Absolute and Relative Paths
Example 1:<CDB:Zone name="Interior"><ConnectTo> \Interior\Section[1]\Level[1]\Aperture[5] </ConnectTo></CDB:Zone>
Example 2:<CDB:Zone name="Aperture[5]"><ConnectTo> \Interior\Section[1]\Level[2]\Compartment[3] </ConnectTo></CDB:Zone>
Example 3:<CDB:Zone name="Compartment[3]"><ConnectTo> Aperture[1] </ConnectTo><ConnectTo> \Interior\Section[1]\Level[1]\Aperture[5] </ConnectTo></CDB:Zone>

Example 1 is an absolute path, expressed as a directory name, starting with the topmost zone, theglobal zone. It tells us that there is one entrance into the model interior through the fifth aperture(Aperture[5]) on the first level (Level[1]) of the first section (Section[1]) of the model interior(\Interior).
Example 2 is also an absolute path. It tells us that the fifth aperture (Aperture[5]) has a single
connection to the third compartment (Compartment[3]) of the second level (Level[2]) of the firstsection (Section[1]) of the model interior (\Interior).
Example 3 illustrates how to use a relative path. It tells us that the third compartment(Compartment[3]) has two exits. The first exit is through the first aperture (Aperture[1]) of thecurrent level. The second exit is through the fifth aperture (Aperture[5]) on the first level(Level[1]) of the first section (Section[1]) of the model interior (\Interior).
Example 1 tells us to use Aperture 5 to enter into the model interior. Example 2 further informs
us that Aperture 5 brings us into Compartment 3. Example 3 says that we can exit Compartment
3 through either Aperture 1 or 5.
The global zone (the top level node) node provides the list of apertures representing entrances
into the model. If the global zone does not provide at least one aperture to enter the model, thenthe model interior is unreachable. To exit a compartment, it must connect to at least one
aperture; if not, you may be able to enter the compartment, but you will not be able to exit.
Finally, an aperture allows entrance into compartments. An aperture without connection is anexit point; in that case, a compartment must connect to the aperture.
The CDB Standard Schema Package provides the XML schema governing the construction of avalid CDB Zone. The schema includes provision for the <ConnectTo> tag.

6.5.6.4.3 Floor Zone

A Floor zone contains one or more Rooms, and all Partitions shared by these Rooms. A Floor isdefined by the following XML tags.

Copyright © 2018 Open Geospatial Consortium

49

Table 6-12: Floor Zone XML Tags
<CDB:Zone name = "Floor"><Label> floor name </Label></CDB:Zone>

The <Label> is optional. It can be used to give the Floor a meaningful name such as “Ground
Floor”, “Basement”, “Mezzanine”, or “Penthouse”.
The subgraph representing a Floor has the following structure.

Floor

Footprint

Room

Partition

Figure 6- 26: Floor Zone Structure

The Footprint of a Floor is the minimum enclosing polygon containing all of the footprints of allof the Rooms on the Floor as well as the footprints of all of the Partitions associated with thoseRooms. The Footprint is defined as per section 6.5.6.2, Model Footprint Zones. The Partitions
contain the Apertures that connect two Rooms together. These Apertures are later referenced by
Rooms.

6.5.6.4.4 Room Zone
A Room zone owns all its Surfaces and may contain Fixtures. A Room is defined by thefollowing XML tags.

Table 6-13: Room Zone XML Tags
<CDB:Zone name = "Room"><Label> room name </Label><Aperture> path to aperture 1 </Aperture>... other apertures as needed<Partition> path to partition 1 </Partition>... other partitions as needed</CDB:Zone>

Copyright © 2018 Open Geospatial Consortium

50

The <Label> is optional. It can be used to better identify the Room by its usual name. Examples
are cubicle, toilet, conference room, atrium, office, electrical room, janitor room, etc.
The <Aperture> is optional but is likely to appear at least once, unless the Room is permanently
closed and cannot be accessed. It points to one Aperture that connects this Room with another
Room on this Floor or on another Floor. Two Rooms on the same Floor are connected throughan Aperture in a Partition on the current Floor. Two Rooms on two different Floors areconnected through an external Aperture in a Partition from the Interior zone. The path to an
Aperture is built as specified in section 6.5.5, Model Zone Naming.
The <Partition> is also optional, but again, is likely to appear several times since a typical Roomhas a floor, a set of walls, and a ceiling.
The subgraph representing a Room has the following structure.

Room

Footprint

FixtureBottomSurfaces(group)SideTop(group)(group)(group)Surface

Surface

Surface

Figure 6- 27: Room Zone Structure

The footprint is the smallest polygon containing all of the bottom surfaces when projected onto
the XY plane17. There can be zero or more Fixtures in a Room. The Surfaces making up thevolume of the Room are separated in three (3) groups (Bottom, Side, and Top) as defined by the
UHRB specification.
17 This definition of a room footprint comes from the UHRB Specification.

Copyright © 2018 Open Geospatial Consortium

51

6.5.6.4.5 Fixture Zone

A Fixture zone is defined in the same manner as a Room; it is made of a number of Surfaces
defining a closed volume. The Fixture is defined by the following XML tags.
Table 6-14: Fixture Zone XML Tags
<CDB:Zone name = "Fixture"><Label> fixture name </Label><Moveable> true/false </Moveable></CDB:Zone>

The <Label> is optional. It allows the modeler to describe what this fixture represents.
The <Moveable> flag is optional. It indicates whether or not the Fixture can move or if it isfixed. By default, the fixture does not move; if it does, the flag is set to true. A piece offurnitures is an example of moveable fixture while a column is an example of a fixed one.
The subgraph representing a Fixture is similar to that of a Room, except for the need todifferentiate between the kinds of Surfaces. Its structure is presented here.

FixtureFootprint

Surface

Figure 6- 28: Fixture Zone Structure

The Footprint is the smallest polygon containing all of the Surfaces when projected onto the XY
plane. The Surfaces form a closed volume, meaning there is no hole in the Fixture.
Alternately, to permit reuse of common fixtures stored in the GTModel Library, the Fixture may
reference an existing model through the use of an XRef node. In that case, the following
subgraph is to be used.

Copyright © 2018 Open Geospatial Consortium

52

Fixture

XRef

Figure 6- 29: Fixture Zone Structure

6.5.6.4.6 Partition Zone

A Partition zone has Apertures, makes reference to all Surfaces composing it, and refers to its
adjacent Rooms. The Partition is defined by the following XML tags.

Table 6-15: Partition Zone XML Tags
<CDB:Zone name = "Partition"><Label> partition name </Label><Room> path to adjacent room 1 </Room><Room> path to adjacent room 2 </Room><Surface> path to surface 1 </Surface>... other surfaces as needed</CDB:Zone>

The <Label> is optional. It allows the modeler to better identify the type of Partition: wall, floor,
ceiling, etc.
The <Room> tag is mandatory and is used to identify the two Rooms adjacent to the Partition18.
For this reason, there must be exactly two <Room> tags. The path to an adjacent Room is as
specified in section 6.5.5, Model Zone Naming. Note that UHRB defines the concept of an“outside” room when the partition defines a building outside wall. In CDB, the path of thisoutside room is \Shell\Exterior as illustrated in 6.5.6.4.1, Model Pseudo-Interior.
The <Surface> tag appears as many times as necessary to refer to all Surfaces making up thisPartition. A path similar to the one used to refer to a Room is used to refer to a Surface. Notethat a Partition does not refer to the Surfaces that belong to its Aperture; that will be taken careof by the Apertures themselves.
The subgraph representing a Partition has the following structure.

18 Note that the CDB standard follows established UHRB conventions as it relates to partitions, namely that all

partitions must be clipped so that there are no more than two neighbouring rooms.

Copyright © 2018 Open Geospatial Consortium

53

Partition

Footprint

Aperture

Figure 6- 30: Partition Zone Structure

The Footprint is the smallest polygon containing all of the referenced Surfaces when projected
onto the XY plane. A Partition can have zero or more Apertures in it.

6.5.6.4.7 Aperture Zone
An Aperture zone provides a mean by which one can enter or exit a Room. The Aperture zone isdefined by the following XML tags.

Table 6-16: Aperture Zone XML Tags
<CDB:Zone name = "Aperture"><Label> aperture name </Label><Is_Open> true/false </Is_Open><Is_Fixed> true/false </Is_Fixed><Damage_Level> percentage of damage </Damage_Level><Room> path to room 1 </Room><Room> path to room 2 </Room><Surface> path to surface 1 </Surface>... other surfaces as needed</CDB:Zone>

The <Label> is optional. It allows the modeler to better identify the type of Aperture: door,
window, trap, etc.
The <Is_Open> and <Is_Fixed> flags are both optional; they are considered false when notprovided.
The <Damage_Level> tag is also optional and provides a mean to indicate the level of damage of
the Aperture. The value is expressed as a percentage using an integer in the range 0 (no damage)to 100 (destroyed).
The <Room> tag appears exactly two times and points to the two Rooms connected by thisAperture. Sometimes one of these two rooms may be an “outside” room - a concept defined in
UHRB. In CDB, the path of this outside room is \Shell\Exterior as illustrated in 6.5.6.4.1, Model
Pseudo-Interior.

Copyright © 2018 Open Geospatial Consortium

54

The <Surface> tag appears as many times as necessary to refer to all Surfaces making up thisAperture.
The subgraph representing an Aperture has the following structure.
Aperture

Footprint

Figure 6- 31: Aperture Structure

The Footprint is the smallest polygon containing all of the referenced surfaces when projected
onto the XY plane.

6.5.6.4.8 Surface ZoneA Surface zone contains useful geometry. That’s all it does. The Surface zone is a plain CDB
zone. Its subgraph is presented here.

SurfaceObjectFace

MeshFigure 6- 32: Surface Zone Structure

Copyright © 2018 Open Geospatial Consortium

55

A Surface is composed of one or more OpenFlight Object nodes holding the geometry defining
the surface: face or mesh records.
6.6 Model Points
A model point is similar to a model zone; it identifies a location on the model that is of interest to
at least one simulation client device. A point defines a local coordinate system on the model.
Hence, a point has a position and an orientation.
In some respect, a point and a zone are similar and can be used interchangeably. A zone is used
when the component of interest is physically modeled and has a graphical representation. Whenthe zone is not modeled but still represents a component of interest, a point is used to indicate its
presence.
Again, the OpenFlight Group Node mechanism provides a convenient means of implementing
the concept of a point because a transformation can be added to the node.
Requirements Class – Model Points/req/openflight/model-points
Target typeOperations

Dependency

Openflight Specification

Requirement 23 /req/openflight/model-point-damage=states
Requirement 24 /req/openflight/model-dis-origin
Requirement 25 /req/openflight/model-viewpoint
6.6.1 Definition
The table below presents the syntax of the XML tags stored in the node’s comment record.
Table 6-17: XML Tags for Points<CDB:Point name = "name">... point attributes</CDB:Point>

The point name is mandatory while the point attributes are optional. In general, a point can havethe same name as a zone. The following table lists the OpenFlight records required to represent
a point.

Copyright © 2018 Open Geospatial Consortium

56

Table 6-18: OpenFlight Records for a Point
GROUP
MATRIX (mandatory)
COMMENT (mandatory)

A model point is used in several occasions such as defining the attach point where another Modelcan anchor itself.
6.6.2 Usages
6.6.2.1 Model DIS Origin
A Model that is intended as a DIS entity requires a point that defines the origin of the entity’scoordinate system. This point is the center of the entity’s bounding volume excluding its
articulated and attached parts19. On a DIS network, the location of an entity is expressed relative
to this point.
Requirement 23
Req 23 req/openflight/model-point-damage=states

There SHALL be a single definition of this point for all damage states and all levels ofdetails for a given model. If the DIS origin is not defined, it SHALL defaults to the model
origin.

The following XML tag identifies the point.
Table 6-19: XML Tags for the DIS Origin<CDB:Point
name = "DIS_Origin"/>

Requirement 24
Req 24 req/openflight/model-dis-origin

The CDB Point representing the DIS Origin SHALL be positioned and oriented according
the definition provided by the DIS Standard. This definition says that the DIS Origin is at
the center of the bounding box of the entity, without articulated and attached parts. The
19 This definition can be found on page 3 of reference [4].

Copyright © 2018 Open Geospatial Consortium

57

standard also says what the orientation must be. The X-axis points forward, the Y-axis
points to the right, and the Z-axis points down. All axes are aligned with the boundingbox defined above.

The intent of the DIS Standard is to have its axis system aligned with the body of the entity.
When it comes to air platform, the body is associated with the fuselage of the entity. To
illustrate the difference in orientation between the DIS entity’s bounding box and the CDB
Model’s bounding box, consider the Chinook helicopter shown below.

Figure 6- 33: Orientation of the Chinook Helicopter

The fuselage of this helicopter has a pitch angle of approximately 1.6 degrees when resting on its
wheels. Below is a snapshot of its fuselage, without rotors and landing wheels.

Copyright © 2018 Open Geospatial Consortium

58

Figure 6- 34: The Body of the Chinook Helicopter

From the snapshots above, it is clear that the orientation of the DIS origin must be such that its
XY plane makes an angle of 1.6 degrees with respect to the XY plane of the CDB axis system.
Here is a recommended way of defining the DIS Origin:
1. Create the Group Node and tag it as a CDB Point whose name is DIS_Origin.
2. Make the CDB Point a child of the zone that best represents the entity’s bounding volume
without any articulated and attached parts.
3. Ensure the zone is properly oriented with respect to the CDB axis system.
4. Add a translation to position the origin at the center of the above bounding volume.
5. Add a rotation to align the X-axis to the front of this bounding volume.
6. Add another rotation to align the Z-axis with the bottom of the bounding volume.
7. By doing so, the Y-axis should already point correctly to the right side of the box.

6.6.2.1.1 Example

The snapshot below shows the proper location and orientation of the DIS origin on the Chinook.
The DIS origin is represented by a set of 3 orthogonal Blue-Red-Green arrows. The blue arrow
indicates the X axis; the green arrow points down and represents the Z axis.

Copyright © 2018 Open Geospatial Consortium

59

Figure 6- 35: The DIS Origon of the Chinook Helicopter

If you watch carefully, you will notice that the DIS axis system is aligned with the fuselage andmakes an angle with the CDB XY plane.
6.6.2.2 Model Viewpoint
To generate the correct view of the outside world from a model’s viewpoint, a client device
needs an indication of where is the viewpoint located with respect to the model’s origin. The
viewpoint corresponds to the pilot’s seat in an aircraft, the driver’s seat in a ground vehicle, thenavigation post on a ship bridge, the periscope on a submarine, or the eyes of a soldier.
Requirement 25
Req 25 req/openflight/model-viewpoint

The viewpoint’s local coordinate system SHALL be oriented such that the Y-axis
indicates the viewing direction and the Z-axis points up.

The viewpoint has optional attributes to define the field of view available from this position.
The field of view is defined by a frustum aligned along the local Y-axis. The horizontal field ofview lies in the local XY plane while the vertical field of view is in the YZ plane.

Copyright © 2018 Open Geospatial Consortium

60

Table 6-20: XML Tags for a Viewpoint<CDB:Point name="Viewpoint"><FOV><Horizontal>min max</Horizontal><Vertical>min max</Vertical></FOV></CDB:Point>

All values are expressed in degrees using decimal numbers. The default values are ±30.0° in
both directions for a total of 60.0° of horizontal and vertical fields of view.
6.6.2.3 Model Attach PointA Model can be attached to another Model by mean of an attach point.
An attach point defines the position to which other (subordinate) models can attach themselves.
For instance, a fighter has a number of attach points defined to receive missiles or external fueltanks.
Table 6-21: XML Tags for Attach Point<CDB:Point
name = "Attach_Point"/>

The orientation of the attach point is used to indicate how the two models connect together. A
connection occurs by superimposing the coordinate system of the subordinate model with thecoordinate of the attach point.
6.6.2.4 Model Anchor Point
The anchor point defines the location where a subordinate Model attaches to a parent Model.
The anchor point is the counterpart to the attach point. Both can be seen as the male/female partof a connector and its receptacle.
Table 6-22: XML Tags for Anchor Point<CDB:Point
name = "Anchor_Point"/>

The orientation of the anchor point is used to indicate how the subordinate model connects to theparent model. A connection occurs by superimposing the anchor point (of the subordinate
model) with the attach point (of the parent model).
The default anchor point of a subordinate model is its origin.
6.6.2.5 Model Center of Mass
The Center of Mass (CM) of a Model is a specific point where, for many purposes, the Model
behaves as if its mass was concentrated there.

Copyright © 2018 Open Geospatial Consortium

61

Table 6-23: XML Tags for Center of Mass
<CDB:Point
name = "Center_Of_Mass"/>

6.7 Model Conforming
Historically, the integration of models onto the terrain has been performed during the database
compilation process. These offline approaches varied considerably from vendor to vendor
because there were no standardized approaches related to terrain meshing structures, varying
visual priority and hidden-surface removal mechanisms, runtime LOD mechanisms, number ofLODs, etc.
This section describes a series of model conformal modes that instruct client-devices on how
they should conform models to the underlying terrain.
All of the conformal modes rely on the conforming of the model origin and/or model vertices
onto the terrain mesh directly beneath the model. Note that the Z-component of the model’svertices is with respect to model’s XY plane (as shown in Figure 6- 36: Conforming Vertices to
Terrain).

V1

z
y
V2

z1

Vn
z2

zn
x

z3

V3
Conform vertices to terrain

z1

z2
Elevv2

Elevv1

Elevv3zn

z3

ElevvnTerrain profile

Figure 6- 36: Conforming Vertices to Terrain

Copyright © 2018 Open Geospatial Consortium

62

Note that by definition, all portions of the model below its XY plane represent some form ofunder ground basement. The conforming of models on steep or rough terrain may yield unusual
results because portions of the basement may be visible. This may require the modelers to level
the terrain in the immediate vicinity or adjust the model.
A modeler can specify a model’s conformal mode by adding the following XML tags to the zone
representing the model.

<CDB:Zone><Conformal mode="..."/></CDB:Zone>

The conformal modes are listed in Table 6-24 below.

Table 6-24: Conformal Modes
Conformal Mode
Absolute
Point
VertexLine
Plane
Surface

6.7.1 Non Conformal (Absolute) Mode
When attributed as a Non Conformal model, none of the model vertices are conformed to theunderlying terrain. Instead the model’s Z-values are used as-is, as elevation values. As a result
the model is absolutely positioned and behaves independently of the terrain. The shape andorientation of the model is preserved. This conformal mode is typically used for the modeled
representation of point-features. Typical use-cases include buildings, trees, and poles.
6.7.2 Point Conformal Mode
The Point Conformal mode conforms a single point of the model (its origin) onto the underlying
terrain. All of the other model vertices are translated along the Z-axis; as a result, the shape ofthe model is preserved by this conformal operation. In effect, the Point Conformal mode
dynamically positions a model on the underlying terrain so as to preserve the model’s relative
altitude over the terrain. Point-conforming is the default conformal mode for the modeled
representation of point-features. Typical use-cases include buildings, trees, and poles.

Copyright © 2018 Open Geospatial Consortium

63

z
y
H
Model origin
x

Omod

z
y

E

Terrainx

Figure 6- 37: Origon Conformal Mode

6.7.3 Vertex Conformal Mode
The Vertex Conformal mode conforms each of the vertices of a model on the underlying terrain.
The shape of the model is not preserved by this conformal operation. The model’s XY plane
defines a reference plane used by client-devices to adjust the elevation of each of the model’svertices. This conformal mode is used for 3D models that represent typically long 3D lineal
features or large 3D areal features that need to follow the terrain profile. Typical uses include
fences, walls, trenches, and forest canopies.

Copyright © 2018 Open Geospatial Consortium

64

Hv

Conform vertices to terrain

Ev

Et

Terrain profile

Figure 6- 38: Vertex Conformal Mode Example

6.7.4 Line Conformal Mode
The Line Conformal mode conforms each of the two reference vertices of the “linear” model on
the underlying terrain. All of the other model vertices are sheared along this axis; as a result, theshape of the model is not preserved by this conformal operation. The model’s XY plane defines
a reference plane used by client-devices to adjust the elevation of the two reference vertices.
This conformal mode is used for models that represent lineal features such as powerlines andmonorails.

Copyright © 2018 Open Geospatial Consortium

65

z
y

Vs

Ve

x

z

Into Terrain
coordinateszyElevvsTerrain profile

Elevvex
Figure 6- 39: Line Conformal Mode

The line that is used to specify the conforming is defined by a Face node with the following
XML tags:<CDB:Face><Conformal_Line/></CDB:Face>

This Face node defines a single line with two vertices, the first one, Vs, being the start and thesecond, Ve, the end of the line.
6.7.5 Plane Conformal Mode
The Plane Conformal mode conforms each of the three reference vertices of the “planar” modelon the underlying terrain. The resulting three vertices define a model transformation matrix that
can then be applied to the vertices of the model. As a result, the shape of the model is preservedby this conformal operation, but the model undergoes a change in pitch and roll angles. Given

Copyright © 2018 Open Geospatial Consortium66

this property, there are relatively few cases where this conformal mode can be used20. However,as shown in
Figure 6- 41: Application of Line and Plane Conformal Modes on 3d Roads, this conformal mode is required when conforming the curved segments of 3D (raised profiled)modeled road features.

Figure 6- 40: Plane Conformal Mode

20 Man-made structures and tree vegetation do not tilt regardless of the terrain they are on.

Copyright © 2018 Open Geospatial Consortium

67Plane Conformal
T2DModels

Vp1
Vs

Vp2 = Vs

Ve = Vp2

Line Conformal
T2DModels
Figure 6- 41: Application of Line and Plane Conformal Modes on 3d Roads

The plane that is used to specify the conforming is defined by a Face node with the following
XML tags:<CDB:Face><Conformal_Face/></CDB:Face>

The Face node has exactly 3 vertices defining the plane used for the conforming. The only
restriction on these 3 vertices is that they must not be collinear.
6.7.6 Surface Conformal Mode
This conformal mode is used for models whose points, edges and surfaces must all conform
exactly to the underlying terrain. The Surface Conformal mode requires that the model’s edges
and surfaces be clipped to the underlying terrain. The original vertices and the added vertices
resulting from the clipping operation are conformed to the underlying terrain. As a result, theshape of the model is not preserved by this conformal operation. This conformal mode isprimarily used for the modeled representation of 2D surface-feature such as paint markings andother terrain overlays. In addition, it can be used for 3D models that represent typically long orlarge 3D lineal and 3D areal features that need to perfectly follow the terrain profile. Note that

Copyright © 2018 Open Geospatial Consortium68

in most cases, the vertex conformal mode provides an adequate solution for 3D models and ismore economical to use than the surface conformal mode.
V4

V3
z3

V2

V1
C1

C1
z4

Clip and conform triangles to terrain

Clipped vertices
z3
Elevv1

Elevc1

Elevv2z4

Elevv4
Elevc2

Terrain profile
Elevv4

Figure 6- 42: Surface Conformal Mode

6.8 Model Levels-of-Detail
Requirements Class – Model Levels of Detail/req/openflight/model-lod
Target typeOperations

Dependency

Openflight Specification

Requirement 26 /req/openflight/significant-sizes
A levels-of-detail model structure is essential when the intent is to use a model in a real-time
application such as flight simulation. The level-of-detail mechanism provides client-devices
with the essential structure for deterministic operation. Deterministic operation can be achieved
only if a client-device can:control the paging bandwidth from the CDB main storage device
control client-device processing load

Copyright © 2018 Open Geospatial Consortium69

control client-device memory footprint
control run-time publishing processing load andcontrol run-time publishing memory footprint
For this reason, it is recommended to create LODs, especially for complex Models, and formodels that are used extensively, in great density in the CDB data store. This is most critical forgeospecific cultural models (especially in densely modeled geospecific areas of the synthetic
environment) since they can consume a significant portion of the paging bandwidth and memory
footprint of the client-devices. As a corollary, simple Models should not be made more complex
by adding unnecessary level of details. The CDB standard provides rules for determining model
complexity, and selecting the appropriate LOD, as defined in Chapter 3 of Volume 1: OGC CDB
Core Standard:Model and Physical Database Structure.
OpenFlight LOD nodes now support two methods of specifying the criteria to determine if alevel of detail is active, that is if the user application should traverse the node and its children.
The first method, the classic one, is to specify the switch in and switch out distances in realworld units. Using this method, a level of detail is active when the distance from the viewpoint
to the center of the LOD is within the switch-in and switch-out distances. The second method
uses the Significant Size associated with the LOD node to determine when to activate the node.
Requirement 26
Req 26 req/openflight/significant-size

The CDB Standard SHALL:
•
•
•
•
•

Use the Significant Size associated with the LOD node to determine when to
activate the node
The Significant Size of LOD node 2 SHALL be less than the Significant Size of
LOD node 1.
Features whose Significant Size is larger than 110 km (the dimension of a
geocell) SHALL be clipped (if a continuous surface) or ungrouped (if multiple
discontinuous surfaces) until the maximum size criteria is met.
LOD nodes SHALL be sorted in decreasing order of their Significant Sizeattribute.
Sibling LOD nodes SHALL be mutually exclusive.

There are several problems associated with the classic, range-based method. In a visual system
for instance, the switching distance should be based on both range and the system resolution of
the entire visual system; a database designed to rely solely on a range-based switching criteria is
not truly portable, especially if the intent is to use it on systems with wildly different visual
resolution. Furthermore, the blending or morphing of models solely based on range criteria canlead to undesirable effects. When the viewpoint moves quickly, the distance over which the

Copyright © 2018 Open Geospatial Consortium70

model is LOD-transitioning should be large enough to avoid the “popping-in” of the higher LOD
version. On the other hand, if the viewpoint is moving very slowly, the distance over which themodel is LOD-transitioning should be reduced to avoid the “LOD-ghosting” of the higher LOD
version. These two constraints make implicit assumptions on the model’s speed. In applications
where the aircraft’s flight regime varies considerably (V22 for example), it is impossible to finda single set of LOD start and end points that simultaneously cater to all flight modes (hoverversus cruise). Here again, a database design that directly encodes the start and end points of amodel’s LOD transition is not truly portable, because it makes implicit assumptions on the speed
it will be used for. Thus, in a tactical fighter application, the start and end points of a model’s
LOD transition need to be widely spaced apart to prevent a popping effect at the onset of the
LOD transition. Conversely, in a tank application, the start and end points of a model’s LOD
transition need to be much more closely spaced to prevent a ghosting effect as the higher LOD
model is blended-in. If the client device wants to implement some form of transition between
LODs, the criteria should be based on a user-defined duration. Transitions between LODs caninvolve fading in the next LOD while fading out the current one. That fading operation should
not last forever. It should be accomplished in a relative short period of time. The second method
to transition from one LOD to the next is to use morphing. In the case of morphing, thetransition period is less critical because the client-device (typically an Image Generator) does notblend-in two models together.
The consequences of such implicit assumptions result in a database that is highly client-device,
and application-specific.
For all these reasons, the CDB standard has selected the second method to control the LOD
mechanism.
Two methods exist to implement LODs, exchange or addition. The two methods can be usedsimultaneously and are not mutually exclusive.
In the first method, details are progressively added to the model, as the viewpoint gets closer.
With the second method, different representations of the same model are substituted for one
another based on the viewing distance. Figure 6- 43: Echange and Additive LOD Nodes, illustrates the general organization of Models with both types of LOD nodes.
6.8.1 Exchange LODs
In the exchange LOD method, different representations of the same model are substituted for one
another based on the model’s Significant Size. It is up to the client-devices to derive appropriate
LOD transition viewing distance from the model’s Significant Size and the client-device’s fieldof-view and resolution parameters.
6.8.2 Additive LODs
Additive LOD is just a special case of the more general Exchange LOD paradigm. When a LOD
node has no sibling LOD, it becomes an Additive LOD node. That does not change the fact thatat most one LOD node gets selected when its Significant Size justifies it.

Copyright © 2018 Open Geospatial Consortium71Figure 6- 43: Echange and Additive LOD Nodes

The LOD nodes in light brown represent Exchange LODs and are mutually exclusive. The two
dark brown shaded LOD nodes are considered Additive LODs because they do not have anothersibling node of type LOD.
Note that to make sense, the Significant Size of LOD node 2 must be less than the Significant
Size of LOD node 1 (Requirement 26). The same is true for the Significant Size of LOD node 3
with respect to LOD node 2. Also, LOD node 3 has an additional constraint, its Significant Sizemust be greater than the one assigned to LOD node 4. If these constraints are not followed, LOD
node 4 will be selected before LOD nodes 2 or 3 have a chance of being displayed.
6.8.3 Significant Size
The concept of a Significant Size is a recent improvement of the OpenFlight Specification.
When a finer model LOD is created, the modeler typically adds additional geometric detail,additional features (such as markings), or refines the shape of curved surfaces (such as engines,
wheels), etc. When assigning a Significant Size to a model LOD, the modeler needs to answer
the following question: When I created a new model LOD, I did so to create additional detail in
my model. What is the largest dimensional change in geometry for this new model LOD? In
other words, what is the largest dimensional difference of a surface between this LOD and thenext coarser LOD? In effect, the value of Significant Size corresponds to the “modelingdifference” between the LOD and the next coarser LOD. At runtime, a client-device converts
this modeling difference value from its real-world dimensional value into a viewing error value(typically measured in pixels or degrees). The client-device can then activate the appropriate
model LOD because it knows that the modeler’s intent in creating the LOD was to showfeatures, eliminate all modeling discrepancies whose dimension equaled that of the Significant
Size dimension associated with that model’s LOD. This contribution of the LOD to the scene is

Copyright © 2018 Open Geospatial Consortium

72

based on the LOD’s Significant Size as well as other parameters (such as system resolution)
relevant to the simulation model used by the client device.
Version 16.0 of the OpenFlight Specification introduces the concept of Visual Significance thatis different from the concept of Significant Size. The concept of Visual Significancetranslates in two fields called Significance and they are found in the Group Record
and Object Records21. Here is the definition of this field as found in reference [11]:“Significance can be used to assist real-time culling and load balancing
mechanisms, by defining the visual significance of this group with respect to othergroups in the database. Normally the value of this attribute is zero”.
The CDB standard mandates a value of zero for Visual Significance; the value zero indicatesthe object or the group has no particular significance and is not more or lessimportant than any other objects or groups. Any other values, whether negative or
positive, are reserved for future use by this Specification.

6.8.3.1 Definition of Significant Size
The Significant Size is defined as the “size” of the model, expressed in meters. By extension, it
applies equally well to a submodel represented by an Additive LOD. In the case of an Exchange
LOD, the Significant Size is the difference between two representations of the model or submodel.
6.8.3.2 Estimating the Size of the Model
Many models have shapes that resemble a cube (with roughly equal length, width, and height), andthus their significant size can be simply estimated by the length of the diagonal of their boundingbox. As the shape of a model departs from that of a simple cube, either with respect to aspect ratio, orwith respect to the amount of negative space within its bounding box, the model’s significant size
should be decreased proportional to the amount of departure.
6.8.3.3 How to use the Significant Size
The Significant Size is used to distribute models into appropriate CDB LODs. Once a value isassigned to the coarsest LOD of a model, subsequent LODs of the same model can be distributed tosubsequent CDB LODs. Use Table 3-1 and the model Significant Size to identify the CDB LOD it
belongs to.
For instance, if the size of a building is estimated to 75 meters, then its coarsest LOD will be storedin CDB LOD 0, according to Table 3-1. On the other hand, a 2-meter park bench will appear in CDB
LOD 5.
6.8.4 LOD Limits
The number of vertices per LOD is limited to ensure a smooth progression between all
representations of the same model. Table 6-25 below gives the maximum number of vertices allowed
for each Model-LOD.
Table 6-25:

Maximum

CDB LOD

21 Users of Creator 3.0 will find the exact same definition for Significance in both the Group and Object Attributes
Help pages.

Copyright © 2018 Open Geospatial Consortium73MaximumNumber of
Vertices per
Model-LOD
Model-LOD
0
1
2
3
4
5
6
7

Number of
Vertices

128
512
2048
8192
32768
1310725242882097152

CDB LODc + 0
CDB LODc + 1
CDB LODc + 2
CDB LODc + 3
CDB LODc + 4
CDB LODc + 5
CDB LODc + 6
CDB LODc + 7

The table above shows that a model is allowed up to 8 levels of details, numbered from 0 to 7.
Model-LOD 0 is the coarsest level of detail of the model and may count up to 128 vertices. As thecomplexity of subsequent Model-LODs augments, a higher vertex count is permitted. The CDB LOD
that is associated with a Model-LOD is expressed relative to the CDB LOD assigned to its coarsest
representation, designated by CDB LODs.

6.8.4.1 How to Assign CDB LODs
To illustrate the use of Table 6-25, take a 3D model representing a building with three
representations:
Coarsest LOD:o 8 verticeso Significant Size estimated to 25 meters• Medium LOD:o 2244 verticeso Significant Size estimated to 4 meters• Finest LOD:o 10320 verticeso Significant Size estimated to 10 cm
The CDB LODs are first established by looking up the Significant Sizes of the three
representations in Table 3-1:
• Coarsest LOD:
o 25 m is CDB LOD 2
o This is CDB LODc
• Medium LOD:o 4 m is CDB LOD 4• Finest LOD:o 10 cm is CDB LOD 10
We then use the vertex count to identify the Model-LOD in Table 6-25:• Coarsest LOD:o 28 vertices is Model-LOD 0• Medium LOD:o 2244 vertices is Model LOD 3
o Should be assigned to CDB LODc (2) + 3 = 5• Finest LOD:•

Copyright © 2018 Open Geospatial Consortium74

o 10320 vertices is Model LOD 4o Should be assigned to CDB LODc (2) + 4 = 6
Since all representations of the model must meet both the constraints associated with the
Significan Size and the Vertex Count, the final CDB LODs are the maximum ones identified
above.
• Coarsest LOD:o CDB LOD 2• Medium LOD:o CDB LOD 5• Finest LOD:o CDB LOD 10
6.8.5 LOD Generation Guidelines
The following guidelines should help modelers produce efficient CDB models for use in real-timeenvironments. There are two way of proceeding; one way is to create the finest representation of themodel and then simplify it until the coarsest representation is obtained. The other way consists increating the coarsest representation first and then refining it until the desired representation is
obtained. In general:
•
•
•
•
•
•

The coarsest Model-LOD is the simplest possible geometric representation of the modelusing at most 128 vertices.
A coarser Model-LOD is created by removing details from a finer Model-LOD.
Alternately, a finer Model-LOD is created by adding details to a coarser Model-LOD.
In both cases, the size of the details that are removed or added to a Model-LOD should beconsistent with its Significant Size.
Model-LOD 0 is mandatory; the others are optional and exist only if Model-LOD 0 isn’t
sufficient to represent the model with a proper level of detail.
Multiple Model-LODs do not need to be consecutive.

6.9 Model Switch Nodes
A Switch Node allows the selection of zero or more children by invoking a selector mask. Any
combination of children can be selected per masks and the number of definable masks isunlimited. The CDB standard makes use of OpenFlight Switch Nodes to control the state ofModel Components (zones and points).
Requirements Class – Model Switch Nodes/req/openflight/model-switch-nodes
Target typeOperations

Dependency

Openflight Specification

Requirement 27 /req/openflight/switch-mask

Copyright © 2018 Open Geospatial Consortium75

Requirement 28 req/openflight/switch-mask-name
6.9.1 Definition
XML tags in the comment record are added to the switch’s primary record to identity it as a CDB
Switch.
Table 6-25: XML Tags to Create a CDB Switch<CDB:Switch name = "switch name">... switch attributes</CDB:Switch>

Requirement 27
Req 27 req/openflight/switch-mask

The switch SHALL contain one mask per state. Note that the first mask, mask index 0, isthe default mask. This means that the value of the Current Mask field in the Switch
record SHALL be 0.

As an example, if the switch has 3 children, each representing a separate state of the parent zone,
then the switch needs 3 masks, each selecting one child.
Requirement 28
Req 28 req/openflight/switch-mask-name

In addition to defining a mask for each switch state, each mask SHALL be named. The
name of the mask SHALL be representative of the state selected by that mask.

The actual name is at the discretion of the modeler.
The corresponding OpenFlight records are as follow:
Table 6-26: OpenFlight Records to Create a CDB Switch
SWITCHCOMMENT (mandatory)
INDEXED STRING

Copyright © 2018 Open Geospatial Consortium766.9.2 Usage
6.9.2.1 Articulations
Switch nodes provide an alternative to DOF nodes when an articulated part is implemented for
only a few positions. An example of this use of switches is the control of undercarriage orcontrol surfaces on aircraft. Suppose the modeler wants to represent the flaps in two distinct
positions: flaps up and flaps down. A switch is the simplest way to implement these two flaps
positions. In this example, the switch name could be “Flap Control” and the two mask names
could be “Flap Up” and “Flap Down”.
Suppose the modeler wants to provide two positions for the door on a hangar: open and close. In
addition, when the door is open, the modeler provides a representation for the interior of thehangar, which is not the case when the door is closed. Again, the use of a switch is appropriate
to provide the control over the door position. A proper name for the switch would be “Door
Position” and the appropriate names for the two masks would be “Door Closed” and “DoorOpen”.
6.9.2.2 Damage States
Switch nodes can be used to select one of many modeled representations of damages. A zone has
at least a normal (usually undamaged) state. When other states exist, an OpenFlight switch nodeis used to select which state is active. A single damage state can be active at any time.
Requirements Class – Damage Status/req/openflight/damage-status
Target typeOperations

Dependency

Openflight Specification

Requirement 29 /req/openflight/damage-transition
Requirement 30 req/openflight/damage-orderFigure 6- 44: General Damage State Tree Structure
shows the general organization of a zone with several states.

Copyright © 2018 Open Geospatial Consortium77

Figure 6- 44: General Damage State Tree Structure

Each damage state represents the zone with a certain level of damage. This level of damage isexpressed as a percentage from 0 to 100%. A level of damage of 0 % means the zone is notdamaged at all. At the opposite end, a percentage of damage of 100 % indicates the zone iscompletely destroyed.
To identify a damage state switch, use the following XML tags in the switch comment record.
Table 6-27: XML Tags for Damage State Switch<CDB:Switch name = "Damage_State"><Damage_Level>...</Damage_Level></CDB:Switch>

The XML element <Damage_Level> is a list of percentages representing the transitions between
child nodes of the switch. The list counts ‘n-1’ entries where ‘n’ is the number of states.
Requirement 29
Req 29 req/openflight/damage-transition

The percentages representing the transitions SHALL be limited to the range [0, 99]. The
value 100 is not allowed because the level of damage SHALL exceed the transition value
in order to select the correct state.

To illustrate the concept of level of damage, assume a damage state switch has 3 child nodes
representing the zone in normal, damaged, and destroyed states. Also, assume that the modeler’s
intent is to switch to the damaged state when the level of damage exceeds 25 %, and to switch to
the destroyed state when the level of damage exceeds 75 %. Here, the XML tag associated withthe switch should look like this.

Copyright © 2018 Open Geospatial Consortium

78

Table 6-28: Example of a Damage State Switch with Two Transitions<CDB:Switch name = "Damage_State"><Damage_Level>25 75</Damage_Level></CDB:Switch>

Requirement 30
Req 30 req/openflight/damage-order

The ordering of damage states SHALL be from left (normal state) to right (destroyed
state). All intermediate states must represent increasingly damaged states from a slightly
damaged state to an almost destroyed state. The number of states is left to the discretionof the modeler.

Figure 6- 45: Damage States Ordering

While the number of damage states is left to the discretion of the modeler, some choices are
better than others. Since a Model is meant to be used in a simulator and since many simulators
are DIS-compliant, it is suggested to create the same number of CDB damage states as there are
DIS damage states for the corresponding entity.
For instance, if the Model represents a DIS land platform such as the M1A2 tank, the modeler
could create four damage states to match the four corresponding DIS damage states labeled No
Damage, Slight Damage, Moderate Damage and Destroyed.
The DIS and the HLA standards are relatively vague regarding the definition of damage states.
In the case of the DIS standard, the damage state is a field that belongs to a structure called the
Entity Appearance. The field has only 2 bits and, accordingly, accommodates four different
values. For HLA, version 2 of the RPR-FOM defines the damaged appearance as a 32-bit

Copyright © 2018 Open Geospatial Consortium

79

enumeration for which only 4 values have been defined so far – the same values as the one
defined by DIS, that is No Damage, Slight Damage, Moderate Damage and Destroyed.
For both DIS and HLA, it is obvious that the damage state is meant to be a visual damage state.
The question to answer is the following: “What should the universally accepted visualappearance be for a slightly (or moderately) damaged state?”
In the DIS world, a platform is often qualified in terms of Mobility and Fire Power22. Using
these two criteria, it is possible to define the following guidelines.
A slightly damaged model should represent a platform with limited mobility. However,its firepower is intact and it should be apparent that the entity is still capable of firing its
weapons.
• A moderately damaged model should represent a platform for which both mobility andfirepower are reduced without being completely out of service.
As a corollary, here are the definitions of normal and destroyed states.
••

An undamaged model should represent a platform for which both mobility and fire power
are completely operational.

A destroyed model should represent a platform for which both mobility and firepower arecompletely out of service.
6.9.2.3 Temporal Anti-aliasing
Temporal anti-aliasing may be achieved with the use of special textures. These textures are often
required to aid IG client-devices to eliminate strobing effects on model rotating objects such as
helicopter rotors, aircraft propellers, or vehicle wheels.

Figure 6- 46: Example of a Texture Representing a Rotor, is an example of a semi-transparent texture used to simulate a rotating helicopter rotor.

22 Note that, on top of the Damage State field, the DIS Entity Appearance structure has two flags to describe the

Mobility and Fire Power of the entity. This is also true for HLA and version 2 of the RPR-FOM which provides for
two flags to describe the fire power and mobility of a physical entity on top of the field used to describe the damage
state.

Copyright © 2018 Open Geospatial Consortium80

Figure 6- 46: Example of a Texture Representing a Rotor

Motion blur textures are general base textures with a Texture Kind of S001. The Texture Index(Tnn) is used to sequentially number several motion blur textures representing the same object.
The use of motion blur textures can be combined with DOF and Switch nodes to produce
efficient switching between several versions of a single rotating part.
The following subtree illustrates how four versions of the above rotor could be modeled using
one solid version and three blurred versions.

Figure 6- 47: Multiple Versions of Rotating Parts

In this example, three textures are used to represent an increasingly blurred rotor.

Copyright © 2018 Open Geospatial Consortium81

In order to detect the presence of the above construct, the following XML comment must be
added to the switch node.
Table 6-29: XML Tags for Motion Blur Switch<CDB:Switch name = "Motion_Blur"><Blurriness>...</Blurriness></CDB:Switch>

The children of the switch node could be any OpenFlight nodes. Most likely, the nodes that
contain the geometry will be OpenFlight Object nodes.
When modeling solid and blurred objects in this manner, the CDB Standard requires that theleftmost child node contains the solid version of the object while the sibling nodes to the rightcontain increasingly blurred version of the same object.
The XML element <Blurriness> is a list of percentages representing the transitions between childnodes of the switch. The list counts ‘n-1’ entries where ‘n’ is the number of child nodes.
Requirement 31
Req 31 req/openflight/blurring-transition

The percentages representing the transitions SHALL be limited to the range [0, 99]. The
value 100 is not allowed because the level of blurriness SHALL exceed the transition
value in order to select the correct child node.

To illustrate the concept of level of blurriness, assume a motion blur switch has two child nodes.
Also, assume that the modeler’s intent is to switch to the second node when the level ofblurriness exceeds 10 %. Here, the XML tag associated with the switch should look like this.
Table 6-30: Example of a Motion Blur Switch with One Transition<CDB:Switch name = "Motion_Blur"><Blurriness>10</Blurriness></CDB:Switch>

6.10 Model Articulations
Requirements Class – Model Articulations/req/openflight/model-articulations
Target typeOperations

Dependency

Openflight Specification

Copyright © 2018 Open Geospatial Consortium82

Requirement 32 req/openflight/articulation-node-rotation
Requirement 33 /req/openflight/gimbal-limits
Requirement 34 req/openflight/articulation-flags
6.10.1 Definition
An OpenFlight DOF node is used to implement the concept of a CDB Articulation. The node
gives the modeler controls over all 9 degrees of freedom, translation, rotation and scaling on all 3
axes. Generally, only one degree of freedom is allowed at a time and most often, that single
degree of freedom is a rotation about a single axis. However, the modeler is free to allow any
translation, rotation and, even scaling; even though stretching an articulation does not usually
produce a realistic effect.
Since only one articulation is allowed per zone, the zone name is sufficient to identify andcontrol the DOF node.
A CDB Articulation node is an OpenFlight DOF node with attributes in the form of XML tags.
The table below presents the syntax of the XML tags stored in the DOF node’s comment record.
Table 6-31: XML Tags for DOF<CDB:Articulation name="name" id="id"><Translation><X rate="value" /><Y rate="value" /><Z rate="value" /></Translation><Rotation><X rate="value" /><Y rate="value" /><Z rate="value" /></Rotation><Scaling><X rate="value" /><Y rate="value" /><Z rate="value" /></Scaling></CDB:Articulation>

The above XML tag is necessary in two circumstances:
1. The articulation represents a DIS Articulated Part.
2. The articulation is to be animated automatically.
A CDB Articulation node has an optional name that is used to self-document the articulation.
The optional identifier provides the corresponding DIS Articulated Part. It is suggested to use a

Copyright © 2018 Open Geospatial Consortium83name inspired from the DIS Articulated Part ID, when the identifier is supplied. For instance,
DIS identifies as Primary Gun 1 the articulated part whose ID is 4416. That example would
generate the following XML tags:<CDB:Articulation name="Primary Gun 1" id="4416" />Section 4.7.3 in reference [4] provides a list of DIS Articulated Part IDs.
It is possible to specify an optional Rate-of-Change for each Degree of Freedom along their X,
Y, and Z axes for Translation, Rotation, and Scaling. The translation rate is expressed in meters
per second. The rotation rate is expressed in degrees per second. Finally, the scaling rate is inunits per second. When not specified, a default rate of zero is assumed.
Requirement 32
Req 32 req/openflight/articulation-node-rotation

The translation rate SHALL be expressed in meters per second. The rotation rate SHALL
be expressed in degrees per second. Finally, the scaling rate SHALL be expressesd inunits per second. When not specified, a default rate of zero SHALL be used.

For instance, a primary radar antenna that rotates at a rate of 10 degrees per second about its Zaxis would require the following XML tags:<CDB:Articulation name="Primary Radar 1" id="5376"><Rotation><Z rate="10"/></Rotation></CDB:Articulation>

Another example, to illustrate how to attribute a rotating wind mill; assuming the mill rotates
about the Y-axis at a rate of 5 degrees per second:<CDB:Articulation><Rotation><Y rate="5"/></Rotation></CDB:Articulation>

Requirement 33
Req 33 req/openflight/gimbal-limits

Gimbal limits are mandatory on DOF nodes and the appropriate flags SHALL be set to

Copyright © 2018 Open Geospatial Consortium84

specify which degrees of freedom are controlled by a particular articulation.

Requirement 34
Req 34 req/openflight/articulation-flags

The Flags field is located at offset 376 in the OpenFlight DOF record and its value cannot
be zero because the articulation SHALL control at least one degree of freedom.

6.10.2 Usage
6.10.2.1 Rotating Parts
A common problem in simulation is to correlate the linear speed of a model with the angularspeed of its wheels. More generally, the client device simulation models often require thedimension of rotating parts. This information can be obtained from the zone extent; thebounding box surrounding a zone provides the dimension of rotating parts.
6.11 Model Light Points
The CDB standard does not make a distinction between light points and light sources. Bothrepresent real lights that emit light and that can illuminate neighboring objects. In most current
visual systems, a light point is a simple representation of a point source of light when viewed
from a distance; it has no observable lighting effect on its immediate surroundings. In real-life
however, as an observer moves closer to the light, its lighting or illuminating effect on thesurrounding objects becomes increasingly observable; furthermore, the actual shape of the lightalso becomes more distinct.
In a typical simulator, client-devices may choose to limit the representation of the light to asingle point and neglect the illuminating effect of the light on neighboring objects and terrain.
For this reason, it is up to the client (and its RTP) to determine whether a light can illuminate its
surroundings or not; the decision is based on the type of light and the inherent
capabilities/capacity of the client.
Another point to consider is the fact that a light may have a very different representation
depending on the client device. For instance, consider the visual representation of a light by an
IG compared with the representation required by a radar system, NVG device or a FLIR device.
For all of these considerations, the CDB standard has adopted the following approach in defining
lights. The OpenFlight file defines only the position, direction and the name of the light type; noother attributes are specified. The CDB standard provides a very elaborate light type naming
convention. This convention permits clients to internally derive all of the properties andparameters needed to render the light. The approach is entirely device-independent. Modelers

Copyright © 2018 Open Geospatial Consortium85

need not concern themselves with hundreds of parameters, many of which are often specific tounderlying 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 deviceindependent, 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 listof 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 req/openflight/light-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 LEVELVERTEX 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 areautomatically propagated from higher levels through lower levels of the OpenFlight graph. A
child node inherits the attribution of its parent node.

Copyright © 2018 Open Geospatial Consortium866.12.1 Definition
Model attributes are added to OpenFlight nodes through a Comment record containing XML
tags. The general format is as follows:<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 thefollowing values:

Zone
Point
Group
ObjectSwitchFace
MeshArticulation
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 thematching 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 theattribute.
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 req/openflight/model-vendor-attributes

The definition of vendor attributes SHALL be stored in Vendor_Attributes.xml

Copyright © 2018 Open Geospatial Consortium87

It is understood that vendor attributes are not interpreted by any other client-devices other thanthose supported by the vendor. Reliance by a vendor on Vendor Attributes can reduce theinteroperability 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; thezone 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 vendorspecific 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 andinterpret the attribute’s value. Furthermore, if the client application recognizes the identificationof the vendor (Acme:), it knows what to do with MyAttr.
6.13 Model Textures
Requirements Class – Model Textures/req/openflight/model-textures
Target typeOperations

Dependency

Openflight Specification

Copyright © 2018 Open Geospatial Consortium

88Requirement 37 req/openflight/texture-file-loading
Requirement 38 /req/openflight/quarterly-textures
Requirement 39 req/openflight/monthly-textures
Requirement 40 req/openflight/texture-mipmap
Requirement 41 req/openflight/texture-palette-path
Requirement 42 req/openflight/texture-shadow-geometry
Requirement 43 req/openflight/model-skin-textures
Requirement 44 req/openflight/model-night-maps
Requirement 45 req/openflight/night-map-generation
To achieve a certain degree of realism, models require the use of textures. Furthermore, textures
add details to a model without increasing its polygon count. This is excellent to reduce thecomplexity of the geometry but at the same time, it creates a load management issue for client
devices that are interested in these textures.
Requirement 37
Req 37 req/openflight/texture-file-loading

In the case of GTModels and MModels, textures are separate files that SHALL be loaded
after the model geometry files are read and loaded by client devices; in the case of
GSModels and T2DModels, the textures can be loaded concurrently with the model
geometry files.

A client device discovers the existence of textures while loading the model.
One of the goals of the CDB standard is to allow client devices to implement efficient load
management mechanisms. For this reason, the Specification decouples as much as possible thetexture aspect of a model from its geometry aspect. This is done by storing all textures related toModels in separate directories.
Recall that the texture filenames itself are constructed from the dataset number, the texture type(selectors 1 and 2), and the texture LOD and these are then concatenated to a modeler-specifictexture name. Section 6.13, Model Textures, provides a description and usage of all of the CDB
texture types for Models. The values of component selectors 1 and 2 convey a semantic meaning
to the texture (time-of-year, paint scheme, night map, light map, normal map, etc) and determine

Copyright © 2018 Open Geospatial Consortium89

whether the texture is to be used as base texture or as a subordinate texture and whether the
texture is switchable (described in the next section).
6.13.1 Handling of Multi-textures
In OpenFlight, several types of textures can be applied in various combinations. Textures fall in
two broad categories: Base and Subordinate.
6.13.1.1 Base Texture Layer
Base textures23 are set of mutually exclusive model textures that provide texture color/intensity
modulation for the model. While a model can have many base textures, only one base texture
can be referenced and applied to model geometry at a time.
The CDB standard supports the following type of Base Textures.
(1) Year-Round Texture: A year-round texture used with GTModels, MModels,
GSModels, T2DModels . In the case of MModels, base-textures are often
replaced with an appropriate Paint Scheme texture (Uniform, Camouflage or
Airline).
(2) Quarterly Textures: A set of 4 textures, each representative of a quarter within
the calendar year used with GTModels, GSModels, T2DModels .
Requirement 38
Req 38 req/openflight/quarterly-textures

The textures SHALL be provided as a complete set, i.e., it is assumed that all 4 textures ofthe same kind (i.e., all four textures have their component selector 1 set to 003) and are allpresent in the model’s texture directory.
The presence of a quarterly texture reference in model geometry tells the clientdevice that a quarterly texture set is available. This allows the client-device toselect any one of the available 4 textures at rendering time. Only one of the
textures need be referenced by the OpenFlight scenegraph geometry, preferably
the third quarter texture. It is also assumed that all 4 textures share the same UV
mapping.
(3) Monthly Textures: A set of 12 textures, each representative of a month within
the calendar year used with GTModels, GSModels, T2DModels .
Requirement 39
Req 39 req/openflight/monthly-textures

23

The CDB Standard uses the term “base texture” the same way as OpenFlight and Creator do.

Copyright © 2018 Open Geospatial Consortium

90

The textures SHALL be provided as a complete set, i.e., it is assumed that all the 12
textures are of the same kind (i.e., all twelve textures have their component selector CS1= 002) and are all present in the model’s texture directory.
The presence of a monthly texture reference in model geometry tells the clientdevice that a monthly texture set is available. This allows the client-device toselect any one of the available 12 textures at rendering time. Only one of the
textures need be referenced by the OpenFlight scenegraph geometry, preferably
the June texture. It is also assumed that all 12 textures share the same
UVmapping.
(4) Uniform Paint Scheme Textures: Used on MModels with relatively uniform
paint schemes should make use of this texture kind. Colors are listed in Appendix
O. It is also assumed that all textures share the same UVmapping.
(5) Camouflage Paint Scheme Textures: Used on MModels with camouflage paintschemes should make use of this texture kind. Camouflages are listed in Annex O(Volume 2: OGC CDB Core: Model and Physical Structure Annexes). It is also
assumed that all textures share the same UVmapping.
(6) Airline Paint Scheme Textures: Used on MModels that represent commercial
aviation airliners should make use of this texture kind to implement the airlines
paint scheme and logos. This base texture addresses the need for multiple skins
painted on identical aircraft type. For instance, the B767-300ER is operated bymore than 60 airlines throughout the world. Annex O Volume 2: OGC CDB
Core: Model and Physical Structure Annexes provides a complete list of Airliners.
It is also assumed that all textures share the same UVmapping.
(7) Shadow Map Textures: Used on MModels as pre-computed orthographic
projections of the MModel. These textures are base textures used to accelerate
the rendering of MModel shadows. Shadow map usage conventions are describedin section 6.13.5.1, Model Shadow Textures.
(8) Motion Blur: Used on MModels as pre-computed motion blurred textures ofrotating parts (e.g., rotor disks). These textures are base textures used to aid
client-devices in eliminating temporal aliasing artifacts. Motion blur textures
conventions are described in section 6.9.2.3, Temporal Anti-aliasing.
6.13.1.2 Subordinate Texture Layer
Base textures can be supplemented with one or more24 subordinate textures. Subordinate
textures form a set of model textures that can be used to provide additional color/intensity
modulation or illumination modulation detail to the Base texture.
The CDB standard supports the following types of subordinate textures.

24

texture.

OpenFlight natively permits up to seven subordinate textures for a total of eight textures including the base

Copyright © 2018 Open Geospatial Consortium

91

(1)

(2)

(3)
(4)

(5)
(6)
(7)
(8)

Night Map: This subordinate texture is used to represent changes to models intheir night configuration, typically as a result of lighting effects emanating frominside the model through windows. Night map textures conventions aredescribed in greater detail in section 6.13.5.3, Model Night Maps.
Detail Texture (Micro/Macro): This subordinate texture is used to add details
to a base texture that lacks the necessary resolution to provide the correct depth
perception. Detail textures conventions are described in greater detail in section
6.13.5.6, Model Detail Texture Maps.
Contaminants: These textures are used to simulate thin layers of matter that
accumulate on surface top. Contaminant textures conventions are described ingreater detail in section 6.13.5.7, Model Contaminant and Skid Mark Textures.
Normal Map: Normal mapping is a technique used for faking the lighting ofbumps and dents; when used in conjunction with a render’s light sources, it can
add surface detail without using more polygons. This subordinate texture is a 3component texture that encodes the normals at each texel. Tangent-spacenormal maps conventions are described in greater detail in section 6.13.5.5,
Model Tangent-space Normal Maps.
Reflection Map: Conventions are described in detail in section 6.13.5.8, Model
Cubic Reflection Maps.
Light Map: This subordinate texture is used to represent the effect of external
light sources onto a model. Light map textures conventions are described ingreater detail in section 6.13.5.4, Model Light Maps.
Gloss Map: A texture that describes whether a surface is matte or gloss;
described in section 6.13.5.9, Model Gloss Maps.
Material Texture: To specify the composite materials at the level of a single
texel; described in section 6.13.5.10, Model Material Textures.

Client-devices are required to use the modeler supplied layer number to determine the order inwhich the subordinate textures are to be rendered. The base layer is always rendered first,
followed by subordinate layer 1, 2, 3, etc. Gaps within the layer sequence are permitted.
Note that layer numbers are not assigned nor reserved to specific subordinate textures.
6.13.1.3 Texture Mapping Conventions
The following table provides the texture mapping for use with each kind of textures.

Copyright © 2018 Open Geospatial Consortium

92

Base
TextureKind Mapping001
Modulate
002
Modulate
004
Modulate
005
Modulate
006
Modulate
007
Modulate
008
Modulate
009
Modulate

Subordinate
TextureKind Mapping
051
Decal
052
N/A
053
Modulate
054
Modulate
055
Modulate
056
Add
057
N/A
058
N/A

6.13.2 Default Gamma Corrections
The default gamma corrections of 3D model texture datasets are defined by the following set ofparameters found in the Defaults.xml metadata file.
• Default_GSModelTexture_Gamma• Default_GSModelInteriorTexture_Gamma• Default_GTModelTexture_Gamma• Default_GTModelInteriorTexture_Gamma• Default_MModelTexture_Gamma
If a parameter is not found in Defaults.xml, or if Defaults.xml is not found in the metadata
directory, assume a default gamma correction of 1.0.
See Annex S Volume 2: OGC CDB Core: Model and Physical Structure Annexesfor thecomplete list of default parameters.
6.13.3 Texture Dimension
It is generally accepted by the modeling community to limit texture dimensions to a power of 2.
The CDB standard goes a step further and enforces this practice.
To preserve the original texture resolution as much as possible, it is suggested to resize thesource texture to the nearest25 power of 2. For instance, if a source texture measures 72 pixels
wide by 13 pixels high, it is recommended to resize it to 64 by 16 pixels.
𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷 = 20 × 22

Where n and m are positive integers (n, m ≥ 1).
6.13.3.1 Texture Mipmap
Requirement 40

Req 40 req/openflight/texture-mipmap

25 Note here that we do not recommend resizing to the next power of 2; instead, resize to the nearest power of 2.

Copyright © 2018 Open Geospatial Consortium93mipmaps associated with a given texture SHALL be present in the texture directory.
Furthermore, the standard requires that mipmaps SHALL be stored in individual files.

𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁𝑁 𝑜𝑜𝑜𝑜 𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀 = max(𝑛𝑛, 𝑚𝑚) + 1

For instance, a texture whose dimension is 23 × 24 has a total of 5 mipmaps.
6.13.3.2 Texture Size
The naming conventions of all model textures are described in Chapter 3 Volume 1: OGC CDB
Core Standard: Model and Physical Data Store Structure. For texture file whose name uses theW field, the value of the field is a power of 2 representing the largest dimension of a (possibly
rectangular) texture.
𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 = 2C

Where W is a non-negative integer (W ≥ 0).

6.13.3.3 Texel Size
For texture file whose name uses the L field, the value of the field is related to the size of thetexels in accordance to Section 3.3.6 Error! Reference source not found. (Volume 1: OGC
CDB Core Standard: Model and Physical Data Store Structure).
6.13.4 Texture Palette
The OpenFlight Texture Palette record stores the names of all textures that are possiblyreferenced by the model; that includes all base and subordinate textures (i.e., all skins and allinterchangeable textures). Each palette entry contains the path and filename of one texture.
Requirement 41
Req 41 req/openflight/texture-palette-path

The path SHALL be relative to the OpenFlight file.

Below are examples of entries in the texture palette.
6.13.4.1 MModel Example
In the case of a moving model, the OpenFlight file resides in the MModelGeometry directory;
for instance, the M1A2 resides in\CDB\MModel\600_MModelGeometry\1_Platform\1_Land\225_United_States\1_Tank\1_1_225_1_1_3_0\

Copyright © 2018 Open Geospatial Consortium

94

Its main texture is called M1A2 and resides in\CDB\MModel\601_MModelTexture\M\1\M1A2\

The corresponding palette entry would be..\..\..\..\..\..\601_MModelTexture\M\1\M1A2\
D601_S005_T001_W11_M1A2.rgb

6.13.4.2 GTModel Example
In the case of a geotypical power pylon model, the OpenFlight file resides in the GTModel
directory\CDB\GTModel\510_GTModelGeometry\A_Culture\T_Comm\040_Power_Pylon\Lxx\

Assuming its texture is called Pylon, it resides in\CDB\GTModel\511_GTModelTexture\P\Y\Pylon\

The corresponding palette entry would be..\..\..\..\..\..\511_GTModelTexture\P\Y\Pylon\
D511_Sxxx_Txxx_Lxx_Pylon.rgb

6.13.4.3 GSModel Example
In the case of a geospecific model, its OpenFlight file resides in the GSModelGeometry
directory. An example is\CDB\Tiles\lat\lon\300_GSModelGeometry\Lxx\Ux\

If the model refers to a geospecific texture, it resides in\CDB\Tiles\lat\lon\301_GSModelTexture\Lxx\Ux\

The corresponding palette entry would be..\..\..\..\301_GSModelTexture\Lxx\Ux\latlon_D301_Sxxx_Txxx_Lxx_Ux_Rx_TNAM.rgb

If the model refers to a geotypical texture, it resides in\CDB\GTModel\511_GTModelTexture\T\N\TNAM

And the corresponding palette entry would be..\..\..\..\..\..\..\GTModel\511_GTModelTexture\T\N\TNAM\
D511_Sxxx_Txxx_Lxx_TNAM.rgb

6.13.4.4 T2DModel Example
In the case of a tiled 2D model, its OpenFlight file resides in the T2DModelGeometry directory.
An example is\CDB\Tiles\lat\lon\310_T2DModelGeometry\Lxx\Ux\

If the model refers to a geospecific texture, it resides in\CDB\Tiles\lat\lon\301_GSModelTexture\Lxx\Ux\

The corresponding palette entry would be

Copyright © 2018 Open Geospatial Consortium95

..\..\..\..\301_GSModelTexture\Lxx\Ux\latlon_D301_Sxxx_Txxx_Lxx_Ux_Rx_TNAM.rgb

If the model refers to a geotypical texture, it resides in\CDB\GTModel\501_GTModelTexture\T\N\TNAM

And the corresponding palette entry would be..\..\..\..\..\..\..\GTModel\501_GTModelTexture\T\N\TNAM\
D511_Sxxx_Txxx_Lxx_TNAM.rgb

6.13.5 Usages
6.13.5.1 Model Shadow Textures
Ideally, Model shadows should be generated at runtime by the client-device from the model’s
actual geometry. However, depending on the technique used by the client device, special
textures called projected shadow maps may be used to cast shadows from Models.
When the projected shadow map technique is used, special object nodes are used to store theshadow polygons.

6.13.5.1.1 Shadow Geometry
Requirement 42
Req 42 req/openflight/texture-shadow-geometry

When geometry exists for the purpose of casting shadows, it SHALL be located under an
object node whose Shadow flag is set.

Copyright © 2018 Open Geospatial Consortium96

Figure 6- 48: Using Shadow Polygons

Several object nodes can be used to store several polygons all textured with projected shadow
maps. It may be desirable to also create separate shadow maps for major articulated parts andlocate these shadow objects just under their corresponding DOF nodes.

6.13.5.1.2 Shadow Maps
Projected shadow maps are created by applying one, two or three orthographic projections on themodel (or optionally on major articulated parts of the model).
Figure 6- 49: Example of a Shadow Map in the XY Plane shows one example of a shadow mapof an aircraft in the XY plane. Similar maps can also be produced for the YZ and ZX planes.

Figure 6- 49: Example of a Shadow Map in the XY Plane

A projected shadow map is a monochrome (single-component) texture without transparency. It
represents the mask to cut out the contour of the model. In theory, a black and white texture
would be enough; however, shades of gray are permitted to represent semi-transparent surfacesthat could be present on the model. In any case, a value of 0 (black) means the model does notblock the passage of lights. The opposite value, 1 (white), indicates the model completely
obstruct the light.
Because the shape of the model may change with damage states, each model state should have its
own set of projected shadow maps. Section 6.9.2.2 describes damage states.
Shadow maps are general base textures. Their Texture Kind is 007 and their Texture Index is asequence number when several shadow maps exist for the same Model.
To illustrate the naming convention, assume the shadow map from

Copyright © 2018 Open Geospatial Consortium97

Figure 6- 49: Example of a Shadow Map in the XY Plane, is called “aircraft”. According to
Section Error! Reference source not found., Error! Reference source not found., and Section
Error! Reference source not found., Error! Reference source not found., the resulting filename would be:
D601_S007_T001_Wnn_aircraft.rgb

The value Wnn represents the texture size, 2nn, and is explained in Section 6.13.3.2, Texture
Size.
Note that if a client-device generates shadows on its own, without the support of pre-computed
projected shadow maps, it can ignore all OpenFlight object nodes whose Shadow flags are set aswell as all textures associated with these nodes.
6.13.5.2 Model Skin Textures
Models skins are base textures that correspond to one or more moving models paint schemes or
one or more time-of-year representations of the cultural feature.
For instance, the same tank can be painted with several different colors to match various areas ofoperation. Below are two examples of the same tank, the M1A2 Abrams, painted for operation
in a desert area (Figure 6- 50: The M1A2 Abrams with Desert Camouflage) or in a forest area (Figure 6- 51: The M1A2 Abrams with a Forest Camouflage).

Copyright © 2018 Open Geospatial Consortium98

Figure 6- 50: The M1A2 Abrams with Desert Camouflage

Figure 6- 51: The M1A2 Abrams with a Forest Camouflage

The two different textures for this tank qualify for use as skins since they have been designed insuch a way that they can be exchanged for one another without affecting their mapping on theaffected polygons.
Requirement 43
Req 43 req/openflight/model-skin-textures

The mapping of textures for a given model or cultural features SHALL be identical since
only the texture is changed, not the UV mapping.

OpenFlight itself does not provide an explicit mechanism to change the base texture assigned to
faces. In fact, OpenFlight supports a single base texture per face record. The other textures thatcan be added to a face are called layers and none of them is a replacement for the base texture.
In order to have several skins for a single model, the CDB standard provides the mechanism
defined in 6.14.5.2, Texture Switch. The enumeration values for each skin can be found in
Annex O, Volume 2: OGC CDB Core: Model and Physical Structure Annexes.
The M1A2 used in the above examples has two skins. Each skin is made of a single texture that
happens to be a mosaic of all the individual textures used by the model. Figure 6-2: M1A2
Desert Skin Mosaic below shows one of the M1A2 skins.

Copyright © 2018 Open Geospatial Consortium99

Figure 6-2: M1A2 Desert Skin Mosaic

The following texture kinds implement the concept of model skins:
Kind 002 – Monthly Representation
Kind 009 – Quarterly Representation
Kind 004 – Uniform Paint Scheme
Kind 005 – Camouflage Paint Scheme
Kind 006 – Airline Paint Scheme
Paint schemes apply to moving models only. Annex O lists available paint schemes (Volume 2:
OGC CDB Core: Model and Physical Structure Annexes).
Time-Of-Year representations are appropriate for cultural features. A good example is the caseof leafy trees. Depending on the hemisphere and the latitude, several textures represent leafy
trees at different stages during the year.
All texture kinds listed above are mutually exclusive; also, all instances of textures of a kind are
mutually exclusive. Since all texture kinds above are base textures, and because only one basetexture can be active at any one time on a face of a model, it follows that only one skin can be
active at a time.

Copyright © 2018 Open Geospatial Consortium100

6.13.5.3 Model Night Maps
Night maps fall under the category of subordinate textures. Night and light maps (see next
section) are both used at night to represent how interior and exterior light sources change theappearance of a Model. It is possible for a Model to have both a night and a light map, or just alight map. However, it is not possible to have a night map alone.
Simulator client-devices invoke a night map when the (simulated) light sources located inside themodel need to change its appearance at night. This is the case when the interior light sources
shine through openings like windows and portholes. To simulate the effect of lights emitted
through these openings, a night map is created; it adds these bright window details normally
missing from the base day texture.
The creation of a night map for models is left to the discretion of the modeler. Creating
additional geometry for the windows and changing the material associated with the polygons toincorporate an emissive component can also produce a lighting effect similar to night maps.
However, this approach requires additional (unnecessary) model geometry that adds additional
computational load in the client-devices. For this reason, the use of night maps is recommended.
Light maps differ from night maps in that they combine the effect of exterior lighting withinterior lights. A light map acts as a (colored) filter to mask portions of the model that are nolonger visible at night when no ambient light exists.
A Model may have a relatively different aspect at night. This difference comes from twochanges in the environment. The ambient illumination provided by sunlight is totally absent atnight; only the moon and man-made light sources affect the appearance of objects. Whenpresent, the moon provides only a modest level of illumination when compared to the sun. In
addition, the model itself might have internal lights turned on that are not modeled in day versionof the texture but that do affect its appearance at night.
To illustrate these differences, imagine a building as seen during the day. No light seems tocome out of its windows because the average daytime sunlight overwhelms any man-madelighting (internal to the building and coming out of the windows). At night, the outside walls of
the building have not changed but light is now emanating from the windows. This is an
important change that requires a modification to the texture used to represent the walls.
Another example of the use of a night map is the case of an aircraft flying at night. During
daytime, the aircraft windows look dark while at night, light comes from the inside and thewindows appear white.
Night maps are used to add details to base textures; details that are not visible during the day andthat become visible at night. Therefore, a night map is not a replacement for the base texture. It
is used in conjunction with the base texture.
The next figures illustrate the purpose of night maps.
Figure 6-3: Base Texture is the base texture used in modeling a commercial aircraft, the Airbus
330, during the day. Notice that portholes are represented by dark rounded rectangles because

Copyright © 2018 Open Geospatial Consortium

101

the lights in the cabin are off. The same is true for the cockpit windows located in the bottom
right of the texture.

Figure 6-3: Base Texture

Figure 6-4: Night Map, is the model’s corresponding night map and shows the same portholes
but this time brighter to reflect the fact that cabin lights are on. This time, notice the appearanceof the cockpit windows as well as the presence of colors in them. Remember that this texture isused to add details that may be missing from the base texture.

Figure 6-4: Night Map

Requirement 44
Req 44 req/openflight/model-night-maps

There are constraints imposed on night maps:
A night map SHALL have the same size as its base texture.
A night map SHALL use the same UV mapping as its base texture.
A night map has a similar format as its base texture (RGB or Intensity)
plus an alpha channel.

Copyright © 2018 Open Geospatial Consortium102

6.13.5.3.1 Night Map Generation
A night map is mapped on top of its base texture using a Decal texture environment. Since anight map is a subordinate texture, it is mapped on polygons using an OpenFlight multitexture
record.
Requirement 45
Req 45 req/openflight/night-map-generation

The Effect field of this multitexture record SHALL contain the value 0 indicating to use
the Texture Environment mapping defined in the Texture Attribute file. The
Environment Type field found in the Texture Attribute file SHALL contain the value 2
indicating a Decal environment mapping.

The night map alpha channel is in fact a mask identifying which portions of the base texture are
replaced by the night map. Accordingly, the alpha channel contains a value of 0 when thecorresponding texel of the base texture is left intact. However, the alpha channel will contain thevalue 1 when the corresponding texel of the base texture is replaced by the equivalent night map
texel. Overall, the Decal environment mapping applies the following transformation to the basetexture.

C = Cb × (1 - An ) + Cn × An

where…

Cb is the color component (or intensity) of the base texture
C n is the color component (or intensity) of the night map
An is the alpha component of the night map
Since the values found in the night map alpha channel are limited to 0 and 1, the resulting color
will either be the one found in the base texture when An is 0 or the one found in the night map
when An is 1.

6.13.5.4 Model Light Maps
Light maps also fall under the category of subordinate textures. Night maps and light maps areboth used at night to represent how interior and exterior light sources change the appearance of a
Model. It is possible for a Model to have both a night map and a light map, or just a light map.
However, it is not possible to have a night map alone.

Copyright © 2018 Open Geospatial Consortium103

Light maps differ from night maps in that they combine the effect of exterior lighting withinterior lights. A light map acts as a (colored) filter to mask portions of the model that are nolonger visible at night when no ambient light exists.
A light map is used when active light sources are located on the outside of the model. This
technique is used to simulate the appearance of a model when lit by local spotlights. For
instance, spotlights may be used to illuminate a building at night. The light map provides theillumination pattern that represents the spotlight illumination on the building. The techniqueprovides a convenient mean to produce interesting and entirely predictable lighting effects
without resorting to computationally intensive local light sources. Their effects are alreadyincorporated into special textures called light maps.
A light map also contains a mask related to the night map when present. Remember that a light
map is a filter (a mask) to retain the detail associated with the base texture and its optional nightmap.
As opposed to a night map, a light map does not have constraints. More specifically:
A light map does not need to be of the same size as its base texture.
A light map has its own UV mapping.
A light map can be an intensity map or an RGB image.
Note that when light sources are modeled with light maps, they only affect the model onto which
they are applied.
The next set of figures illustrates how light maps contribute to the lighting of a model. Note thata light map is not applied directly to the model base texture. The light map is first modified totake into account the ambient lighting, and then the resulting lighting is applied to the model.
Figure 6-5: Light Map, is the light map matching the base texture in Figure 6-3: Base Texture.
Notice that it combines light lobes representing external light spots with the mask associatedwith internal light sources from the night map. This mask is used to key in details that stayvisible at night.

Figure 6-5: Light Map

Figure 6-6: Combined Effect of Base Textures and Light Maps, shows on the actual aircraft theresult of applying the light map from Figure 6-5: Light Map to the base texture from Figure 6-3:

Copyright © 2018 Open Geospatial Consortium104Base Texture. Notice that portholes and cockpit windows are still dark since the base texture has
not been modified by the night map yet.

Figure 6-6: Combined Effect of Base Textures and Light Maps

Figure 6-7: Combined Effect of Night and Light Maps, shows the result of adding the night map
to the base texture and then applying the light map. This time, we can clearly see the lights
coming through portholes and cockpit windows.

Figure 6-7: Combined Effect of Night and Light Maps

6.13.5.4.1 How and When to Use Night Maps and Light Maps
The CDB standard recommends the use of night maps to represent lights that are internal to themodel; this permits the client device to control the appearance of the model with internal lights
on or off. This condition is usually true at night, hence the name of the texture.
Similarly, the CDB standard recommends the use of light maps to represent the effect of lightsthat are external to the model; this permits the client-device to control the appearance of themodel with external spotlights on or off.
Note that night and light maps can be applied to any of the skins since skins are base textures.

6.13.5.4.2 How and When Not to Use Light Maps
A client device may discard light maps if the effect of external lights is internally generated by
its GPU. It can be envisioned that future development of specialized hardware – such asgraphics processor unit – will allow more of the lighting effects to be generated in real-time.
When this time comes, artificial textures generated off-line such as light maps will become
obsolete.

Copyright © 2018 Open Geospatial Consortium105

6.13.5.5 Model Tangent-space Normal Maps
A normal map is an RGB texture (without an alpha channel) where the normal to the surface is
encoded in the Red, Green, and Blue channels. The normal (i, j, k) values are encoded in thefollowing manner into the 8-bit value of each channel:
R [0, 255] = i [-1.0, +1.0]
G [0, 255] = j [-1.0, +1.0]
B [0, 255] = k [-1.0, +1.0]
The mapping is identical on all channels; the range of all possible 8-bit values (0, 255) is mapped
linearly to the range of floating point values -1.0 to +1.0. This mapping provides a resolution of
2/255 or 0.0078.
In addition, the reader should note that the floating-point value 0.0 has no exact integer
equivalent26. Here, the closest value to 0.0 is approximately ±0.0039 and is obtained when thechannel contains 127 or 128.
Besides this particular encoding of the normal into the RGB channels, a normal map has all theother attributes of a standard RGB texture whose format is defined in in the SGI Image File
Format27.
In the industry, there are at least two types of Normal Map: object-space normal map, andtangent-space normal map. Both types have their pros and cons. The CDB standard opts fortangent-space normal map. A sample is shown here.

26 The conventional OpenGL mapping specifies that -1 and 1 can be represented exactly, but 0 can not.
27 ftp://ftp.sgi.com/sgi/graphics/grafica/sgiimage.html

Copyright © 2018 Open Geospatial Consortium106Figure 6-8: Normal Map Sample

Typically, the normal points away from the surface, and not toward the underlying surface. For
this reason, the value of the k-component of the normal is positive, most of the time, resulting ina bluish tint of the map. A negative k-component could indicate the presence of a cliff with an
overhang, for instance.
6.13.5.6 Model Detail Texture Maps
A detail texture map is 1- or 3-component (aka channel) texture where each texel is represented
as an 8-bit unsigned integer. A detail texture exhibits two important properties; it has a neutral
luminance (intensity) and chrominance (color). This is achieved by applying the following
constraints:
The 8-bit unsigned value of each texel is scaled to a floating point value in therange -1.0 to 1.0
The average value of an individual component is always 0.0
The Detail texture is mapped on the underlying surface through a simple addition
operation
The net effect of applying a Detail Texture Map is to highlight (> 0) or darken (< 0) fragment
details on the underlying surface. When using a single component detail texture map, only theintensity of the resulting image is affected; when using a 3-component detail texture map, thecolor is also varied.

Copyright © 2018 Open Geospatial Consortium107

Figure 6-9: Detail Texture Map Sample

Recall that a detail texture map is a mean of adding high-frequency (spatial) details to a rather
low-frequency image.
6.13.5.7 Model Contaminant and Skid Mark Textures
Historically, Image Generators of civil aviation simulators provided the means for flight
instructors to control the appearance of airport runways, taxiways, and roads with various surface
contaminants. To this end, the CDB provides a set of standardized Model Contaminant and Skid
Mark Textures that are commonly used in flight simulators and listed in Annex O, Volume 1.1:
OGC CDB Core: Model and Physical Structure: Informative Annexes. These textures are
typically four-component (R, G, B, alpha) textures that act as an overlay to airport surfaces.
6.13.5.8 Model Cubic Reflection Maps
Reflection mapping (aka environment mapping) is an efficient image-based lighting techniquefor approximating the appearance of a reflective surface by means of a precomputed texture
image. The texture is used to store the image of the distant environment surrounding therendered object.

Copyright © 2018 Open Geospatial Consortium108Figure 6-10: Environment Used to Produce Reflection Map

Figure 6-11: Resulting Reflection Map

Copyright © 2018 Open Geospatial Consortium

109

Figure 6-12: Rendered Reflection Map onto Reflecting Cube

The CDB standard assumes that the surrounding environment is stored using a cubic mapping
approach. In this technique, the environment is projected onto the six faces of a cube and stored
as six square textures or unfolded into six square regions of a single texture. The reflection
mapping approach is more efficient than the classical ray tracing approach of computing theexact reflection by tracing a ray and following its optical path. The reflection color used in theshading computation at a pixel is determined by calculating the reflection vector at the point on
the object and mapping it to the texel in the environment map. This technique often produces
results that are superficially similar to those generated by raytracing, but is less computationallyexpensive since the radiance value of the reflection comes from calculating the angles ofincidence and reflection, followed by a texture lookup, rather than followed by tracing a ray
against the scene geometry and computing the radiance of the ray, simplifying the GPU
workload.
Note however that in most circumstances, a mapped reflection is only an approximation of thereal reflection. Environment mapping relies on four assumptions:•••

All radiance incident upon the statically-positioned object being shaded comes from an
infinite distance. When this is not the case, then a) the reflection of nearby geometry
appears in the wrong place on the reflected object, and b) no parallax is seen in thereflection.
The object being shaded is convex, such that it contains no self-interreflections. When
this is not the case the object does not appear in the reflection; only the environment
does.
The environment map is valid for the location for which it was generated.

Copyright © 2018 Open Geospatial Consortium

110

•

The environment is static.

6.13.5.9 Model Gloss Maps
A gloss map is a texture that describes whether a surface is matte or gloss. The texture is used tomodulate specular highlights in the same way the material shininess does. A gloss map is stored
as an 8-bit single channel texture (a grey-scale image) where texels are mapped to the range 0.0(matte) to 1.0 (glossy). The values in the gloss map play the same role as the single shininessvalue found in the OpenFlight material assigned to a polygon. In this way, the gloss map caneffectively modulate the specularity on a per-pixel basis. Note that if the material applied to thesurface has no specular component, then the gloss map has no effect.
6.13.5.10 Model Material Textures
Material textures fall under the category of subordinate textures. They are mapped to Models thesame way as any other textures. As such, the surfaces these textures are mapped to possess theirown set of UV mapping.
A material texture tells the interested client devices (e.g., FLIR, CGF) what the underlying
surface is made of. For this reason, a material texture is not at all related to a base texture. The
two are completely independent and exist separately. A material texture does not require that abase texture be applied to the model. In fact, it is perfectly possible to create a Model that does
not use texture except for a single material texture describing its various materials.
The <Material> tag presented in section 6.5.3 is a high level mean of providing material
information about the geometry of a model. With the use of a material texture, the modeler can
provide highly detailed material information about the same model.
In short, the <Material> tag supports a polygon-based approach of sensor client devices such as
FLIR, NVG, and RADAR. A Material texture is a texel-based approach supporting animplementation of such client devices with a much higher resolution.
In the case of the Raster Material dataset (dataset code 005) applied onto the terrain, it isconceivable that multiple layers and mixtures of materials are required to represent the richvariety of materials found on the earth surface. However, for Models, a single material layer isprobably adequate for the vast majority of man-made objects.
6.14 Model Descriptor (Metadata) Datasets
Each type of 3D Models has its set of ModelDescriptor datasets; they are:1. GSModelDescriptor
2. GSModelInteriorDescriptor
3. GTModelDescriptor
4. GTModelInteriorDescriptor
5. MModelDescriptor
Each file is needed to summarize and regroup the information concerning one portion of amodel, its shell or its interior. The information are collected and stored in an XML file to help
client devices implement efficient load management mechanism.

Copyright © 2018 Open Geospatial Consortium

111

The format of the model descriptor file is as follows:<Model_Metadata><Name>...</Name><Identification>...</Identification><Mass>...</Mass><Parts>...</Parts><Textures>...</Textures><Configurations>...</Configurations><Composite_Material_Table>...</Composite_Material_Table></Model_Metadata>

6.14.1 Model Name
The <Name> is an arbitrary string from the character set presented in section 2.2. This name isthe human readable version of the model identification code that follows.
6.14.2 Model Identification
Models are either modeled representation of cultural features or moving models. In both cases,
the CDB standard has a unique way to identify them. For moving models, the identification
scheme corresponds to their DIS entity type. For cultural features, their feature code is used.
6.14.2.1 Moving Model Identification
The DIS entity type is a list of up to seven integers and can be specified in two different
manners. All fields have a default value of zero.
First, you can use a list of one to seven integers as illustrated here:<Identification><DIS_Entity_Type><List>...</List></DIS_Entity_Type></Identification>

Or you can use this more verbose syntax to specify the value of individual fields:<Identification><DIS_Entity_Type><Kind>...</Kind><Domain>...</Domain><Country>...</Country><Category>...</Category><Subcategory>...</Subcategory><Specific>...</Specific><Extra>...</Extra></DIS_Entity_Type></Identification>

All fields are limited to the range [0, 255] except the country code that can go up to 65535.
6.14.2.2 Cultural Feature Identification
For cultural features, their feature code is specified in the following manner:

Copyright © 2018 Open Geospatial Consortium112

<Identfication><Feature_Attribute_Catalog_Code><Code>...</Code><Subcode>...</Subcode></Feature_Attribute_Catalog_Code></Identification>

The feature code has a fixed format of two letters followed by three digits; it is the same as thefeature attribute described in section Error! Reference source not found. of the CDB Standard,
Volume 1: OGC CDB Core Standard:Model and Physical Database Structure. The subcode is an
optional integer in the range [0, 999].
6.14.3 Model Mass
The model mass is optional. It makes sense only when the Model represents a moving model.
<Mass><Total>...</Total><Metal>...</Metal></Mass>

The total mass of the model is expressed in kilograms. The portion of the model that is made ofa metallic alloy is expressed as a percentage of the total mass. The value of <Metal> lies in therange [0.0, 1.0].
When the model mass is specified, the total mass is mandatory while the metallic portion is
optional. The total mass must be larger than zero. The metallic portion defaults to zero.
6.14.4 Model Parts
A Model may be separated into several parts. If the complexity of a part justifies it, each partmay be split into multiple files.
The whole section is optional. It is required only if more than one part exists or if a part has
more than one file.
If present, the section is a list of at least one part formatted like this.
<Parts><Part no="no" numFiles="numFiles" name="partName" />...
</Parts>

The part number is mandatory. It starts at 1 and increases by 1 for each subsequent part. The
first part is also referred to as the body of the model.
The number of files is optional and defaults to 1.
The part name28 is optional and is used only to improve the readability of the file.

28 As a guideline, it is suggested to set the part name the same as the global zone name of that part. For instance, if
the part represents an external fuel tank, a good name for both the part and its global zone would be “External FuelTank”.

Copyright © 2018 Open Geospatial Consortium113

6.14.5 Model Textures
This section lists all textures that could be possibly used by the model. In the event the model
does not use texture, the whole section is omitted. The section contains a list of textures andoptional texture switches.
<Textures><Texture .../><Texture .../>...
<Switch .../><Switch .../>...
</Textures>

6.14.5.1 Texture Metadata
For each texture, the section provides the client device with the necessary information to decide
when and which texture mipmap should be loaded.
The section is formatted like this.
<Texture no="number" name="name"><Dataset>...</Dataset><Kind>...</Kind><Index>...</Index><Mipmap>min max</Mipmap><Resolution>...</Resolution><Coverage><U>min max</U><V>min max</V></Coverage></Texture>

The texture number is a strictly positive integer to uniquely identify the texture. The texturename corresponds to the TNAM field in the texture filename as defined in Section Error!
Reference source not found., Error! Reference source not found..
The <Dataset>, <Kind>, and <Index> fields correspond respectively to the dataset number andcomponent selectors 1 and 2; they match the D, S and T fields in the texture filename.
The mipmap field defines the smallest and largest mipmap available for this texture. The valueof this field is used to compose the W field in the texture filename of moving models (seeexamples in section Error! Reference source not found.).
The texture resolution is expressed in texels per meter29. It is the same for both the U and V axes
even though it is recognized that it can differ between the two dimensions. The intent is toprovide an indication of how precise the texture is when mapped to the model geometry. It helps
client device decide which mipmap is more appropriate to use.

29 This unit of measurement (texels per meter) is akin to DPI (dot per inch) used to quantify the resolution of printersand displays.

Copyright © 2018 Open Geospatial Consortium

114

The texture coverage is optional and defines the minimum and maximum values for the U and V
texture coordinates. This information indicates if the texture is repeated along one or both axes.
If the coverage is in the interval [0, 1], the texture is clamped; otherwise, it is repeated.
6.14.5.2 Texture Switch
A Texture Switch is defined when switchable textures appear in the list of textures. Switchable
textures are textures that can be exchanged for one another because they share the same UV
mapping, as explained in section 6.13.5.2, Model Skin Textures.
The section is formatted like this.
<Switch no="number" name="name"><State no="number" name="name" textures="list"/>...
</Switch>

The switch number is a unique positive integer identifying the switch. The switch name is aunique string limited to 32 characters; all switches are uniquely identified by a number and a
name.
A switch has two or more states; each state selecting a list of one or more textures. State
numbers are consecutive and start at 1. The state name is a unique string also limited to 32
characters. The list of textures associated with a state contains the texture numbers of theselected textures. Note that a state (e.g., a skin) may require more than one texture, hence theneed to specify a list of textures associated with a state.

6.14.5.2.1 Example
Assume that the following two textures are stored in the M1A2 texture folder:\CDB\MModel\601_MModelTexture\M\1\M1A2\
D601_S004_T005_Wxx_M1A2.rgb
D601_S005_T001_Wxx_M1A2.rgb

Here is an excerpt of the model metadata presenting the two textures, the switch, and the twocorresponding states.

Copyright © 2018 Open Geospatial Consortium115

<Textures><Texture no="3" name="M1A2"><Dataset>601</Dataset><Kind>4</Kind><Index>5</Index>...
</Texture><Texture no="10" name="M1A2"><Dataset>601</Dataset><Kind>5</Kind><Index>1</Index>...
</Texture>...
<Switch no="1" name="Paint Scheme"><State no="1" name="Uniform Beige Paint" textures="3"/><State no="2" name="Desert Camouflage" textures="10"/></Switch></Textures>

The texture switch is named “Paint Scheme” because it controls the selection of the paint scheme
to apply to the M1A2. The first state selects texture 3 which corresponds to a beige uniform
paint; the second state selects texture 10 corresponding to a desert camouflage.
Note that the texture switch mechanism is not limited to base textures; it can be used to switch
light maps for example.
6.14.6 Model Configurations
Often, a single Model – especially a moving model – comes with a variety of possible equipment
and/or ordnance. This can be as diversified as fuel tanks, missiles, radio emitters, etc. To
configure a model with its ordnance, the CBD Specification defines the concept of model
configuration. A configuration defines the set of equipment and ordnance attached to the various
stations found on the model.
The configuration section is optional. It is a list of one or more configurations defined like this.
<Configurations><Configuration>...</Configuration>...
</Configurations>6.14.6.1 Defining Stations in a Configuration
A configuration is a sequence of one or more stations, each defining one piece of equipment in
one location.
<Configuration name="ConfigName"><Station name="StationName"><Location>...</Location><Equipment>...</Equipment></Station>... other stations as needed</Configuration>

The configuration and station names are both optional and are used for documentation purposes
only.

Copyright © 2018 Open Geospatial Consortium

116

The location of a station is defined by its fully qualified name as specified in section 6.5.5,
Model Zone Naming.
6.14.6.2 Defining Equipment in a Station
The equipment is defined by either its DIS identification or a reference to an external part, and an
optional anchor point.
<Equipment name="EquipmentName"><Identification>...</Identification><External_Part>...</External_Part><Anchor>...</Anchor></Equipment>

The equipment name is optional and is used for documentation purposes only.
The anchor point is specified in the same manner as the location of a station, by providing its
path (on the subordinate model) as specified in section 6.5.5, Model Zone Naming.
6.14.6.3 Defining Equipment Names
Either a DIS emitter name or a DIS entity type identifies the equipment. When the equipment is
an emitter, the syntax is as follows.
<Identification><DIS_Emitter_Name>...</DIS_Emitter_Name></Identification>

Emitter names are defined by the DIS standard. For DIS, refer to Section 8.1.1 of reference [4]for a list of DIS Emitter Names. For the HLA standard, the RPR-FOM lists all emitter names.
To avoid confusion, both DIS and HLA refer to emitter names using numbers. For instance, theNATO emitter AS 15 KENT altimeter is referred to as emitter 8735.
When the equipment is another entity (e.g., a missile), its DIS entity type is supplied in thefollowing manner.
<Identification><DIS_Entity_Type>...</DIS_Entity_Type></Identification>

Recall that the DIS entity type is a list of up to 7 numbers as defined by reference [4]. For
example, the AGM-114K-SAL Hellfire missile would be referred to as:<DIS_Entity_Type><List>2 2 225 1 3 5 1</List></DIS_Entity_Type>or

Copyright © 2018 Open Geospatial Consortium117

<DIS_Entity_Type><Kind>2</Kind><Domain>2</Domain><Country>225</Country><Category>1</Category><Subcategory>3</Subcategory><Specific>5</Specific><Extra>1</Extra></DIS_Entity_Type>

Equipment can also be defined by a reference to an external part if need be. A good example ofsuch equipment is a fuel tank.
<External_Part><Part_Number>...</Part_Number><Configuration>...<Configuration></External_Part>

The external part is identified by its part number as defined previously in the <Parts> section.
The external part may also require it own configuration. Take the example of a Hellfire missile
rack attached to an attack helicopter like the Apache. The rack can hold up to 4 missiles. Eachmissile attaches to one of four separate weapon stations located on the rack. For this more
complex example, assume the rack has only two missiles out of four. This configuration can be
specified with the following piece of XML.
<External_Part><Part_Number>1</Part_Number><Configuration><Station name="Missile 1"><Location>\Missile_Rack\Attach_Point[1]</Location><Equipment><Identification><DIS_Entity_Type><List>2 2 225 3 5 1</List></DIS_Entity_Type></Identification></Equipment></Station><Station name="Missile 2"><Location>\Missile_Rack\Attach_Point[2]</Location><Equipment><Identification><DIS_Entity_Type><List>2 2 225 3 5 1</List></DIS_Entity_Type></Identification></Equipment></Station><Configuration></External_Part>

With the help of model configurations, it is possible to create several variants of a single Model,
each variant defined by its own configuration.
This way, one Apache can have two configurations, one when equipped with Hellfire missiles
and one when equipped with rocket launchers.

Copyright © 2018 Open Geospatial Consortium118

6.14.7 Model Composite Materials
The composite material table is the last component of the Model Metadata and is defined in
section Error! Reference source not found., Error! Reference source not found. in the CDB
Standard, Volume 1: OGC CDB Core Standard: Model and Physical Database Structure.

Copyright © 2018 Open Geospatial Consortium

119Annex A: Conformance Class Abstract Test Suite (Normative)
A.1 Conformance class: CRS

This test is to validate that the Coordinate Reference System (CRS) header content is properly
structured in the Openflight header record.
Conformance Class/conf/openflight/header-crs

Requirements Class/req/openflight/ crs

Dependency

Openflight Specification

Test 1/conf/header-crs/crs
Requirement/req/openflight/model-global-zone

Test purpose

Verify that the CRS codes are properly set

Test method

Pass if the values are set to the default of “0”Test type

Conformance

A.2 Conformance Class: Tree Structure
Conformance Class/conf/openflight/tree-structure

Requirements Class/req/openflight/tree-structure

Dependency

Openflight Specification

Test 2/conf/tree-structure/model-global-zone

Test 3Requirement/req/core/openflight/model-global-zone

Test purpose

Verify that a CDB OpenFlight Model has a global zone as its root
node. This node identifies the model.

Test method

Visual. Pass if the model has a global zone as its root node. Checkfile system structure.

Test type

Conformance/conf/tree-structure/2dmodel
Requirement/req/openflight/2dmodel

Test purpose

Verify that each 2DModel is implemented as a Model Zone with its
own subgraph.

Copyright © 2018 Open Geospatial Consortium

120

Test 4

Test 5

Test 6

Test method

Visual. Pass if the a model zone has its own sub-graph

Test type

Conformance/conf/tree-structure/2dmodel-rules
Requirement/req/openflight/2dmodel-rules

Test purpose

Verify the A 2DModel has at least two layers: layer 0 and layer 1.
Verify that Layer 0 is empty because it represents the terrain on
top of which subsequent layers are applied. Verify that each layer
is composed of exactly one OpenFlight Object node.

Test method

Pass if there are at least two layers. Visual inspection

Test type

Conformance/conf/tree-structure/2dmodels
Requirement

req/openflight/2dmodels

Test purpose

Verify that for T2DModels, node attributes are defined only at thezone level; that is, at the global zone or at the individual 2DModelzones. Node attributes are not permitted at the Group, LOD,
Object, Face, and Mesh node levels.

Test method

Visual, Pass if node attributes are defined only at the zone level

Test type

Conformance/conf/tree-structure/xref
Requirement

req/openflight/xref

Test purpose

Verify that all external OpenFlight references are made using a
relative path.

Test method

Visual. Pass if external references use relative paths.

Test type

Conformance

A.3 Conformance Class: Modeling Conventions

The following are the conformance tests for the OpenFlight modelling conventions.
Conformance Class/conf/openflight/model-conventions

Requirements Class/req/openflight/model-conventions

Copyright © 2018 Open Geospatial Consortium121

Dependency

Openflight Specification

Test 7/conf/model-conventions/crs-models

Test 8

Test 9Test 10

Test 11Requirement/req/openflight/crs-models

Test purpose

Verifythat CDB Models use the same coordinate system
convention as OpenFlight

Test method

Visual. Pass if the CRS definitions are the same.

Test type

Conformance/conf/model-conventions/model-origin
Requirement/req/openflight/model-origin

Test purpose

Verify that the model origin is located at the center of the bounding
rectangle and that along the Z axis, the origin as selected allows
the model to be correctly positioned on the ground for groundrelated models on or a water plane for surface and subsurface
platforms.

Test method

Visual. Pass if the model is correctly positioned in the display.

Test type

Conformance/conf/model-conventions/t2-model-coordinates
Requirement/req/openflight/ t2-model-coordinates

Test purpose

Verify that the latitude (y) and longitude (x) coordinates are
expressed in decimal degrees and that the values are relative tothe file’s (implicit) origin which is the south-west corner of the tile.

Test method

Visual. Pass if coordinates are expressed in decimal degrees..

Test type

Conformance/conf/model-conventions/roll-pitch-yaw
Requirement

req/openflight/roll-pitch-yaw

Test purpose

Verify that the Pitch, Roll and Yaw angles refer to rotations aroundthe X, Y, and Z axes and Angles are measured in degrees. The
Roll and Yaw angles vary from ±180 degrees while the Pitch angle
is limited to the range ±90 degrees.

Test method

Visual. Pass if all angles are degrees

Test type

Conformance/conf/model-conventions/geometry

Copyright © 2018 Open Geospatial Consortium

122

Test 12Requirement

req/openflight/geometry

Test purpose

Verify the implementers of the CDB OpenFlight standard adhere to
set of constraints, rules and guidelines as defined in OpenFlight
Requirement 11 when creating the geometry of Models.

Test method

Visual. Pass if all polygons are convex, all vertices of a polygon
are in the same place, and that all polygon vertices (coordinates)
have a counter-clockwise ordering.

Test type

Conformance/conf/model-conventions/ geometry-layer-constraint
Requirement

req/openflight/ geometry-layer-constraint

Test purpose

Verify that Layer 0, the base layer, contains geometry thatcompletely encompasses the geometry of subsequent layers.
Other layers areprocessed in order, one after the other. A layer ismade of one or more nodes; all nodes of a given layer have thesame relative priority.

Test method

Visual and software. Software can check processing order. Pass if
the base layer contains a geometry that encompasses thegeometry of sub-layers.

Test type

Conformance

A.4 Conformance Class: Model Zones

This conformance class tests requirements related to OpenFlight model zones.
A model zone represents a component of interest on the Model. A model zone (as well as thecomponent it represents) occupies a certain volume and is delimited by a bounding box. At least
one simulator subsystem must be interested in a specific component to justify the creation of acorresponding zone. Examples of zones are a turret on a tank, or an engine on a platform, or an
entrance door on a building, etc
Conformance Class/conf/openflight/model-zones

Requirements Class/req/openflight/model-zones

Dependency

Openflight Specification

Test 13/conf/model-zones/model-zone-bounding-box
Requirement/req/openflight/model-zone-bounding-box

Test purpose

Verify that a model zone has a Bounding Box.

Copyright © 2018 Open Geospatial Consortium

123

Test 14

Test 15

Test 16

Test 17

Test 18

Test method

Visual. Pass if there is a bounding box.

Test type

Conformance/conf/model-zones/zone-name
Requirement/req/openflight/zone-name

Test purpose

Verify that there is a zone name.

Test method

Visual. Pass if there is a zone name.

Test type

Conformance/conf/model-zone/global-zone
Requirement/req/openflight/ global-zone

Test purpose

Verify that the model has at least one zone that encompasses thewhole model and that is called the model global zone.

Test method

Visual. Pass if of there is one zone encompassing the wholemodel.

Test type

Conformance/conf/ model-zone /hot-spot-temperature
Requirement

req/openflight/hot-spot-temperature

Test purpose

Verify that temperatures are expressed as integer Celsius.

Test method

Visual. Pass if temperatures are integer Censius

Test type

Conformance/conf/ model-zone /model-footprint-zones
Requirement

req/openflight/ model-footprint-zones

Test purpose

Verify that Client-devices assume that the geometry that is
associated with a Model Footprint Zone is hidden.

Test method

Visual. Check Client code.

Test type

Conformance/conf/ model-zone /model-footprint-hierarchy

Copyright © 2018 Open Geospatial Consortium

124

Test 19

Test 20

Test 21Requirement

req/openflight/model-footprint-hierarchy

Test purpose

Verify that the Model Footprint is placed under a CDB Footprint
Zone node.

Test method

Visual. Pass if model footprint is correctly placed in hierarchy.

Test type

Conformance/conf/ model-zone /model-cutout-zones
Requirement

req/openflight/model-cutout-zones

Test purpose

Verify that the Model Cutout is modeled as a set of OpenFlight
Face or Mesh records. Verify that client-devices assume that thegeometry that is associated with a Model Cut-Out Zone is hidden
and cut-out...

Test method

Visual.

Test type

Conformance/conf/ model-zone /model-cutout-geometry
Requirement

req/openflight/model-cutout-geometry

Test purpose

Verify that the Cutout geometry is placed under a CDB Model
Cutout Zone node.

Test method

Visual.

Test type

Conformance/conf/ model-zone /model-pseudo-interior-zone
Requirement

req/openflight/model-pseudo-interior-zone

Test purpose

Verify that since the pseudo-interior is a placeholder for the realinterior that it is placed under its own subgraph and identified by a
CDB zone whose name is “Interior”.

Test method

Visual.

Test type

Conformance

Copyright © 2018 Open Geospatial Consortium

125

Test 22

/conf/ model-zone /model- interior-zone
Requirement

req/openflight/model- interior-zone

Test purpose

Verify that The Model interior itself has a global zone whose nameis “Interior”.

Test method

Visual.

Test type

Conformance

A.5 Conformance Class: Model Points

A model point is similar to a model zone; it identifies a location on the model that is of interest to
at least one simulation client device. A point defines a local coordinate system on the model.
Hence, a point has a position and an orientation. The following tests ensure that model points arecorrectly modeled and comply with the model points requirements class.
Conformance Class/conf/openflight/model-points

Requirements Class/req/openflight/model-points

Dependency

Openflight Specification

Test 23/conf/model-points/model-point-damage-states

Test 24

Requirement/req/core/openflight/model-point-damage-states

Test purpose

Verify that there is a single definition of this point for all damage
states and all levels of details for a given model.

Test method

Visual. Pass if there is a single definition.

Test type

Conformance/conf/ model-points/model-dis-origin
Requirement/req/openflight/model-dis-origin

Test purpose

Verify that the CDB Point representing the DIS Origin is positioned
and oriented according the definition provided by the DIS
Standard. This definition says that the DIS Origin is at the centerof the bounding box of the entity, without articulated and attachedparts. The standard also says what the orientation SHALL be.
The X-axis points forward, the Y-axis points to the right, and the Zaxis points down. All axes are aligned with the bounding box
defined above.

Test method

Visual. Pass if the dis origin is correctly encoded.

Copyright © 2018 Open Geospatial Consortium

126

Test type
Test 25

Conformance/conf/ model-points /model-viewpoint
Requirement/req/openflight/model-viewpoint

Test purpose

Verify the viewpoint’s local coordinate system is oriented such that
the Y-axis indicates the viewing direction and the Z-axis points up.

Test method

Visual inspection. Pass if orientation is correct.

Test type

Conformance

A.6 Conformance Class: Model Points

A levels-of-detail model structure is essential when the intent is to use a model in a real-time
application such as flight simulation. The level-of-detail mechanism provides client-devices
with the essential structure for deterministic operation. The following test determines whether
the OpenFlight model and CDB data store use the proper method to determine if a level of detailis still active.
Conformance Class/conf/openflight/model-level-of-detail

Requirements Class/req/openflight/significant-sizes

Dependency

Openflight Specification

Test 26/conf/model-level-of-detail/significant-sizes
Requirement/req/openflight/significant-sizes

Test purpose

Verify that the implementation method uses the Significant Size
associated with the LOD node to determine when to activate thenode

Test method

Visual.

Test type

Conformance

A.7 Conformance Class: Model Switch Nodes
Conformance Class/conf/openflight/model-switch-nodes

Requirements Class/req/openflight/switch-mask

Dependency

Openflight Specification

Test 27/conf/model-switch-nodes/switch-mask
Requirement/req/core/openflight/switch-mask

Copyright © 2018 Open Geospatial Consortium

127

Test 28

Test purpose

Verify that the switch contains one mask per state. Note that thefirst mask, mask index 0, is the default mask. This means that thevalue of the Current Mask field in the Switch record is 0.

Test method

Visual. Pass if values are correct.

Test type

Conformance/conf/ model-switch-nodes/switch-mask-name
Requirement/req/openflight/ switch-mask-name

Test purpose

Verify that each mask has a name. The name of the mask SHALL
be representative of the state selected by that mask.

Test method

Visual. Pass if each mask has a name

Test type

Conformance

A.8 Conformance Class: Damage Status
Conformance Class/conf/openflight/model-switch-nodes

Requirements Class/req/openflight/damage-status

Dependency

Openflight Specification

Test 29/conf/ damage-status /switch-mask

Test 30

Requirement/req/core/openflight/damage-transition

Test purpose

Verify that the percentages representing the transitions are limited
to the range [0, 99]. The value 100 is not allowed because thelevel of damage cannot exceed the transition value in order toselect the correct state.

Test method

Visual. Pass if values are in valid range.

Test type

Conformance/conf/ damage-status /switch-mask-name
Requirement/req/openflight/ damage-order

Test purpose

Verify that the ordering of damage states is from left (normal state)
to right (destroyed state). All intermediate states must represent
increasingly damaged states from a slightly damaged state to analmost destroyed state.

Test method

Visual. Pass if ordering is correct.

Test type

Conformance

Copyright © 2018 Open Geospatial Consortium

128A.9 Conformance Class: Model Articulations

Conformance Class/conf/openflight/model-points

Requirements Class/req/openflight/model-articulations

Dependency

Openflight Specification

Test 32/conf/model-articulations/articulation-node-rotation

Test 33

Test 34

Requirement/req/core/openflight/model-point-damage-states

Test purpose

Verify that the translation rate is expressed in meters per second.
Verify that the rotation rate is expressed in degrees per second.
Finally, verify that the scaling rate is expressesd in units per
second. When not specified, verify that a default rate of zero isused.

Test method

Visual. Pass if units of measure are correct.

Test type

Conformance/conf/model-articulations /gimbal-limits
Requirement/req/openflight/global-limits

Test purpose

Verify that the appropriate flags are set to specify which degrees of
freedom are controlled by a particular articulation.

Test method

Visual. Pass if flags are correctly set.

Test type

Conformance/conf/ model-articulations /articulation-flags
Requirement/req/openflight/articulation-flags

Test purpose

Verify the Flags field, located at offset 376 in the OpenFlight DOF
record, has a non-zero value because the articulation control has
at least one degree of freedom.

Test method

Visual inspection. Pass if orientation is correct.

Test type

Conformance

Copyright © 2018 Open Geospatial Consortium

129A.10 Conformance Class: Model Textures

Conformance Class/conf/openflight/model-textures

Requirements Class/req/openflight/model-textures

Dependency

Openflight Specification

Test 37/conf/model-textures/texture-file-loading

Test 38

Test 39

Test 40

Requirement/req/core/openflight/ texture-file-loading

Test purpose

Verify thatforn the case of GTModels and MModels, textures are
separate files that are loaded after the model geometry files areread and loaded by client devices; in the case of GSModels andT2DModels, the textures can be loaded concurrently with themodel geometry files.

Test method

Visual. Pass if units of measure are correct.

Test type

Conformance/conf/model- textures/qualterly-textures
Requirement/req/openflight/quarterly-textures

Test purpose

Verify that the quarterly textures are provided as a complete set,i.e., it is assumed that all 4 textures of the same kind (i.e., all four
textures have their component selector 1 set to 003) and are allpresent in the model’s texture directory

Test method

Visual. Pass if flags are correctly set.

Test type

Conformance/conf/ model- textures/monthly-textures
Requirement/req/openflight/monthly-textures

Test purpose

Verify the monthly textures are provided as a complete set, i.e., it
is assumed that all the 12 textures are of the same kind (i.e., alltwelve textures have their component selector CS1 = 002) and are
all present in the model’s texture directory.

Test method

Visual inspection. Pass if orientation is correct.

Test type

Conformance/conf/ model- textures/texture-mipmap
Requirement/req/openflight/texture-mipmap

Test purpose

Verify that the mipmaps associated with a given texture arepresent in the texture directory. Furthermore, verify that themipmaps are stored in individual files..

Copyright © 2018 Open Geospatial Consortium

130

Test 41

Test 42

Test 43

Test 44

Test 45

Test method

Visual inspection. Pass if orientation is correct.

Test type

Conformance/conf/ model- textures/texture-palette-path
Requirement/req/openflight/texture-palette-path

Test purpose

Verify that the palette path is relative to the OpenFlight file

Test method

Visual inspection. Pass if orientation is correct.

Test type

Conformance/conf/ model- textures/texture-shadow-geometry
Requirement/req/openflight/texture-shadow-geometry

Test purpose

Verify that when a geometry exists for the purpose of casting
shadows that the geometry is located under an OpenFlight object
node whose Shadow flag is set

Test method

Visual inspection. Pass if orientation is correct.

Test type

Conformance/conf/ model- textures/model-skin-textures
Requirement/req/openflight/model-skin-textures

Test purpose

Verify that the mapping of textures for a given model or culturalfeatures is identical since only the texture is changed, not the UV
mapping

Test method

Visual inspection. Pass if orientation is correct.

Test type

Conformance/conf/ model- textures/model-night-maps
Requirement/req/openflight/model-night-maps

Test purpose

Verify that a night map has the same size as its base texture, thata night map uses the same UV mapping as its base texture andthat a night map has a similar format as its base texture (RGB or
Intensity) plus an alpha channel

Test method

Visual inspection. Pass if orientation is correct.

Test type

Conformance/conf/ model- textures/model-night-generation
Requirement/req/openflight/model-night-generation

Test purpose

Verify that the Effect field of the multitexture record contains thevalue 0 indicating using the Texture Environment mapping definedin the Texture Attribute file. Verify that the Environment Type fieldfound in the Texture Attribute file contains the value 2 indicating a
Decal environment mapping

Copyright © 2018 Open Geospatial Consortium131

Test method

Visual inspection. Pass if orientation is correct.

Test type

Conformance

Copyright © 2018 Open Geospatial Consortium132

Annex B: Revision history

Date

ReleaseAuthorParagraph modified Description

2/12/2016

1.0

C. ReedMany

Many edits, added requirements,
requirements classes, and Annex A

2/26/201612/28/17

1.0
1.1

C. Reed
C. ReedAnnex A
VariousFinish ATS
Minor edits. Change URI to be 1.1
consistent.

Copyright © 2018 Open Geospatial Consortium

133Annex C: OpenFlight v16.0 Technical Description – AnnotatedThis document has been annotated to reflect the conventions established by the CDB standard.
Collectively, these conventions are referred to as OpenFlight/CDB. The conventions define how
OpenFlight files are interpreted by a CDB-compliant OpenFlight reader; the stated conventions
supersede or replace related aspects of this annotated specification. Unless stated otherwise,
CDB-compliant OpenFlight readers will ignore any data that fails to conform to the statedconventions.

OpenFlight®
Scene Description
Database Specification

Annotated with CDB conventions
Version 16.0
Document Revision A

Copyright © 2018 Open Geospatial Consortium134

November 2004

Copyright © 2018 Open Geospatial Consortium

135

OpenFlight Scene Description Database Specification, version 16.0. November, 2004

Contents
OpenFlight Concepts ...................................................................................................................9
Database Hierarchy ......................................................................................................................9
Node Attributes ..........................................................................................................................12
Palettes .......................................................................................................................................12
Instancing ...................................................................................................................................13
Replication. ................................................................................................................................14
Bounding Volumes ....................................................................................................................14
Multitexture................................................................................................................................14
OpenFlight Record Types ..........................................................................................................15
Control Records .........................................................................................................................16
Hierarchy Level Change Records ..............................................................................................16
Push Level Record .............................................................................................................17
Pop Level Record...............................................................................................................17
Push Subface Record .........................................................................................................17
Pop Subface Record ...........................................................................................................17
Push Extension Record ..................................................................................................... 17
Pop Extension Record. .......................................................................................................17
Push Attribute Record. ...................................................................................................... 18
Pop Attribute Record. ........................................................................................................18
Hierarchy Instancing Records. ...........................................................................................18
Instance Definition Record ................................................................................................18
Instance Reference Record. ...............................................................................................19
Node Primary Records ...............................................................................................................19
Header Record ...................................................................................................................19Group Record.. ...................................................................................................................22
Object Record. ...................................................................................................................25
Face Record. ......................................................................................................................26
Mesh Nodes .......................................................................................................................28
Mesh Record. ............................................................................................................ 29
Local Vertex Pool Record..........................................................................................30
Mesh Primitive Record. .............................................................................................32
Light Point Nodes ..............................................................................................................34
Indexed Light Point Record. ..................................................................................... 34
Light Point Record. ................................................................................................... 34
Light Point System Record. ...............................................................................................37
Degree of Freedom Record ................................................................................................37
Vertex List Record .............................................................................................................39
Morph Vertex List Record. ................................................................................................39
Binary Separating Plane Record ........................................................................................40
External Reference Record. ...............................................................................................41
Level of Detail Record .......................................................................................................41
Sound Record .....................................................................................................................43
Light Source Record ..........................................................................................................44
Road Segment Record........................................................................................................44
Road Construction Record. ................................................................................................45
Clip Region Record............................................................................................................47
Text Record........................................................................................................................47
Switch Record. ...................................................................................................................49
CAT Record .......................................................................................................................50
Extension Record. ..............................................................................................................51
Curve Record .....................................................................................................................51
Ancillary Records ......................................................................................................................52
Comment Record ...............................................................................................................53
Lond ID Record .................................................................................................................53
Indexed String Record .......................................................................................................53
Multitexture........................................................................................................................54
Multitexture Record .................................................................................................. 54
UV List Record ......................................................................................................... 55

Copyright © 2018 Open Geospatial Consortium136

Replicate Record ................................................................................................................57
Road Zone Record .............................................................................................................58
Transformation Records.....................................................................................................58
Matrix Record ........................................................................................................... 59
Rotate About Edge Record ....................................................................................... 59
Translate Record ....................................................................................................... 59
Scale Record ............................................................................................................. 59
Rotate and/or Scale to Point Record ..........................................................................60
Put Record................................................................................................................. 60
General Matrix Record ............................................................................................. 60
Rotate About Point Record ....................................................................................... 60
Vector Record ....................................................................................................................61
Bounding Volume Records ................................................................................................61
Bounding Box Record................................................................................................62
Bounding Sphere Record ...........................................................................................62
Bounding Cylinder Record ........................................................................................62
Bounding Convex Hull Record................................................................................. 62
Bounding Histogram Record .................................................................................... 62
Bounding Volume Center Record............................................................................. 63
Bounding Volume Orientation Record ..................................................................... 63
CAT Data Record ..............................................................................................................63
Extension Attribute Record................................................................................................64
Continuation Record ..........................................................................................................65
Palette Records...........................................................................................................................66
Vertex Palette Records.......................................................................................................66
Vertex Palette Record ............................................................................................... 67
Vertex with Color Record ..........................................................................................68
Vertex with Color and Normal Record ..................................................................... 68
Vertex with Color and UV Record ........................................................................... 69
Vertex with Color, Normal and UV Record ............................................................. 69
Color Palette Record ..........................................................................................................70
Name Table Record ...........................................................................................................71
Material Palette Record......................................................................................................71
Texture Palette Record.......................................................................................................73
Eyepoint and Trackplane Palette Record ...........................................................................73
Key Table Records.............................................................................................................76
Linkage Palette Record ......................................................................................................77
Sound Palette Record .........................................................................................................80
Light Source Palette Record ..............................................................................................81
Light Point Appearance Palette Record .............................................................................82
Light Point Animation Palette Record ...............................................................................85
Line Style Palette Record...................................................................................................85
Texture Mapping Palette Record .......................................................................................86
Texture Pattern Files ..................................................................................................................93
Texture Attribute Files ...............................................................................................................93
Vertex Node Parameters ..........................................................................................................103
Face Node Parameters..............................................................................................................103
Object Node Parameters ..........................................................................................................104
LOD Node Parameters .............................................................................................................104
Group Node Parameters ...........................................................................................................104
DOF Node Parameters .............................................................................................................105
Sound Node Parameters ...........................................................................................................106
Switch Node Parameters ..........................................................................................................106
Text Node Parameters ..............................................................................................................107
Light Source Node Parameters ................................................................................................107
Clip Node Parameters ..............................................................................................................107
Valid Opcodes..........................................................................................................................109
Obsolete Opcodes................................... .................................................................................111
Overview .........................................................................................................................113
Format Changes .......................................................................................................................113
Continuation Record ................................................................................................................113
Header Record .........................................................................................................................114
Mesh Nodes .............................................................................................................................114

Copyright © 2018 Open Geospatial Consortium

137

Mesh Record ........................................................................................................................... 115
Local Vertex Pool Record....................................................................................................... 116
Mesh Primitive Record ........................................................................................................... 118
Multitexture..............................................................................................................................120
Multitexture Record ................................................................................................................ 120
UV List Record ....................................................................................................................... 122
Texture Attribute File ..............................................................................................................123
Subtexture ............................................................................................................................... 123
Overview .........................................................................................................................125
Document Corrections .............................................................................................................125
Text Record..............................................................................................................................126
CAT Record .............................................................................................................................126
Header Record .........................................................................................................................127
Group Record ...........................................................................................................................128
Level of Detail Record .............................................................................................................129
External Reference Record ......................................................................................................130
Indexed String Record .............................................................................................................130
Face Record .............................................................................................................................131
Mesh Record ............................................................................................................................131
Local Vertex Pool Record........................................................................................................132
Vertex Palette Records.............................................................................................................133
Light Points ..............................................................................................................................136
Light Point Appearance Palette Record .................................................................................. 136
Light Point Animation Record ................................................................................................ 139
Indexed Light Point Record .................................................................................................... 140
Light Point System Record ..................................................................................................... 140
Texture Mapping Palette Record .............................................................................................141
Parameters for 3 Point Put Texture Mapping (Type 1 ............................................................ 141
Parameters for 4 Point Put Texture Mapping (Type 2 ............................................................ 141
Overview.........................................................................................................................143
Document Corrections .............................................................................................................143
Header Record .........................................................................................................................143
Face Record .............................................................................................................................144
Mesh Record ............................................................................................................................144
Switch Record ..........................................................................................................................145
Texture Mapping Palette Record .............................................................................................145
Indexed String Record .............................................................................................................147
Bounding Convex Hull Record................................................................................................147
Bounding Histogram Record ...................................................................................................147
Format Changes .......................................................................................................................147
External Reference Record ......................................................................................................147
Face Record .............................................................................................................................148
Mesh Record ............................................................................................................................148
Light Point Appearance Palette Record ...................................................................................148
Shader Palette Record ..............................................................................................................149
Texture Attribute File ..............................................................................................................149
Texture Mapping Palette Record .............................................................................................150
Parameters for 3 Point Put Texture Mapping (Type 1 ............................................................ 150

Copyright © 2018 Open Geospatial Consortium

138

OpenFlight® Scene Description
The following symbols have been used throughout the document to specify theconventions established by OpenFlight/CDB.
ü=

The record, field or value is supported by OpenFlight/CDB readers and follows
the same conventions and usage as the OpenFlight Standard

 = The record, field is not considered by OpenFlight/CDB readers (e.g. ignored) = The record, field or value is specific to MultiGen-Paradigm and therefore is notconsidered by OpenFlight/CDB readers (e.g. ignored) = The value for the specified field is not supported by OpenFlight/CDB readers.
OpenFlight/CDB readers ignore any fields with values that are not supported.

 = The record, field or value is specific to MultiGen’s Creator tool and therefore isnot considered by OpenFlight/CDB readers (e.g. ignored)

This document describes the OpenFlight Scene Description Database Specification, commonlyreferred to as simply “OpenFlight”. OpenFlight is a 3D scene description file format that was
created and is maintained by MultiGen-Paradigm, Inc. While OpenFlight databases are typicallycreated and edited using MultiGen-Paradigm software tools, the format is widely adopted and as
a result, many tools exist to read and write OpenFlight database files.
The primary audience for this document includes software developers whose applications areintended to read and/or write OpenFlight database files. To this end, this document discusses
concepts incorporated in OpenFlight and contains a detailed description of the physical layout of
OpenFlight files as represented on disk.

Copyright © 2018 Open Geospatial Consortium

139

OpenFlight Concepts
The OpenFlight database format supports both simple and relatively sophisticated real-time
software applications. The full implementation of OpenFlight supports variable levels of detail,degrees of freedom, sound, instancing (both within a file and to external files), replication, animation sequences, bounding volumes for real-time culling, scene lighting features, light points
and light point strings, transparency, texture mapping, material properties, and many other features.
A simple application that interprets an OpenFlight database can implement a subset of thedatabase specification and use databases that contain that subset. Such an application could simply scan for the color palette, faces, and vertices, and ignores groups, objects, and other moresophisticated features.

Database Hierarchy
The OpenFlight database hierarchy organizes the visual database into logical groupings andfacilitates real-time functions such as field-of-view culling, level-of-detail switching, and instancing. Each OpenFlight database is organized in a tree structure.
The database tree structure consists of nodes (historically called beads). Most nodes can havechild nodes as well as sibling nodes. In general, nodes can be thought of in three hierarchicalclasses. Starting from the top of the hierarchy, these three node classes include container nodes,
geometry nodes and vertex nodes.
Container nodes are nodes that impose some logical grouping or behavior on the set of nodes it
contains. The group node, for example allows you to “collect” similar nodes under one common
parent for whatever reason your application needs. You might choose to group your nodes spatially or by some other criteria important to your application. Another common container node,
the level of detail node, imposes a particular visual behavior on the nodes it contains. It defines arange of distances inside which the nodes it contains are visible.
Geometry nodes are nodes that actually represent some physical (renderable) geometry. The attributes of geometry nodes typically include visual attributes such as color, material, texture, etc.
The two main geometry nodes in OpenFlight are the face and mesh nodes. Other geometry nodes
include the light point and text node. Though OpenFlight allows it, there are very few cases inwhich at least one geometry node is not contained somewhere below a container node.
Vertex nodes are the building blocks of geometry nodes. Individually, a vertex node represents a
discrete point in space. Collected together under a geometry node such as a face node, a set ofvertex nodes define a closed (or unclosed) loop. A closed loop of vertex nodes defines a face (orpolygon). The “front” side of the face is determined by the ordering in which the vertex nodes
appear under the face node. An unclosed loop of vertex nodes defines a set of line segments,
again oriented according to the order in which the vertex nodes appear.
Each node type has data attributes specific to its function in the database. The principal nodetypes in OpenFlight are described here:
Header: There is one header node per database file. It is always the first node in the file andrepresents the top of the database hierarchy and tree structure. For more information, see “Header
Record” on page 19.
Group: A group node distinguishes a logical subset of the database. Group nodes can be trans-

Copyright © 2018 Open Geospatial Consortium140

formed (translated, rotated, scaled, etc.). The transformation applies to itself and to all its children. Groups can have child nodes and sibling nodes of any type, except a header node. For more
information, see “Group Record” on page 22.
Object: An object node contains a logical collection of geometry. It is effectively a low-levelgroup node that offers some attributes distinct from the group node. For more information, see“Object Record” on page 25.
Face: A face node represents geometry. Its children are limited to a set of vertices that describe apolygon, line, or point. For a polygon, the front side of the face is viewed from an in-order
traversal of the vertices. Face attributes include color, texture, material, and transparency. For
more information, see “Face Record” on page 26.
Mesh: A mesh node defines geometric primitives that share attributes and vertices. See For more
information, see “Mesh Nodes” on page 28.
Light point: A light point node represents a collection of light point vertices or a replicated stringof a single light point vertex. A light point is visible as one or more self-illuminated small points
that do not illuminate surrounding objects. For more information, see “Light Point Nodes” onpage 34.
Light point system: A light point system enables you to collect a set of light points andenable/disable or brighten/dim them as a group. For more information, see “Light Point System
Record” on page 37.
Subface: A subface node is a face node that is assumed to be coplanar to, and drawn on top of, its
superface. Subfaces can themselves be superfaces to allow multiple levels of “nesting”. This
construct resolves the display of coplanar faces. A subface is introduced, after a face node, by apush subface control record and concluded by a pop subface control record. Note that the
OpenFlight format does not enforce a subface to be coplanar with its superface but this is recommended.
Light source: A light source node serves as the location and orientation of a light source. The
light source position and direction are transformed by the transformations above it in the tree (ifany). For more information, see “Light Source Record” on page 44.
Sound: A sound node serves as the location for a sound emitter. The emitter position is the soundoffset transformed by the transformations above it in the tree (if any). For more information, see“Sound Record” on page 43.
Text: A text node draws text in a string with a specified font, without injecting the actual geometry into the database as face nodes. This is a leaf node and therefore cannot have any children.
For more information, see “Text Record” on page 47.
Vertex: A vertex node represents a point in space, expressed as a double precision 3D coordinates. Each vertex is stored in the vertex palette record. Vertex attributes include x, y, z andoptionally include color, normal and texture mapping information. Vertex nodes are the childrenof face nodes and light point nodes. For more information, see “Vertex List Record” on page 39,“Morph Vertex List Record” on page 39 and “Vertex Palette Records” on page 66.
Morph vertex: A morph vertex node is a second vertex node. The vertex and morph vertex represent the two endpoints of a path between which the actual vertex may be interpolated. One
endpoint represents the minimum (non morphed) weighting and the other represents the maximum (fully morphed) weighting. Each endpoint (or weight) is a reference into the vertex paletterecord. All vertex attributes may be morphed. Morph vertex nodes are the children of face nodes.
For more information, see For more information, see “Morph Vertex List Record” on page 39.
Clip region: A clip node defines a set of clipping planes. Any geometry, of the clip node’s chil-

Copyright © 2018 Open Geospatial Consortium141dren, that falls outside the specified clipping planes is not displayed. For more information, see“Clip Region Record” on page 47.
Degree of freedom: A degree of freedom (DOF) node serves as a local coordinate system with apredefined set of internal transformations. It specifies the articulation of parts in the database andset limits on the motion of those parts. For more information, see “Degree of Freedom Record”
on page 37.
Level of detail: A level of detail (LOD) node serves as a switch to turn the display of everything
below it on or off based on its range from the viewer, according to its switch-in, switch-out distance and center location. For more information, see “Level of Detail Record” on page 41.
Switch: A switch node is a more general case of an LOD node. It allows the selection of zero or
more children by invoking a selector mask. Any combination of children can be selected permask and the number of definable masks is unlimited. For more information, see “Switch
Record” on page 49.
External reference: An external reference node serves to reference a node in another database
file, or an entire database file. The referenced (child) node or database is considered an externalpart of the referencing (parent) database. For more information, see “External Reference Record”
on page 41.

Node Attributes
Nodes in the OpenFlight scene contain attributes whose values describe different properties orcharacteristics of the node. Most attributes are represented directly on the node itself and are
geared toward describing the specific characteristics of that type of node. The level of detail(LOD) node, for example, defines a switch in and switch out distance. Used together, these distances define a range within which the geometry contained in the LOD is visible.
Other attributes are represented indirectly on a node, using a lookup index into a table (palette) of
attributes to describe the characteristics of a node. The face node, for example, defines several
indirect attributes, including color index, material index and texture index. The values of theseindex attributes are used to map specific colors, materials and textures to the face node. The
definitions of the colors, materials and textures referenced by these index attributes are stored inpalettes in the database rather than directly on the nodes themselves.
This mechanism of indirect attribute mapping via palettes has some advantages. It can both save
space in the OpenFlight file and can simplify the task of making global changes to nodes in the
database.
To see how this indirection saves space, consider the material index attribute on the face node. A
material is defined by over 15 separate color and other visual attributes. If each of these attributes
were maintained per face in the database, the size of the database would get large quickly. Since
it is common to map a single material to hundreds (or even thousands) of faces in the database, it
is much more efficient to store a single material index attribute per face rather than storing theentire material definition.
Also, in terms of changing the appearance of a particular material in your database, when you dochange the material definition in the palette, the faces that reference that material get updated
automatically. This can make global changes much more simple to accomplish.

Palettes

Copyright © 2018 Open Geospatial Consortium142

In the previous section, indirect attribute mapping was introduced. As part of that discussion, thenotion of database palettes was also mentioned briefly. In fact, indirect attribute mapping is notpossible without a robust implementation of database palettes. A database palette is a collection(or set) of attribute definitions. As mentioned in the previous section, the material palette defines
a set of materials, each material being composed of several different color and visual attributes.
The OpenFlight database supports many different palettes. The most obvious palettes are thecolor, material and texture palettes. Most palettes support variable numbers of elements whileothers enforce fixed size constraints. The material and texture palettes are both variable sized
palettes that can contain zero or more entries. The color palette, in contrast, is a fixed size palettethat contains exactly 1024 entries.
Database palettes are not limited to supporting indirect attribute mapping. The vertex palette forexample, defines a set of “shared” vertex nodes that can be indirectly referenced by multiple faces
and/or light point nodes in the database. Similar to the space savings achieved by attributepalettes, the vertex palette also saves much disk space in the OpenFlight file when many geometry nodes share references to the same exact point in space (vertex).
All the database palettes supported by OpenFlight are described in “Palette Records” on page 66.
Specific palettes in OpenFlight include:•”Color Palette Record” on page 70•”Material Palette Record” on page 71•”Texture Palette Record” on page 73•”Texture Mapping Palette Record” on page 86•”Sound Palette Record” on page 80•”Line Style Palette Record” on page 85•”Light Source Palette Record” on page 81•”Light Point Appearance Palette Record” on page 82•”Light Point Animation Palette Record” on page 85•”Vertex Palette Records” on page 66•”Name Table Record” on page 71•”Eyepoint and Trackplane Palette Record” on page 73•”Linkage Palette Record” on page 77

Instancing
Instancing is the ability to define all or part of a database once, then reference it one or moretimes while applying various transformations. This allows you to define a piece of geometry onceand place it multiple times in the scene. OpenFlight supports internal and external instancing with
operations such as Rotate, Translate, Scale, and Put.
An internal instance is a subtree of the database that has been declared as an instance definition.
An instance definition represents the root of a stand-alone subtree within the database. It is introduced by an instance definition record that contains a unique instance definition number. An
instance definition is invoked by an instance reference record in a subsequent part of the databasetree.
An external instance refers to an entire database file. It is introduced by an external reference
node. An external reference node contains the name of the (child) database file to attach to thatpoint in the referencing (parent) database tree. It also includes attributes that determine whether
the child uses its own color, material, and texture palettes, or those of its parent.
Instance definitions can themselves contain instance definitions and references. Internal instances

Copyright © 2018 Open Geospatial Consortium143

cannot reference themselves. External instances should not reference themselves directly or
indirectly. The result of such use is undefined.
Instance definition and instance reference records are described in “Hierarchy Instancing
Records” on page 18. External reference records are described in “External Reference Record” onpage 41.

Replication
Replication instances a subtree of the database several times, applying a transformation eachtime. For example, a string of trees can be represented by a single group node that is instantiatedand translated to a new position several times.
Replication is legal for group, face, and light point nodes. Therefore a replication record is anancillary record of a group, face, or light point node. In conjunction with a replication record
there will be one or more ancillary transformation records.

Bounding Volumes
Bounding volumes can be used by the application to determine if a particular subtree of the database is in view. A bounding volume can be a box, a sphere, or a cylinder. Each group node canhave only one bounding volume. The volume normally encompasses the full geometric extent of
the group node’s children, including any instances and replications. A bounding volume record isan ancillary record of a group node.

Multitexture
OpenFlight supports eight textures per polygon or mesh as well as eight uv values per vertex. The
texture information stored directly on the face, mesh and vertex record is referred to as “the basetexture” or “texture layer 0”. Each additional texture layer is stored in ancillary records to theface, mesh and vertex list records and is referred to as “texture layer N” (for N=1..7). See“Multitexture” on page 54 for more information.

Copyright © 2018 Open Geospatial Consortium

144

2

OpenFlight File Format
The hierarchical structure of an OpenFlight database is stored on disk as a file. The fileconsists of a linear stream of binary records. Byte ordering in the file is big endian. All
OpenFlight records begin with a 4 byte sequence. The first two bytes of this sequence
identifies the record type (opcode) and the second two bytes specify the length of therecord. Note that the length includes this 4 byte sequence so the minimum length of any
record (that does not contain any additional data) will be 4. Given this very regularstructure, OpenFlight records can be read from disk and parsed easily.
•All OpenFlight records are a multiple of 4 bytes in length. When a record contains lessthan an full multiple of 4 bytes of data, the record is padded up (bytes added to the end of
the record) to be a multiple of 4 bytes in length. In some cases, OpenFlight records arepadded up to be multiples of 8 bytes in length.
•The length of all records (and fields in all records) as well as the offset of all fields are
expressed in bytes.
•Unless explicitly stated otherwise, bit fields and masks are counted starting at 0 (i.e., thefirst bit is bit number 0).
•Unless explicitly stated otherwise, the elements of matrix records stored in OpenFlightappear in row major order. That is, the elements of the matrix appear in the following
order:

row0col0, row0col1, row0col2, row0col3,
row1col0, row1col1, row1col2, row1col3,
row2col0, row2col1, row2col2, row2col3,
row3col0, row3col1, row3col2, row3col3•The length of all OpenFlight records is limited to the largest value that can be encodedwith 2 bytes or 16 bits (65535). For fixed-size records, this maximum size is sufficient.
For variable-size records, this limitation is addressed with the Continuation Record. For
more information, see “Continuation Record” on page 65.

OpenFlight Record Types
There are four major categories of records: control records, node primary records,
ancillary records and continuation records.
Control records mark the hierarchy of the tree. A push control record (a record containing
the push opcode) indicates an increase in the depth of the tree. A push control record
drops you down one level in the tree. A pop control record (a record containing a pop
opcode) returns you to the previous level of hierarchy. All records between a push and a
pop represent sibling nodes at the same level of hierarchy. Other control records include:
instance definition, instance reference, push subface, pop subface, push attribute, and pop
attribute.
Each node is represented on disk by one primary record and zero or more ancillary
records. The primary record identifies a node type and includes most of the node attributedata. Additional node attributes, such as comments, long ID, and transformations, arestored in subsequent ancillary records. Ancillary records follow the primary record, but
precede any control records. Child nodes are introduced by a push control record and areconcluded by a pop control record.

Copyright © 2018 Open Geospatial Consortium

6-145

Palette records are ancillary records of the header node. Palette records generally follow
the header node’s primary record, with the exception of behavior (linkage) paletterecords. Behavior palette records, if present, are the last (non-control) records in the file.
Continuation records are used to “continue” a record in the OpenFlight Scene Description
file stream, when the original record is larger than 65535 bytes. The continuation record
appears in the stream immediately following the record that it “continues”. The datacontained in the continuation record is defined by the original record and is assumed tobe directly appended onto the content of the original record. Multiple continuation
records may follow a record, in which case all continuation records would be appended(in sequence) to the original record
Many records include an eight character ASCII ID consisting of the first seven charactersof the node name plus a terminating <nil> character. If the node ID is longer than sevencharacters, an ancillary long ID record containing the complete ID follows the node
primary record.
For example, a record with an object opcode is followed by a push control record. Next
comes a record with a face opcode, also followed by a push control record. After thatcomes the vertex list record(s) that describe the vertices of the face, and then a pop
control record. This, in turn, may be followed by another face record for the next face inthe same object, or by a pop record to return to object level.
The fields within each OpenFlight record are stored in big-endian byte order. OpenFlightdatabase files have the extension “.flt” by convention.

Control Records
Control records indicate a change in the level of the database hierarchy. The three basic
types of control records are: level changes, instance definition, and instance reference.
Level changes are indicated by push and pop control records. Instance definitions andreferences are indicated by instance definition and instance reference control records.
Hierarchy Level Change Records
A database contains three distinct types of hierarchy: generic, subface, and attribute.
Hierarchy may be skipped by scanning past the push control record for the corresponding
pop control record.
Generic

A push level control record introduces a generic subtree of thedatabase hierarchy. A pop level control record concludes that
subtree.

Subface

A push subface control record introduces a subtree of coplanar faces.
A pop subface control record concludes that subtree.

Extension A push extension control record introduces a subtree of user definedrecords. A pop extension control records concludes that subtree.
Attribute

A push attribute control record introduces a subtree of records
reserved for internal use by MultiGen-Paradigm, Inc.. A pop
attribute control record concludes that subtree.

Push Level Record

Copyright © 2018 Open Geospatial Consortium

6-146

Data Type

OffsetLengthDescription

Int
Unsigned
Int

0
2

2
2

Push Level Opcode 10
Length - length of the record

Pop Level Record

Data Type

OffsetLengthDescription

Int
Unsigned
Int

0
2

2
2

Pop Level Opcode 11
Length - length of the record

Push Subface Record

Data Type

OffsetLengthDescription

Int
Unsigned
Int

0
2

2
2

Push Subface Opcode 19
Length - length of the record

Pop Subface Record

Data Type

OffsetLengthDescription

Int
Unsigned
Int

0
2

2
2

Pop Subface Opcode 20
Length - length of the record

Data Type

OffsetLengthInt
Unsigned
Int
Char
Unsigned
Int

0
2

2
2

Push Extension Opcode 21
Length - length of the record

4
22

18
2

Reserved
Vertex reference index; -1 if
not vertex extension

Push Extension Record

Copyright © 2018 Open Geospatial Consortium

Description

CDB OpenFlight
Readerüü

CDB OpenFlight
Readerüü

CDB OpenFlight
Readerüü

CDB OpenFlight
Readerüü

CDB OpenFlight
Reader
ü
ü




6-147

Pop Extension Record

Data Type

OffsetLengthDescription

Int
Unsigned
Int
Char
Unsigned
Int

0
2

2
2

Pop Extension Opcode 22
Length - length of the record

4
22

18
2

Reserved
Vertex reference index; -1 if
not vertex extension

Data Type

OffsetLengthInt
Unsigned
Int
Int

0
2

2
2

Push Attribute Opcode 122
Length - length of the record

44Vertex reference index; -1 if
not vertex attribute

Data Type

OffsetLengthDescription

Int
Unsigned
Int

0
2

2
2

Pop Attribute Opcode 123
Length - length of the record

Push Attribute Record
Description

Pop Attribute Record

CDB OpenFlight
Readerüü

CDB OpenFlight
Readerüü
CDB OpenFlight
Readerüü

Hierarchy Instancing Records
An instance definition record introduces a stand-alone subtree of the database. The
subtree is referenced one or more times from different branches in the database by
instance reference records. At the point of reference, the subtree is copied (or possibly
shared) as a child of the current parent node.
The instance definition record must appear in the file stream prior to the first instancereference record that references it. A typical usage of these records might look like:
INSTANCE DEFINITION 1
PUSH
The records between this PUSH and POP define thestand-alone subtree that is INSTANCE DEFINITION 1
POP
...
GROUP
MATRIXPUSH
INSTANCE REFERENCE 1
POP
GROUP
MATRIX
PUSH

Copyright © 2018 Open Geospatial Consortium

6-148

INSTANCE REFERENCE 1
POP

In this example, both groups reference instance definition number 1, each presumably
applying a different matrix to place the instance in different locations in the scene.

Instance Definition Record
Data Type

OffsetLengthDescription

Int

0

2

Unsigned
Int
Int
Int

2

2

Instance Definition Opcode
62
Length - length of the record

4
6

2
2

Reserved
Instance definition number

Data Type

OffsetLengthInt

02

Unsigned
Int
Int
Int

2

2

Instance Reference Opcode
61
Length - length of the record

4
6

2
2

Reserved
Instance definition number

Instance Reference Record
Description

CDB OpenFlight
Readerüüü

CDB OpenFlight
ReaderüüüNode Primary Records
Header Record
The header record is the primary record of the header node and is always the first recordin the database file. Attributes within the header record provide important information
about the database file as a whole.
Format revision level indicates the OpenFlight version of the file. Correctly interpretingthe attributes of other records, such as the face and vertex records, depends upon theformat revision. The format revision encompasses both Flight and OpenFlight versions.

Copyright © 2018 Open Geospatial Consortium

6-149

Some representative values for format revision are:Format Revision Value
11
12
14
1420
1510
1540
1550
1560
1570
1580
1600

Flight/OpenFlight Version
Flight V11
Flight V12
OpenFlight v14.0 and v14.1
OpenFlight v14.2
OpenFlight v15.1
OpenFlight v15.4
OpenFlight v15.5
OpenFlight v15.6
OpenFlight v15.7
OpenFlight v15.8
OpenFlight v16.0

CDB OpenFlight Reader











ü

This document describes OpenFlight version 16.0, therefore the attribute descriptions are
based upon a format revision level of 1600.
Geographic attributes such as projection type, latitude, and longitude may be stored in theheader record. The MultiGen Series II and Creator Terrain options set the value of these
attributes when creating terrain databases. Positive latitudes reference the northernhemisphere and negative longitudes reference the western hemisphere.
Delta x, y and z attributes indicate the placement of the database when several separate
databases, each with a local origin of zero, are used to represent an area.

Copyright © 2018 Open Geospatial Consortium

6-150Data Type

OffsetLengthInt
Unsigned Int
Char

0
2
4

2
2
8

Int
Int
Char
Int
Int
Int
Int
Int
Int

12
16
20
52
54
56
58
60
62

4
4
32
2
2
2
2
2
1

Int
Int

63
64

1
4

Int
Int

68
92

4*6
4

Int
Int
Int

96
124
126

4*7
2
2

Header Record

Description

Header Opcode 1
Length - length of the record
7 char ASCII ID; 0 terminates(usually set to “db”)
Format revision level
Edit revision level
Date and time of last revision
Next Group node ID number
Next LOD node ID number
Next Object node ID number
Next Face node ID number
Unit multiplier (always 1)
Vertex coordinate units
0 = Meters
1 = Kilometers
4 = Feet
5 = Inches
8 = Nautical miles
if TRUE set texwhite on new faces
Flags (bits, from left to right)
0 = Save vertex normals
1 = Packed Color mode
2 = CAD View mode
3-31 = SpareReserved
Projection type
0 = Flat earth
1 = Trapezoidal
2 = Round earth
3 = Lambert
4 = UTM
5 = Geodetic
6 = GeocentricReserved
Next DOF node ID number
Vertex storage type
1 = Double precision float - should
always be 1

Copyright © 2018 Open Geospatial Consortium

CDB OpenFlight
Reader
ü
ü
ü

ü







ü
ü











ü
ü




ü






6-151

Data TypeInt

DoubleDoubleDoubleDouble
Int
Int
Int
Int
Int
Int
Int
Int
DoubleDoubleDoubleDoubleDoubleDoubleDoubleDouble
Int
Int
Int
Int
Int
Int
Int
Int
Int

OffsetLength

128

4

132
140
148
156
164
166
168
176
178
180
182
184
188
196
204
212
220
228
236
244
252
254
256
258
260
262
264
266
268

8
8
8
8
2
2
4*2
2
2
2
2
4
8
8
8
8
8
8
8
8
2
2
2
2
2
2
2
2
4

Header Record (Continued)
Description

Database origin
100 = OpenFlight
200 = DIG I/DIG II
300 = Evans and Sutherland
CT5A/CT6
400 = PSP DIG
600 = General Electric
CIV/CV/PT2000
700 = Evans and Sutherland GDFSouthwest database coordinate x
Southwest database coordinate yDelta x to place database
Delta y to place database
Next sound node ID number
Next path node ID number
Reserved
Next Clip node ID number
Next Text node ID number
Next BSP node ID number
Next Switch node ID number
Reserved
Southwest corner latitude
Southwest corner longitude
Northeast corner latitude
Northeast corner longitude
Origin latitude
Origin longitude
Lambert upper latitude
Lambert lower latitude
Next Light source node ID number
Next Light point node ID number
Next Road node ID number
Next CAT node ID number
Reserved
Reserved
Reserved
Reserved
Earth ellipsoid model
0 = WGS 1984
1 = WGS 1972

Copyright © 2018 Open Geospatial Consortium

CDB OpenFlight
Reader








































6-152

Int
Int
Int

272
274
276

2
2
2

Char

278

6

2 = Bessel
3 = Clarke 1866
4 = NAD 1927
-1 = User defined ellipsoid
Next Adaptive node ID number
Next Curve node ID number
UTM zone (for UTM projections negative value means Southernhemisphere)
Reserved

Copyright © 2018 Open Geospatial Consortium










6-153

Header Record (Continued)

Data Type

OffsetLengthDescription

Double284

8Double292

8

Unsignedint
Unsigned
int
Int
Double300

2Delta z to place database(used in conjunction withexisting Delta x and Delta yvalues)Radius (distance fromdatabase origin to farthest
corner)Next Mesh node ID number

302

2

304
308

4
8

Double316

8

CDB OpenFlight
Reader

Next Light Point System ID
numberReserved
Earth major axis (for user
defined ellipsoid) in meters
Earth minor axis (for user
defined ellipsoid) in meters






Group Record
The group record is the primary record of the group node. Groups are the most generichierarchical node present in the database tree. Attributes within the group record provide
bounding volumes that encompass the group’s children and real-time control flags.
Relative priority specifies a fixed ordering of the group relative to its sibling nodes.
Ordering is from left (lesser values) to right (higher values). Nodes of equal priority may
be arbitrarily ordered. All nodes have an implicit (default) relative priority value of zero.
A group can represent an animation sequence in which case each immediate child of thegroup represents one frame of the sequence. An animation sequence is made of one ormore loops.
For a group with N children, both forward and backward loops consist of N frames. The
frames of forward and backward loops are:Direction

ForwardBackward

Frame 1Child 1Child N

Frame 2Child 2Child N-1

Frame 3

Child 3
Child N-2

...

...
...

Frame NChild NChild 1

Independent of the direction of the loop, a loop can optionally swing. A swing loop is one
that plays its children in the primary direction and then plays them in the opposite
direction. Note that as the loop swings from the current direction to the opposite
direction, the last frame in the current direction is not repeated. Therefore, for a groupwith N children, the first loop of both forward swing and backward swing animations

Copyright © 2018 Open Geospatial Consortium

6-154

consist of M frames where M equals ((2*N)-1) frames. Subsequent loops of swing
animations consist of M-1 frames. The frames of the first loop of forward and backward
swing animations are:Direction

ForwardFrame 1Child 1

Backward Child N

Frame 2Child 2
Child
N-1

...

Frame N... ChildN... Child
1

Frame N+1

Child N1Child 2

Frame N+2

Child N2Child 3...

Frame M... Child 1... Child N

The frames of subsequent loops of forward and backward swing animations are:Direction

Frame 1

Frame 2...

ForwardChild 2Child 3... ChildN... Child1

Backward Child
N-1

Child
N-2

Frame N

Frame N+1

Frame N+2...

Frame M1

Child N1Child 2Child N2Child 3... Child 1... Child N

The number of times an animation loop repeats within the sequence is specified by theloop count attribute. A loop count of 0 indicates that the loop is to repeat forever.
The duration of one loop within the sequence is specified by the loop duration attributeand is measured in seconds. A loop duration of 0 indicates that the loop is to play as fast
as possible.
For finite animation sequences (those with positive, non-zero loop count values), theduration that the last frame of the last loop is extended after the sequence has finish is
specified by the last frame duration attribute and is measured in seconds. A last frame
duration of 0 indicates that the last frame is not displayed any longer after the sequence
finishes.
Special effect ID1 and ID2 are application-defined attributes. Their values can be used toenhance the meaning of existing attributes, such as the animation flags, or extend theinterpretation of the group node. Normally, the value of these attributes is zero.
Significance can be used to assist real-time culling and load balancing mechanisms, bydefining the visual significance of this group with respect to other groups in the database.
Normally the value of this attribute is zero.
Layer ID is used by the Instrumentation Tools in the modeling products to identify (fordisplay) a collection of groups, independent of their locations in the hierarchy. Normallythe value of this attribute is zero.

Copyright © 2018 Open Geospatial Consortium

6-155

Group Record
Data Type

OffsetLengthDescription

Int
Unsigned
Int
Char

0
2

2
2

Group Opcode 2
Length - length of the record

4

8

Int
Int
Int

12
14
16

2
2
4

7 char ASCII ID; 0
terminates
Relative priority
Reserved
Flags (bits, from left toright)
0 = Reserved
1 = Forward animation
2 = Swing animation
3 = Bounding box follows
4 = Freeze bounding box
5 = Default parent
6 = Backward animation
7-31 = SpareSpecial effect ID1 application definedSpecial effect ID2 application definedSignificance

Int

20

2

Int

22

2

Int

24

2

Int
Int
Int
Int
Float
Float

26
27
28
32
36
40

1
1
4
4
4
4

Copyright © 2018 Open Geospatial Consortium

Layer code
Reserved
Reserved
Loop countLoop duration in seconds
Last frame duration inseconds

CDB OpenFlight
Reader

ü
ü
ü

ü

ü

ü
ü



ü



üper CDB
convention




ü
ü
ü

6-156

Here are some examples that show how the values of the animation flags (forward
animation, backward animation and swing animation) affect the animation. Note thatthese flags define how one “loop” of the animation sequence behaves.
ForwardAnimation

Backward
Animation

0
1
0
1
0
1

0
0
1
0
1
1

Group Animation Flags Examples
Swing
Animation

0
0
0
1
1
Any

ResultGroup is not animatedAnimation loop is forward, no swing.
Animation loop is backward, no swing.
Animation loop is forward with swing.
Animation loop is backward with swing.
Undefined, must be either forward or backward(not both).

Here are some examples that show how the loop duration, loop count and last frame
duration attributes affect the animation. Note that these values are independent of theanimation flags from above.

Group Animation Count Examples

Loop
Duration

Loop
Count

Last Frame
Duration

0

0

Any

T

0

Any

0

N

0

0

N

T

T1

N

0

T1

N

T2

ResultEach loop plays as fast as possible.
Loops are played forever.
Last Frame Duration not applicable.
Each loop lasts T seconds.
Loops are played forever.
Last Frame Duration not applicable.
Each loop plays as fast as possible.
N loops are played.
Last frame displayed as long as any other frame.
Each loop plays as fast as possible.
N loops are played.
Last frame of last (Nth) loop displayed T seconds
longer than any other frame.
Each loop lasts T1 seconds.
N loops are played.
Last frame of last (Nth) loop displayed as long as anyother frame.
Each loop lasts T1 seconds.
N loops are played.
Last frame of last (Nth) loop displayed T2 seconds
longer than any other frame.

Object Record
The object record is the primary record of the object node. Objects are low-levelgrouping nodes that contain attributes pertaining to the state of it child geometry. Only
face and light point nodes may be the children of object nodes.
The time-of-day object flags can be used to inhibit the display of certain objects,
depending on the current time of day.

Copyright © 2018 Open Geospatial Consortium

6-157

The illumination flag, when set, makes an object self-illuminating, and is not subject tolighting calculations. In practice, geometric normals should be ignored.
The flat shading flag, when set, indicates that lighting calculations should produce a
faceted appearance to the object’s geometry. In practice, geometric normals should beconstrained to face normals.
The shadow flag indicates the object represents the shadow of the rest of the group. Whenused as part of a moving model (e.g., an aircraft), the application can apply appropriate
distortions, creating a realistic shadow on the terrain or runway.
Relative priority specifies a fixed ordering of the object relative to its sibling nodes.
Ordering is from left (lesser values) to right (higher values). Nodes of equal priority may
be arbitrarily ordered. All nodes have an implicit (default) value of zero.
When used, transparency applies to all an object’s children (geometry). The value should
be modulated with the transparency of the geometry and material alpha calculation, as
described in the Face Record, Mesh Record and Material Record sections.
Note:

The MultiGen-Paradigm, Inc. modeling environment does not use the object
transparency value for rendering as described above.

However, when an object’s transparency value is set in Creator, that value is set on all
children faces of the object. Runtime applications may choose to use the transparency
value at the object level at their discretion.

Object Record

Data Type

OffsetLengthDescription

Int
Unsigned
Int
Char

0
2

2
2

Object Opcode 4
Length - length of the record

48

7 char ASCII ID; 0
terminates

ü

Int

12

4

Int

16

2

Flags (bits from to right)
0 = Don't display in daylight
1 = Don't display at dusk
2 = Don't display at night3 = Don't illuminate
4 = Flat shaded
5 = Group's shadow object
6-31 = Spare
Relative priority

ü
ü
ü
ü
ü
ü
ü

ü

Unsigned
Int

18

2

Transparency

ü

Int

20

2



Int

22

2

0 = Opaque65535 = Totally clear
Special effect ID1 application definedSpecial effect ID2 -Copyright © 2018 Open Geospatial Consortium

OpenFlight CDB
Reader

ü
ü



6-158

Int

24

2

application definedSignificance

Int

26

2

ReservedüPer CDB conventions

Face Record
The face record is the primary record of the face node. A face contains attributes
describing the visual state of its child vertices. Only vertex and morph vertex nodes may
be children of faces. This should not be confused with the fact that faces may havesubfaces.
If a face contains a non-negative material index, its apparent color is a combination of theface color and material color, as described in “Material Palette Record” on page 71. If aface contains a nonaddictive material with an alpha component and the transparency field
is set, the total transparency is the product of the material alpha and face transparency.
Note: As mentioned in “Object Record” on page 25, the object transparency is not usedin the MultiGen-Paradigm, Inc. modeling environment to determine the actual
transparency value of a face.
If a face is a unidirectional or bidirectional light point, the face record is followed by avector record (Vector Opcode 50) that contains the unit vector indicating the direction inwhich the primary color is displayed. For bidirectional light points, the alternate color isdisplayed in the opposite direction (180 degrees opposed).
Note: This method of defining light points is obsolete after OpenFlight version 15.2.
Such light point faces will be turned into the new light point record when it is read
into MultiGen II v1.4 or later.
Relative priority specifies a fixed ordering of the face relative to its sibling nodes.
Ordering is from left (lesser values) to right (higher values). Nodes of equal priority may
be arbitrarily ordered. All nodes have an implicit (default) value of zero.

Copyright © 2018 Open Geospatial Consortium

6-159

Face Record

Data Type

Offset Length

Description

Int
Unsigned Int
Char
Int
Int
Int

0
2
4
12
16
18

2
2
8
4
2
1

Int

19

1

Unsigned Int
Unsigned Int
Int
Int

20
22
24
25

2
2
1
1

Int

26

2

Face Opcode 5
Length - length of the record
7 char ASCII ID; 0 terminates
IR color code
Relative priority
Draw type
0 = Draw solid with backface culling(front side only)
1 = Draw solid, no backface culling(both sides visible)
2 = Draw wireframe and close
3 = Draw wireframe
4 = Surround with wireframe in alternate
color
8 = Omnidirectional light
9 = Unidirectional light
10 = Bidirectional light
Texture white = if TRUE, draw textured
face white
Color name index
Alternate color name index
Reserved
Template (billboard)
0 = Fixed, no alpha blending
1 = Fixed, alpha blending
2 = Axial rotate with alpha blending
4 = Point rotate with alpha blending
Detail texture pattern index, -1 if none

Int
Int
Int

28
30
32

2
2
2

Texture pattern index, -1 if none
Material index, -1 if none
Surface material code (for DFAD)

Int
Int
Unsigned Int

34
36
40

2
4
2

Unsigned Int

42

1

Feature ID (for DFAD)
IR material code
Transparency
0 = Opaque65535 = Totally clear
LOD generation control

Copyright © 2018 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü
ü

ü
ü
ü
ü








ü
ü


ü
ü
ü
ü
ü


Note: Detail
textures are IRIS
GL specificüüü(tentative)



ü


6-160

Unsigned Int
Int

43
44

1
4

Unsigned Int

48

1

Char
Unsigned Int

49
56

7
4

Unsigned Int

60

4

Int
Int
Unsigned Int
Unsigned Int
Int
Int

64
66
68
72
76
78

2
2
4
4
2
2

Line style index
Flags (bits from left to right)
0 = Terrain
1 = No color
2 = No alternate color
3 = Packed color
4 = Terrain culture cutout (footprint)
5 = Hidden, not drawn
6 = Roofline
7-31 = Spare
Light mode
0 = Use face color, not illuminated
1 = Use vertex colors, not illuminated
2 = Use face color and vertex normals
3 = Use vertex colors and vertex normals
Reserved
Packed color, primary (a, b, g, r) - only b,g, r used
Packed color, alternate (a, b, g, r) - onlyb, g, r used
Texture mapping index
Reserved
Primary color index
Alternate color index
Reserved
Shader index, -1 if none

Copyright © 2018 Open Geospatial Consortium


ü
ü
ü
ü
ü
ü
ü
ü

ü
ü
ü
ü
ü

ü
ü


ü
ü



6-161

Mesh Nodes
A mesh node defines a set of geometric primitives that share attributes and vertices. Prior
to OpenFlight version 15.7, the fundamental geometric construct was the face (polygon)
which was represented by a unique set of attributes and vertices. Meshes, by contrast,
represent “sets” of related polygons, each sharing common attributes and vertices. Usinga mesh, related polygons can be represented in a much more compact format. Each meshconsists of one set of “polygon” attributes (color, material, texture, etc.), a common“vertex pool” and one or more geometric primitives that use the shared attributes andvertices. Using a mesh, you can represent triangle strips, triangle fans, quadrilateral strips
and indexed face sets.
A mesh node is defined by three distinct record types:•Mesh Record - defines the “polygon” attributes associated to all geometricprimitives of the mesh.
•Local Vertex Pool Record - defines the set of vertices that are referenced by thegeometric primitives of the mesh.
•Mesh Primitive Record - defines a geometric primitive (triangle-strip, triangle-fan,quadrilateral-strip or indexed face set) for the mesh.
A mesh node consists of one mesh record, one local vertex pool record, and one or moremesh primitive records. The mesh primitive records are delimited by push and pop
control records as shown in the following example:
MESH
LOCAL VERTEX POOL
PUSH
MESH PRIMITIVEMESH PRIMITIVE...
MESH PRIMITIVEPOP

Copyright © 2018 Open Geospatial Consortium

6-162

Mesh Record
The mesh record is the primary record of a mesh node and defines the common “facelike” attributes associated to all geometric primitives of the mesh. These attributes are
identical to those of the face record. See “Face Record” on page 26.

Mesh Record

Data Type

OffsetLengthDescription

CDB OpenFlight
ReaderInt
Unsigned
Int
Char
Int
Int
Int
Int

0
2

2
2

Mesh Opcode 84
Length - length of the record

4
4
16
20
22

8
4
4
2
1

7 char ASCII ID; 0 terminates
Reserved
IR color code
Relative priority
Draw type
0 = Draw solid with backface culling(front side only)
1 = Draw solid, no backface culling(both sides visible)
2 = Draw wireframe and close
3 = Draw wireframe
4 = Surround with wireframe inalternate color
8 = Omnidirectional light
9 = Unidirectional light
10 = Bidirectional light
Texture white = if TRUE, draw
textured face white

ü


ü
ü
ü

ü
ü

ü








Int

23

1

Unsigned
Int
Unsigned
Int

24

2

Color name index

ü

26

2

Alternate color name index

ü

Int
Int

28
29

1
1

Int

30

2

Reserved
Template (billboard)
0 = Fixed, no alpha blending
1 = Fixed, alpha blending
2 = Axial rotate with alpha blending
4 = Point rotate with alpha blending
Detail texture pattern index, -1 if
none


ü
ü
ü
ü
ü


Int
Int

32
34

2
2

Texture pattern index, -1 if none
Material index, -1 if none

Copyright © 2018 Open Geospatial Consortium

Note: Detail textures
are IRIS GL specific

ü
ü

6-163

Int

36

2

Surface material code (for DFAD)

Int
Int
Unsigned
Int

38
40
44

2
4
2

Feature ID (for DFAD)
IR material code
Transparency

Unsigned
Int
Unsigned
Int
Int

46

1

0 = Opaque65535 = Totally clear
LOD generation control



47

1

Line style index



48

4

Unsigned
Int

52

1

Flags (bits from left to right)
0 = Terrain
1 = No color
2 = No alternate color
3 = Packed color
4 = Terrain culture cutout (footprint)
5 = Hidden, not drawn
6 = Roofline
7-31 = Spare
Light mode

ü
ü
ü
ü
ü
ü
ü
ü

ü
ü
ü

Char
Unsigned
Int
Unsigned
Int
Int
Int
Unsigned
Int
Unsigned
Int
Int
Int

ü

(tentative)



ü

53
60

7
4

64

4

68
70
72

2
2
4

0 = Use mesh color, not illuminated
1 = Use vertex colors, notilluminated
2 = Use mesh color and vertex
normals
3 = Use vertex colors and vertex
normals
Reserved
Packed color, primary (a, b, g, r) only b, g, r used
Packed color, alternate (a, b, g, r) only b, g, r used
Texture mapping index
Reserved
Primary color index

76

4

Alternate color index

ü

80
82

2
2

Reserved
Shader index, -1 if noneCopyright © 2018 Open Geospatial Consortium

ü
ü

ü
ü


ü

6-164

Local Vertex Pool Record

This record defines a set of vertices that is referenced by the geometry (primitives) of the
mesh.
Note:

Currently the Local Vertex Pool is used exclusively in the context of mesh nodes,
but it is designed in a general way so that it may appear in other contexts infuture versions of the OpenFlight Scene Description.

Data
Type
Int
Unsigned
Int

OffsetLength02

2
2

Unsigned
Int
Unsigned
Int

4

4

8

4

Local Vertex Pool Record
Description
Local Vertex Pool Opcode 85
Length - length of the record
Note: Since the length of this record
is represented by an unsigned short,the maximum length of the vertex
pool is 216- 1 (or 65535 bytes). If theentire vertex pool cannot fit into thissize, one or more continuation records
will follow. (See “Continuation
Record” on page 65.)
Number of vertices - number ofvertices in the local vertex pool
Attribute mask - Bit mask indicating
what kind of vertex information is
specified for each vertex in the local
vertex pool. Bits are ordered from left
to right as follows:
Bit#Description0
Has Position - if set, data foreach vertex in will include x, y, and z
coordinates (3 doubles)1
Has Color Index - if set, data
for each vertex will include a color
value that specifies a color table index
as well as an alpha value
2
Has RGBA Color - if set, data
for each vertex will include a color
value that is a packed RGBA color
value
Note: Bits 1and 2 are mutually
exclusive - a vertex can have either
color index or RGB color value orneither, but not both.
3
Has Normal - if set, data foreach vertex will include a normal (3floats)4
Has Base UV - if set, data foreach vertex will include uv texture
coordinates for the base texture (2floats)Copyright © 2018 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü

ü
ü

ü
ü

ü

ü

ü
ü

6-165

5
Has UV Layer 1 - if set, data
for each vertex will include uv texture
coordinates for layer 1 (2 floats)
6
Has UV Layer 2 - if set, data
for each vertex will include uv texture
coordinates for layer 2 (2 floats)
7
Has UV Layer 3 - if set, data
for each vertex will include uv texture
coordinates for layer 3 (2 floats)
8
Has UV Layer 4 - if set, data
for each vertex will include uv texture
coordinates for layer 4 (2 floats)
9
Has UV Layer 5 - if set, data
for each vertex will include uv texture
coordinates for layer 5 (2 floats)
10
Has UV Layer 6 - if set, data
for each vertex will include uv texture
coordinates for layer 6 (2 floats)
11
Has UV Layer 7 - if set, data
for each vertex will include uv texture
coordinates for layer 7 (2 floats)
12-31 Spare

Copyright © 2018 Open Geospatial Consortium

ü
ü
ü
ü
ü
ü
ü


6-166

Local Vertex Pool Record (Continued)

Then beginning at offset 12, the following fields are repeated for eachvertex in the local vertex pool, depending on the bits set in the Attributemask field above.
In the fields listed below, N ranges from 0 to Number of vertices - 1.
DoubleVaries 8*3
CoordinateN - Coordinate of vertex N(x, y, z) - present if Attribute mask
includes Has Position.
Unsigned Int
Varies 4
colorN - Color for vertex N - present
if Attribute mask includes Has Color
Index or Has RGBA Color.
If Has Color Index, lower 3 bytes
specify color table index, upper 1
byte is Alpha.
If Has RGBA Color, 4 bytes specify(a, b, g, r) values.
Float
Varies 4*3
normalN - Normal for vertex N (i, j, k)- present if Attribute mask includes
Has Normal.
Float
Varies 4*2
uvBaseN - Texture coordinates (u, v)
for base texture layer of vertex N present if Attribute mask includes
Has Base UV.
Float
Varies 4*2
uv1N - Texture coordinates (u, v) for
layer 1 of vertex N - present if
Attribute mask includes Has UVLayer 1.
Float
Varies 4*2
uv2N - Texture coordinates (u, v) for
layer 2 of vertex N - present if
Attribute mask includes Has UVLayer 2.
Float
Varies 4*2
uv3N - Texture coordinates (u, v) for
layer 3 of vertex N - present if
Attribute mask includes Has UVLayer 3.
Float
Varies 4*2
uv4N - Texture coordinates (u, v) for
layer 4 of vertex N - present if
Attribute mask includes Has UVLayer 4.
Float
Varies 4*2
uv5N - Texture coordinates (u, v) for
layer 5 of vertex N - present if
Attribute mask includes Has UVLayer 5.
Float
Varies 4*2
uv6N - Texture coordinates (u, v) for
layer 6 of vertex N - present if
Attribute mask includes Has UVLayer 6.
Float
Varies 4*2
uv7N - Texture coordinates (u, v) for
layer 7 of vertex N - present if
Attribute mask includes Has UVLayer 7.

Copyright © 2018 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü

ü
ü

ü

ü

ü

ü

ü

ü

ü

6-167

Mesh Primitive Record
This record defines a geometric primitive (triangle strip, triangle fan, quadrilateral strip,
or indexed polygon) for a mesh.

Mesh Primitive Record

Data Type

OffsetLengthInt
Unsigned
Int
Int

0
2

2
2

Description

Mesh Primitive Opcode 86
Length - length of therecord4
2
Primitive Type - specifies
how the vertices of theprimitive are interpreted
1 = Triangle Strip
2 = Triangle Fan
3 = Quadrilateral Strip
4 = Indexed Polygon
Unsigned
62
Index Size - specifies theIntlength (in bytes) of each of
the vertex indices that
follow - will be either 1, 2,
or 4
Unsigned
84Vertex Count- number ofIntvertices contained in thisprimitive.
The following field is repeated for each vertex referenced by themesh primitive. These vertices are interpreted according toPrimitive Type. In the field below, N ranges from 0 to Vertex
Count - 1.
12+(N*Index
Int
Index
IndexN - Index of vertex N
Size)
Size
of the mesh primitive.

Copyright © 2018 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü
ü
ü
ü
ü
ü
ü

ü
ü
ü

6-168

Each mesh primitive is represented using the Mesh Primitive record above. The
following descriptions explain how the vertices of each primitive type are interpreted asgeometry:• Triangle Strip - This mesh primitive defines a connected group of triangles in thecontext of the enclosing mesh. Each triangle shares the “polygon” attributes definedby the enclosing mesh. This primitive contains a sequence of indices that reference
vertices from the local vertex pool. One triangle is defined for each vertex presented
after the first two vertices. For odd n, vertices n, n+1, and n+2 define triangle n. For
even n, vertices n+1, n, and n+2 define triangle n. The first triangle is n=1. The firstvertex in the vertex pool is n=1. N vertices represent N-2 triangles.
• Triangle Fan - Like the Triangle Strip, this mesh primitive also defines a connectedgroup of triangles in the context of the enclosing mesh. Each triangle shares the“polygon” attributes defined by the enclosing mesh. This primitive contains asequence of indices that reference vertices from the local vertex pool. One triangle isdefined for each vertex presented after the first two vertices. Vertices 1, n+1, and n+2
define triangle n. The first triangle is n=1. The first vertex in the vertex pool is n=1.
N vertices represent N-2 triangles.
• Quadrilateral Strip - This mesh primitive defines a connected group ofquadrilaterals in the context of the enclosing mesh. Each quadrilateral shares the“polygon” attributes defined by the enclosing mesh. This primitive contains asequence of indices that reference vertices from the local vertex pool. One
quadrilateral is defined for each pair of vertices presented after the first pair. Vertices
2n-1, 2n, 2n+2, and 2n+1 define quadrilateral n. The first quadrilateral is n=1. The
first vertex in the vertex pool is n=1. N vertices represent (N/2)-1 quadrilaterals.
• Indexed Polygon -This mesh primitive defines a single polygon in the context of theenclosing mesh. This primitive is similar to the other mesh primitives in that it also
shares the polygon attributes of the enclosing mesh. It is different from the othermesh primitive types in that while triangle strips/fans and quadrilateral strips describe
a set of connected triangles/quadrilaterals, the indexed polygon defines a single
polygon. This primitive contains a sequence of indices that reference vertices fromthe local vertex pool. One polygon is defined by the sequence of vertices in thisrecord. N vertices represent 1 N-sided closed polygon or 1 (N-1)-sided unclosed
polygon.
Light Point Nodes
The OpenFlight format supports two kinds of light point records, indexed and inline. In
indexed light point records, the attributes are stored in two palettes; the light point
appearance palette and the light point animation palette. The indexed light point record
simply stores indices into these two palettes. In inline light point records, all the attributes
are stored directly in the light point record itself. This section describes both of theserecords.

Copyright © 2018 Open Geospatial Consortium

6-169

Indexed Light Point Record
The indexed light point record is one of the records that can represent a light point node.
The appearance index specifies an entry in the light point appearance palette that contains
the visual attributes of the light point.
The animation index specifies an entry in the light point animation palette that contains
the behavioral attributes of the light point.
The palette entries referenced by the indexed light point record describe the visual stateof the light point’s child vertices. Only vertex nodes may be children of light point nodes.

Indexed Light Point Record

Data Type

OffsetLengthDescription

Int

0

2

Unsigned
Int
Char

2

2

Indexed Light Point Record
Opcode 130
Length - length of the record

4

8

Int
Int
Int

12
16
24

4
20
4

Int

28

4

7 char ASCII ID; 0
terminates
Appearance index
Animation index
Draw order (for calligraphic
lights)Reserved

CDB OpenFlight
Reader

ü
ü
ü

ü




Light Point Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider Light
Point Records.

The light point record is one of the records that can represent a light point node. The lightpoint record contains attributes describing the visual state of its child vertices. Only
vertex nodes may be children of light point nodes.
Light points are geometric points that represent real world light sources such as runway
lights, vehicle lights, street lights, and rotating beacons. Light points differ from lightsources in that they do not illuminate the scene around them. They are primarily used tomodel important visual cues without incurring the tremendous rendering overhead
associated with light sources.
Most light point attributes are specific to these unique requirements. Light points can bedisplayed on special purpose calligraphic imaging systems, the more familiar raster
variety, or even hybrid raster/calligraphic (RASCAL) systems.

Copyright © 2018 Open Geospatial Consortium

6-170

Data TypeInt
Unsigned Int
Char
Int
Int
Unsigned Int
Int

Offset
0
2
4
12
14
16
20

Length
2
2
8
2
2
4
4

Float
Float
Float
Float
Int

24
28
32
36
40

4
4
4
4
4

Int

44

4

Int

48

4

Int

52

4

Float
Float
Float
Float

56
60
64
68

4
4
4
4

Float

72

4

Float

76

4

Float

80

4

Float

84

4

Float
Float

88
92

4
4

Light Point Record

Description
Light Point Record Opcode 111
Length - length of the record
7 char ASCII ID; 0 terminates
Surface material code
Feature ID
Back color for bidirectional points
Display mode
0 = RASTER
1 = CALLIGRAPHIC
2 = EITHER
Intensity - scalar for front colors
Back intensity - scalar for back color
Minimum defocus - (0.0 - 1.0) for calligraphic points
Maximum defocus - (0.0 - 1.0) for calligraphic points
Fading mode
0 = Enable perspective fading calculations
1 = Disable calculations
Fog Punch mode
0 = Enable fog punch through calculations
1 = Disable calculations
Directional mode
0 = Enable directional calculations
1 = Disable calculations
Range mode
0 = Use depth (Z) buffer calculation
1 = Use slant range calculation
Min pixel size - minimum diameter of points in pixels
Max pixel size - maximum diameter of points in pixels
Actual size - actual diameter of points in database units
Transparent falloff pixel size - diameter in pixels whenpoints become transparent
Transparent falloff exponent>= 0 - falloff multiplier exponent
1.0 - linear falloff
Transparent falloff scalar> 0 - falloff multiplier scale factor
Transparent falloff clamp - minimum permissible falloff
multiplier result
Fog scalar>= 0 - adjusts range of points for punch threw
effect.
Reserved
Size difference threshold - point size transition hint torenderer

Copyright © 2018 Open Geospatial Consortium

6-171

Data TypeInt

Offset96

Length
4

Float
Float
Float

100
104
108

4
4
4

Float

112

4

Float
Float
Float
Float
Float

116
120
124
128
132

4
4
4
4
4

Int
Int

136
140

4
4

Float

144

4*3

Light Point Record (Continued)

Description
Directionality
0 = OMNIDIRECTIONAL
1 = UNIDIRECTIONAL
2 = BIDIRECTIONAL
Horizontal lobe angle - total angle in degrees
Vertical lobe angle - total angle in degrees
Lobe roll angle - rotation of lobe about local Y axis in degrees
Directional falloff exponent>= 0 - falloff multiplier exponent
1.0 - linear falloff
Directional ambient intensity - of points viewed off axis
Animation period in seconds
Animation phase delay in seconds - from start of period
Animation enabled period in seconds
Significance - drop out priority for RASCAL lights (0.0 1.0)
Calligraphic draw order - for rendering consistency
Flags (bits, from left to right)
0 = reserved
1 = No back color
TRUE = don’t use back color for bidirectional
points
FALSE = use back color for bidirectional points
2 = reserved
3 = Calligraphic proximity occulting (Debunching)
4 = Reflective, non-emissive point
5-7 = Randomize intensity
0 = never
1 = low
2 = medium
3 = high
8 = Perspective mode
9 = Flashing
10 = Rotating
11 = Rotate Counter Clockwise
Direction of rotation about local Z axis
12 = reserved
13-14 = Quality
0 = Low
1 = Medium
2 = High
3 = Undefined
15 = Visible during day
16 = Visible during dusk
17 = Visible during night
18-31 = Spare
Axis of rotation for rotating animation (i, j, k)

Copyright © 2018 Open Geospatial Consortium

6-172

Light Point System Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider
Light Point System Records.
The light point system record enables you to collect a set of light points andenable/disable or brighten/dim them as a group.
Data TypeInt
Unsigned Int
Char
Float
Int

Offset
0
2
4
12
16

Int

20

Light Point System Record
Length
2
2
8
4
4

4

Description
Light Point System Record Opcode 130
Length - length of the record
7 char ASCII ID; 0 terminates
Intensity
Animation state
0 = On1 = Off
2 = Random
Flags (bits, from left to right)
0 = Enabled
1-31 = Spare

Degree of Freedom Record
The degree of freedom (DOF) record is the primary record of the DOF node. The DOF
node specifies a local coordinate system and the range allowed for translation, rotation,and scale with respect to that coordinate system.
The DOF record can be viewed as a series of applied transformations consisting of thefollowing elements:[PTTTRRRSSSP]
where “P” denotes “put,” “T” denotes “translate,” “R” denotes “rotate,” and “S” denotes“scale.”It is important to understand the order in which these transformations are applied to thegeometry. A pre-multiplication is assumed, so the sequence of transformations must beread from right to left, in order to describe its effect on the geometry contained below the
DOF. In this manner, a DOF is interpreted as a Put followed by three Scales, three
Rotates, three Translates, and a Put.
Taking the transformations in right to left order, they represent:
1. A Put (3 point to 3 point transformation). This matrix brings the DOF coordinate
system to the world origin, with its x-axis aligned along the world x-axis and its yaxis in the world x-y plane. Testing against the DOF's constraints is performed in thisstandard position. This matrix is therefore the inverse of the last (see step 11 below).
2. Scale in x.
3. Scale in y.
4. Scale in z.

Copyright © 2018 Open Geospatial Consortium

6-173

5. Rotation about z (yaw).
6. Rotation about y (roll).
7. Rotation about x (pitch).
8. Translation in x.
9. Translation in y.
10. Translation in z.
11. A final Put. This matrix moves the DOF coordinate system back to its original
position in the scene.
The DOF record specifies the minimum, maximum, and current values for eachtransformation. Only the current value affects the actual transformation applied to thegeometry. The increment value specifies discrete allowable values within the rangeof legal values represented by the DOF.

Copyright © 2018 Open Geospatial Consortium

6-174

Degree of Freedom Record

Data Type

OffsetLengthDescription

Int
Unsigned
Int
Char
Int
Double0222Degree-of-Freedom Opcode 14
Length - length of the record

4
12
16

8
4
8*3

Double40

8*3

Double64

8*3

Double88

8

Double96

8

Double104

8

DoubleDouble

112
120

8
8

Double128

8

Double136

8DoubleDouble

144
152

8
8

Double160

8

Double168

8DoubleDouble

176
184

8
8

DoubleDoubleDoubleDouble

192
200
208
216

8
8
8
8

DoubleDoubleDoubleDouble

224
232
240
248

8
8
8
8

Double256

87 char ASCII ID; 0 terminates
Reserved
Origin of DOF's local coordinate
system (x, y, z)
Point on x axis of DOF's local
coordinate system (x, y, z)
Point in xy plane of DOF's local
coordinate system (x, y, z)
Min z value with respect to local
coordinate system
Max z value with respect to local
coordinate system
Current z value with respect tolocal coordinate system
Increment in z
Min y value with respect to local
coordinate system
Max y value with respect to the
local coordinate system
Current y value with respect tolocal coordinate system
Increment in y
Min x value with respect to local
coordinate system
Max x value with respect to local
coordinate system
Current x value with respect tolocal coordinate system
Increment in x
Min pitch (rotation about the xaxis)
Max pitch
Current pitch
Increment in pitch
Min roll (rotation about the yaxis)
Max roll
Current roll
Increment in roll
Min yaw (rotation about the z
axis)
Max yaw

Copyright © 2018 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü

ü

ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü

6-175

DoubleDoubleDoubleDouble

264
272
280
288

8
8
8
8

Current yaw
Increment in yaw
Min z scale (about local origin)
Max z scale (about local origin)

Copyright © 2018 Open Geospatial Consortium

ü
ü
ü
ü

6-176

Degree of Freedom Record (Continued)

Data Type

OffsetLengthDescription

Double296

8DoubleDouble

304
312

8
8

Double320

8

Double328

8DoubleDouble

336
344

8
8

Double352

8

Double360

8Double
Int

368
376

8
4

Current z scale (about
local origin)
Increment for scale in z
Min y scale (about local
origin)Max y scale (about local
origin)Current y scale (about
local origin)
Increment for scale in y
Min x scale (about local
origin)Max x scale (about local
origin)Current x scale (about
local origin)
Increment for scale in x
Flags (bits, from left toright)
0 = x translation islimited
1 = y translation islimited
2 = z translation islimited
3 = Pitch rotation islimited
4 = Roll rotation islimited
5 = Yaw rotation islimited
6 = x scale is limited
7 = y scale is limited
8 = z scale is limited
9 = Reserved
10 = Reserved
11-31 = SpareReserved

Int

380

4

Copyright © 2018 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü

ü
ü
ü





6-177

Vertex List Record
A vertex list record is the primary record of a vertex node. Each record references one ormore vertices in the vertex palette. See “Vertex Palette Records” on page 66. A vertex
node is a leaf node in the database and therefore cannot have any children.

Vertex List Record
Data Type

OffsetLengthDescription

CDB OpenFlight
ReaderInt
0
2
Vertex List Opcode 72ü
Unsigned
2
2
Length - length of the recordüIntThe following field is repeated for each vertex contained in the vertex list record.
In the field below, N ranges from 0 to Number of vertices - 1, where Number of vertices =(Length - 4) / 4
Int4+(N*4) 4
OffsetN - Byte offset intoü
vertex palette of the actual
vertex for vertex N.
Morph Vertex List Record
A morph vertex list record is the primary record of a morph vertex node. Like the vertex
list record, each morph vertex list record references one or more vertices in the vertex
palette. See: “Vertex Palette Records” on page 66. A morph vertex node is a leaf node in
the database and therefore cannot have any children.
Each record references one or more pairs of vertices (weights) in the vertex palette. One
weight is the 0 percent morph attributes and the other weight is the 100 percent morph
attributes. Since each weight references a vertex, all vertex attributes including color,
normal, and texture coordinates may be morphed.
When the eyepoint approaches the switch-in distance, the vertex attributes displayed are
100 percent morphed. When the eyepoint reaches the distance computed by LOD switchin distance minus LOD transition range, the vertex attributes displayed are 0 percent
morphed. Within the LOD transition range, the vertex attributes displayed areinterpolated between the two known vertex attributes.
Geometric morphing is controlled by the parent LOD node. Only morph vertex nodes areaffected. Both morphing and static geometry (vertices) may exist within the same branchof the database hierarchy.

Morph Vertex List Record

Data
Offset Lengt Description
Type
h
Int
0
2
Morph Vertex List Opcode 89
Unsigned 2
2
Length - length of the record
Int
The following fields are repeated for each vertex containedin the morph vertex list record.
In the fields below, N ranges from 0 to Number of vertices 1, where
Number of vertices = (Length - 4) / 8

Copyright © 2018 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü

ü

6-178

Int
Int

4+(N* 48)8+(N* 48)

Offset 0N - Offset into vertex
palette of Nth 0% vertex.
Offset 100N - Offset into
vertex palette of Nth 100%vertex.

üüBinary Separating Plane Record
The binary separating plane (BSP) record is the primary record of the BSP node. A BSP
allows you to model 3D databases without depth (Z) buffer support.
An application uses this information to cull portions of the database according to whichside of the plane the subtree is situated on with regard to eyepoint position and viewing
direction.
This record contains an equation ax + by + cz + d = 0 that describes the separating plane.

Binary Separating Plane Record

Data Type

OffsetLengthDescription

Int

0

2

Unsigned
Int
Char

2

2

4

8

Int
Double

12
16

4
8*4

Binary Separating Plane(BSP) Opcode 55
Length - length of therecord7 char ASCII ID; 0
terminates
Reserved
Plane equation coefficients(a, b, c, d)

Copyright © 2018 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü
ü


ü

6-179

External Reference Record
The external reference record is the primary record of the external reference node.
External references allow one database to reference, or instance, a node in anotherdatabase (or an entire database). At the point of reference, the referenced node/database iscopied (or possibly shared) as a child of the current parent node.
The override flags allow the referencing (parent) database to control use of the referenced(child) node/database palettes. If an override flag (e.g., material) is set, the childnode/database uses its own (material) palette. Otherwise, the child node/database uses thecurrent (parent’s) palette. The override flags are hierarchical and may affect references
made by the child node/database.
The view as bounding box field is used by the MultiGen-Paradigm, Inc. modelingenvironment and is not expected to be used by runtime applications.

External Reference Record

Data Type

OffsetLengthDescription

Int

0

2

Unsigned
Int
Char

2

2

External Reference Opcode
63
Length - length of the record

4

200

Int
Int

204
208

4
4

Int

Int

212

214

2

2

Copyright © 2018 Open Geospatial Consortium

199-char ASCII path; 0
terminates
Format of this string is:filename<node name>if <node name> absent,
references entire file
Reserved
Flags (bits, from left to right)
0 = Color palette override
1 = Material palette override
2 = Texture and texture
mapping palette override
3 = Line style paletteoverride
4 = Sound palette override
5 = Light source paletteoverride
6 = Light point paletteoverride
7 = Shader palette override
8-31 = Spare
View as bounding box
0 = View external reference
normally
1 = View external reference
as bounding box
Reserved

CDB OpenFlight
Reader

ü
ü
ü

















6-180

Level of Detail Record
The level of detail (LOD) record is the primary record of the LOD node. LOD’s areperhaps the most important hierarchical node present in the database tree. Proper use oflevel-of-detail modeling concepts can vastly improve real-time playback of large
databases. Attributes within the LOD record provide switching and transition distances
for real-time culling and load management mechanisms.
The center coordinate can be used by a real-time application to calculate the slant range
distance from the eyepoint to the LOD. Based upon the result of this calculation, a realtime application can choose not to display the LOD’s children and thus reduce systemload. The center of the LOD is generally the transformed center of the geometry of the
LOD’s children. This should include the effects of instancing and (parent) group
replication as well.
The use previous slant range flag indicates that the slant range for this LOD is the sameas the previous (sibling) LOD, implying the center coordinate is also the same. The realtime application can reuse the previous slant range calculation when evaluating this LOD,
thereby improving performance.
If the freeze center flag is not set, the MultiGen-Paradigm, Inc. modeling environment aswell as OpenFlight API based applications will recalculate the center point of the LOD
when the OpenFlight file is saved.
Transition range specifies the range over which real-time smoothing effects should be
employed while switching from one LOD to another. Smoothing effects include
geometric morphing and image blending. The smoothing effect is active between: switchin distance minus transition range (near), and switch-in distance (far). The center distanceof the effect is therefore switch-in distance minus one half the transition range.
Significant size is a value used to calculate switch in and out distances based on viewing
parameters of your simulation display system. This value is used internally by MultiGenParadigm and will be enhanced in future versions of OpenFlight.

Copyright © 2018 Open Geospatial Consortium

6-181

Level of Detail Record

Data Type

OffsetLengthDescription

Int
Unsigned
Int
Char

0
2

2
2

Level-of-Detail Opcode 73
Length - length of the record

4

8

Int
DoubleDouble
Int

12
16
24
32

4
8
8
2

Int

34

2

Int

36

4

7 char ASCII ID; 0
terminates
Reserved
Switch-in distance
Switch-out distanceSpecial effect ID1 application definedSpecial effect ID2 application defined
Flags (bits, from left toright)

DoubleDoubleDoubleDoubleDouble

40
48
56
64
72

8
8
8
8
8

Copyright © 2018 Open Geospatial Consortium

0 = Use previous slant range
1 = Reserved
2 = Freeze center (don'trecalculate)
3-31 = Spare
Center coordinate x of LOD
Center coordinate y of LOD
Center coordinate z of LOD
Transition range
Significant size

CDB OpenFlight
Reader

ü
ü
ü


ü
ü


ü
ü



ü
ü
ü
ü
ü

6-182

Sound Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider
Sound Records.
The sound record is the primary record of the sound node. A sound node represents the
position and orientation of a sound emitter in the database.
Amplitude and pitch blend are relative to the amplitude in the waveform file. Falloff
defines how amplitude falls off when approaching the edge of the sound lobe, withmaximum amplitude at the center of the lobe.
Priority determines which sounds are played when more emitters populate a scene than
the sound system can play simultaneously.
Width defines the half angle of the sound lobe. Direction sets the type of sound lobe.
Doppler, absorption, and delay flags enable or disable the modeling of Doppler,
atmospheric absorption, and propagation delay in the sound environment.
Active indicates a sound is to be activated when read in to the modeling environment.

Sound Record

Data TypeInt
Unsigned Int
Char
Int
Int
Int
DoubleFloat

Offset
0
2
4
12
16
20
24
48

Length
2
2
8
4
4
4
8*3
4*3

Float
Float
Float
Float
Float
Int

60
64
68
72
76
80

4
4
4
4
4
4

Int

84

4

Copyright © 2018 Open Geospatial Consortium

Description
Sound Node Opcode 91
Length - length of the record
7 char ASCII ID; 0 terminates
Reserved
Index into sound palette
Reserved
Coordinate of offset from local origin (x, y, z)
Sound direction (vector) wrt local coordinate
axes (i, j, k)
Amplitude of soundPitch bend of soundPriority of soundFalloff of soundWidth of sound lobe
Flags (bits, from left to right)
0 = Doppler
1 = Atmospheric absorption
2 = Delay
3-4 = Direction:
0 = Omnidirectional
1 = Unidirectional
2 = Bidirectional
5 = Active
6-31 = SpareReserved

6-183

Light Source Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider
Light Source Records.
The light source record is the primary record of the light source node. Light sources
illuminate the database. They contain position and rotation data (overriding any
information stored in the light palette), an index into the light palette, and information on
how the light behaves within the hierarchy.
The enabled flag indicates whether the light is turned on and, therefore, a factor of thelighting (rendering) model.
The global flag specifies whether the light shines on the entire database or only on its
children (for example, the cabin light in a car).

Light Source Record

Data TypeInt
Unsigned Int
Char
Int
Int
Int
Int

Offset
0
2
4
12
16
20
24

Length
2
2
8
4
4
4
4

Int
Double

28
32

4
8*3

Float
Float

56
60

4
4

Copyright © 2018 Open Geospatial Consortium

Description
Light Source Record Opcode 101
Length - length of the record
7 char ASCII ID; 0 terminates
Reserved
Index into light palette
Reserved
Flags (bits, from left to right)
0 = Enabled
1 = Global
2 = Reserved
3 = Export
4 = Reserved
5-31 = SpareReserved
Position (for Local or Spot lights only) (x, y,z)
Yaw (azimuth for Infinite or Spot lights only)
Pitch (elevation for Infinite or Spot lights
only)

6-184

Road Segment Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider
Road Segment Records.
A road segment record is the primary record of a road segment node. It stores theattributes used to create and modify a road segment. The children of the road node
represent the geometry and paths of the road and should not be manually edited. Any
modification invalidates the road segment.
Data TypeInt
Unsigned Int
Char

Offset024Road Segment Record

Length228Description
Road Segment Opcode 87
Length of record
7 char ASCII ID; 0 terminates

Road Construction Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider
Road Construction Records.
A road construction record is the primary record of a road construction node. It
supersedes the Road Segment Record described previously. It is created by the Pathfinder
option of MultiGen II Pro v1.5 as well as the Road Tool option beginning with Creator
v2.1. It stores the parameters defining the road path construction for one road section. In
practice, the children of the road construction node usually represent the geometry andpaths of the road section. Although every field in the road construction record may be
modified, this data makes the most sense when it is kept in sync with the geometry that iscreated from it. Therefore, typical usage will be read-only access from applications able
to analyze the road surface from this given data.
The Road type field dictates how the following fields define the current road section. For
all road types, the Entry and Exit control points lie on the boundaries of the road section.
The Alignment control point is only necessary for the Curve type as it defines ahorizontal tangent with the other control points.
Other fields particular to the Curve type are the horizontal curve parameters. The
horizontal components of the Curve type start and end with spiral transitions of specified
lengths. An Arc Radius length is used to define the constant curve area. The
Superelevation is specified in a rise over run slope measured laterally across the road forthe maximum banking which is used throughout the constant curve component. The
banking transitions along the spiral sections in one of three ways defined by the Spiraltype field.
Both the Curve and Hill types may have a vertical curve component defined by theremaining fields. Slopes are given at both the entry and exit of the section. If the given
slopes don't intersect within the road segment then two vertical parabolas are constructed
instead of one, and the Additional vertical parabola flag is set. Note that this flag’s value
is only valid when the Road Tools version field is 3 or later. This flag may also be set
when convergence of the slopes creates a vertical curve length less than Minimum curve

Copyright © 2018 Open Geospatial Consortium

6-185

length. Otherwise, Vertical curve length is used to define the horizontal distance coveredby the single parabola vertical curve.

Data TypeInt
Unsigned Int
Char
Char
Int

Offset
0
2
4
12
16

Int
DoubleDoubleDoubleDoubleDoubleDouble

20
24
48
72
96
104
112

Road Construction Record
Length
2
2
8
4
4

4
8*3
8*3
8*3
8
8
8

Copyright © 2018 Open Geospatial Consortium

Description
Road Construction Opcode 127
Length of record
7 char ASCII ID; 0 terminates
Reserved
Road type
0 = Curve
1 = Hill
2 = StraightRoad Tools version
Entry control point (x, y, z)
Alignment control point (x, y, z)
Exit control point (x, y, z)
Arc radius
Entry spiral length
Exit spiral length

6-186

Road Construction Record (Continued)

Data TypeDoubleInt

Offset120
128

Length8
4Int
DoubleDoubleDoubleDouble

132
136
144
152
160

4
8
8
8
8

Description
Superelevation
Spiral type
0 = Linear with length
1 = Linear with angle
2 = Cosine with length
Additional vertical parabola flag
Vertical curve length
Minimum curve length
Entry slope
Exit slope

Road Path Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider
Road Path Records.
A road path record is the primary record of a road path node. A road path node is a childof a road segment node. It describes a lane of the parent road segment. The child of aroad path node is a face node whose vertices provide the coordinates of the center of thelane.
Road path record attributes may also be written to an ASCII file for easy access by theapplication. The format of the file is described in “Road Path Files,” page 99.

Road Path Record

Data TypeInt
Unsigned Int
Char
Int
Char
DoubleBooleanInt

Offset
0
2
4
12
16
136
144
148

Length
2
2
8
4
120
8
4
4

Int

152

480

Copyright © 2018 Open Geospatial Consortium

Description
Road Path Opcode 92
Length of record
7 char ASCII ID; 0 terminates
Reserved
Path name; 0 terminates
Speed limit
No passing
Vertex normal type
0 = Up-vector
1 = Heading, Pitch, Roll
Reserved

6-187

Clip Region Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider
Clip Region Records.
A clip region record is the primary record of a clip node. It defines those regions in 3D
space in which drawing occurs. Clip regions only clip the geometry below the clip nodein the hierarchy.
The coordinates create a four-sided face that defines the clip region in space. Planes areformed along the edges of the four-sided face normal to the face; a fifth plane clips theback side of the face.

Data TypeInt
Unsigned Int
Char
Int
Int
Char

Offset
0
2
4
12
16
18

Length
2
2
8
4
2
5

Char
DoubleDoubleDoubleDoubleDouble

23
24
48
72
96
120

1
8*3
8*3
8*3
8*3
8*20

Clip Region Record

Description
Clip Region Opcode 98
Length of record
7 char ASCII ID; 0 terminates
Reserved
Reserved
Flags for enabling the individual clip planes
Char 0 is flag for edge defined by coordinate 0
and 1Char 1 is flag for edge defined by coordinate 1
and 2
Char 2 is flag for edge defined by coordinate 2
and 3
Char 3 is flag for edge defined by coordinate 3
and 0Char 5 is flag for plane that clips the half spacebehind the clip region
Reserved
1st coordinate defining the clip region (x, y, z)
2nd coordinate defining the clip region (x, y, z)
3rd coordinate defining the clip region (x, y, z)
4th coordinate defining the clip region (x, y, z)
Five plane equation coefficients (ax + by +cz + d)
Coefficients are ordered:a0, a1, a2, a3, a4
b0, b1, b2, b3, b4
c0, c1, c2, c3, c4
d0, d1, d2, d3, d4

Copyright © 2018 Open Geospatial Consortium

6-188

Text Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider
Text Records.
The text record is the primary record of the text node. Text draws a string of data using a
specified font. The record specifies the visual characteristics of the text and formatting
information.
The actual string for the text is stored in the comment record immediately following. The
format of the text record is:

Data TypeInt
Unsigned Int
Char
Int
Int
Int

Offset
0
2
4
12
16
20

Length
2
2
8
4
4
4

Int

24

4

Int

28

4

Double
Int
Int
Int

32
40
44
64

8
4
4*5
4

Int
Int
Int
Int
Int
Int
Int
Int
Int
Int

68
72
76
80
84
88
92
96
100
104

4
4
4
4
4
4
4
4
4
4*2

Copyright © 2018 Open Geospatial Consortium

Text Record

Description
Text Opcode 95
Length of record
7 char ASCII ID; 0 terminates
Reserved
ReservedType-1 = Static
0 = Text String
1 = Float
2 = Integer
Draw type
0 = Solid
1 = Wireframe and close
2 = Wireframe
3 = Surround with wireframe in alternate color
Justification
0 = Left
1 = Right
2 = Center
Floating point value
Integer value
Reserved
Flags (bits, from left to right)
0 = Boxable (Unused)
1-31 = Spare
Color
Color 2 (Unused)
Material
Reserved
Maximum number of lines (Unused)
Maximum number of characters
Current length of text (Unused)
Next line number available (Unused)Line number at top of display (Unused)
Low/high values for integers

6-189

DoubleDoubleDouble
Char
Int
Int
Int
Int
Int
Int

112
128
152
176
296
300
304
308
312
316

8*2
8*3
8*3
120
4
4
4
4
4
4

Low/high values for floats
Lower-left corner of rectangle around text (x, y, z)
Upper-right corner of rectangle around text (x, y, z)
Font name
Draw vertical
Draw italic
Draw bold
Draw underline
Line style
Reserved

Switch Record
A switch record is the primary record of a switch node. A switch represents a set ofmasks that control the display of the switch’s children.
Each mask contains one bit for each child of the switch. Each mask bit indicates that thecorresponding child is selected (1) or deselected (0). Each mask selects some, none, or allof the children for display according to the state of the mask bits.
Both the switch children and mask bits begin counting from 0. Therefore the selection
state, for a particular switch child is derived from a given mask with the following
calculation:mask_bit = 1 << (child_num % 32)
mask_word = mask_words [mask_num * num_words + child_num / 32]
child_selected = mask_word & mask_bit
The current mask value is an index into the set of masks and indicates the selected mask.
The masks of a switch node can be named. These names are stored in the ancillary
record, indexed string record. See “Indexed String Record” on page 53.

Switch Record

Data Type

OffsetLengthDescription

Int
Unsigned
Int
Char

0
2

2
2

Switch Opcode 96
Length of record

4

8

Int
Int
Int
Int

12
16
20
24

4
4
4
4

7 char ASCII ID; 0
terminates
Reserved
Current mask
Number of masks
Number of words per mask
- the number of 32 bit words
required for each mask,
calculated as follows:(number of children / 32) +X
where X equals:
0 if (number of children

Copyright © 2018 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü
ü


ü
ü
ü

6-190

modulo 32) is zero
1 if (number of children
modulo 32) is nonzero
UnsignedInt

28

Variable

Copyright © 2018 Open Geospatial Consortium

Mask words.
The length (in bytes) can becalculated as follows:
Number of words per mask
* Number of masks * 4
bytes

ü

6-191

CAT Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider CAT

Records.

A continuously adaptive terrain (CAT)record is the primary record of a CAT
node. A continuously adaptive terrainskin is a hierarchical triangle meshdesigned for high fidelity, real-timeviewing. A CAT skin is represented in
OpenFlight by a record stream consistingof: a CAT record, a set of CAT data
records, a push record, the CAT
hierarchy and geometry, and a pop
record. CAT hierarchy and geometry isrepresented by standard OpenFlight
constructs of LOD’s, groups, externalreferences, faces, and vertices.

Copyright © 2018 Open Geospatial Consortium

6-192

CAT Record

Data TypeInt
Unsigned Int
Char
Int
Int
Int

Offset
0
2
4
12
16
20

Length
2
2
8
4
4
1

Int

21

1

Int
Unsigned Int
Unsigned Int
Int
Int
Int
Int
Int
Int
Int
Int
Unsigned Int
Unsigned Int

22
24
26
28
30
32
34
36
40
48
50
52
56

2
2
2
2
2
2
2
4
4*2
2
2
4
4

Copyright © 2018 Open Geospatial Consortium

Description
CAT Opcode 115
Length - length of the record
7 char ASCII ID; 0 terminates
Reserved
IR color code
Draw type
0 = Hidden, don’t draw
1 = Draw solid, no backface
2 = Draw wireframe
Texture white = if TRUE, draw textured face
white
Reserved
Color name index
Alternate color name index
Detail texture pattern index, -1 if none
Texture pattern index, -1 if none
Material index, -1 if none
Surface material code (for DFAD)
IR material code
Reserved
Texture mapping index
Reserved
Primary color index
Alternate color index

6-193

CAT Record (Continued)

Data TypeInt
DoubleInt

Offset60
64
72

Length
4
8
4

Int

76

4

Description
Reserved
Reserved
Flags (bits, from left to right)
0 = No color
1 = No alternate color
2-31 = SpareReserved

Extension Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider
Extension Records.
An extension node record is the primary record of an extension node. It introduces a user
defined node type that is defined by an extension site that utilizes the extensibility of the
OpenFlight format. It specifies the site information for a third party record whichcontains additional data that is not represented by the standard OpenFlight records. The
content of the data itself is transparent to users other than the extension site. The data canbe accessed by the combination of the OpenFlight API and the data dictionary defined by
the extension site.
The relationship of an extension node relative to other hierarchical nodes is defined by
the standard push and pop control records. For more information about extensions, pleaserefer to the “OpenFlight API User’s Guide, Level 3: Extensions”.
The extension record (Opcode 100) may also introduce new attributes to existing nodes(See “Extension Attribute Record” on page 64.)

Extension Record

Data TypeInt
Unsigned Int
Char
Char

Offset0
2
4
12

Length
2
2
8
8

Int
Int
Unsigned Int
Char

20
21
22
24

1
1
2
VariesCopyright © 2018 Open Geospatial Consortium

Description
Extension Opcode 100
Length of the total extension record
7 char ASCII ID; 0 terminates
Site ID - Unique site name. 7 char ASCII ID;
0 terminates
Reserved
Revision - site specific
Record code - site specific
Extended data - site specific

6-194Curve Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider Curve

Records.

A curve record is the primary record of a curve node. A curve node represents one ormore curve segments joined together with at least G0 continuity. Let a curve segment be
defined by 4 geometric constraints. We will call these geometric constraints control
points in the curve record. The way the control points are grouped and used will be
discussed below.
Let each control point be a double precision 3D coordinate, P = (x, y, z).
Let the group of control points be (P0, P1,..., Pk).
The currently defined curve types are B-spline, Cardinal, and Bezier.
If the curve type is Bezier, P0, P1, P2, and P3 form the first curve segment. P3, P4, P5, andP6 form the next segment, and so on. Notice that the last control point in the first segment
becomes the first control point in the second segment.
If the curve type is either B-spline or Cardinal, P0, P1, P2, and P3 form the first curve
segment. P1, P2, P3, and P4 from the next segment, and so on. Notice that the second
control point in the first segment becomes the first control point in the second segment.
Note that the smoothness of the curve depends on how many times your renderer samples
the curve equation into piece-wise linear elements. In the MultiGen-Paradigm, Inc.
modeling environment, each curve segment is evenly sampled 11 times to produce 10lines per curve segment.

Curve Record

Data TypeInt
Unsigned Int
Char
Int
Int

Offset0
2
4
12
16

Length
2
2
8
4
4

Int
Char
Double

20
24
32

4
8
Variable

Copyright © 2018 Open Geospatial Consortium

Description
Curve Opcode 126
Length of the total curve record
7 char ASCII ID; 0 terminates
Reserved
Curve type
4 = B-spline
5 = Cardinal
6 = Bezier
Number of control points
Reserved
Coordinates of control points. Eachcoordinate is (x, y, z)
Coordinates are ordered:
cp0x, cp0y, cp0z,
cp1x, cp1y, cp1z,...
cpNx, cpNy, cpNz
where N is Number of control points - 1(Length = Number of control points * 3 * 8
bytes.)

6-195

Ancillary Records
Ancillary records follow node primary records. They contain supplementary attribute data for thenode they follow. Ancillary records are optional but must precede any control record, following
the node primary record, when present, as shown in this example:
GROUP
COMMENTLONG ID
PUSH
...
POP
In this example, the comment and long ID ancillary records apply to the group record. There is noorder dependency between ancillary records. The comment could appear before or after the long
ID record in the example above, but must appear before any control record.

Comment Record
A comment record is an ancillary record that contains text data that belongs to the preceding node
primary record. The text description is a variable length ASCII string terminated by a <nil>character.

Data Type

OffsetLengthInt
Unsigned
Int
Char

0
2

2
2

4

Length 4

Comment Record

Copyright © 2018 Open Geospatial Consortium

Description

Comment Opcode 31
Length - length of therecordText description of node; 0terminates

CDB OpenFlight
Reader

ü
ü
ü

6-196

Long ID Record
A long ID record is an ancillary record that contains the full name of the preceding node. It ispresent only when the name exceeds eight characters (seven characters plus a terminating <nil>character).

Note that the ID field found in third field of every primary OpenField record must
be unique. The ID itself can be in Short or Long form. In Short form, the ID islimited to a 7 char ASCII string. In Long form, the ID can be of up to (64K – 5)characters in length. The Long ID record, when present, replaces the 7 char string
found in the third of the primary record.
Long ID Record

Data Type

OffsetLengthDescription

Int
Unsigned
Int
Char

0
2

2
2

Long ID Opcode 33
Length - length of the record

4Length 4

ASCII ID of node; 0terminates

CDB OpenFlight
ReaderüüüIndexed String Record
An indexed string record is an ancillary record that contains an integer index followed by avariable length character string. In this way, arbitrary strings can be associated to indices in a general way.
Currently, indexed string records are only used in the context of switch nodes, for which they
represent the names of the masks contained in the switch node. The index specifies the mask
number for which the string specifies the name. Mask numbers start at 0. Not all masks are required to have names.

Indexed String Record

Data Type

OffsetLengthDescription

Int
Unsigned
Int
Unsigned
Int
Char

0
2

2
2

Indexed string Opcode 132
Length - length of the record

4

4

Index

ü

8

Length 8

ASCII string; 0 terminatesü

Copyright © 2018 Open Geospatial Consortium

CDB OpenFlight
Readerüü

6-197

Multitexture
OpenFlight supports eight textures per polygon or mesh as well as eight uv values per vertex. The
current texture information stored on the polygon is referred to as “the base texture” or “texture
layer 0”. Each additional texture is referred to as “texture layer N”. Therefore, to support eighttextures per polygon, a base texture is required as well as seven additional texture layers. Not alllayers are required. Nor is any mandate set forth requiring that layers be contiguous after the baselayer. The additional texture layers for each polygon, mesh, and vertex are represented in ancillary
records at the face, mesh and vertex primary node level as shown in the following example:

FACE
MULTITEXTURE
PUSH
VERTEX LISTUV LISTPOP
The records that are used to represent multitexture in the OpenFlight file are described in thefollowing sections.

Multitexture Record
The multitexture record is an ancillary record of face and mesh nodes. It specifies the texture layer
information for the face or mesh.

Data Type

OffsetLengthUnsigned Int
Unsigned Int
Int

0
2
4

2
2
4

Multitexture Record
Description

Multitexture Opcode 52
Length - length of the record
Attribute mask - Bit mask indicating
what kind of multitexture information
is present in this record. Bits are ordered from left to right and have thefollowing definitions:Bit #Description0
Has
Layer 1 - if set, multitexture
information for texture layer 1 ispresent.
1
Has Layer 2 - if set,
multitexture information for texture
layer 2 is present.
2
Has Layer 3 - if set,
multitexture information for texture
layer 3 is present.
3
Has Layer 4 - if set,
multitexture information for texture
layer 4 is present.

Copyright © 2018 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü
ü

ü

ü
ü
ü

6-198

4
Has Layer 5 - if set,
multitexture information for texture
layer 5 is present.
5
Has Layer 6 - if set,
multitexture information for texture
layer 6 is present.
6
Has Layer 7 - if set,
multitexture information for texture
layer 7 is present.
7-31 Spare
The following fields are repeated for each multitexture layer that is
specified as present by the bits set in the Attribute mask field above. Thismechanism allows for “sparse” multitexture layer information to be present
and does not require that the information present be contiguous.
Unsigned Int Varies
2
textureN - Texture index for texture
layer N
Unsigned Int Varies
2
effectN - Multitexture effect for
texture layer N
0 = Texture environment

Unsigned Int

Varies2

Unsigned Int

Varies2

1 = Bump map
2-100 = Reserved by MultiGenParadigm, Inc.
>100 = user (runtime) defined
mappingN - Texture mapping index
for texture layer N
dataN - Texture data for layer N. Thisis user defined.
For example, it may be used as a
blend percentage or color or any otherdata needed by the runtime todescribe texture layer N

Copyright © 2018 Open Geospatial Consortium

ü
ü
ü


ü
ü
ü
ü


ü
ü

6-199

UV List Record
The uv list record is an ancillary record of vertex nodes. This record (if present) always
follows the vertex list or morph vertex list record and contains texture layer information
for the vertices represented in the vertex list record it follows.

UV List Record

Data Type

OffsetLength Description

Unsigned Int
Unsigned Int
Int

0
2
4

2
2
4

UV List Opcode 53
Length - length of the record
Attribute mask - Bit mask
indicating what kind of multitexture information is present inthis record. Bits are orderedfrom left to right as follows:
Bit # Description0
Has Layer 1 - if set, uvs
for layer 1 are present
1
Has Layer 2 - if set,uvs for layer 2 are present
2
Has Layer 3 - if set,uvs for layer 3 are present
3
Has Layer 4 - if set,uvs for layer 4 are present
4
Has Layer 5 - if set,uvs for layer 5 are present
5
Has Layer 6 - if set,uvs for layer 6 are present
6
Has Layer 7 - if set,uvs for layer 7 are present
7-31 SpareCDB OpenFlight
Reader

ü
ü
ü

ü
ü
ü
ü
ü
ü
ü


The following fields are repeated for each vertex contained in the corresponding vertex
list or morph vertex list record.
If this uv list record follows a vertex list record, the following fields are repeated for eachlayer present (as specified by the bits set in Attribute mask).
Data Type
OffsetLengthFloat
4ui, N - Texture coordinate U for vertex i, layer N
Float
4vi, N - Texture coordinate V for vertex i, layer N
The number of vertices represented in the uv list record that follows a vertex list record
must be identical to the number of vertices contained in that vertex list record. This
number can also be calculated as follows:
Number of vertices = (Length - 8) / (8 * X), where X is the number of bits set in Attributemask.
If this uv list record follows a morph vertex list record, the following fields are repeatedfor each layer present (as specified by the bits set in Attribute mask).

Copyright © 2018 Open Geospatial Consortium

6-200Data Type
Float
Float
Float
Float

Offset4
4
4
4

Lengthu0i, N - Texture U for the 0% vertex i, layer N
v0i, N - Texture V for the 0% vertex i, layer N
u100i, N - Texture U for the 100% vertex i, layer N
v100i, N - Texture V for the 100% vertex i, layer N

Again, the number of vertices represented in the uv list record that follows a morph
vertex list record must be identical to the number of vertices contained in that morph
vertex list record. This number can also be calculated as follows:
Number of vertices = (Length - 8) / (16 * X), where X is the number of bits set in
Attribute mask.

ExampleConsider a triangular face (3 vertices) that contains morph vertex information and has
texture layers 1 and 3 defined. The following example shows the contents of the uv list
record corresponding to the morph vertex list record representing this triangle:
Data TypeopcodelengthuvmaskOffsetUnsigned Int
Unsigned Int
Unsigned Int

Length22
4

u0 1,1v0 1,1
u100 1,1v100 1,1
u0 1,3v0 1,3u100 1,3v100 1,3
u0 2,1v0 2,1
u100 2,1
v100 2,1
u0 2,3v0 2,3u100 2,3v100 2,3
u0 3,1v0 3,1
u100 3,1
v100 3,1
u0 3,3v0 3,3u100 3,3v100 3,3

Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float

8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8
8

Description
53 (UV List opcode).
200 (Length of the record)
1010 0000 0000 0000 (layers 1and 3 ON,
others OFF)
Texture U for the 0% vertex 1, layer 1.
Texture V for the 0% vertex 1, layer 1.
Texture U for the 100% vertex 1, layer 1.
Texture V for the 100% vertex 1, layer 1.
Texture U for the 0% vertex 1, layer 3.
Texture V for the 0% vertex 1, layer 3.
Texture U for the 100% vertex 1, layer 3.
Texture V for the 100% vertex 1, layer 3.
Texture U for the 0% vertex 2, layer 1.
Texture V for the 0% vertex 2, layer 1.
Texture U for the 100% vertex 2, layer 1.
Texture V for the 100% vertex 2, layer 1.
Texture U for the 0% vertex 2, layer 3.
Texture V for the 0% vertex 2, layer 3.
Texture U for the 100% vertex 2, layer 3.
Texture V for the 100% vertex 2, layer 3.
Texture U for the 0% vertex 3, layer 1.
Texture V for the 0% vertex 3, layer 1.
Texture U for the 100% vertex 3, layer 1.
Texture V for the 100% vertex 3, layer 1.
Texture U for the 0% vertex 3, layer 3.
Texture V for the 0% vertex 3, layer 3.
Texture U for the 100% vertex 3, layer 3.
Texture V for the 100% vertex 3, layer 3

Replicate Record

Copyright © 2018 Open Geospatial Consortium

6-201

A replicate record is an ancillary record of group, face, and light (string) point nodes. It
indicates the number of times the group, face, or light (string) point is instantiated. An
ancillary transformation record must also be present. The transformation is iteratively
applied to each instance to uniquely place it in the database.

Data Type

OffsetLengthInt
Unsigned
Int
Int
Int

0
2

2
2

4
6

2
2

Replicate Record
Description

Replicate Opcode 60
Length - length of therecordNumber of replications
Reserved

CDB OpenFlight
ReaderüüüRoad Zone Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider Road Zone

Records.

The road zone record is an ancillary record of the header node. It references a road zone
file that contains gridded elevation data. The format of the file is described in “Road
Zone Files,” page 101.
Data TypeInt
Unsigned Int
CharInt
DoubleDoubleDoubleDoubleDoubleInt
Int

Offset
0
2
4
124
128
136
144
152
160
168
172

Road Zone Record

Length
2
2
120
4
8
8
8
8
8
4
4

Description
Road Path Opcode 88
Length - length of the record
Zone file name; 0 terminates
Reserved
Lower-left x coordinate
Lower-left y coordinate
Upper-right x coordinate
Upper-right y coordinate
Grid interval
Number of posts along x axis
Number of posts along y axis

Transformation Records

CDB OpenFlight Readers: CDB-compliant OpenFlight readers consider only the Matrix
Transformation Records. The Rotate About Edge Record, Translate Record, Scale Record, Rotate
About Point Record, Rotate and/or Scale to Point Record, Put Record and General Matrix Record
are specific to the MultiGen Creator tool; as a result, CDB OpenFlight readers do not consider
them.
Transformation records may be ancillary records of most nodes. All hierarchical nodes
may be transformed except the header node. Some nodes may only be transformed

Copyright © 2018 Open Geospatial Consortium

6-202

implicitly, as part of some other operation, such as point replication within a light point
string.
There are several distinct types of transformation records. For a transformation applied to
any node, a matrix record is always present and represents the final (composite)transformation. When present, the transformation records that follow a matrix record
represent the individual transformations applied to the node. If an application only needs
the final transformation, the matrix record is sufficient and the transformation records
that follow the matrix record can be ignored. The records following the matrix record are
only needed by the application if it needs to decompose the transformation. The
MultiGen-Paradigm, Inc. modeling environment uses these records in order to allow themodeler to modify any of the discrete transformations applied to a node.
Again, each record that follows the matrix record represents a discrete transformation thathas been concatenated to form the composite matrix. Concatenation is done in the orderthat the records are encountered, using pre-multiplication.
Note: The final and general matrices are only single-precision, while the discrete

transformations are double-precision.

Data TypeInt
Unsigned Int
Float

Offset0
2
4

Length22
4*16Matrix Record

Description
Matrix Opcode 49
Length - length of the record
4x4 matrix, row major order

Rotate About Edge Record

Data TypeInt
Unsigned Int
Int
DoubleDoubleFloat
Int

Offset
0
2
4
8
32
56
60

Length
2
2
4
8*3
8*3
4
4

Description
Rotate About Edge Opcode 76
Length - length of the record
Reserved
First point on edge (x, y, z)Second point on edge (x, y, z)
Angle by which to rotate
Reserved

Data TypeInt
Unsigned Int
Int
DoubleDoubleOffset02
4
832

Length
2
2
4
8*3
8*3

Description
Translate Opcode 78
Length - length of the record
Reserved
From point (x, y, z)
Delta to translate (x, y, z)

Copyright © 2018 Open Geospatial Consortium

Translate Record

6-203

Data TypeInt
Unsigned Int
Int
Double
Float
Float
Float
Int

Offset
0
2
4
8
32
36
40
44

Length
2
2
4
8*3
4
4
4
4

Data TypeInt
Unsigned Int
Int
Double
Float
Float
Float
Float

Offset
0
2
4
8
32
36
40
44

Length
2
2
4
8*3
4
4
4
4

Scale Record

Description
Scale Opcode 79
Length - length of the record
Reserved
Scale center (x, y, z)
x scale factor
y scale factor
z scale factor
Reserved

Rotate About Point Record

Description
Rotate About Point Opcode 80
Length - length of the record
Reserved
Rotation center point (x, y, z)i, axis of rotationj, axis of rotationk, axis of rotation
Angle by which to rotate

Rotate and/or Scale to Point Record

Data TypeInt
Unsigned Int
Int
DoubleDoubleDouble
Float
Float
Float
Int

Offset
0
2
4
8
32
56
80
84
88
92

Length
2
2
4
8*3
8*3
8*3
4
4
4
4

Description
Rotate and/or Scale Opcode 81
Length - length of the record
Reserved
Scale center (x, y, z)
Reference point (x, y, z)
To point (x, y, z)Overall scale factor
Scale factor in direction of axis
Angle by which to rotate
Reserved

Data TypeInt
Unsigned Int
Int
DoubleDoubleDoubleDoubleDoubleDoubleOffset
0
2
4
8
32
56
80
104
128

Length
2
2
4
8*3
8*3
8*3
8*3
8*3
8*3

Description
Put Opcode 82
Length - length of the record
Reserved
From point origin (x, y, z)
From point align (x, y, z)
From point track (x, y, z)
To point origin (x, y, z)
To point align (x, y, z)
To point track (x, y, z)

Put Record

General Matrix Record

Copyright © 2018 Open Geospatial Consortium

6-204

Data TypeInt
Unsigned Int
Float

Offset0
2
4

Length22
4*16

Description
General Matrix Opcode 82
Length - length of the record
4x4 matrix, row major order

Vector Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider Vector

Records.

A vector record is an ancillary record of the (pre v15.4) face node. Its only use is toprovide the direction vector for old-style unidirectional and bidirectional light point faces.
Data TypeInt
Unsigned Int
Float
Float
Float

Offset024812Vector Record

Length22444Description
Vector Opcode 50
Length - length of the record
i component
j component
k component

Bounding Volume Records
Bounding volumes are ancillary records for group nodes only. They generally encompass
all the geometry of a group’s children. A bounding volume may describe a box, sphere,
cylinder, convex hull or histogram.
The center coordinate of a bounding volume is stored as a separate record. The
orientation of a bounding volume is also stored as a separate record. The convex hull data
is represented by a sequence of triangles forming the convex hull around the groupgeometry.
Applications may use the bounding volume information with culling and collision
detection algorithms.

Copyright © 2018 Open Geospatial Consortium

6-205

Bounding Box Record

Data Type

OffsetLengthDescription

Int
Unsigned
Int
Int
Double0222Bounding Box Opcode 74
Length - length of the record

4
8

4
8

Double16

8

Double24

8

Double32

8

Double40

8

Double48

8

Reserved
x coordinate of lowest
cornery coordinate of lowest
cornerz coordinate of lowest
cornerx coordinate of highest
cornery coordinate of highest
cornerz coordinate of highest
cornerBounding Sphere Record

Data Type

OffsetLengthDescription

Int

0

2

Unsigned
Int
Int
Double22

Bounding Sphere Opcode
105
Length - length of the record

4
8

4
8

Reserved
Radius of the sphere

Bounding Cylinder Record

Data Type

OffsetLengthInt

02

Unsigned
Int
Int
DoubleDouble22

Bounding Cylinder Opcode
106
Length - length of the record

4
8
16

4
8
8

Reserved
Radius of the cylinder base
Height of the cylinder

Copyright © 2018 Open Geospatial Consortium

Description

CDB OpenFlight
Reader

ü
ü


ü
ü
ü
ü
ü
ü
CDB OpenFlight
Readerüüü
CDB OpenFlight
Reader

ü
ü


ü
ü

6-206

Data
Type
Int

Bounding Convex Hull Record

OffsetLength02

Description

Bounding Convex Hull
Opcode 107
Unsigned 2
2
Length - length of theInt
recordInt
4
4
Number of triangles
The following fields are repeated for each triangle represented
in the convex hull data.
In the fields listed below, N ranges from 0 to Number oftriangles-1.
Double8+(N*72) 8
x coordinate of vertex 1 oftriangleN
Double16+(N*72) 8
y coordinate of vertex 1 oftriangleN
Double24+(N*72) 8
z coordinate of vertex 1 oftriangleN
Double32+(N*72) 8
x coordinate of vertex 2 oftriangleN
Double40+(N*72) 8
y coordinate of vertex 2 oftriangleN
Double48+(N*72) 8
z coordinate of vertex 2 oftriangleN
Double56+(N*72) 8
x coordinate of vertex 3 oftriangleN
Double64+(N*72) 8
y coordinate of vertex 3 oftriangleN
Double72+(N*72) 8
z coordinate of vertex 3 oftriangleN

Copyright © 2018 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü
ü
ü

ü
ü
ü
ü
ü
ü
ü
ü
ü

6-207

Bounding Histogram Record

Data Type

OffsetLengthDescription

Int

0

2

Unsigned
Int
Char

2

2

4

Variable

Bounding Histogram
Opcode 119
Length - length of therecordThe contents of this record
is reserved for use by MultiGen-Paradigm.

Data Type

OffsetLengthDescription

Int

0

2

Unsigned
Int
Int
DoubleDoubleDouble22

Bounding Volume Center
Opcode 108
Length - length of the record

4
8
16
24

4
8
8
8

Reserved
x coordinate of centery coordinate of centerz coordinate of center

Bounding Volume Center Record

CDB OpenFlight
Reader

CDB OpenFlight
Reader

ü
ü


ü
ü
ü

Bounding Volume Orientation Record

Data Type

OffsetLengthDescription

Int

0

2

Unsigned
Int
Int
DoubleDoubleDouble22

Bounding Volume
Orientation Opcode 109
Length - length of the record

4
8
16
24

4
8
8
8

Reserved
Yaw angle
Pitch angle
Roll angle

CDB OpenFlight
Reader

ü
ü


ü
ü
ü

CAT Data Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider CAT

Records.

The CAT data records contain the information needed to reconstruct a Continuously
Adaptive Terrain skin from its OpenFlight representation. They provide the information
which links faces between levels of detail within a CAT skin. CAT data is stored as a key
table with an opcode of 116. For specific detail please refer to “Key Table Records” onpage 76.
Each CAT data record describes how a face within a CAT skin is related to faces at the

Copyright © 2018 Open Geospatial Consortium

6-208

next finer level of detail. The coarsest level of detail is level zero. The next finer level ofdetail is one, and so forth. Each data record is stored in the key table using an ordinal key,
counting up from zero. The face node ID is stored in the data record, thereby providing
the cross reference to the OpenFlight face node that represents it.
In OpenFlight, each CAT level of detail is parented by a LOD node. Each CAT triangle
strip is parented by a group node.

CAT Data Header Record

Data TypeInt
Unsigned Int
Int

Offset0
2
4

Length
2
2
4

Int
Int

8
12

4
4

Description
CAT Data Opcode 116
Length - length of the record
Subtype
1 = indicates this record is a key table header
Max number - maximum number of face keys
Actual number - actual number of face keys

CAT Data Header Record (Continued)

Data Type
OffsetLengthDescription
Int
16
4
Total length of packed face dataInt
20
4
Reserved
Int
24
4
Reserved
Int
28
4
Reserved
The following fields are repeated for each face record represented in the CAT data.
In the fields listed below, N ranges from 0 to Actual number - 1.
Int
32+(N*12) 4
Face indexN - index of face N
Int
36+(N*12) 4
ReservedN - reserved space for face N
Int
40+(N*12) 4
Face data offsetN - offset for face data record N in the
CAT data.
Note: This offset is measured relative to the Packed
face data field in the CAT data face record described
below.

Copyright © 2018 Open Geospatial Consortium

6-209Data TypeInt
Unsigned Int
Int

Offset0
2
4

CAT Data Face Record

Length224Description
CAT Data Opcode 116
Length - length of the record
Subtype2 = indicates this record is a key data record
Int84
Total length of all packed face records
The following fields constitute one face record and are repeated for each face record represented
in the CAT data. In the fields listed below, N ranges from 0 to Actual number - 1. Actual
number is from the CAT data header record.
Int
Varies4
LODN - Level of detail to which this face N belongs.
Int
Varies4Child index 1N - The 1st child (within this table) of faceN, or -1 for no face.
Int
Varies4Child index 2N - The 2nd child (within this table) offace N, or -1 for no face.
Int
Varies4Child index 3N - The 3rd child index (within this table)of face N, or -1 for no face.
Int
Varies4Child index 4N - The 4th child index (within this table)of face N, or -1 for no face.
Int
Varies4
ID LengthN - length of face node ID string which
follows
Char
VariesVariesIDN - ASCII ID of the face to which this record applies.

Copyright © 2018 Open Geospatial Consortium

6-210

Extension Attribute Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider Extension

Attribute Records.

The extension attribute record is an ancillary record defined by an extension site thatutilizes the extensibility of the OpenFlight format. It specifies the site information of athird party extended record which describes additional data that is not represented by thestandard OpenFlight records. The data itself is transparent to users other than theextension site. The data can be accessed by the combination of the OpenFlight API andthe data dictionary defined by the extension site.
Any hierarchical node can contain extension attribute records. Extension attributes are
introduced by an push extension control record and concluded by a pop extension control
record.
The extension record (Opcode 100) may also introduce a new node type (See “Extension
Record” on page 51.)
Data TypeInt
Unsigned Int
Char
Char
Int
Int
Unsigned Int
Char

Offset
0
2
4
12
20
21
22
24

Extension Attribute Record
Length
2
2
8
8
1
1
2
Variable

Description
Extension Opcode 100
Length of the total extension record
7 char ASCII ID; 0 terminates
Site ID - Unique site nameReserved
Revision - site specific
Record code - site specific
Extended data - site specific

Continuation Record
All OpenFlight records begin with a 4 byte sequence. The first two bytes identify therecord (opcode) and the second two bytes specify the length of the record. Given thisregular record structure, the length of all OpenFlight records is limited to the largest
value that can be encoded with 2 bytes or 16 bits (65535). For fixed-size records, thismaximum size is sufficient. For variable-size records, this limitation is addressed with thecontinuation record which is described in this section.
The continuation record accommodates variable size records in the OpenFlight Scene
Description. The continuation record is used to “continue” a record in the OpenFlight filestream. It appears in the stream immediately following the record that it “continues” (therecord that is being continued will be referred to as the “original” record). In this way, thecontinuation record is an ancillary record to any other record type. The data contained in
the continuation record is defined by the original record and is assumed to be directly
appended onto the content of the original record.
Note:

Multiple continuation records may follow a record, in which case allcontinuation records would be appended (in sequence) to the original record.

Copyright © 2018 Open Geospatial Consortium

6-211

Continuation Record

Data Type

OffsetLengthDescription

Unsigned
Int
UnsignedInt
Varies

0

2

2

2

4

Length4

Continuation Record
Opcode 23
Length - length of therecordDepends on the originalrecord. The contents of thisfield are to be appended
directly to the end of theoriginal record contents(before the original record
contents are parsed)

CDB OpenFlight
ReaderüüüIn theory, any OpenFlight record may be “continued”, but in practice only variable length
records, whose length is likely to exceed 65535 bytes, are. Following is a list of thevariable length OpenFlight record types to which the continuation record is likely toapply:•“Extension Record” on page 51•“Name Table Record” on page 71•“Local Vertex Pool Record” on page 30•“Mesh Primitive Record” on page 32

Example: In the following example, the color name table is “too” big to fit in 65535
bytes so the primary palette record, NAME TABLE, is followed by one (or more)
CONTINUATION records. The contents of each of the continuation records is appended
to the contents of the name table record before the name table data is parsed.
NAME TABLE
CONTINUATIONCONTINUATION

Copyright © 2018 Open Geospatial Consortium

6-212

Palette Records
Palette records are ancillary records of the header node. They contain attribute data
globally shared by other nodes in the database. Other nodes, such as face nodes, reference
the palette data by index.
Individual palettes contain resources such as vertex, material, light source, texture
pattern, and line style definitions.
Vertex Palette Records
Double precision vertex records are stored in a vertex palette for the entire database.
Vertices shared by one or more geometric entities are written only one time in the vertex
palette. This reduces the overall size of the OpenFlight file by writing only “unique”
vertices. Vertex palette records are referenced by faces and light points via vertex list andmorph vertex list records. See “Vertex List Record” on page 39 and “Morph Vertex List
Record” on page 39 for more information.
Note:
The vertices referenced by mesh nodes are not contained in vertex paletterecords. Instead, they are contained in local vertex pool records. See “Local Vertex Pool
Record” on page 30. The vertex palette record signifies the start of the vertex palette. It
contains a one word entry specifying the total length of the vertex palette, which is equal
to the length of this header record plus the length of the following vertex records. The
individual vertex records follow this header, each starting with its own opcode. The
length field in the vertex palette record makes it possible to skip over vertex records until
the data is actually needed.

As stated above, vertices may be shared, and are accessed through the vertex and morph
vertex list records following each face record. A face may contain all morph vertices, allnon-morph vertices, or a mixture of both. Thus there can be one or more list records
following each face. Consecutive vertices with the same type are grouped together within
a list record. The length of each list record is determined by the number of consecutive
vertices of each type. For each vertex, there is a one word field pointing to its vertex
record in the vertex palette. Since this offset includes the length of the vertex paletterecord, the value of the first pointer is 8.
Data Type

OffsetInt

Vertex Palette Record
LengthDescription

02

Unsigned Int

2

2

Int

4

4

Vertex Palette Opcode
67
Length - length of therecordLength of this record
plus length of the vertex
paletteCDB OpenFlight
ReaderüüüThe vertex palette record is immediately followed by vertex records. Each vertex record
contains all the attributes of a vertex that has been referenced one or more times in the
database.
The Color name index references a name in the color name palette.
The Hard edge flag indicates this vertex starts an edge that is to be preserved by polygon

Copyright © 2018 Open Geospatial Consortium

6-213

reduction or decimation algorithms.
The Normal frozen flag indicates the normal is not to be updated by shading or lighting
algorithms.
The No color flag indicates the vertex does not have a color. If set, neither the Packed
color or Vertex color index fields are defined.
When a vertex has a color (the No color flag is not set), the Packed color field is always
specified (regardless of the value of the Packed color flag) and contains the red, green,
blue and alpha color components. For alpha, 0 represents fully transparent, 255 fully
opaque. If the Packed color flag is set, the Vertex color index field will be undefined.
Here are some examples that show how vertex palette records can represent vertex
colors:PackedColor
Flag

PackedColor

VertexColorIndex

Result0a, g, b, r

N

Vertex color index and Packed color attributes
are both specified.
a, b, g, r specify the vertex color components.
g, b, r components match those of color index Nin palette.
Vertex color index attribute is not specified,
only packed color.
a, b, g, r specify the vertex color components.

1

a, g, b, r

Not defined

Data Type

OffsetLengthDescription

Int

0

2

Unsigned
Int
Unsigned
Int
Int

2

2

4

2

Vertex with Color Opcode
68
Length - length of therecordColor name index

62Vertex with Color Record

Double
Int

8
32

8*3
4

Unsigned
Int

36

4

Copyright © 2018 Open Geospatial Consortium

Flags (bits, from left toright)
0 = Start hard edge
1 = Normal frozen
2 = No color
3 = Packed color
4-15 = Spare
Vertex coordinate (x, y, z)
Packed color (a, b, g, r) always specified when thevertex has color
Vertex color index - valid
only if vertex has color andPacked color flag is not set

CDB OpenFlight
Reader

ü
ü
ü
ü

ü

ü
ü

ü
ü
ü

6-214

Data Type

Vertex with Color and Normal Record
OffsetLengthDescription

Int

0

2

Unsigned
Int
Unsigned
Int
Int

2

2

4

2

Vertex with Color andNormal Opcode 69
Length - length of therecordColor name index

62

Double
Float
Int

8
32
44

8*3
4*3
4

Unsigned
Int

48

4

Int

52

4

Data Type

OffsetInt
Unsigned
Int
Unsigned
Int
Int

DoubleFloat
Int

Flags (bits, from left toright)
0 = Start hard edge
1 = Normal frozen
2 = No color
3 = Packed color
4-15 = Spare
Vertex coordinate (x, y, z)
Vertex normal (i, j, k)
Packed color (a, b, g, r) always specified when thevertex has color
Vertex color index - valid
only if vertex has color andPacked color flag is not set
Reserved

Vertex with Color and UV Record
LengthDescription

0

2

2

2

4

2

Vertex with Color and UVOpcode 71
Length - length of therecordColor name index

6

2

8
32
40

8*3
4*2
4

Copyright © 2018 Open Geospatial Consortium

Flags (bits, from left toright)
0 = Start hard edge
1 = Normal frozen
2 = No color
3 = Packed color
4-15 = Spare
Vertex coordinate (x, y, z)
Texture coordinate (u, v)
Packed color (a, b, g, r) always specified when the

CDB OpenFlight
Reader

ü
ü
ü
ü

ü

ü
ü

ü
ü
ü
ü

CDB OpenFlight
Reader

ü
ü
ü
ü

ü

ü
ü

ü
ü
ü

6-215

vertex has color
Unsigned
Int

44

4

Vertex color index - valid
only if vertex has color andPacked color flag is not set

üVertex with Color, Normal and UV Record

Data Type

OffsetLengthDescription

Int

0

2

Unsigned
Int
Unsigned
Int
Int

2

2

4

2

Vertex with Color, Normal
and UV Opcode 70
Length - length of therecordColor name index

62

Double
Float
Float
Int

8
32
44
52

8*3
4*3
4*2
4

Unsigned
Int

56

4

Int

60

4

Copyright © 2018 Open Geospatial Consortium

Flags (bits, from left toright)
0 = Start hard edge
1 = Normal frozen
2 = No color
3 = Packed color
4-15 = Spare
Vertex coordinate (x, y, z)
Vertex normal (i, j, k)
Texture coordinate (u, v)
Packed color (a, b, g, r) always specified when thevertex has color
Vertex color index - valid
only if vertex has color andPacked color flag is not set
Reserved

CDB OpenFlight
Reader

ü
ü
ü
ü

ü

ü
ü

ü
ü
ü
ü
ü


6-216

Color Palette Record
The color palette record contains all colors indexed by face and vertex nodes in the
database.
The color record is divided into two sections: one for color entries and one for color
names. All color entries are in 32-bit packed format (a, b, g, r). Each color consists of red,green, and blue components of 8 bits each, plus 8 bits reserved for alpha (future).
Currently alpha is always 0xff (fully opaque). The color entry section consists of 1024
ramped colors of 128 intensities each.
The color name section may or may not be included. If the length of the color paletterecord is greater than 4228, then you can assume that the color name section is included.
When it is present, the color name section consists of a header followed by 0 or morecolor name entries. The header contains the number of names in the palette. If this value
is 0, there are no names following in the palette. Each color name entry contains the namestring, pointer to the associated color entry, and other reserved information. The namefield is a variable-length, null-terminated ASCII string, with a maximum of 80 bytes.

Color Palette Record

Data Type

OffsetLengthDescription

Int
Unsigned
Int
Char
Int

0
2

2
2

Color Palette Opcode 32
Length - length of the record

4
132

128
4

Int

136

4

etc.
Int

...
4224

...
4

Reserved
Brightest RGB of color 0,
intensity 127 (a, b, g, r)
Brightest RGB of color 1,
intensity 127 (a, b, g, r)

Brightest RGB of color 1023,
intensity 127 (a, b, g, r)
As stated above, if the length of the color palette record is greaterthan 4228, then it also contains a color name section as shown below:
Int
4228
4
Number of color names
The following fields are repeated for each color name entry present in
the color palette record.
In the fields listed below, N ranges from 0 to Number of color names- 1.
Unsigned
Varies2
LengthN - length of color nameInt
subrecord N. This length is thetotal length of this field plus
the length of the next 3 fields
plus the length of the Color
nameN field.
Int
Varies2
ReservedN - reserved space forcolor name N

Copyright © 2018 Open Geospatial Consortium

CDB
OpenFlight
Reader

ü
ü


ü
ü
ü
ü
ü
ü

ü



6-217

Int

Varies2

Int

Varies2

Char

VariesLengthN8

Color indexN - index of color
in palette corresponding tocolor name N
ReservedN - reserved space forcolor name N
Color nameN - color name N; 0
terminates, max 80 bytesüüName Table Record
The name table contains a lookup table of names referenced within the database. These
names are typically used as attributes (e.g., color name index in the face record). The
primary benefit of the name table is to allow name referencing, so each name string isonly stored once. Each name entry in the name table contains fields for the its length,
index, and string. The name index is used by the database to reference names within thetable. The name string is a variable-length, null-terminated ASCII string, with amaximum of 80 bytes.

Data Type

OffsetInt
0
Unsigned
2
Int
Int
4
Unsigned
8
Int
Name Table Entry 0Int
10
Unsigned
14
Int
Char
16

LengthName Table Record

2
2
4
2

Name Table Opcode 114
Length - length of therecordNumber of names
Next available name index

CDB OpenFlight
Readerüüü

Length0 - length of entry 0
Name index0 - index
corresponding to entry 0
Name string0 - name forentry 0; 0 terminates.
Variable length, maximumof 80 charsüü

Length1 - length of entry 1
Name index1 - index
corresponding to entry 1
VariesName string1 - name forentry 1; 0 terminates.
Variable length, maximumof 80 chars
...
...
...
...
Name Table Entry N, where N is Number of names - 1
Int
Varies4
LengthN - length of entry N
Unsigned
Varies2
Name indexN - index
Intcorresponding to entry NüüName Table Entry 1
Int
VariesUnsigned
VariesInt
Char
Varies4
2

Description

Varies4
2

Copyright © 2018 Open Geospatial Consortium

ü

ü

ü
ü

6-218

Char

VariesVariesName stringN - name forentry N; 0 terminates.
Variable length, maximumof 80 chars

üMaterial Palette Record
The material palette contains descriptions of materials used while drawing geometry. It is
composed of an arbitrary number of material palette records. The material palette records
must follow the header record and precede the first push.
The appearance of a face or mesh in OpenFlight is a combination of the geometry (faceor mesh) color and the material properties. The geometry color is factored into thematerial properties as follows:
Ambient:
The displayed material's ambient component is the product of the ambient component of
the material and the geometry color:
Displayed ambient (red) = Material ambient (red)* geometry color (red)Displayed ambient (green) = Material ambient (green)* geometry color (green)
Displayed ambient (blue) = Material ambient (blue)* geometry color (blue)
For example, suppose the material has an ambient component of {1.0,.5,.5} and thegeometry color is {100, 100, 100}. The displayed material has as its ambient color {100,50, 50}.
Diffuse:As with the ambient component, the diffuse component is the product of the diffuse
component of the material and the geometry color:
Displayed diffuse (red) = Material diffuse (red)* geometry color (red)Displayed diffuse (green) = Material diffuse (green)* geometry color (green)
Displayed diffuse (blue) = Material diffuse (blue)* geometry color (blue)
Specular:
Unlike ambient and diffuse components, the displayed specular component is taken
directly from the material:
Displayed specular (red) = Material specular (red)Displayed specular (green) = Material specular (green)
Displayed specular (blue) = Material specular (blue)

Copyright © 2018 Open Geospatial Consortium

6-219

Emissive:
The displayed emissive component is taken directly from the material:
Displayed emissive (red) = Material emissive (red)Displayed emissive (green) = Material emissive (green)
Displayed emissive (blue) = Material emissive (blue)
Shininess:
The MultiGen-Paradigm, Inc. modeling environment uses the shininess directly from thematerial. Specular highlights are tighter, with higher shininess values.
Alpha:An alpha of 1.0 is fully opaque, while 0.0 is fully transparent. The final alpha applied is acombination of the transparency value of the geometry (face or mesh) with the alphavalue of the material record. The final alpha value is a floating point number between 0.0(transparent) and 1.0 (opaque), and is computed as follows:
Final alpha = material alpha * (1.0 - (geometry transparency / 65535))

Material Palette Record

Data
Type
Int
Int
Int
Char
Int

OffsetLengthDescription

0
2
4
8
20

2
2
4
12
4

Float

24

4*3

Float

36

4*3

Float

48

4*3

Float

60

4*3

Float
Float

72
76

4
4

Int

80

Material Palette Opcode 113
Length - length of the record
Material index
Material name
Flags
0 = Material is used
1-31 = Spare
Ambient component ofmaterial (r, g, b) *Diffuse component ofmaterial (r, g, b) *Specular component ofmaterial (r, g, b) *Emissive component ofmaterial (r, g, b) *Shininess - (0.0-128.0)
Alpha - (0.0-1.0) where 1.0
is opaque
Reserved

4* normalized values between 0.0 and 1.0, inclusive.

CDB OpenFlight
Reader

ü
ü
ü
ü
ü
ü

ü
ü
ü
ü
ü
ü


Texture Palette Record
There is one record for each texture pattern referenced in the database. These records
must follow the header record and precede the first push.
A palette and pattern system can be used to reference the texture patterns. A texture
palette is made up of 256 patterns. The pattern index for the first palette is 0 - 255, for thesecond palette 256 - 511, etc. Note: If less than 256 patterns exist on a palette, several

Copyright © 2018 Open Geospatial Consortium

6-220pattern indices are unused. The x and y palette locations are used to store offset locationsin the palette for display.

Texture Palette Record

Data Type

OffsetLengthDescription

Int
Unsigned
Int
Char
Int
Int

0
2

2
2

Texture Palette Opcode 64
Length - length of the record

4
204
208

200
4
4*2

File name of texture pattern
Texture pattern index
Location in the texture
palette (x, y)

Copyright © 2018 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü

ü
ü


6-221

Eyepoint and Trackplane Palette Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider the
Eyepoint and Trackplane Palette Records.
OpenFlight files can contain up to ten eyepoint and trackplane positions. The first
eyepoint and trackplane in the file is reserved as the “last” one set during the modelingsession. The other nine are user-defined. Both the eyepoints and trackplanes are
combined in the Eyepoint and Trackplane palette record which is described in thissection.

Eyepoint and Trackplane Palette Record

Data Type
OffsetLengthDescription
Int
02
Eyepoint and Trackplane Palette Opcode 83
Unsigned Int
22
Length - length of the record
Int
4
4
Reserved
The following fields are repeated for 10 eyepoints
Eyepoint 0 - 272 bytes
Double
8
Float
32
Float
44
Float
108
Float
112
Float
116
Float
120
Float
124
Float
188
Float
200
Float
204
Float
208
Int
220
Int
224
Int
228
Int
232
Int
236
Int
240
Int
244
Int
276
Eyepoint 1
280

8*3
4*3
16*4
4
4
4
4
16*4
3*4
4
4
3*4
4
4
4
4
4
4
4*8
4
272

Eyepoint 2

552

272

Eyepoint 3

824

272

Eyepoint 4

1096

272

Eyepoint 5

1368

272

Eyepoint 6

1640

272

Copyright © 2018 Open Geospatial Consortium

Rotation center (x, y, z)
Yaw, pitch, and roll angles
4x4 rotation matrix, row major order
Field of view
Scale
Near clipping plane
Far clipping plane
4x4 fly-through matrix, row major order
Eyepoint position (x, y, z)
Yaw of fly-throughPitch of fly-throughEyepoint direction vector (i, j, k)
No fly through - 1 if no fly-throughOrtho view - 1 if ortho drawing mode
Valid eyepoint - 1 if this is a valid eyepoint
Image offset x
Image offset y
Image zoom
Reserved
Reserved
Eyepoint 1 - the fields listed above arerepeated here.
Eyepoint 2 - the fields listed above arerepeated here.
Eyepoint 3 - the fields listed above arerepeated here.
Eyepoint 4 - the fields listed above arerepeated here.
Eyepoint 5 - the fields listed above arerepeated here.
Eyepoint 6 - the fields listed above are

6-222

Eyepoint 7

1912

272

Eyepoint 8

2184

272

Eyepoint 9

2456

272

repeated here.
Eyepoint 7 - the fields listed above arerepeated here.
Eyepoint 8 - the fields listed above arerepeated here.
Eyepoint 9 - the fields listed above arerepeated here.

Eyepoint and Trackplane Palette Record (Continued)

Data Type
OffsetLengthDescription
The following fields are repeated for 10 trackplanes
Trackplane 0 - 128 bytes
Int
2728
Int
2732
Double2736
Double2760
Double2784
Boolean
2808
Int
2809

4
4
8*3
8*3
8*3
1
1

Int

2810

1

Int
Float
DoubleDoubleInt
Int
Boolean

2811
2812
2816
2824
2832
2833
2834

1
4
8
8
1
1
1

Int
Int
DoubleBooleanInt
Trackplane 1

2835
2836
2840
2848
2852
2856

1
4
8
4
4
128

Trackplane 2

2984

128

Trackplane 3

3112

128

Trackplane 4

3240

128

Trackplane 5

3368

128

Trackplane 6

3496

128

Copyright © 2018 Open Geospatial Consortium

Valid trackplane - 1 if this is a valid trackplane
Reserved
Trackplane origin coordinate (x, y, z)
Trackplane alignment coordinate (x, y, z)
Trackplane plane coordinate (x, y, z)
Grid visible - 1 if grid is visible
Grid type flag
0 = rectangular grid
1 = radial grid
Grid under flag
0 = draw grid over scene
1 = draw grid under scene
2 = draw grid depth buffered
Reserved
Grid angle for radial grid
Grid spacing in X. Radius if radial grid.
Grid spacing in Y
Radial grid spacing direction control
Rectangular grid spacing direction control
Snap cursor to grid - 1 if snap cursor to grid ison
Reserved
Reserved
Grid size (a power of 2)
Mask of visible grid quadrants
Reserved
Trackplane 1 - the fields listed above arerepeated here.
Trackplane 2 - the fields listed above arerepeated here.
Trackplane 3 - the fields listed above arerepeated here.
Trackplane 4 - the fields listed above arerepeated here.
Trackplane 5 - the fields listed above arerepeated here.
Trackplane 6 - the fields listed above are

6-223

Trackplane 7

3624

128

Trackplane 8

3752

128

Trackplane 9

3880

128

repeated here.
Trackplane 7 - the fields listed above arerepeated here.
Trackplane 8 - the fields listed above arerepeated here.
Trackplane 9 - the fields listed above arerepeated here.

Key Table Records

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider the Key

Table Records.

Key table records store variable length data records and their identifiers. The linkage
editor, sound palette, and CAT Data are stored as key table records. The first key table
record contains the key table header and a set of keys. If all the keys cannot fit into thefirst record, additional key records are written. This is followed by one or more key tabledata records.

A key table consists of: For an example of the use of key table records, see “Sound
Palette Record” on page 108.

Data TypeInt

Offset0

Key Table Header Record
Length2

Description
Opcode - opcode of record using key table
for storage
Unsigned Int 2
2
Length - length of the record
Int44
Subtype
1 = indicates this record is a key table
headerInt
8
4
Max number - maximum number of entries
Int
12
4
Actual number - actual number of entries
Int
16
4
Total length of packed data
Int
20
4*3
Reserved
The following fields are repeated for each key in the key table.
In the fields listed below, N ranges from 0 to Actual number - 1.
Int
32+(N*12) 4
Key valueN - key value N

Copyright © 2018 Open Geospatial Consortium

6-224

Int

36+(N*12) 4

Int

40+(N*12) 4

Copyright © 2018 Open Geospatial Consortium

ReservedN - reserved space for key N,
defined by record using key table for storage
Data offsetN - offset for data corresponding
to key N.
Note: This offset is measured relative to the
Packed data field in the key table data record
described below.

6-225

Data TypeInt
Unsigned Int
Int

Offset0
2
4

Length
2
2
4

Int
Char

8
12

4
Data
lengthKey Table Data

Description
Opcode - opcode of record using key table for storage
Length - length of the record
Subtype2 = indicates this record is a key table data
recordData length
Packed data
Data is always 4 byte aligned, with unused bytes set to0.
Data length can be calculated as follows: Length - 12

Linkage Palette Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider the Linkage

Palette Records.

Database linkages use key table records. Linkage data consists of two different
constructs: nodes and arcs. Nodes usually contain data pertaining to database entities
such as DOFs. In addition, the nodes may represent modeling driver functions and code
nodes. The arcs contain information on how all the nodes are connected to each other.
For most nodes, the value of the node is contained in the following Entity namesubrecord. For example, this node value can be a node name, when the node represents a
database entity, or a math formula as a string, in the case of a formula node. Names are
stored as null-terminated ASCII strings.
See “Linkage Editor Parameter IDs” on page 103 for parameter ID values anddescriptions.
Data TypeInt
Unsigned Int
Int

Offset0
2
4Linkage Palette Header Record
Length224Description
Linkage Palette Opcode 90
Length - length of the record
Subtype
1 = indicates this record is a key table headerInt
8
4
Max number - maximum number of entries. Each
entry is either a node, arc, or entity name.
Int
12
4Actual number - actual number of entries. Each entry
is either a node, arc, or entity name.
Int
16
4
Total length of data
Int
20
4*3
Reserved
The following fields are repeated for each key in the key table.
In the fields listed below, N ranges from 0 to Actual number - 1.
Int
32+(N*12) 4
Key valueN - key value N
Int
36+(N*12) 4
Data typeN - data type for key N
0x12120001 = Node data
0x12120002 = Arc data
0x12120004 = Database entity name

Copyright © 2018 Open Geospatial Consortium

6-226

Int

40+(N*12) 4

Data TypeInt
Unsigned Int
Int
Int
Char

Offset024Data offsetN - offset for data corresponding to key N.
Note: This offset is measured relative to the Packed
data field in the linkage palette data record described
below.

Linkage Palette Data Record

Description
Linkage Palette Opcode 90
Length - length of the record
Subtype2 = indicates this record is a key data record
8
4Data length12
Data
Packed data. Each packed data item is either alengthnode data subrecord, arc data subrecord or entity
name subrecord. Node data subrecords can beeither general nodes, formula nodes, or drivernodes. All these subrecords are described in thefollowing sections.
Data length can be calculated as follows: Length- 12
The offsets listed in the following subrecords are measured from the start of the subrecord, notfrom the start of the linkage palette data record that contains this packed data.

Data Type
Int
Int
Int

Offset
0
4
8

Int
Int
Int
Int
Int
Int
Int

12
28
32
36
40
44
48

Length224General Node Data Subrecord
Length
4
4
4
4*4
4
4
4
4
4
4

Description
Identifier
Reserved
Node type0x12120003 = Header node
0x12120005 = Database entity node
Reserved
Sinks
Sources
Next node identifier
Previous node identifier
Arc source identifier
Arc sink identifier

Copyright © 2018 Open Geospatial Consortium

6-227

Data Type
Int
Int
Int

Offset
0
4
8

Int
Int
Int
Int
Int
Int
Int
Int
Int
Int
Int

12
16
20
24
28
32
36
40
44
48
52

Formula Node Data Subrecord
Length
4
4
4
4
4
4
4
4
4
4
4
4
4
4

Copyright © 2018 Open Geospatial Consortium

Description
Identifier
Reserved
Data type0x12150000 = Formula node
Reserved
Reserved
Reserved
Reserved
Sinks
Sources
Next node identifier
Previous node identifier
Arc source identifier
Arc sink identifier
Reserved

6-228

Formula Node Data Subrecord (Continued)

Data Type
Int
Int
Int
Int
Int
Int
Int

Offset
56
60
64
68
72
76
80

Data Type
Int
Int
Int

Offset
0
4
8

Int
Int
Int
Int
Int
Int
Int
Int
Int
Int
Float
Float
Float
Float
Float
Float
Float
Int
Int
Int
Int

12
16
20
24
28
32
36
40
44
48
52
56
60
64
68
72
76
80
84
88
92

Length
4
4
4
4
4
4
4

Description
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved
Reserved

Driver Node Data Subrecord
Length
4
4
4

4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4

Copyright © 2018 Open Geospatial Consortium

Description
Identifier
Reserved
Node type0x12140001 = Ramp driver node
0x12140004 = Variable driver node
0x12140005 = External file driver node
Reserved
Reserved
Reserved
Reserved
Sinks
Sources
Next node identifier
Previous node identifier
Arc source identifier
Arc sink identifier
Current value
Min amplitude
Max amplitude
Wave offset
Min time
Max time
Time steps
Reserved
Reserved
Reserved
Reserved

6-229

Arc Data Subrecord

Data Type
Int
Int
Int

Offset0
4
8

Length
4
4
4

Int
Int
Int

12
16
20

4
4
4

Copyright © 2018 Open Geospatial Consortium

Description
Identifier
Reserved
Data type0x12120002 = Arc data subrecord
Reserved
Reserved
Priority

6-230

Arc Data Subrecord (Continued)

Data TypeInt

Offset24

Length
4

Int

28

4

Int
Int
Int
Int
Int

32
36
40
44
48

4
4
4
4
4

Data TypeChar

Offset0

LengthVariable

Description
Source parameter - parameter ID if source node
is a node
Sink parameter - parameter ID if sink node is anodenumber (0...7) for variables (x1...x8)
Only valid if sink node is a formula
Reserved
Next source identifier
Next sink identifier
Node source identifier
Node sink identifier

Entity Name Subrecord

Description
ASCII string; 0 terminates

Sound Palette Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider the Sound

Palette Records.

The sound palette uses key table records to store the sound index and file name. The
index is the key value, and the file name is the data record, formatted as a null-terminated
ASCII string. The sound palette header record indicates the number of sounds associatedwith the database.
Data TypeInt
Unsigned Int
Int

Offset02
4Sound Palette Header Record
Length224Description
Sound Palette Opcode 93
Length - length of the record
Subtype
1 = indicates this record is a key table
headerInt
8
4
Max number - the maximum number of sounds
in paletteInt
12
4Actual number - the actual number of sounds
in paletteInt
16
4
Total length - total length of the sound filenames contained in the sound palette key data
record, which follows this record and is
described below
Int
20
4*3
Reserved
The following fields are repeated for each sound represented in the palette.
In the fields listed below, N ranges from 0 to Actual number - 1.
Int
32+(N*12) 4
Sound indexN - index of sound N in the palette

Copyright © 2018 Open Geospatial Consortium

6-231

Int

36+(N+12) 4

Int

40+(N*12)

4

Copyright © 2018 Open Geospatial Consortium

ReservedN - reserved space for sound N in thepaletteFile name offsetN - starting offset for file nameof sound N in the palette. This offset ismeasured relative to the Packed file names
field in the sound palette data record described
below.

6-232

Sound Palette Data Record

Data TypeInt
Unsigned
Int
Int

Offset0
2

Length22

Description
Sound Palette Opcode 93
Length - length of the record

4

4

Int
Char

8
12

4
Data length

Subtype2 = indicates this record is a key data record
Total length of all packed sound file names
Packed file names.
Use File name offsets contained in sound palette key
table header to locate individual names in this data
blocks.
Data length can be calculated as follows: Length - 12

Light Source Palette Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider the Light

Source Records.

These records represent entries in the light source palette. Entries are referenced by lightsource nodes using the palette index. Lights can be flagged as modeling lights, which
illuminate a scene without being stored as part of the hierarchy. A modeling light isalways positioned at the eye; its direction is stored in the palette. A light referenced by anode obtains its position and direction from the node. In this case, the palette yaw andpitch components are ignored.

Light Source Palette Record

Data TypeInt
Unsigned
Int
Int
Int
Char
Int
Float

Offset0
2

Length22

Description
Light Source Palette Opcode 102
Length - length of the record

4
8
16
36
40

4
2*4
20
4
4*4

Float

56

4*4

Float

72

4*4

Int

88

4

Int
Float
Float
Float
Float

92
132
136
140
144

4*10
4
4
4
4

Light source index
Reserved
Light source name; 0 terminates
Reserved
Ambient component of light source (r, g, b, a) - alphaunusedDiffuse component of light source (r, g, b, a) - alphaunusedSpecular component of light source (r, g, b, a) - alphaunusedLight type
0 = Infinite
1 = Local
2 = Spot
Reserved
Spot exponential drop-off term
Spot cutoff angle (in degrees)
Yaw
Pitch

Copyright © 2018 Open Geospatial Consortium

6-233

Float
Float
Float
Int

148
152
156
160

4
4
4
4

Int

164

4*19

Constant attenuation coefficientLinear attenuation coefficient
Quadratic attenuation coefficient
Modeling light
0 = Light source is not active during modeling
1 = Light source is active during modelingReserved

Light Point Appearance Palette Record
The light point appearance palette record defines the visual attributes of light points.

Light Point Appearance Palette Record

Data Type

OffsetLengthDescription

Int

0

2

Unsigned Int
Int
Char

2
4
8

2
4
256

Int
Int
Int
Unsigned Int
Int

264
268
270
272
276

4
2
2
4
4

Float
Float
Float

280
284
288

4
4
4

Float

292

4

Int

296

4

Int

300

4

Int

304

4

Light Point Appearance Palette
Opcode 128
Length - length of the record
Reserved
Light Point Type Name
0 terminates
Appearance
Surface material code
Feature ID
Back color for bidirectional points
Display mode
0 = RASTER
1 = CALLIGRAPHIC
2 = EITHER
Intensity - scalar for front colors
Back intensity - scalar for back color
Minimum defocus - (0.0 - 1.0) for
calligraphic points
Maximum defocus - (0.0 - 1.0) for
calligraphic points
Fading mode
0 = Enable perspective fading
calculations
1 = Disable calculations
Fog Punch mode
0 = Enable fog punch throughcalculations
1 = Disable calculations
Directional mode
0 = Enable directional calculations
1 = Disable calculations

Copyright © 2018 Open Geospatial Consortium

CDB
OpenFlight
Reader

ü

ü

ü
ü





















6-234

Int

308

4

Float

312

4

Float

316

4

Float

320

4

Float

324

4

Float

328

4

Float

332

4

Float

336

4

Float

340

4

Float
Float

344
348

4
4

Int

352

4

Float

356

4

Float

360

4

Float

364

4

Float

368

4

Float

372

4

Float

376

4

Int

380

4

Range mode
0 = Use depth (Z) buffer calculation
1 = Use slant range calculation
Min pixel size - minimum diameterof points in pixels
Max pixel size - maximum diameterof points in pixels
Actual size - actual diameter ofpoints in database units
Transparent falloff pixel size diameter in pixels when points
become transparent
Transparent falloff exponent>= 0 - falloff multiplier exponent
1.0 - linear falloff
Transparent falloff scalar> 0 - falloff multiplier scale factor
Transparent falloff clamp - minimum
permissible falloff multiplier result
Fog scalar>= 0 - adjusts range of points forpunch threw effect.
Fog intensity
Size difference threshold - point sizetransition hint to renderer
Directionality
0 = OMNIDIRECTIONAL
1 = UNIDIRECTIONAL
2 = BIDIRECTIONAL
Horizontal lobe angle - total angle indegrees
Vertical lobe angle - total angle indegrees
Lobe roll angle - rotation of lobe
about local Y axis in degrees
Directional falloff exponent>= 0 - falloff multiplier exponent
1.0 - linear falloff
Directional ambient intensity - ofpoints viewed off axis
Significance - drop out priority for
RASCAL lights (0.0 - 1.0)
Flags (bits, from left to right)
0 = reserved
1 = No back color
TRUE = don’t use back color forbidirectional points
FALSE = use back color forbidirectional points
2 = reserved

Copyright © 2018 Open Geospatial Consortium





































6-235

Float
Float

384
388

4
4

Float

392

4

Float

396

4

Float

400

4

Float

404

4

Int
Int

408
410

2
2

3 = Calligraphic proximity occulting(Debunching)
4 = Reflective, non-emissive point
5-7 = Randomize intensity
0 = never
1 = low
2 = medium
3 = high
8 = Perspective mode
9 = Flashing
10 = Rotating
11 = Rotate Counter Clockwise
Direction of rotation about local Z
axis
12 = reserved
13-14 = Quality
0 = Low
1 = Medium
2 = High
3 = Undefined
15 = Visible during day
16 = Visible during dusk
17 = Visible during night
18-31 = Spare
Visibility range (> 0.0)
Fade range ratio - percentage of total
range at which light points start tofade (0.0 - 1.0)
Fade in duration - time it takes(seconds) light point to fade in whenturned on
Fade out duration - time it takes(seconds) light point to fade out
when turned off
LOD range ratio - percentage of total
range at which light points LODs areactive (0.0 - 1.0)
LOD scale - size of light point LOD
polygon relative to light point
diameter
Texture pattern index, -1 if none
Reserved

Copyright © 2018 Open Geospatial Consortium
































6-236

Light Point Animation Palette Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider the Light

Point Animation Palette Records.

The light point animation palette record defines the behavioral attributes of light points.
Data TypeInt
Unsigned Int
Int
char
Int
Float
Float
Float
Float
Int

Offset
0
2
4
8
264
268
272
276
280
292

Light Point Animation Palette Record
Length
2
2
4
256
4
4
4
4
4*3
4

Description
Light Point Animation Opcode 129
Length - length of the record
Reserved
Animation name; 0 terminates
Animation index
Animation period in seconds. Note: Rate = 1/Period
Animation phase delay in seconds - from start of period
Animation enabled period (time on) in seconds
Axis of rotation for rotating animation (i, j, k)Flags (bits, from left to right)
0 = Flashing
1 = Rotating
2 = Rotate counter clockwise
3-31 = Spare
Int
296
4
Animation type
0 = Flashing sequence
1 = Rotating
2 = Strobe
3 = Morse code
Int
300
4
Morse code timing
0 = Standard timing
1 = Farnsworth timing
Int
304
4
Word rate (for Farnsworth timing)
Int
308
4
Character rate (for Farnsworth timing)
char
312
1024
Morse code string
Int
1336
4
Number of sequences (for Flashing sequence)
The following fields are repeated for each sequence represented in the light point animation
palette entry.
In the fields listed below, N ranges from 0 to Number of sequences - 1.
1340+(N*12)
Unsigned Int
4
Sequence StateN - state of sequence N
0 = On1 = Off
2 = Color change
1344+(N*12)
Float
4
Sequence DurationN - duration of sequence N inseconds
1348+(N*12)
Unsigned Int
4
Sequence ColorN - color for sequence N.
Defined if Sequence state is On or Color change

Copyright © 2018 Open Geospatial Consortium

6-237

Line Style Palette Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider the Line

Style Palette Records.

Line style records define the outline displayed around faces in wireframe or wireframeover-solid mode. The Pattern field defines a mask to control the display of segments of
the line. For example, if all the bits of the mask are set, the line is drawn as a solid line. If
every other bit is on, the line is displayed as a dashed line. The Line Width field controls
the width of the line in pixels. Line style 0 is the default. Faces are assigned line styles inthe Line Style field of the face record. One of these records appears for each line styledefined in the OpenFlight file.
Data Type
Int
Int
Int
Int
Int

Offset02468Line Style Palette Record

Length22224Description
Line Style Palette Record Opcode 97
Length of record
Line style index
Pattern mask
Line width

Texture Mapping Palette Record

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider any of
the Texture Mapping Palette Records.

The texture mapping palette record defines methods and parameters used to map textures
onto geometry. One record is created for each texture mapping reference in the palette.
These records must follow the header record and precede the first push.

Texture Mapping Palette Record

Data Type
Int
Int
Int
Int
Char
Int

Offset
0
2
4
8
12
32

Length
2
2
4
4
20
4

Int
Double

36
40

4
8*16

Description
Texture Mapping Palette Opcode 112
Length - length of the record
Reserved
Texture mapping index
Texture mapping name
Texture mapping type
0 = None
1 = Put
2 = 4 Point Put
3 = Reserved
4 = Spherical Project
5 = Radial Project
6 = Reserved
Warped flag; if TRUE, 8 point warp applied
4x4 Transformation matrix (for types 1, 2, 4 & 5),
row major

The parameters for put texture mapping will appear immediately following the texture
mapping palette record if Texture mapping type is 1.

Copyright © 2018 Open Geospatial Consortium

6-238

Parameters for Put Texture Mapping (Type 1)

Data TypeInt

Offset168

Length
4

Int

172

4

Double176

8*3

Double

200

8*3

Int

224

4*3

Int
DoubleDoubleDoubleDoubleDoubleDouble
Int

236
240
264
288
312
336
360
384

4
8*3
8*3
8*3
8*3
8*3
8*3
4

Int

388

4

Float
Float

392
396

4
4

Copyright © 2018 Open Geospatial Consortium

Description
State of Put Texture tool
0 = Start state - no points entered
1 = One point entered
2 = Two points entered
3 = Three points entered
Active geometry point
1 = Origin point
2 = Alignment point
3 = Shear point
Lower-left corner of bounding box forgeometry using this mapping when mapping
was created (x, y, z)
Upper-right corner of bounding box forgeometry using this mapping when mapping
was created (x, y, z)
Use real world size flags for each of the put
pointsReserved
Texture origin point (x, y, z)
Texture alignment point (x, y, z)
Texture shear point (x, y, z)Geometry origin point (x, y, z)Geometry alignment point (x, y, z)Geometry shear point (x, y, z)
Active texture point
1 = Origin point
2 = Alignment point
3 = Shear point
UV display type
1 = XY
2 = UVU Repetition
V Repetition

6-239

The parameters for 4 point put texture mapping will appear immediately following the
texture mapping palette record if Texture mapping type is 2

Data TypeInt

Parameters for 4 Point Put Texture Mapping (Type 2)
Offset168

Length
4

Int

172

4

Double176

8*3

Double

200

8*3

Int

224

3*4

Int
DoubleDoubleDoubleDoubleDoubleDoubleDoubleDouble
Int

236
240
264
288
312
336
360
384
408
432

4
8*3
8*3
8*3
8*3
8*3
8*3
8*3
8*3
4

Int

436

4

Float
Int
Double

440
444
448

4
4
8*16

Float
Float

576
580

4
4

Description
State of 4 Point Put Texture tool
0 = Start state - no points entered
1 = One point entered
2 = Two points entered
3 = Three points entered
4 = Four points entered
Active geometry point
1 = Origin point
2 = Alignment point
3 = Shear point
4 = Perspective point
Lower-left corner of bounding box forgeometry using this mapping when mapping
was created (x, y, z)
Upper-right corner of bounding box forgeometry using this mapping when mapping
was created (x, y, z)
Use real world size flags for each of the put
pointsReserved
Texture origin point (x, y, z)
Texture alignment point (x, y, z)
Texture shear point (x, y, z)
Texture perspective point (x, y, z)Geometry origin point (x, y, z)Geometry alignment point (x, y, z)Geometry shear point (x, y, z)Geometry perspective point (x, y, z)
Active texture point
1 = Origin point
2 = Alignment point
3 = Shear point
4 = Perspective point
UV display type
1 = XY
2 = UV
Depth scale factor
Reserved
4x4 Transformation matrix for the 4 point
projection plane, row major order
U Repetition
V Repetition

The parameters for spherical project mapping will appear immediately following
the texture mapping palette record if Texture mapping type is 4.

Copyright © 2018 Open Geospatial Consortium

6-240Data Type
Float
DoubleFloat
Float

Parameters for Spherical Project Mapping (Type 4)
Offset168
172
196

Length
4
8*3
4

200

4

Description
Scale
Center of the projection sphere (x, y, z)
Scale / (maximum dimension of the mapped
geometry bounding box
Maximum dimension of the mapped geometrybounding box when mapping was created

The parameters for radial project mapping will appear immediately following the
texture map- ping palette record if Texture mapping type is 5.
Data TypeInt

Parameters for Radial Project Mapping (Type 5)
Offset168

Length
4

Int
Float
Float
Double

172
176
180
184

4
4
4
8*16

DoubleDouble

312
336

8*3
8*3

Copyright © 2018 Open Geospatial Consortium

Description
Active geometry point
1 = End point 1 of cylinder center line
2 = End point 2 of cylinder center line
Reserved
Radial scale
Scale along length of cylinder
4x4 Trackplane to XY plane transformation
matrix,row major order
End point 1 of cylinder center line (x, y, z)
End point 2 of cylinder center line (x, y, z)

6-241

The parameters for warped mapping will be included if the Warped flag is set in
the texture mapping palette record. This parameter block will appear immediately
following the texture mapping parameter block to which the warp applies. In theoffset fields below, X is equal to the size of the texture mapping palette record
plus the size of the texture mapping parameter block to which the warp applies.

Data TypeInt

Parameters for Warped Mapping (Warped Flag Set)
OffsetX+0

Length
4

Int

X+4

4

Int
Double

X+8
X+16

8
8*8*2

Double

X+144

8*8*2

Copyright © 2018 Open Geospatial Consortium

Description
Active geometry point
0 = First warp FROM point
1 = Second warp FROM point
2 = Third warp FROM point
3 = Fourth warp FROM point
4 = Fifth warp FROM point
5 = Sixth warp FROM point
6 = Seventh warp FROM point
7 = Eighth warp FROM point
8 = First warp TO point
9 = Second warp TO point
10 = Third warp TO point
11 = Fourth warp TO point
12 = Fifth warp TO point
13 = Sixth warp TO point
14 = Seventh warp TO point
15 = Eighth warp TO point
Warp tool state
0 = Start state - no points entered
1 = One FROM point entered
2 = Two FROM point entered
3 = Three FROM point entered
4 = Four FROM point entered
5 = Five FROM point entered
6 = Six FROM point entered
7 = Seven FROM point entered
8 = All FROM point enteredReserved
FROM points transformed to XY plane by
above matrix.
8 FROM points are ordered 1, 2, ... 8. Eachpoint is (x, y)
TO points transformed to XY plane by above
matrix.
8 TO points are ordered 1, 2, ... 8. Each pointis (x, y)6-242

Shader Palette Record
The shader palette contains descriptions of shaders used while drawing geometry. It is
composed of an arbitrary number of shader palette records. The shader palette records
must follow the header record and precede the first push.

Shader Palette Record

Data Type

OffsetLengthDescription

Int

0

2

Shader Opcode 133

Unsigned
Int
Int
Int

2

2

Length - length of the record

4
8

4
4

char
char

12
1036

1024
1024

char

2060

1024

Int

3084

4

Int

3088

4

char

3092

256

char

3348

256

Shader index
Shader type
0 = Cg
1 = CgFX
2 = OpenGL Shading
Language
Shader name; 0 terminates
Vertex program file name; 0terminates(Cg Shader type specific)
Fragment program filename; 0 terminates(Cg Shader type specific)
Vertex program profile (CgShader type specific)
Fragment program profile(Cg Shader type specific)
Vertex program entry point(Cg Shader type specific)
Fragment program entry
point (Cg Shader typespecific)

CDB OpenFlight
Reader
















Texture Files
Texture Pattern Files
OpenFlight does not have its own texture pattern format, but rather uses existing texture
formats and references patterns by file name. See “Texture Palette Record” on page 73.
File formats currently supported include:•AT&T® image 8 format (8-bit color lookup)

Copyright © 2018 Open Geospatial Consortium

CDB OpenFlight
Readers6-243

•AT&T image 8 template format•SGI intensity modulation (*.int)•SGI intensity modulation with alpha (*.inta)•SGI RGB (*.rgb)•SGI RGB with alpha (*.rgba)•GIF•JPEG/JFIF (*.jpg)•TIFF (*.tif)•IFF/ILBM•BMP/DIB
•PCX
•PNG
•PPM
•Sun™ Raster•Direct Draw Surface (DDS)•Targa™
•Alias™ Pix•SGI clip texture


ü30
ü30
ü
ü30














The format of the file is determined by the file name extension, the magic numbers within
the file, or the texture attribute file, as described in the following section.

30 The SGI format is fully supported by the CDB standard but a single file extension used, *.rgb.
Consequently, all image formats (int, inta, rgb, and rgba) are stored in .rgb files regardless of the number ofchannels in the image.

Copyright © 2018 Open Geospatial Consortium

6-244

Texture Attribute Files
CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider
texture attribute (*.attr) files.

A corresponding attribute file is created for each texture pattern, with the name of theattribute file the same as the texture file, followed by the extension “.attr”. These attribute
files are used by the modeling software, and may not be necessary for the application
using the database.
The attribute file contains information specifying how to parse the texture pattern file, set
the texture hardware and software environment for the texture pattern, or position theimage in a database.
The format of the texture attribute file is described in this section.

Texture Attribute File Format

Data
Type
Int
Int
Int
Int
Int
Int
Int

OffsetLengthDescription

0
4
8
12
16
20
24

4
4
4
4
4
4
4

Int

28

4

Int

32

4

Number of texels in u direction
Number of texels in v direction
Real world size u direction (obsolete - not used)
Real world size v direction (obsolete - not used)
x component of up vector
y component of up vector
File format type
0 = AT&T image 8 pattern
1 = AT&T image 8 template
2 = SGI intensity modulation
3 = SGI intensity w/alpha4 = SGI RGB
5 = SGI RGB w/alphaMinification filter type
0 = Point
1 = Bilinear
2 = Mipmap (obsolete)
3 = Mipmap Point
4 = Mipmap linear
5 = Mipmap bilinear
6 = Mipmap trilinear
7 = None
8 = Bicubic
9 = Bilinear greater/equal
10 = Bilinear less/equal
11 = Bicubic greater/equal
12 = Bicubic less/equal
Magnification filter type
0 = Point
1 = Bilinear

Copyright © 2018 Open Geospatial Consortium

6-245

Int

36

4

Int

40

4

Int

44

4

Int
Int
Int
Int

48
52
56
60

4
4
4
4

Int

64

4

Int
DoubleDouble
Int
Int
Int

68
100
108
116
120
124

4*8
8
8
4
4
4

2 = None
3 = Bicubic
4 = Sharpen
5 = Add Detail6 = Modulate Detail
7 = Bilinear greater/equal
8 = Bilinear less/equal
9 = Bicubic greater/equal
10 = Bicubic less/equal
Wrap method u,v - only used when either Wrapmethod u or Wrap method v is set to None
0 = Repeat
1 = Clamp
4 = Mirrored Repeat
Wrap method u
0 = Repeat
1 = Clamp
3 = None - use Wrap method u,v
4 = Mirrored Repeat
Wrap method v
0 = Repeat
1 = Clamp
3 = None - use Wrap method u,v
4 = Mirrored Repeat
Modified flag - for internal use only
x pivot point for rotating textures
y pivot point for rotating textures
Environment type
0 = Modulate
1 = Blend
2 = Decal
3 = Replace
4 = Add
TRUE if intensity pattern to be loaded in alpha withwhite in color
Reserved
Real world size u direction
Real world size v direction
Code for origin of imported texture
Kernel version number
Internal format type
0 = Default
1 = TX_I_12A_4
2 = TX_IA_8
3 = TX_RGB_5
4 = TX_RGBA_4
5 = TX_IA_12
6 = TX_RGBA_8
7 = TX_RGBA_12
8 = TX_I_16 (shadow mode only)

Copyright © 2018 Open Geospatial Consortium

6-246

Int

128

4

Int
Float
Int
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Float
Int

132
136
168
172
176
180
184
188
192
196
200
204
208
212
216
220
224
228
232
236
240

4
4*8
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4
4

Int

244

4

Float
Float
Double

248
252
284

4
4*8
8

9 = TX_RGB_12
External format type
0 = Default
1 = TX_PACK_8
2 = TX_PACK_16
TRUE if using following 8 floats for MIPMAP kernel
8 floats for kernel of separable symmetric filter
if TRUE send:
LOD0 for TX_CONTROL_POINT
SCALE0 for TX_CONTROL_POINT
LOD1 for TX_CONTROL_POINT
SCALE1 for TX_CONTROL_POINT
LOD2 for TX_CONTROL_POINT
SCALE2 for TX_CONTROL_POINT
LOD3 for TX_CONTROL_POINT
SCALE3 for TX_CONTROL_POINT
LOD4 for TX_CONTROL_POINT
SCALE4 for TX_CONTROL_POINT
LOD5 for TX_CONTROL_POINT
SCALE5 for TX_CONTROL_POINT
LOD6 for TX_CONTROL_POINT
SCALE6 for TX_CONTROL_POINT
LOD7 for TX_CONTROL_POINT
SCALE7 for TX_CONTROL_POINT
Control Clamp
Magnification filter type for alpha0 = Point
1 = Bilinear
2 = None
3 = Bicubic
4 = Sharpen
5 = Add Detail6 = Modulate Detail
7 = Bilinear greater/equal
8 = Bilinear less/equal
9 = Bicubic greater/equal
10 = Bicubic less/equal
Magnification filter type for color
0 = Point
1 = Bilinear
2 = None
3 = Bicubic
4 = Sharpen
5 = Add Detail6 = Modulate Detail
7 = Bilinear greater/equal
8 = Bilinear less/equal
9 = Bicubic greater/equal
10 = Bicubic less/equal
Reserved
Reserved
Lambert conic projection central meridian

Copyright © 2018 Open Geospatial Consortium

6-247

DoubleDoubleDouble
Float
Int
Int
Int
Int
Int
Int
Int
Float
Float
Float
Float
Int

292
300
308
316
336
340
344
348
352
356
360
364
368
372
376
380

8
8
8
4*5
4
4
4
4
4
4
4
4
4
4
4
4

Int

384

4

Int
Int
Int

388
392
396

4
4
4

Int

400

4

Int
Int
Int

404
408
412

4
4
4

Int
Int
Int
Char
Int
Int
Int

416
420
424
1020
1538
1584
1588

4
4
149*4
512
13*4
4
4

Lambert conic projection upper latitude
Lambert conic projection lower latitude
Reserved
Reserved
TRUE if using next 5 integers for TX_DETAIL
J argument for TX_DETAIL
K argument for TX_DETAIL
M argument for TX_DETAIL
N argument for TX_DETAIL
Scramble argument for TX_DETAILTRUE if using next 4 floats for TX_TILE
Lower-left u value for TX_TILE
Lower-left v value for TX_TILE
Upper-right u value for TX_TILE
Upper-right v value for TX_TILE
Projection
0 = Flat earth
3 = Lambert conic
4 = UTM
7 = Undefined projection
Earth model
0 = WGS84
1 = WGS72
2 = Bessel
3 = Clark 1866
4 = NAD27
Reserved
UTM zone
Image origin
0 = Lower left
1 = Upper left
Geospecific points units
0 = Degrees
1 = Meters
2 = Pixels
Reserved
Reserved
Hemisphere for geospecific points units
0 = Southern
1 = Northern
Reserved
Reserved
Reserved
Comments; 0 terminates
Reserved
Attribute file version number
Number of geospecific control points

If the value of the Number of geospecific control points field is greater than 0, theCopyright © 2018 Open Geospatial Consortium

6-248

following fields are also contained in the attribute file:

Geospecific Control Point subrecord

Data Type
OffsetLengthInt
4Reserved
The following fields are repeated for each geospecific control point in the texture
attribute file.
Note: In the fields below, N ranges from 0 to Number of geospecific control points – 1.
The earth coordinates depend on the projection, earth model, and geospecific points
units.
DoubleDoubleDoubleDouble8888Texel uN - texel u of control point
Texel vN - texel v of control point
Earth coordinate xN - earth x coordinate of control point.
Earth coordinate yN - earth y coordinate of control point.

If the value of the Number of geospecific control points field is greater than 0, thefollowing fields are also contained in the attribute file:
Data
Type
Int

OffsetLength4

Number of subtextures

If the value of the Number of subtextures field is greater than 0, the following fields arerepeated for each subtexture in the texture attribute file.
In the fields below, N ranges from 0 to Number of subtextures - 1.
The Left, Bottom, Right and Top fields are all measured in texels.

Data
Type
Char
Int
Int
Int
Int

Subtexture subrecord

OffsetLength32
44
44NameN - name of subtexture N; 0 terminates
LeftN - Coordinate of left edge of subtexture N
BottomN - Coordinate of bottom edge of subtexture N
RightN - Coordinate of right edge of subtexture N
TopN - Coordinate of top edge of subtexture N

Copyright © 2018 Open Geospatial Consortium

6-249

4

Road Path Files
CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider the Road

Path Files.

A road path file contains the attributes of a road path node in ASCII format. The name of
the file is user defined. Each attribute is denoted by a keyword, a literal colon, a space,
and the value(s). Boolean values are denoted by the string literals “TRUE” and“FALSE”. For the “POINT” keyword its values consist of an XYZ coordinate and an
orientation vector, separated by spaces. The orientation vector is specified as either anormal up-vector, or in degrees of heading, pitch, and roll. The “STORE_HPR”
keyword specifies which method is used. For path nodes that define the road’s centerline
path, construction information for the correlated road section is also stored withadditional keywords. Here’s an example:

5

Road Zone Files

Copyright © 2018 Open Geospatial Consortium

6-250

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider the Road

Zone Files.

Zone files are gridded posts files containing elevation and attribute data for a road. Thezone data is followed immediately by a series of:(Number of data points in x) * (Number of data points in y) elevation data points.
The elevation data points are followed immediately by a series of:(Number of data points in x) * (Number of data points in y) surface types corresponding
to each of the elevation data points above.
The elevation data points as well as the surface types begin at the lower-left corner.
Values are ordered from bottom to top, then in columns from left to right.
Data TypeInt
Int
DoubleDoubleDouble
Int
Int
Float
Float
Char

Road Zone File Format

Offset
0
4
8
32
56
64
68
72
76
80

Length
4
4
8*3
8*3
8
4
4
4
4
440

Data Type
Version - road tools format version
Reserved
Lower left corner (x, y, z)
Upper right corner (x, y, z)
Grid interval - spacing between data points
Number of data points in x
Number of data points in y
Low z elevation data point
High z elevation data point
Reserved

The following field is repeated for each data point in the road zone file.
In this field, N ranges from 0 to Number of data points - 1, where
Number of data points = Number of data points in x * Number of data points in y.
Data Type
Float

OffsetElevation Data Point subrecord

520+(N*4)

Length4

Data TypeZN - elevation value for data point N

The following field is repeated for each data point in the road zone file.
In this field, N ranges from 0 to Number of data points - 1, where
Number of data points = Number of data points in x * Number of data points in y and M
is equal to Number of data points.
Data TypeChar

Offset520+(M*4)+N

Surface Type subrecord

Length1

Data TypeSurface typeN - user defined surface type fordata point N

6 Linkage Editor Parameter IDs

CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider Linkage

Editor Parameter IDs.

Vertex Node Parameters

Copyright © 2018 Open Geospatial Consortium

6-251

ID
258
259
260
261
262
265
266
267
269
270
271

Description
X coordinate
Y coordinate
Z coordinate
Texture U coordinate
Texture V coordinate
Color
Hard edge flag
Freeze normal flag
Normal I component
Normal J component
Normal K component

Face Node Parameters
ID
514
515
516
518
519
520
521
522
523
525
526
527
529
530
534
535
536
537
538
539
540

Description
Color
Polygon drawing
Lighting mode
Relative priority
Draw both sides flag
Texture index
Template
InfraredTerrain flag
Material index
Feature ID
Surface material code
Draw textured faces white
IR material
Detail texture index
Transparency
Alternate color
LOD control
Line style index
Light point directional mode
Texture mapping

Copyright © 2018 Open Geospatial Consortium

6-252

Object Node Parameters
ID
770
771
772
773
774
775
776
777
778
779
782

Description
Relative priority
Inhibit during day flag
Inhibit during dusk flag
Inhibit during night flag
No illumination flag
Flat shading flag
Shadow flag
Transparency
Special #1
Special #2
SignificanceLOD Node Parameters
ID
1026
1027
1028
1029
1030
1031
1032
1033
1034
1036
1037

Description
Switch-in distance
Switch-out distanceSpecial #1
Special #2
Use previous range flag
Center X coordinate
Center Y coordinate
Freeze center flag
Center Z coordinate
Additive LOD’s below flag
Transition distanceGroup Node Parameters
ID
1282
1284
1286
1287
1288
1289
1290
1291

Description
Relative priority
Animation type
Bounding volume typeSpecial #1
Special #2
Replication countSignificanceLayer

Copyright © 2018 Open Geospatial Consortium

6-253

DOF Node Parameters
ID
1538
1539
1540
1542
1543
1544
1546
1547
1548
1550
1551
1552
1554
1555
1556
1558
1559
1560
1562
1563
1564
1566
1567
1568
1570
1571
1572
1574
1575
1576
1577
1578
1579
1580
1581
1582
1583
1584

Description
Current Z
Minimum Z
Maximum Z
Current Y
Minimum Y
Maximum Y
Current X
Minimum X
Maximum X
Current pitch
Minimum pitch
Maximum pitch
Current roll
Minimum roll
Maximum rollCurrent yaw
Minimum yaw
Maximum yaw
Current Z scale
Minimum Z scale
Maximum Z scale
Current Y scale
Minimum Y scale
Maximum Y scale
Current X scale
Minimum X scale
Maximum X scale
X constrained motion flag
Y constrained motion flag
Z constrained motion flag
Pitch constrained motion flag
Roll constrained motion flag
Yaw constrained motion flag
X scale constrained motion flag
Y scale constrained motion flag
Z scale constrained motion flag
Repeating texture flag
Membrane mode flag

Sound Node Parameters

Copyright © 2018 Open Geospatial Consortium

6-254

ID
1796
1797
1798
1799
1800
1801
1802
1803
1804
1805
1806
1807
1808
1809
1810
1812

Description
Amplitude
Pitch bend
Priority
Falloff
Width
Doppler
Absorption
Delay
Directivity
X coordinate
Y coordinate
Z coordinate
Direction vector I component
Direction vector J component
Direction vector K component
Active flag

Switch Node Parameters
ID
2050

Description
Current mask index

Copyright © 2018 Open Geospatial Consortium

6-255

Text Node Parameters
ID
2307
2308
2310
2311
2312
2315
2316
2317
2318
2325
2326
2327
2329
2330
2331
2332
2333
2334

Description
Text type
Draw type
Color
Alternate color
Material index
Integer value minimum
Integer value maximum
Float value minimum
Float value maximum
Current integer value
Current float value
Decimal places for float value
Line style index
Justification type
Vertical flag
Bold flag
Italic flag
Underline flag

Light Source Node Parameters
ID
2819
2820
2821
2822
2823
2824
2825

Description
Enabled flag
Global flag
X coordinate
Y coordinate
Z coordinate
Yaw
Pitch

Clip Node Parameters

7

ID
3074
3075
3076
3077
3078

Description
Plane 0 enable
Plane 1 enable
Plane 2 enable
Plane 3 enable
Plane 4 enable

OpenFlight Opcodes

Valid Opcodes

Copyright © 2018 Open Geospatial Consortium

6-256OpcodeRecord TypeFor more information, see…

1
2
4
5
10

HeaderGroup
ObjectFace
Push Level

11

Pop Level

14

Degree of Freedom

19

Push Subface

20

Pop Subface

21

Push Extension

22

Pop Extension

23

Continuation

31

Comment

32

Color Palette

33
49
50
52

Long ID
Matrix
VectorMultitexture

53
55

UV ListBinary Separating Plane

60
61

Replicate
Instance Reference

62

Instance Definition

63

External Reference64

Texture Palette

67

Vertex Palette

68

Vertex with Color

69

Vertex with Color and“Header Record” on page 19“Group Record” on page 22“Object Record” on page 25“Face Record” on page 26“Push Level Record” onpage 17“Pop Level Record” onpage 17“Degree of Freedom Record”
on page 37“Push Subface Record” onpage 17“Pop Subface Record” onpage 17“Push Extension Record” onpage 17“Pop Extension Record” onpage 17“Continuation Record” onpage 65“Comment Record” onpage 53“Color Palette Record” onpage 70“Long ID Record” on page 53“Matrix Record” on page 59“Vector Record” on page 61“Multitexture Record” onpage 54“UV List Record” on page 55“Binary Separating Plane
Record” on page 40“Replicate Record” on page 57“Instance Reference Record”
on page 19“Instance Definition Record”
on page 19“External Reference Record”
on page 41“Texture Palette Record” onpage 73“Vertex Palette Record” onpage 67“Vertex with Color Record”
on page 68“Vertex with Color and

Copyright © 2018 Open Geospatial Consortium

CDB OpenFlight
Reader

ü
ü
ü
ü
ü
ü
ü
ü
ü



ü
ü
ü
ü
ü

ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
ü
6-257

72

NormalVertex with Color,
Normal and UVVertex with Color and
UV
Vertex List

73

Level of Detail74

Bounding Box

76

Rotate About Edge

78
79
80

Translate
Scale
Rotate About Point

81

84
85

Rotate and/or Scale to
Point
Put
Eyepoint and Trackplane
PaletteMesh
Local Vertex Pool86

Mesh Primitive

87

Road Segment

88

Road Zone

89

Morph Vertex List

90

Linkage Palette

91
92

Sound
Road Path

93

Sound Palette

94

General Matrix

95
96
97

Text
SwitchLine Style Palette

98

Clip Region

100

Extension

70
71

82
83

Normal Record” on page 68“Vertex with Color, Normal
and UV Record” on page 69“Vertex with Color and UVRecord” on page 69“Vertex List Record” onpage 39“Level of Detail Record” onpage 41“Bounding Box Record” onpage 62“Rotate About Edge Record”
on page 59“Translate Record” on page 59“Scale Record” on page 59“Rotate About Point Record”
on page 60“Rotate and/or Scale to Point
Record” on page 60“Put Record” on page 60“Eyepoint and Trackplane
Palette Record” on page 73“Mesh Record” on page 29“Local Vertex Pool Record”
on page 30“Mesh Primitive Record” onpage 32“Road Segment Record” onpage 44“Road Zone Record” onpage 58“Morph Vertex List Record”
on page 39“Linkage Palette Record” onpage 77“Sound Record” on page 43“Road Path Record” onpage 46“Sound Palette Record” onpage 80“General Matrix Record” onpage 60“Text Record” on page 47“Switch Record” on page 49“Line Style Palette Record” onpage 85“Clip Region Record” onpage 47“Extension Record” on

Copyright © 2018 Open Geospatial Consortium

ü
ü
ü
ü
ü







ü
ü
ü


ü






ü




6-258

101

Light Source

102

Light Source Palette

103
104
105

Reserved
Reserved
Bounding Sphere

106

Bounding Cylinder

107

Bounding Convex Hull

108

Bounding Volume
CenterBounding Volume
Orientation

109
110
111

Reserved
Light Point112

Texture Mapping Palette

113

Material Palette

114

Name Table

115
116

Continuously Adaptive
Terrain (CAT)CAT Data

117
118
119

Reserved
Reserved
Bounding Histogram

120
121
122

Reserved
Reserved
Push Attribute123

Pop Attribute

124
125
126
127

Reserved
Reserved
Curve
Road Construction

128

Light Point Appearance
Palettepage 51“Light Source Record” onpage 44“Light Source Palette Record”
on page 81“Bounding Sphere Record” onpage 62“Bounding Cylinder Record”
on page 62“Bounding Convex Hull
Record” on page 62“Bounding Volume Center
Record” on page 63“Bounding Volume
Orientation Record” onpage 63“Light Point Record” onpage 34“Texture Mapping PaletteRecord” on page 86“Material Palette Record” onpage 71“Name Table Record” onpage 71“CAT Record” on page 50“CAT Data Record” onpage 63“Bounding Histogram Record”
on page 62“Push Attribute Record” onpage 18“Pop Attribute Record” onpage 18“Curve Record” on page 51“Road Construction Record”
on page 45“Light Point Appearance
Palette Record” on page 82

Copyright © 2018 Open Geospatial Consortium





ü
ü
ü
ü
ü



ü
ü













ü

6-259

129
130

Light Point Animation
PaletteIndexed Light Point

131

Light Point System

132

Indexed String

133

Shader Palette“Light Point Animation PaletteRecord” on page 85“Indexed Light Point Record”
on page 34“Light Point System Record”
on page 37“Indexed String Record” onpage 53“Shader Palette Record” onpage 91

Copyright © 2018 Open Geospatial Consortium


ü

ü


6-260

Obsolete Opcodes
CDB OpenFlight Readers: CDB-compliant OpenFlight readers do not consider thefollowing obsolete OpenFlight opcodes.
Opcode
3
6
7
8
9
12
13
16
17
40
41
42
43
44
45
46
47
48
51
65
66
77

Record Type
Level of Detail (single precision floating point, replaced by Opcode 73)
Vertex with ID (scaled integer coordinates, replaced by Opcodes 68-71)
Short Vertex w/o ID (scaled integer coordinates, replaced by Opcodes 68-71)
Vertex with Color (scaled integer coordinates, replaced by Opcodes 68-71)
Vertex with Color and Normal (scaled integer coordinates, replaced by Opcodes 6871)
Translate (replaced by Opcode 78)
Degree of Freedom (scaled integer coordinates, replaced by Opcode 14)
Instance Reference (replaced by Opcode 61)
Instance Definition (replaced by Opcode 62)
Translate (replaced by Opcode 78)
Rotate about Point (replaced by Opcode 80)
Rotate about Edge (replaced by Opcode 76)
Scale (replaced by Opcode 79)
Translate (replaced by Opcode 78)
Scale nonuniform (replaced by Opcode 79)
Rotate about Point (replaced by Opcode 80)
Rotate and/or Scale to Point (replaced by Opcode 81)
Put (replaced by Opcode 82)
Bounding Box (replaced by Opcode 74)
Eyepoint Palette (only eyepoints, replaced by Opcode 83)
Material Palette (fixed size 64 entries, replaced by Opcode 80)
Scale (replaced by Opcode 79)

Copyright © 2018 Open Geospatial Consortium

6-261

A Summary of Changes Version 15.7
CDB OpenFlight Readers: This section is not applicable to CDB-compliant OpenFlight
readers. The first version of the CDB standard is based on OpenFlight v16.0.

Overview
This section describes the changes in the OpenFlight Scene Description between versions
15.6 and 15.7. OpenFlight version 15.7 coincides with MultiGen Creator versions 2.4
through 2.5.1 and the OpenFlight API versions 2.4 through 2.5.1. The changes made forthis version are:•”Continuation Record “ on this page.
•”Header Record” on page 114•”Mesh Record” on page 115•”Local Vertex Pool Record” on page 116•”Mesh Primitive Record” on page 118•”Multitexture Record” on page 120•”UV List Record” on page 122•”Texture Attribute File” on page 123

Format Changes
Continuation Record
All OpenFlight records begin with a 4 byte sequence. The first two bytes identify therecord (opcode) and the second two bytes specify the length of the record. Given thisregular record structure, the length of all OpenFlight records is limited to the largest
value that can be encoded with 2 bytes or 16 bits (65535). In most cases, this maximum
size is sufficient but there are cases where it is not. For fixed size records, this is not a
problem. For variable size records, this limitation is being addressed with this version.
A new record, called the continuation record is introduced in this version toaccommodate variable size records in the OpenFlight Scene Description. The
continuation record is used to “continue” a record in the OpenFlight Scene Description
file stream. It would appear in the stream immediately following the record that it“continues” (the record that is being continued will be referred to as the “original”
record). The data contained in the continuation record is defined by the original record
and is assumed to be directly appended onto the content of the original record.

Copyright © 2018 Open Geospatial Consortium

6-262

Note: Multiple continuation records may follow a record, in which case all continuation
records would be appended (in sequence) to the original record.

Data Type
Unsigned Int
Unsigned Int
VariesOffset0
2
4

Continuation Record
New record for OpenFlight 15.7
Length2
2
Length-4

Description
Continuation Record Opcode 23
Length - length of the record
Depends on the original record. The contentsof this field are to be appended directly to theend of the original record contents (before theoriginal record contents are parsed)

Header Record
New attributes have been appended to the end of the existing header record (see “Header
Record” on page 19). The following fields were added at the specified offsets in theheader record.

Header Record changes for OpenFlight15.7
New Fields

Data TypeDoubleOffset284

Length
8

Double292

8

Unsigned Int
Unsigned Int

300
302

2
2

Description
Delta z to place database (used in conjunction
with existing Delta x and Delta y values)
Radius (distance from database origin to
farthest corner)
Next Mesh node ID number
Reserved

Mesh Nodes
A mesh node defines a set of geometric primitives that share attributes and vertices. In
previous versions of OpenFlight, the fundamental geometric construct was the polygon.
Each polygon has a unique set of attributes and vertices. Meshes are used to represent“sets” of related polygons, each sharing common attributes and vertices. Using a mesh,related polygons can be represented in a much more compact format. Each mesh will
share one set of “polygon” attributes (color, material, texture, etc.), a common “vertex
pool” and one or more geometric primitives that use the shared attributes and vertices.
Using a mesh you can represent triangle strips, triangle fans, quadrilateral strips andindexed face sets.
A mesh node is defined by three distinct record types:•Mesh Record - defines the “polygon” attributes associated to all geometric primitives ofthe mesh.

Copyright © 2018 Open Geospatial Consortium

6-263

•Local Vertex Pool Record - defines the set of vertices that are referenced by thegeometric primitives of the mesh.
•Mesh Primitive Record - defines a geometric primitive (triangle-strip, triangle-fan,quadrilateral-strip or indexed face set) for the mesh.
A mesh node consists of one mesh record, one local vertex pool record, and one or moremesh primitive records. The mesh primitive records are delimited by push and pop
control records as shown in the following example:
MESH
LOCAL VERTEX POOL
PUSH MESHPRIMITIVE
MESH PRIMITIVE...
MESH PRIMITIVEPOP

Mesh Record
The mesh record is the primary record of a mesh node and defines the common “facelike” attributes associated to all geometric primitives of the mesh. These attributes are
identical to those of the face record. See “Face Record” on page 26.

Mesh Record
New record for OpenFlight 15.7

Data TypeInt
Unsigned Int
Char
Int
Int
Int

Offset
0
2
4
12
16
18

Length
2
2
8
4
2
1

Int

19

1

Unsigned Int
Unsigned Int
Int

20
22
24

2
2
1

Copyright © 2018 Open Geospatial Consortium

Description
Mesh Opcode 84
Length - length of the record
7 char ASCII ID; 0 terminates
IR color code
Relative priority
Draw type
0 = Draw solid with backface culling
1 = Draw solid, no backface culling
2 = Draw wireframe
3 = Draw wireframe and close
4 = Surround with wireframe in alternate
color
8 = Omnidirectional light
9 = Unidirectional light
10 = Bidirectional light
Texture white = if TRUE, draw textured face
white
Color name index
Alternate color name index
Reserved

6-264

Mesh Record
New record for OpenFlight 15.7 (Continued)

Data TypeInt

Offset25

Length
1

Int
Int
Int
Int
Int
Int
Unsigned Int

26
28
30
32
34
36
40

2
2
2
2
2
4
2

Unsigned Int
Unsigned Int
Int

42
43
44

1
1
4

Unsigned Int

48

1

Char
Unsigned Int
Unsigned Int
Int
Int
Unsigned Int
Unsigned Int
Int

49
56
60
64
66
68
72
76

7
4
4
2
2
4
4
4

Description
Template (billboard)
0 = Fixed, no alpha blending
1 = Fixed, alpha blending
2 = Axial rotate with alpha blending
4 = Point rotate with alpha blending
Detail texture pattern index, -1 if none
Texture pattern index, -1 if none
Material index, -1 if none
Surface material code (for DFAD)
Feature ID (for DFAD)
IR material code
Transparency
0 = Opaque65535 = Totally clear
LOD generation control
Line style index
Flags (bits from left to right)
0 = Terrain
1 = No color
2 = No alternate color
3 = Packed color
4 = Terrain culture cutout (footprint)
5 = Hidden, not drawn
6-31 = Spare
Light mode
0 = Use mesh color, not illuminated
1 = Use vertex colors, not illuminated
2 = Use mesh color and vertex normals
3 = Use vertex colors and vertex normals
Reserved
Packed color, primary (a, b, g, r)
Packed color, alternate (a, b, g, r)
Texture mapping index
Reserved
Primary color index
Alternate color index
Reserved

Local Vertex Pool Record
This record defines a set of vertices that is referenced by the geometry (primitives) of themesh.

Copyright © 2018 Open Geospatial Consortium

6-265Note:

Currently the Local Vertex Pool is used exclusively in the context of mesh nodes,
but it is designed in a general way so that it may appear in other contexts in futureversions of the OpenFlight Scene Description.

Data TypeInt
Unsigned
Int

Offset0
2

Length2
2

Unsigned
Int
Unsigned
Int

4

4

8

4

Local Vertex Pool Record
New record for OpenFlight 15.7

Description
Local Vertex Pool Opcode 85
Length - length of the record
Note: Since the length of this record is represented by an unsigned
short, the maximum length of the vertex pool is 216- 1 (or 65535
bytes). If the entire vertex pool cannot fit into this size, one or more
continuation records will follow. (See “Continuation Record” onpage 65.)
Number of vertices - number of vertices in the local vertex pool
Attribute mask - Bit mask indicating what kind of vertex information is specified for each vertex in the local vertex pool. Bits areordered from left to right as follows:Bit #Description0
Has Position - if set, data for each vertex in will include x,y, and z coordinates (3 doubles)1
Has Color Index - if set, data for each vertex will include acolor value that is a color table index (1 int)
2
Has RGB Color - if set, data for each vertex will include acolor value that is a packed RGB color (1 int)
Note: Bits 1and 2 are mutually exclusive - a vertex can have either
color index or RGB color value or neither, but not both.
3
Has Normal - if set, data for each vertex will include a
normal (3 floats)
4
Has Base UV - if set, data for each vertex will include uv
texture coordinates for the base texture (2 floats)
5
Has UV Layer 1 - if set, data for each vertex will include
uv texture coordinates for layer 1 (2 floats)
6
Has UV Layer 2 - if set, data for each vertex will include
uv texture coordinates for layer 2 (2 floats)
7
Has UV Layer 3 - if set, data for each vertex will include
uv texture coordinates for layer 3 (2 floats)
8
Has UV Layer 4 - if set, data for each vertex will include
uv texture coordinates for layer 4 (2 floats)
9
Has UV Layer 5 - if set, data for each vertex will include
uv texture coordinates for layer 5 (2 floats)
10
Has UV Layer 6 - if set, data for each vertex will include
uv texture coordinates for layer 6 (2 floats)
11
Has UV Layer 7 - if set, data for each vertex will include
uv texture coordinates for layer 7 (2 floats)
12-31 Spare

Copyright © 2018 Open Geospatial Consortium

6-266

Local Vertex Pool Record
New record for OpenFlight 15.7 (Continued)

Then beginning at offset 12, the following fields are repeated for each vertex in the local
vertex pool, depending on the bits set in the Attribute mask field above:
In the fields listed below, N ranges from 0 to Number of vertices - 1.
DoubleVaries 8*3
CoordinateN - Coordinate of vertex N (x, y, z) - present
if Attribute mask includes Has Position.
Unsigned
Varies 4
colorN - Color for vertex N - present if Attribute maskIntincludes Has Color Index or Has RGB Color.
If Has Color Index, specifies color table index.
If Has RGB Color, 4 bytes specify (a, b, g, r) values(alpha ignored).
Float
Varies 4*3
normalN - Normal for vertex N (i, j, k) - present if
Attribute mask includes Has Normal.
Float
Varies 4*2
uvBaseN - Texture coordinates (u, v) for base texture
layer of vertex N - present if Attribute mask includes
Has Base UV.
Float
Varies 4*2
uv1N - Texture coordinates (u, v) for layer 1 of vertex
N - present if Attribute mask includes Has UV Layer
1.
Float
Varies 4*2
uv2N - Texture coordinates (u, v) for layer 2 of vertex
N - present if Attribute mask includes Has UV Layer
2.
Float
Varies 4*2
uv3N - Texture coordinates (u, v) for layer 3 of vertex
N - present if Attribute mask includes Has UV Layer
3.
Float
Varies 4*2
uv4N - Texture coordinates (u, v) for layer 4 of vertex
N - present if Attribute mask includes Has UV Layer
4.
Float
Varies 4*2
uv5N - Texture coordinates (u, v) for layer 5 of vertex
N - present if Attribute mask includes Has UV Layer
5.
Float
Varies 4*2
uv6N - Texture coordinates (u, v) for layer 6 of vertex
N - present if Attribute mask includes Has UV Layer
6.
Float
Varies 4*2
uv7N - Texture coordinates (u, v) for layer 7 of vertex
N - present if Attribute mask includes Has UV Layer
7.
Mesh Primitive Record
This record defines a geometric primitive (triangle strip, triangle fan, quadrilateral strip,
or indexed polygon) for a mesh.

Copyright © 2018 Open Geospatial Consortium

6-267

Data TypeInt
Unsigned Int
Int

Offset0
2
4

Mesh Primitive Record
New record for OpenFlight 15.7
Length222

Description
Mesh Primitive Opcode 86
Length - length of the record
Primitive Type - specifies how the verticesof the primitive are interpreted
1 = Triangle Strip
2 = Triangle Fan
3 = Quadrilateral Strip
4 = Indexed Polygon
Unsigned Int 6
2
Index Size - specifies the length (in bytes) ofeach of the vertex indices that follow - will
be either 1, 2, or 4
Unsigned Int 8
4
Vertex Count - number of vertices in thisprimitive.
The following field is repeated for each vertex referenced by the mesh primitive. Thesevertices are interpreted according to Primitive Type. In the field below, N ranges from 0
to Vertex Count - 1.
12+(N*Index Size)
Int
Index
IndexN - Index of vertex N of the meshSizeprimitive.
Each mesh primitive is represented using the Mesh Primitive record above. The
following descriptions explain how the vertices of each primitive type are interpreted asgeometry:•Triangle Strip - This mesh primitive defines a connected group of triangles in thecontext of the enclosing mesh. Each triangle shares the “polygon” attributes defined by
the enclosing mesh. This primitive contains a sequence of indices that reference vertices
from the local vertex pool. One triangle is defined for each vertex presented after the firsttwo vertices. For odd n, vertices n, n+1, and n+2 define triangle n. For even n, vertices
n+1, n, and n+2 define triangle n. The first triangle is n=1. The first vertex in the vertex
pool is n=1. N vertices represent N-2 triangles.
•Triangle Fan - Like the Triangle Strip, this mesh primitive also defines a connectedgroup of triangles in the context of the enclosing mesh. Each triangle shares the“polygon” attributes defined by the enclosing mesh. This primitive contains a sequenceof indices that reference vertices from the local vertex pool. One triangle is defined foreach vertex presented after the first two vertices. Vertices 1, n+1, and n+2 define triangle
n. The first triangle is n=1. The first vertex in the vertex pool is n=1. N vertices represent
N-2 triangles.
•Quadrilateral Strip - This mesh primitive defines a connected group of quadrilaterals
in the context of the enclosing mesh. Each quadrilateral shares the “polygon” attributes
defined by the enclosing mesh. This primitive contains a sequence of indices thatreference vertices from the local vertex pool. One quadrilateral is defined for each pair ofvertices presented after the first pair. Vertices 2n-1, 2n, 2n+2, and 2n+1 define
quadrilateral n. The first quadrilateral is n=1. The first vertex in the vertex pool is n=1. N
vertices represent (N/2)-1 quadrilaterals.
•Indexed Polygon -This mesh primitive defines a single polygon in the context of theenclosing mesh. This primitive is similar to the other mesh primitives in that it also sharesthe polygon attributes of the enclosing mesh. It is different from the other mesh primitive
types in that while triangle strips/fans and quadrilateral strips describe a set of connected

Copyright © 2018 Open Geospatial Consortium

6-268

triangles/quadrilaterals, the indexed polygon defines a single polygon. This primitive
contains a sequence of indices that reference vertices from the local vertex pool. One
polygon is defined by the sequence of vertices in this record. N vertices represent 1 Nsided closed polygon or 1 (N-1)-sided unclosed polygon.
Multitexture
OpenFlight supports 8 textures per polygon or mesh as well as 8 uv's per vertex. The
current texture information stored on the polygon is referred to as “the base texture” or“texture layer 0”. Each additional texture is referred to as “texture layer N”. Therefore, tosupport 8 textures per polygon, a base texture is required as well as 7 additional texture
layers. The additional texture layers for each polygon, mesh, and vertex will be
represented in ancillary records at the Face, Mesh, and Vertex primary node levels asshown in the following example:
FACE
MULTITEXTURE
PUSH
VERTEX LISTUV LISTPOP

The records that are used to represent multitexture in the OpenFlight file are described in
the following sections.
Multitexture Record
The multitexture record is an ancillary record of face and mesh nodes. It specifies the
texture layer information for the face or mesh.

Copyright © 2018 Open Geospatial Consortium

6-269

Data Type
Unsigned Int
Unsigned Int
Int

Offset02
4Multitexture Record
New record for OpenFlight 15.7
Multitexture Record
New record for OpenFlight 15.7
Length224Description
Multitexture Opcode 52
Length - length of the record
Attribute mask - Bit mask indicating what kindof multitexture information is present in thisrecord. Bits are ordered from left to right asfollows:
Bit # Description0
Has Layer 1 - if this bit is set,
multitexture information for texture
layer 1 is present.
1
Has Layer 2 - if this bit is set,
multitexture information for texture
layer 2 is present.
2
Has Layer 3 - if this bit is set,
multitexture information for texture
layer 3 is present.
3
Has Layer 4 - if this bit is set,
multitexture information for texture
layer 4 is present.
4
Has Layer 5 - if this bit is set,
multitexture information for texture
layer 5 is present.
5
Has Layer 6 - if this bit is set,
multitexture information for texture
layer 6 is present.
6
Has Layer 7 - if this bit is set,
multitexture information for texture
layer 7 is present.
7-31 Spare
The following fields are repeated for each multitexture layer that is specified as presentby the bits set in the Attribute mask field above. This mechanism allows for “sparse”
multitexture layer information to be present and does not require that the information
present be contiguous.
Unsigned Int Varies
2
textureN - Texture index for texture layer N
Unsigned Int Varies
2
effectN - Multitexture effect for texture layer N
0 = Texture environment
1 = Bump map
2-100 = Reserved by MultiGenParadigm>100 = user (runtime) defined
Unsigned Int Varies
2
mappingN - Texture mapping index for texture
layer N

Copyright © 2018 Open Geospatial Consortium

6-270Unsigned Int

Varies2

Copyright © 2018 Open Geospatial Consortium

dataN - Texture data for layer N. This is user
defined.
For example, it may be used as a blend
percentage or color or any other data needed by
the runtime to describe texture layer N

6-271

UV List Record
The uv list record is an ancillary record of vertex nodes. This record (if present) always
follows the vertex list or morph vertex list record and contains texture layer information
for the vertices represented in the vertex list record it follows.

Data Type
Unsigned Int
Unsigned Int
Int

Offset0
2
4

UV List Record
New record for OpenFlight 15.7
Length224Description
UV List Opcode 53
Length - length of the record
Attribute mask - Bit mask indicating what kindof multitexture information is present in thisrecord. Bits are ordered from left to right asfollows:
Bit #Description0
Has Layer 1 - if set, uvs for layer 1
are present
1
Has Layer 2 - if set, uvs for layer 2
are present
2
Has Layer 3 - if set, uvs for layer 3
are present
3
Has Layer 4 - if set, uvs for layer 4
are present
4
Has Layer 5 - if set, uvs for layer 5
are present
5
Has Layer 6 - if set, uvs for layer 6
are present
6
Has Layer 7 - if set, uvs for layer 7
are present
7-31 Spare

The following fields are repeated for each vertex contained in the corresponding vertex
list or morph vertex list record.
If this uv list record follows a vertex list record, the following fields are repeated for eachlayer present (as specified by the bits set in the Attribute mask field).
Data Type
Float
Float

Offset4
4

Descriptionui, N - Texture U for vertex i, layer Nvi, N - Texture V for vertex i, layer N

If this uv list record follows a morph vertex list record, the following fields are repeatedfor each layer present (as specified by the bits set in the Attribute mask field).
Data Type
Float
Float

Offset4
4

Description
u0i, N - Texture U for the 0% vertex i, layer N
v0i, N - Texture V for the 0% vertex i, layer N

Copyright © 2018 Open Geospatial Consortium

6-272

FloatFloat

44u100i, N - Texture U for the 100% vertex i, layer N
v100i, N - Texture V for the 100% vertex i, layer N

Copyright © 2018 Open Geospatial Consortium

6-273

Texture Attribute File
Subtexture
Subtexture definitions have been added to the end of the Texture Attribute File (see“Texture Attribute Files” on page 93). After all the geospecific control points are listed,
the following subtexture information now appears:

Texture Attribute File Format changes for OpenFlight 15.7
New Fields

Data TypeInt

Length4

Description
Number of subtextures

If the value of the Number of subtextures field is greater than 0-, the following fields arerepeated for each subtexture in the texture attribute file.
The Left, Bottom, Right and Top fields are all measured in texels.
Data Type
Char
Int
Int
Int
Int

Length32
4444Description
NameN - name of subtexture N; 0 terminates
LeftN - Coordinate of left edge of subtexture N
BottomN - Coordinate of bottom edge of subtexture N
RightN - Coordinate of right edge of subtexture N
TopN - Coordinate of top edge of subtexture N

Copyright © 2018 Open Geospatial Consortium

6-274

B Summary of Changes Version 15.8
Overview
This section describes the changes in the OpenFlight Scene Description between versions
15.7 and 15.8 as well as the errors contained in previous versions of this document thathave been corrected in this version.
OpenFlight version 15.8 coincides with MultiGen Creator version 2.6 and the OpenFlight
API version 2.6. The changes made for this version are:
•
•
•
•
•
•
•
•
•
•
•
•
•
•

“Header Record” on page 127“Group Record” on page 128“Level of Detail Record” on page 129“External Reference Record” on page 130“Indexed String Record” on page 130 (for Switch nodes)“Face Record” on page 131“Mesh Record” on page 131“Local Vertex Pool Record” on page 132“Vertex Palette Records” on page 133“Light Point Appearance Palette Record” on page 136“Light Point Animation Record” on page 139“Indexed Light Point Record” on page 140“Light Point System Record” on page 140“Texture Mapping Palette Record” on page 141

Also new in this version of the document is the addition of the “offset” column in therecord format tables.

Document Corrections
The errors corrected in this version of the document are described in the sections that
follow.

Copyright © 2018 Open Geospatial Consortium

6-275

Text Record
The Reserved field, previously omitted in prior versions of this document, has been
documented in the specification for OpenFlight 15.8. The offsets of fields following thisfield have been adjusted accordingly.

Text Record error corrected in OpenFlight 15.8 specification
Reserved field (documented)

Data TypeInt

Offset16

Length4

Description
Reserved

The Draw bold field, previously omitted in prior versions of this document, has been
documented in the specification for OpenFlight 15.8. The offsets of fields following thisfield have been adjusted accordingly.

Text Record error corrected in OpenFlight 15.8 specification
Draw bold field (documented)

Data TypeInt

Offset304

Length4

Description
Draw bold

For a complete description of the text record, see “Text record” on page 47.
CAT Record
The Relative priority field, included erroneously in the previous version of this document,
has been removed from the specification for OpenFlight 15.8. The offsets of fields
following this field have been adjusted accordingly.

CAT Record error corrected in OpenFlight 15.8 specification
Relative priority field (removed)

Data TypeInt

Offset20

Length2

Description
Relative priority

The Feature ID field, included erroneously in the previous version of this document, hasbeen removed from the specification for OpenFlight 15.8. The offsets of fields following
this field have been adjusted accordingly.

CAT Record error corrected in OpenFlight 15.8 specification
Feature ID field (removed)

Data TypeInt

Offset38

Length2

Copyright © 2018 Open Geospatial Consortium

Description
Relative priority

6-276

The Reserved field, previously omitted in prior version of this document, has been
documented in the specification for OpenFlight 15.8. The offsets of fields following thisfield have been adjusted accordingly.

CAT Record error corrected in OpenFlight 15.8 specification
Reserved field (documented)

Data TypeInt

Offset60

Length4

Description
Reserved

Format Changes
Header Record
The header record has been modified to include additional projection attributes. New
attributes have been appended to the end of the existing header record and some of theexisting fields have new values possible.
The following fields were added to the end (at the specified offsets) of the header record.

Header Record changes for OpenFlight15.8
New Fields

Data Type
Unsigned Int
Int
DoubleOffset302
304
308

Length2
48

Double316

8

Description
Next Light Point System ID number
Reserved
Earth major axis (for user defined ellipsoid) inmetersEarth minor axis (for user defined ellipsoid) inmetersThe Projection type field has been changed to include two new possible values,
Geocentric and Geodetic as shown here. New values are shown in bold font:

Data TypeInt

Header Record changes for OpenFlight15.8
Projection type field

Offset92

Length4

Copyright © 2018 Open Geospatial Consortium

Description
Projection type
0 = Flat earth
1 = Trapezoidal
2 = Round earth
3 = Lambert
4 = UTM
5 = Geocentric
6 = Geodetic

6-277

The Earth ellipsoid model field has been changed to include one new possible value, User
defined ellipsoid as shown here. This new value is shown in bold font.

Data TypeInt

Header Record changes for OpenFlight15.8
Earth ellipsoid field

Offset268

Length4

Description
Earth ellipsoid model
0 = WGS 1984
1 = WGS 1972
2 = Bessel
3 = Clarke 1866
4 = NAD 1927
5 = User defined ellipsoid

A field, previously labeled “Reserved” in prior versions of this document, has been
described. It is the UTM zone for UTM projections and is shown here.

Data TypeInt

Header Record changes for OpenFlight15.8
UTM zone field

Offset276

Length2

Description
UTM zone (for UTM projections - negativevalue means Southern hemisphere)

For a complete description of the header record, see “Header Record” on page 22.
Group Record
The group record has been modified to include additional animation attributes. New
attributes have been appended to the end of the existing group record and some of theexisting fields have new values possible.
The following fields were added to the end (at the specified offsets) of the group record.

Data Type
Int
Float
Float

Group Record changes for OpenFlight15.8
New Fields

Offset32
36
40

Length444Copyright © 2018 Open Geospatial Consortium

Description
Loop countLoop duration in seconds
Last frame duration in seconds

6-278

The Flags field has been changed to include a new bit which can be used to specify
backwards animations as shown here. The new bit is shown in bold font.

Data TypeInt

Group Record changes for OpenFlight15.8
Flags field

Offset16

Length4

Description
Flags (bits, from left to right)
0 = Reserved
1 = Forward animation
2 = Swing animation
3 = Bounding box follows
4 = Freeze bounding box
5 = Default parent
6 = Backward animation
7-31 = Spare

For a complete description of the group record, see “Group Record” on page 22.
Level of Detail Record
The level of detail record has been modified to include an additional attribute, Significant
size. This new value helps an application to calculate switch ranges for the geometry
more effectively for different display settings (field of view, screen size and resolution).
The following field was added to the end (at the specified offset) of the level of detailrecord.

Data TypeDoubleLOD Record changes for OpenFlight15.8
New Field

Offset72

Length8

Description
Significant size

For a complete description of the level of detail record, see “Level of Detail Record” onpage 41.

Copyright © 2018 Open Geospatial Consortium

6-279

External Reference Record
The Flags field of the external reference record has been modified to include a new bit,
Light point palette override, which is used to specify that the light point appearance andanimation palettes override those contained in the master file. The new bit is shown inbold font.

Data TypeInt

External Reference Record changes for OpenFlight15.8
Flags field
Offset208

Length4

Description
Flags (bits, from left to right)
0 = Color palette override
1 = Material palette override
2 = Texture and texture mapping paletteoverride
3 = Line style palette override
4 = Sound palette override
5 = Light source palette override
6 = Light point palette override
7-31 = Spare

For a complete description of the external reference record, see “External Reference
Record” on page 41.
Indexed String Record
Switch nodes now allow individual masks to be named. These names are stored in a newancillary record called the Indexed String record. While these new ancillary records are
currently only applicable to Switch records, they are not limited to Switch records andmay be useful in future versions of OpenFlight in other contexts.
The new Indexed String Record is an ancillary record that contains an integer index
followed by a variable length character string. In this way, arbitrary strings can beassociated to indices in a general way.
With respect to Switch mask names, the index specifies the mask number for which thestring specifies a name. Mask numbers start at 0. Not all masks are required to havenames.

Data TypeInt
Unsigned Int
Unsigned Int
Char

Offset02
4
8

Indexed String Record
New record for OpenFlight 15.8
Length2
2
2
Length - 8

Description
Indexed string Opcode 132
Length - length of the record
Index
ASCII string; 0 terminates

For a completed description of the indexed string record, see “Indexed String Record” onpage 53.

Copyright © 2018 Open Geospatial Consortium

6-280

Face Record
The Flags field of the face record has been modified to include a new bit, Roofline, which
is used to specify that a face is part of a building’s roof as viewed from above. The new
specification of the Flags field is shown here. The new bit is shown in bold font.

Data TypeInt

Face Record changes for OpenFlight15.8
Flags field

Offset44

Length4

Description
Flags (bits from left to right)
0 = Terrain
1 = No color
2 = No alternate color
3 = Packed color
4 = Terrain culture cutout (footprint)
5 = Hidden, not drawn
6 = Roofline
7-31 = SpareMesh Record
Similar to the Face record described above, the Flags field of the mesh record has been
modified to include a new bit, Roofline, which is used to specify that a mesh is part of abuilding’s roof as viewed from above. The new specification of the Flags field is shown
here. The new bit is shown in bold font.

Data TypeInt

Mesh Record changes for OpenFlight15.8
Flags field

Offset44

Length4

Copyright © 2018 Open Geospatial Consortium

Description
Flags (bits from left to right)
0 = Terrain
1 = No color
2 = No alternate color
3 = Packed color
4 = Terrain culture cutout (footprint)
5 = Hidden, not drawn
6 = Roofline
7-31 = Spare

6-281

Local Vertex Pool Record
The Local Vertex Pool record has been modified to include an alpha color component for
those vertices in the pool that have color. The alpha color component is represented as a 1
byte integer value whose range is 0 (fully transparent) to 255 (fully opaque).
The definition of the Attribute mask field has been changed as shown here.
Note: The physical layout of this field has not changed, only its definition. The bits forwhich new definitions apply are shown in bold font:

Data Type

Local Vertex Pool Record changes for OpenFlight15.8
Attribute mask field

Unsigned Int

OffsetLengthDescription

8

4

Attribute mask - Bit mask indicating what kind ofvertex information is specified for each vertex in
the local vertex pool. Bits are ordered from left toright as follows:
Bit
Description#0
Has Position - if set, data for each vertex inwill include x, y, and z coordinates (3doubles)1
Has Color Index - if set, data for eachvertex will include a color value thatspecifies a color table index as well as analpha value
2
Has RGBA Color - if set, data for eachvertex will include a color value that is apacked RGBA color value
Note: Bits 1and 2 are mutually exclusive - a vertex
can have either color index or RGB color value orneither, but not both.
3
Has Normal - if set, data for each vertex will
include a normal (3 floats)
4
Has Base UV - if set, data for each vertex
will include uv texture coordinates for thebase texture (2 floats)
5
Has UV Layer 1 - if set, data for each vertex
will include uv texture coordinates for layer
1 (2 floats)
6
Has UV Layer 2 - if set, data for each vertex
will include uv texture coordinates for layer
2 (2 floats)
7
Has UV Layer 3 - if set, data for each vertex
will include uv texture coordinates for layer
3 (2 floats)
8
Has UV Layer 4 - if set, data for each vertex
will include uv texture coordinates for layer
4 (2 floats)

Copyright © 2018 Open Geospatial Consortium

6-282

9
10
11
1231

Copyright © 2018 Open Geospatial Consortium

Has UV Layer 5 - if set, data for each vertex
will include uv texture coordinates for layer
5 (2 floats)
Has UV Layer 6 - if set, data for each vertex
will include uv texture coordinates for layer
6 (2 floats)
Has UV Layer 7 - if set, data for each vertex
will include uv texture coordinates for layer
7 (2 floats)
Spare

6-283

The color field of the vertex pool data (data for each vertex) has been modified to include
an alpha color component as shown here. The affected field is shown in bold font.

Local Vertex Pool Record changes for OpenFlight15.8
Color field

Data Type
Unsigned Int

Offset4

Description
colorN - Color for vertex N - present if Attribute mask
includes Has Color Index or Has RGBA Color.
If Has Color Index, lower 3 bytes specify color tableindex, upper 1 byte is Alpha.
If Has RGBA Color, 4 bytes specify (a, b, g, r) values.

For a complete description of the local vertex pool record, see “Local Vertex Pool
Record” on page 30.
Vertex Palette Records
Vertex Palette Records have been modified to include an alpha color component. The
alpha color component is represented as a 1 byte integer value whose range is 0 (fullytransparent) to 255 (opaque).
Prior to OpenFlight version 15.8, vertex colors were represented in vertex palette records
in one of two ways: Packed Color or Color Index. Depending on the value of the Packed
color flag, either the Packed color (a, b, g, r) attribute or the Vertex color index attributewas valid, but not both. For example, if the Packed color flag was TRUE, then the Packed
color attribute contained the RGB components of the vertex color and the Vertex color
index attribute was not specified. Conversely, if the Packed color flag was FALSE, thenthe Vertex color index attribute contained the index (in the Color Palette) of the vertex
color and the Packed color attribute was not specified. Furthermore, the A (alpha)component of the Packed color attribute was not valid and was ignored.
In OpenFlight version 15.8, the A (alpha) component of the Packed color attribute isvalid and all vertex records include the Packed color (a, b, g, r) attribute, even those that
also include the Vertex color index attribute. For those vertices that include the Vertex
color index attribute, the RGB components of the Packed color attribute will match thoseof the color specified by the Vertex color index attribute if it was looked up in the color
palette. This implies that an application concerned only with the RGB components of avertex color can simply reference the Packed color attribute and ignore the Vertex color
index attribute in all cases.
All the updated vertex palette records are shown here. The Packed color is shown in bold
font to emphasize that it is always specified (for both color index and packed color
specifications).

Copyright © 2018 Open Geospatial Consortium

6-284

Vertex with Color Record changes for OpenFlight 15.8
Packed color field

Data typeInt
Unsigned Int
Unsigned Int
Int

Offset0
2
4
6

Length22
2
2

Double
Int

8
32

8*3
4

Unsigned Int

36

4

Description
Vertex with Color Opcode 68
Length - length of the record
Color name index
Flags (bits, from left to right)
0 = Start hard edge
1 = Normal frozen
2 = No color
3 = Packed color
4-15 = Spare
Vertex coordinate (x, y, z)
Packed color (a, b, g, r) - always specified
when the vertex has color
Vertex color index - valid only if vertex has
color and Packed color flag is not set

Vertex with Color and Normal Record changes for OpenFlight 15.8
Packed color field

Data typeInt
Unsigned Int
Unsigned Int
Int

Offset0
2
4
6

Length22
2
2

Double
Float
Int

8
32
44

8*3
4*3
4

Unsigned Int

48

4

Int

52

4

Copyright © 2018 Open Geospatial Consortium

Description
Vertex with Color and Normal Opcode 69
Length - length of the record
Color name index
Flags (bits, from left to right)
0 = Start hard edge
1 = Normal frozen
2 = No color
3 = Packed color
4-15 = Spare
Vertex coordinate (x, y, z)
Vertex normal (i, j, k)
Packed color (a, b, g, r) - always specified
when the vertex has color
Vertex color index - valid only if vertex has
color and Packed color flag is not set
Reserved

6-285

Vertex with Color and UV Record changes for OpenFlight 15.8
Packed color field

Data typeInt
Unsigned Int
Unsigned Int
Int

Offset0
2
4
6

Length22
2
2

Double
Float
Int

8
32
40

8*3
4*2
4

Unsigned Int

44

4

Description
Vertex with Color and UV Opcode 71
Length - length of the record
Color name index
Flags (bits, from left to right)
0 = Start hard edge
1 = Normal frozen
2 = No color
3 = Packed color
4-15 = Spare
Vertex coordinate (x, y, z)
Texture coordinate (u, v)
Packed color (a, b, g, r) - always specified
when the vertex has color
Vertex color index - valid only if vertex has
color and Packed color flag is not set

Vertex with Color, Normal and UV Record changes for OpenFlight 15.8
Packed color field

Data typeInt

Offset0

Length2

Description
Vertex with Color, Normal and UV Opcode
70
Unsigned Int 2
2
Length - length of the record
Unsigned Int 42
Color name index
Int
62
Flags (bits, from left to right)
0 = Start hard edge
1 = Normal frozen
2 = No color
3 = Packed color
4-15 = Spare
Double8
8*3Vertex coordinate (x, y, z)
Float
36
4*3
Vertex normal (i, j, k)
Float
44
4*2
Texture coordinate (u, v)
Int
52
4
Packed color (a, b, g, r) - always specified
when the vertex has color
Unsigned Int 56
4Vertex color index - valid only if vertex has
color and Packed color flag is not set
Int
60
4
Reserved
For a complete description of the vertex palette records, see “Vertex Palette Records” onpage 66.

Copyright © 2018 Open Geospatial Consortium

6-286

Light Points
The representation of Light Points in OpenFlight version 15.8 is significantly different
from prior versions. Previously, all light point attributes were described completely
within the primary record of the light point node.
In OpenFlight version 15.8, light point attributes have been divided into two categories,
appearance and behavioral. To accommodate this, two new palettes have been created,the Light Point Appearance Palette and the Light Point Animation palette. A new IndexedLight Point node record has been added that references entries from the Light Point
Appearance and Animation palettes. In effect, this moves the light point attributes out of
the node record itself into entries of the two palettes and makes it much easier to sharecommon attributes between multiple light points.
Note that the Light Point Record (Opcode 111) used in previous versions of OpenFlightremains valid for applications that require the data in this other format. Creator and the
OpenFlight API versions 2.6 support both light point formats.
Following is a description of the new records in OpenFlight version 15.8 used to describe
Light Point Palettes and Indexed Light Points.

Light Point Appearance Palette Record
The light point appearance palette record defines the visual attributes of light points.

Light Point Appearance Palette Record
New record for OpenFlight 15.8

Data TypeInt
Unsigned Int
Int
Char
Int
Int
Int
Unsigned Int
Int

Offset
0
2
4
8
264
268
270
272
276

Length
2
2
4
256
4
2
2
4
4

Float
Float
Float

280
284
288

4
4
4

Float

292

4

Int

296

4

Copyright © 2018 Open Geospatial Consortium

Description
Light Point Appearance Palette Opcode 128
Length - length of the record
Reserved
Appearance name; 0 terminates
Appearance index
Surface material code
Feature ID
Back color for bidirectional points
Display mode
0 = RASTER
1 = CALLIGRAPHIC
2 = EITHER
Intensity - scalar for front colors
Back intensity - scalar for back color
Minimum defocus - (0.0 - 1.0) for calligraphic
pointsMaximum defocus - (0.0 - 1.0) for
calligraphic points
Fading mode
0 = Enable perspective fading calculations
1 = Disable calculations

6-287

Light Point Appearance Palette Record
New record for OpenFlight 15.8 (Continued)

Data TypeInt

Offset300

Length
4

Int

304

4

Int

308

4

Float
Float
Float
Float

312
316
320
324

4
4
4
4

Float

328

4

Float

332

4

Float

336

4

Float

340

4

Float
Float

344
348

4
4

Int

352

4

Float
Float
Float

356
360
364

4
4
4

Float

368

4

Float
Float

372
376

4
4

Description
Fog Punch mode
0 = Enable fog punch through calculations
1 = Disable calculations
Directional mode
0 = Enable directional calculations
1 = Disable calculations
Range mode
0 = Use depth (Z) buffer calculation
1 = Use slant range calculation
Min pixel size - minimum diameter of points in pixels
Max pixel size - maximum diameter of points in pixels
Actual size - actual diameter of points in database units
Transparent falloff pixel size - diameter in pixels when points
become transparent
Transparent falloff exponent>= 0 - falloff multiplier exponent
1.0 - linear falloff
Transparent falloff scalar> 0 - falloff multiplier scale factor
Transparent falloff clamp - minimum permissible falloff
multiplier result
Fog scalar>= 0 - adjusts range of points for punch threw effect.
Fog intensity
Size difference threshold - point size transition hint torenderer
Directionality
0 = OMNIDIRECTIONAL
1 = UNIDIRECTIONAL
2 = BIDIRECTIONAL
Horizontal lobe angle - total angle in degrees
Vertical lobe angle - total angle in degrees
Lobe roll angle - rotation of lobe about local Y axis in degrees
Directional falloff exponent>= 0 - falloff multiplier exponent
1.0 - linear falloff
Directional ambient intensity - of points viewed off axis
Significance - drop out priority for RASCAL lights (0.0 - 1.0)

Copyright © 2018 Open Geospatial Consortium

6-288

Data TypeInt

Light Point Appearance Palette Record
New record for OpenFlight 15.8 (Continued)
Offset380

Length
4

Float
Float

384
388

4
4

Float

392

4

Float

396

4

Float

400

4

Float

404

4

Copyright © 2018 Open Geospatial Consortium

Description
Flags (bits, from left to right)
0 = reserved
1 = No back color
TRUE = don’t use back color forbidirectional points
FALSE = use back color forbidirectional points
2 = reserved
3 = Calligraphic proximity occulting(Debunching)
4 = Reflective, non-emissive point
5-7 = Randomize intensity
0 = never
1 = low
2 = medium
3 = high
8 = Perspective mode
9 = Flashing
10 = Rotating
11 = Rotate Counter Clockwise
Direction of rotation about local Z axis
12 = reserved
13-14 = Quality
0 = Low
1 = Medium
2 = High
3 = Undefined
15 = Visible during day
16 = Visible during dusk
17 = Visible during night
18-31 = Spare
Visibility range (> 0.0)
Fade range ratio - percentage of total range at
which light points start to fade (0.0 - 1.0)
Fade in duration - time it takes (seconds) lightpoint to fade in when turned on
Fade out duration - time it takes (seconds)
light point to fade out when turned off
LOD range ratio - percentage of total range at
which light points LODs are active (0.0 - 1.0)
LOD scale - size of light point LOD polygon
relative to light point diameter

6-289

Light Point Animation Record
The light point animation palette record defines the behavioral attributes of light points

Data TypeInt
Unsigned Int
Int
char
Int
Float
Float
Float
Float
Float
Float
Int

Light Point Animation Palette Record
New record for OpenFlight 15.8

Offset
0
2
4
8
264
268
272
276
280
284
288
292

Length
2
2
4
256
4
4
4
4
4
4
4
4

Description
Light Point Animation Opcode 129
Length - length of the record
Reserved
Animation name; 0 terminates
Animation index
Animation period in seconds. Note: Rate = 1/Period
Animation phase delay in seconds - from start of period
Animation enabled period (time on) in seconds
Axis of rotation for rotating animation, I
Axis of rotation for rotating animation, J
Axis of rotation for rotating animation, K
Flags (bits, from left to right)
0 = Flashing
1 = Rotating
2 = Rotate counter clockwise
3-31 = Spare
Int
296
4
Animation type
0 = Flashing sequence
1 = Rotating
2 = Strobe
3 = Morse code
Int
300
4
Morse code timing
0 = Standard timing
1 = Farnsworth timing
Int
304
4
Word rate (for Farnsworth timing)
Int
308
4
Character rate (for Farnsworth timing)
char
312
1024
Morse code string
Int
1336
4
Number of sequences (for Flashing sequence)
The following fields are repeated for each sequence represented in the light point animation palette entry.
In the fields listed below, N ranges from 0 to Number of sequences - 1.
1340+(N*12)
Unsigned Int
4
Sequence StateN - state of sequence N
0 = On1 = Off
2 = Color change
1344+(N*12)
Float
4
Sequence DurationN - duration of sequence N in seconds
1348+(N*12)
Unsigned Int
4
Sequence ColorN - color for sequence N.
Defined if Sequence state is On or Color change
For a complete description of the light point animation palette record, see “Light Point Animation
Palette Record” on page 85.

Copyright © 2018 Open Geospatial Consortium

6-290Indexed Light Point Record
The indexed light point record is one of the records that can represent a light point node.
The appearance index specifies an entry in the light point appearance palette that contains
the visual attributes of the light point.
The animation index specifies an entry in the light point animation palette that contains
the behavioral attributes of the light point.
The palette entries referenced by the indexed light point record describe the visual stateof the light point’s child vertices. Only vertex nodes may be children of light point nodes.

Data TypeInt
Unsigned Int
Char
Int
Int
Int
Int

Offset
0
2
4
12
16
20
24

Indexed Light Point Record
New record for OpenFlight 15.8
Length
2
2
8
4
4
4
4

Description
Indexed Light Point Record Opcode 130
Length - length of the record
7 char ASCII ID; 0 terminates
Appearance index
Animation index
Draw order (for calligraphic lights)
Reserved

For a complete description of the light point records, see “Indexed Light Point Record”
on page 34.

Light Point System Record
The light point system record enables you to collect a set of light points andenable/disable or brighten/dim them as a group.

Data TypeInt
Unsigned Int
Char
Float
Int

Offset
0
2
4
12
16

Int

20

Light Point System Record
New record for OpenFlight 15.8
Length
2
2
8
4
4

4

Description
Light Point System Record Opcode 130
Length - length of the record
7 char ASCII ID; 0 terminates
Intensity
Animation state
0 = On1 = Off
2 = Random
Flags (bits, from left to right)
0 = Enabled
1-31 = Spare

For a complete description of the light point system record, see “Light Point System
Record” on page 37.

Copyright © 2018 Open Geospatial Consortium

6-291

Texture Mapping Palette Record
Parameters for 3 Point Put Texture Mapping (Type 1)
The UV display type field, previously labeled Reserved in prior versions of thisdocument, has been re-labeled in the specification for OpenFlight 15.8. The physicallayout of the record was not changed.

Data TypeInt

Parameters for 3 Point Put Texture Mapping (Type 2)changes for OpenFlight15.8
UV display type field (re-labeled)
Offset388

Length4

Description
UV display type
1 = XY
2 = UV

Parameters for 4 Point Put Texture Mapping (Type 2)
The following fields were added to the end (at the specified offsets) of the parameter
subrecord.

Data Type
Float
Float

Parameters for 4 Point Put Texture Mapping (Type 2)changes for OpenFlight15.8
New Fields
Offset576
580

Length44Description
U Repetition
V Repetition

The UV display type field, previously labeled Reserved in prior versions of the
document, has been re-labeled in the specification for Open Flight 15.8. The physicallayout of the record was not changed.

Data TypeInt

Parameters for 4 Point Put Texture Mapping (Type 2)changes for OpenFlight15.8
UV display type field (re-labeled)
Offset436

Length4

Copyright © 2018 Open Geospatial Consortium

Description
UV display type
1 = XY
2 = UV

6-292

C Summary of Changes Version 16.0
Overview
This section describes the changes in the OpenFlight Scene Description between versions
15.8 and 16.0 as well as the errors contained in previous versions of this document thathave been corrected in this version.
OpenFlight version 16.0 coincides with MultiGen Creator version 3.0 and the OpenFlight
API version 3.0. The changes made for this version are:
•
•
•
•
•
•
•

“External Reference Record” on page 147“Face Record” on page 148“Mesh Record” on page 148“Light Point Appearance Palette Record” on page 148“Shader Palette Record” on page 149“Texture Attribute File” on page 149“Texture Mapping Palette Record” on page 150

Document Corrections
The errors corrected in this version of the document are described in the sections that
follow.
Header Record
The value corresponding to User defined ellipsoid for the Earth ellipsoid model field has
been corrected. It was previously listed as having a value of 5. The correct value is -1.
The corrected value is shown in bold font.

Header Record error corrected in OpenFlight 16.0 specification
Earth ellipsoid model field (corrected)

Data TypeInt

Offset268

Length4

Copyright © 2018 Open Geospatial Consortium

Description
Earth ellipsoid model
0 = WGS 1984
1 = WGS 1972
2 = Bessel
3 = Clarke 1866
4 = NAD 1927
-1 = User defined ellipsoid6-293

Face Record
The possible values listed for the Draw type field have been corrected. The affectedvalues are shown in bold font.

Face Record error corrected in OpenFlight 16.0 specification
Draw type field (corrected)

Data TypeInt

Offset18

Length1

Description
Draw type
0 = Draw solid with backface culling
1 = Draw solid, no backface culling
2 = Draw wireframe and close
3 = Draw wireframe
4 = Surround with wireframe in alternate
color
8 = Omnidirectional light
9 = Unidirectional light
10 = Bidirectional light

For a complete description of the face record, see “Face Record” on page 26.
Mesh Record
The Reserved field at offset 12, previously omitted in prior versions of this document, hasbeen documented in the specification for OpenFlight 16.0. The offsets of fields following
this field have been adjusted accordingly.

Mesh Record error corrected in OpenFlight 16.0 specification
Reserved field (documented)

Data TypeInt

Offset12

Length4

Description
Reserved

The possible values listed for the Draw type field have been corrected. The affectedvalues are shown in bold font.

Mesh Record error corrected in OpenFlight 16.0 specification
Draw type field (corrected)

Data TypeInt

Offset18

Length1

Copyright © 2018 Open Geospatial Consortium

Description
Draw type
0 = Draw solid with backface culling
1 = Draw solid, no backface culling
2 = Draw wireframe and close
3 = Draw wireframe
4 = Surround with wireframe in alternate
color
8 = Omnidirectional light
9 = Unidirectional light
10 = Bidirectional light

6-294

For a complete description of the mesh record, see “Mesh Record” on page 29.
Switch Record
The order of the fields were corrected. The affected fields are shown here.

Switch Record error corrected in OpenFlight 16.0 specification
field order (corrected)

Data TypeInt
Int

Offset20
24

Length44Description
Number of masks
Number of words per mask - the number of 32
bit words required for each mask, calculated
as follows:(number of children / 32) + X
where X equals:
0 if (number of children modulo 32) is zero
1 if (number of children modulo 32) isnonzeroFor a complete description of the switch record, see “Switch Record” on page 49.
Texture Mapping Palette Record
The parameters for warped mapping in the texture mapping palette record were corrected.
The 128 byte 4x4 Trackplane to XY plane transformation matrix was erroneously listed
where an 8 byte reserved field was located. The entire record is shown here. The
corrected field and offsets are shown in bold font:

Copyright © 2018 Open Geospatial Consortium

6-295

Parameters for Warped Mapping error corrected in OpenFlight 16.0
specification
Reserved field (corrected)

Data TypeInt

OffsetX+0

Length
4

Int

X+4

4

Int
Double

X+8
X+16

8
8*8*2

Double

X+144

8*8*2

Description
Active geometry point
0 = First warp FROM point
1 = Second warp FROM point
2 = Third warp FROM point
3 = Fourth warp FROM point
4 = Fifth warp FROM point
5 = Sixth warp FROM point
6 = Seventh warp FROM point
7 = Eighth warp FROM point
8 = First warp TO point
9 = Second warp TO point
10 = Third warp TO point
11 = Fourth warp TO point
12 = Fifth warp TO point
13 = Sixth warp TO point
14 = Seventh warp TO point
15 = Eighth warp TO point
Warp tool state
0 = Start state - no points entered
1 = One FROM point entered
2 = Two FROM point entered
3 = Three FROM point entered
4 = Four FROM point entered
5 = Five FROM point entered
6 = Six FROM point entered
7 = Seven FROM point entered
8 = All FROM point enteredReserved
FROM points transformed to XY plane by
above matrix.
8 FROM points are ordered 1, 2, ... 8. Eachpoint is (x, y)
TO points transformed to XY plane by above
matrix.
8 TO points are ordered 1, 2, ... 8. Each pointis (x, y)

For a complete description of the texture mapping palette record, see “Texture Mapping
Palette Record” on page 86.

Copyright © 2018 Open Geospatial Consortium

6-296

Indexed String Record
The length of the Index field has been corrected. It was previously listed as 2 bytes. The
correct length is 4 bytes. The corrected field and length are shown in bold font:
Data TypeInt
Unsigned Int
Unsigned Int
Char

Offset02
4
8

Indexed String Record

Length2
2
4
Length - 8

Description
Indexed string Opcode 132
Length - length of the record
Index
ASCII string; 0 terminates

Bounding Convex Hull Record
The description of this previously undocumented record has been added to thespecification. For a complete description of this record, see “Bounding Convex Hull
Record” on page 62.
Bounding Histogram Record
The description of this previously undocumented record has been added to thespecification. For a complete description of this record, see “Bounding Histogram
Record” on page 62.

Format Changes
External Reference Record
The Flags field of the external reference record has been modified to include a new bit,
Shader palette override, which is used to specify that the shader palette override thosecontained in the master file. The new bit is shown in bold font.

Data TypeInt

External Reference Record changes for OpenFlight15.8
Flags field
Offset208

Length4

Description
Flags (bits, from left to right)
0 = Color palette override
1 = Material palette override
2 = Texture and texture mapping paletteoverride
3 = Line style palette override
4 = Sound palette override
5 = Light source palette override
6 = Light point palette override
7 = Shader palette override
8-31 = Spare
For a complete description of the external reference record, see “External Reference
Record” on page 41.

Copyright © 2018 Open Geospatial Consortium

6-297

Face Record
The face record has been modified to include a new attribute, Shader index, which is used
to specify the shader (if any) that is applied to the face.

Data TypeInt

Face Record changes for OpenFlight 16.0
Flags field

Offset78

Length2

Description
Shader index, -1 if none

For a complete description of the face record, see “Face Record” on page 26.
Mesh Record
Similar to the Face record described above, the mesh record has been modified to include
a new attribute, Shader index, which is used to specify the shader (if any) that is applied
to the mesh.

Data TypeInt

Mesh Record changes for OpenFlight 16.0
Flags field

Offset78

Length2

Description
Shader index, -1 if none

For a complete description of the mesh record, see “Mesh Record” on page 29.
Light Point Appearance Palette Record
The light point appearance palette record has been modified to include a new attribute,
Texture pattern index, which is used to specify the texture (if any) that is applied to thelight point appearance.

Light Point Appearance Record changes for OpenFlight 16.0
Texture pattern index field

Data TypeInt
Int

Offset408
410

Length22

Description
Texture pattern index, -1 if none
Reserved

For a complete description of the light point appearance palette record, see “Light Point
Appearance Palette Record” on page 82.

Copyright © 2018 Open Geospatial Consortium

6-298

Shader Palette Record
The shader palette contains descriptions of shaders used while drawing geometry. It is
composed of an arbitrary number of shader palette records. The shader palette records
must follow the header record and precede the first push.

Shader Palette Record
New record for OpenFlight 16.0

Data TypeInt
Unsigned Int
Int
Int

Offset0
2
4
8

Length
2
2
4
4

char
char

12
1036

1024
1024

char

2060

1024

Int
Int
char
Char

3084
3088
3092
3348

4
4
256
256

Description
Shader Opcode 133
Length - length of the record
Shader index
Shader type
0 = Cg
1 = CgFX
2 = OpenGL Shading Language
Shader name; 0 terminates
Vertex program file name; 0 terminates(Cg Shader type specific)
Fragment program file name; 0 terminates(Cg Shader type specific)
Vertex program profile (Cg Shader type specific)
Fragment program profile (Cg Shader type specific)
Vertex program entry point (Cg Shader type specific)
Fragment program entry point (Cg Shader typespecific)

Texture Attribute File
The Wrap method fields (Wrap method u,v, Wrap method u and Wrap method v) havebeen changed to include a new possible value, Mirrored repeat as shown here. This newvalue is shown in bold font:.

Texture Attribute File Format changes for OpenFlight 16.0Wrap method
fieldsData TypeInt

Offset36

Length
4

Int

40

4

Description
Wrap method u,v - only used when either
Wrap method u or Wrap method v is set toNone
0 = Repeat
1 = Clamp
4 = Mirrored Repeat
Wrap method u
0 = Repeat
1 = Clamp
3 = None - use Wrap method u,v
4 = Mirrored Repeat

Copyright © 2018 Open Geospatial Consortium

6-299

Texture Attribute File Format changes for OpenFlight 16.0Wrap method
fieldsData TypeInt

Offset44

Length4

Description
Wrap method v
0 = Repeat
1 = Clamp
3 = None - use Wrap method u,v
4 = Mirrored Repeat

The Environment type field has been changed to include a new possible value, Add asshown here. This new value is shown in bold font.

Texture Attribute File Format changes for OpenFlight 16.0Environment
type field

Data TypeInt

Offset60

Length4

Description
Environment type
0 = Modulate
1 = Blend
2 = Decal
3 = Replace
4 = Add

Texture Mapping Palette Record
Parameters for 3 Point Put Texture Mapping (Type 1)
The following fields were added to the end (at the specified offsets) of the parameter
subrecord.

Data Type
Float
Float

Parameters for 3 Point Put Texture Mapping (Type 1)changes for OpenFlight 16.0
New Fields
Offset392
396

Length4
4

Copyright © 2018 Open Geospatial Consortium

Description
U Repetition
V Repetition

6-300

Index

Copyright © 2018 Open Geospatial Consortium

6-301

B

C

D

E

F

Binary separating plane record 40
Bounding volumes 61
overview 14
bounding box record 62
bounding convex hull record 62
bounding cylinder record 62
bounding histogram record 62
bounding sphere record 62
bounding volume center record 63
bounding volume orientation record 63
CAT data
key data record 64
key header record 63
CAT record 50
Clip region
overview 11
clip region record 47
Color palette record 70
Comment record 53
Continuation record 66
Control records
overview 16
push level record 17
pop level record 17
push subface record 17
pop subface record 17
push extension record 17
pop extension record 17
push attribute record 18
pop attribute record 18
Curve record 52
Database hierarchy 9
Degree of freedom
overview 11
degree of freedom record 38
Extension attribute record 65
Extension record 51
External reference
overview 12
external reference record 41
Eyepoint palette record 74
Faceoverview 10
face record 27

G
302

Copyright © 2018 Open Geospatial ConsortiumGeneral matrix record 60
see also Transformations
Geospecific control points 98
see also Texture attribute fileGroupoverview 10
group record 24

H

I

K
L

M

Headeroverview 10
header record 20

Indexed string record 54, 147
Instancing 18
overview 13
Key table data record 77
Key table header record 76
Level of detailoverview 11
level of detail record 41
Light point
overview 10
indexed light point record 34
light point record 35
Light point animation palette record 85
Light point appearance palette record 82
Light point system
overview 10
light point system record 37
Light source
overview 11
light source record 44
Light source palette record 81
Line style palette record 86
Linkage palette dataarc data subrecord 79
driver node data subrecord 79
entity name data subrecord 80
formula node data subrecord 78
general node data subrecord 78
Linkage palette data record 78
Linkage palette header record 77
Local vertex pool record 31
Long ID record 53
Material palette record 73
Matrix record 59
see also Transformations

303

Copyright © 2018 Open Geospatial ConsortiumMeshoverview 10
local vertex pool record 31
mesh primitive record 33
mesh record 29
Mesh primitive record 33
Morph vertex 11
Morph vertex list record 40
Multitexture
overview 14
multitexture record 55
UV list record 56NO

Name table record 71
Objectoverview 10
object record 26
Opcodeslist of obsolete 111
list of valid 109

P

Palette records 66
Pop attribute record 18

304

Copyright © 2018 Open Geospatial Consortium

Pop extension record 17
Pop level record 17
Pop subface record 17
Push attribute record 18
Push extension record 17
Push level record 17
Push subface record 17
Put record 60
see also Transformations

R

S

T

Replicate record 58
Replication
overview 14
Road construction record 45
Road path record 46
Road segment record 44
Road zone fileelevation data point subrecord 101
surface type subrecord 101
Road zone record 58
Rotate about edge record 59
see also Transformations
Rotate about point record 60
see also Transformations
Rotate and/or scale to point record 60
see also Transformations
Scale record 59
see also Transformations
Shader palette record 91
Sound
overview 11
sound record 43
Sound palette data record 81
Sound palette header record 80
Subface 11
Subtexture 98
see also Texture attribute file
Switchoverview 11
switch record 49
Text

overview 11305

Copyright © 2018 Open Geospatial ConsortiumTexturetext Record 48

supported formats 93
Texture attribute file
overview 93
format 94
geospecific control point subrecord 98
subtexture subrecord 98
Texture mapping paletteparameters for 4 put texture mapping 88
parameters for put texture mapping 87
parameters for radial project mapping 89
parameters for spherical project mapping 89
parameters for warped mapping 90, 146
texture mapping palette record 86
Texture palette record 73
Texture pattern file 93
Trackplane palette record 74
Transformations 58
general matrix record 60
matrix record 59
put record 60
rotate about edge record 59
rotate about point record 60
rotate and/or scale to point record 60
scale record 59
translate record 59
Translate record 59
see also Transformations

U
V

UV list record 56
Vector record 61
Vertexoverview 11
morph vertex list record 40
vertex palette header record 67
vertex with color and normal record 68
vertex with color and uv record 69
vertex with color record 68
vertex with color, normal and uv record 69
Vertex306

Copyright © 2018 Open Geospatial Consortium

307

Copyright © 2018 Open Geospatial Consortium

308

Copyright © 2018 Open Geospatial Consortium