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

T2DModels being an alternate representation of the terrain and its imagery and materials, a number of restrictions are necessary to ensure client devices can consume the dataset efficiently.

All Face and Mesh nodes share exactly the same set of graphic attributes (color, textures, material, and other flags). Stated differently, the Face and Mesh nodes provide the shape of the layer while the Object node controls its appearance.

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

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

The pilot would be stored in file 2:

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

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

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

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

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

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

The location of the model origin is defined in the following manner:

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 is mounted on its winglets.

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

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

Figure 6-9. Coordinate System - Ground Based Model

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

Figure 6-10. Coordiante System - Lifeform

Cultural Feature – When a Model represents a cultural feature, the origin is the point 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

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

Figure 6-12. Coordinate System - Power Pylon

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 (opcode 49) is considered by CDB client-devices. All other transformation records (opcode 76, 78, 79, 80, 81, 82 and 94) are discarded ^[11].

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 less important 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:

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

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

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\Metadata\Model_Components.xml supplies a comprehensive list of zones that are candidates for hot spots. Typical hot spot names are Engine and Chimney to name only these two. Other zones that are of interest for hot spots simulation are wings leading edge and other surfaces subjected to friction.

Landing zones are used primarily by the Computed Generated Forces (CGF) sub-system of the simulator. 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 landing zones.

Landing zones must have a bounding box that tightly fits the landing area. If required by the geometry of the landing zone, the modeler should create a local coordinate system that is axially oriented 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 the bounding box associated with the Group Node representing the zone. The landing zone geometry must be located under the Group Node to obtain meaningful dimensions.

A Model Footprint ^[14] conceptually represents the footprint (i.e., the terrain surface outline) of a model on the ground. The Model Footprint is modeled as a set of OpenFlight Face or Mesh records.

The footprint geometry should be terrain conformed using the “Surface Conformal Mode” as explained in section 6.7, Model Conforming. This instructs client-devices to conform this footprint 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 the model geometry with its XY plane ^[16].

A polygon that is tagged as Model Footprint can be used by client-devices to identify the portion of the terrain that is covered by a model. The Cultural Footprint can be used by client-devices such as:

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

Figure 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

A Model Cutout Zone conceptually represents clipping geometry that is used to cut out the terrain from a 2DModel or a 3DModel. Cutouts are typically used in conjunction with model interiors 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 consist of a simple cube. Similarly, the Model Cutout Zone for a tunnel entrance would consist of a simple cylinder or a partially-open cube (see Figure 5‑9: Modeling of Wells, Overhanging Cliffs and Tunnels).

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 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 geometry ^[17].

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 the Model 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

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 a building interior or a tunnel interior). The Model Cutout is necessary for models straddling the terrain surface and whose interior is modeled and viewed from within. The reason for this is that when 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.

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

Figure 6-22. Cutout Zone Structure

This section focuses on how to represent the interior of Models for an intelligent use by client-devices.

A Model is composed of 2 parts: a shell, and an optional interior. The shell contains both the exterior and the pseudo-interior. Client-devices need only access the shell if they do not need to penetrate and interact with the interior of the models; otherwise, they require both the shell and the interior. The shell of a Model is stored in five (5) datasets:

The optional model interior is stored in four (4) datasets:

Refer to CDB Standard Volume 7 OGC CDB Data Model Guidance section 6.5 for guidelines on Handling of Model Interiors.

A Model that is intended as a DIS entity requires a point that defines the origin of the entity’s coordinate system. This point is the center of the entity’s bounding volume excluding its articulated and attached parts ^[21].]. On a DIS network, the location of an entity is expressed relative to this point.

The following XML tag identifies the point.

Table 6-19: XML Tags for the DIS Origin

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.

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:

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, the navigation post on a ship bridge, the periscope on a submarine, or the eyes of a soldier.

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 of view lies in the local XY plane while the vertical field of view is in the YZ plane.

Table 6-20: XML Tags for a Viewpoint

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.

A 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 fuel tanks.

Table 6-21: XML Tags for 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 the coordinate of the attach 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 part of a connector and its receptacle.

Table 6-22: XML Tags for Anchor Point

The orientation of the anchor point is used to indicate how the subordinate model connects to the parent 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.

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.

Table 6-23: XML Tags for Center of Mass

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.

Many models have shapes that resemble a cube (with roughly equal length, width, and height), and thus their significant size can be simply estimated by the length of the diagonal of their bounding box. As the shape of a model departs from that of a simple cube, either with respect to aspect ratio, or with 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.

The Significant Size is used to distribute models into appropriate CDB LODs. Once a value is assigned to the coarsest LOD of a model, subsequent LODs of the same model can be distributed to subsequent 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 stored in CDB LOD 0, according to Table 3-1. On the other hand, a 2-meter park bench will appear in CDB LOD 5.

To illustrate the use of Table 6-25, take a 3D model representing a building with three representations:

The CDB LODs are first established by looking up the Significant Sizes of the three representations in Table 3-1:

We then use the vertex count to identify the Model-LOD in Table 6-25:

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.

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 or control 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 the hangar, 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 “Door Open”.

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 node is used to select which state is active. A single damage state can be active at any time.

Figure 6‑45: General Damage State Tree Structure shows the general organization of a zone with several states.

Figure 6-45. General Damage State Tree Structure

Each damage state represents the zone with a certain level of damage. This level of damage is expressed as a percentage from 0 to 100%. A level of damage of 0 % means the zone is not damaged at all. At the opposite end, a percentage of damage of 100 % indicates the zone is completely 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

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.

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 with the switch should look like this.

Table 6-28: Example of a Damage State Switch with Two Transitions

Figure 6-46. 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 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 visual appearance be for a slightly (or moderately) damaged state?”

In the DIS world, a platform is often qualified in terms of Mobility and Fire Power ^[24]. Using these two criteria, it is possible to define the following guidelines.

As a corollary, here are the definitions of normal and destroyed states.

A destroyed model should represent a platform for which both mobility and firepower are completely out of service.

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‑47: Example of a Texture Representing a Rotor, is an example of a semi-transparent texture used to simulate a rotating helicopter rotor.

Figure 6-47. 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-48. Multiple Versions of Rotating Parts

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

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

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 the leftmost child node contains the solid version of the object while the sibling nodes to the right contain increasingly blurred version of the same object.

The XML element <Blurriness> 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 child nodes.

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 of blurriness 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

A common problem in simulation is to correlate the linear speed of a model with the angular speed of its wheels. More generally, the client device simulation models often require the dimension of rotating parts. This information can be obtained from the zone extent; the bounding box surrounding a zone provides the dimension of rotating parts.

Base textures ^[25] 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.

The presence of a quarterly texture reference in model geometry tells the client-device that a quarterly texture set is available. This allows the client-device to select 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.

The presence of a monthly texture reference in model geometry tells the client-device that a monthly texture set is available. This allows the client-device to select 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.

Base textures can be supplemented with one or more ^[26] 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.

Client-devices are required to use the modeler supplied layer number to determine the order in which 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.

The following table provides the texture mapping for use with each kind of textures.

\[Number\ of\ Mipmaps = \max\left( n,m \right) + 1\]

For instance, a texture whose dimension is 2³ × 2⁴ has a total of 5 mipmaps.

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 the W field, the value of the field is a power of 2 representing the largest dimension of a (possibly rectangular) texture.

\[Texture\ Size = 2^{W}\ \]

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

For texture file whose name uses the L field, the value of the field is related to the size of the texels in accordance to Section 3.3.6 Table 3‑1: CDB LOD vs. Model Resolution (Volume 1: OGC CDB Core Standard: Model and Physical Data Store Structure).

In the case of a moving model, the OpenFlight file resides in the MModelGeometry directory; for instance, the M1A2 resides in

Its main texture is called M1A2 and resides in

The corresponding palette entry would be

In the case of a geotypical power pylon model, the OpenFlight file resides in the GTModel directory

Assuming its texture is called Pylon, it resides in

The corresponding palette entry would be

In the case of a geospecific model, its OpenFlight file resides in the GSModelGeometry directory. An example is

If the model refers to a geospecific texture, it resides in

The corresponding palette entry would be

If the model refers to a geotypical texture, it resides in

And the corresponding palette entry would be

In the case of a tiled 2D model, its OpenFlight file resides in the T2DModelGeometry directory. An example is

If the model refers to a geospecific texture, it resides in

The corresponding palette entry would be

If the model refers to a geotypical texture, it resides in

And the corresponding palette entry would be

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 the shadow polygons.

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 of operation. Below are two examples of the same tank, the M1A2 Abrams, painted for operation in a desert area (Figure 6‑51) or in a forest area (Figure 6‑52).

Figure 6-51. The M1A2 Abrams with Desert Camouflage

Figure 6-52. The M1A2 Abrams with a Forest Camouflage

The two different textures for this tank qualify for use as skins since they have been designed in such a way that they can be exchanged for one another without affecting their mapping on the affected polygons.

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 that can 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‑53: M1A2 Desert Skin Mosaic below shows one of the M1A2 skins.

Figure 6-53. M1A2 Desert Skin Mosaic

The following texture kinds implement the concept of model skins:

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 case of 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 base texture 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.

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 the appearance of a Model. It is possible for a Model to have both a night and a light map, or just a light 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 the model 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 to incorporate 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 with interior lights. A light map acts as a (colored) filter to mask portions of the model that are no longer visible at night when no ambient light exists.

A Model may have a relatively different aspect at night. This difference comes from two changes in the environment. The ambient illumination provided by sunlight is totally absent at night; only the moon and man-made light sources affect the appearance of objects. When present, 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 version of 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 to come out of its windows because the average daytime sunlight overwhelms any man-made lighting (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 the windows appear white.

Night maps are used to add details to base textures; details that are not visible during the day and that 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‑54: 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 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-54. BaseTexture

Figure 6‑55: 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 appearance of the cockpit windows as well as the presence of colors in them. Remember that this texture is used to add details that may be missing from the base texture.

Figure 6-55. Night Map

Light maps also fall under the category of subordinate textures. Night maps and light maps are both 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.

Light maps differ from night maps in that they combine the effect of exterior lighting with interior lights. A light map acts as a (colored) filter to mask portions of the model that are no longer 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 the illumination pattern that represents the spotlight illumination on the building. The technique provides a convenient mean to produce interesting and entirely predictable lighting effects without resorting to computationally intensive local light sources. Their effects are already incorporated 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 night map.

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 that a light map is not applied directly to the model base texture. The light map is first modified to take into account the ambient lighting, and then the resulting lighting is applied to the model.

Figure 6‑56: Light Map, is the light map matching the base texture in Figure 6‑54: Base Texture. Notice that it combines light lobes representing external light spots with the mask associated with internal light sources from the night map. This mask is used to key in details that stay visible at night.

Figure 6-56. Light Map

Figure 6‑57: Combined Effect of Base Textures and Light Maps, shows on the actual aircraft the result of applying the light map from Figure 6‑56: Light Map to the base texture from Figure 6‑54: 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-57. Combined Effect of Base Textures and Light Maps

Figure 6‑58: 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-58. Combined Effect of Night and Light 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 the following manner into the 8-bit value of each channel:

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 equivalent ^[28]. Here, the closest value to 0.0 is approximately ±0.0039 and is obtained when the channel contains 127 or 128.

Besides this particular encoding of the normal into the RGB channels, a normal map has all the other attributes of a standard RGB texture whose format is defined in in the SGI Image File Format ^[29].

In the industry, there are at least two types of Normal Map: object-space normal map, and tangent-space normal map. Both types have their pros and cons. The CDB standard opts for tangent-space normal map. A sample is shown here.

Figure 6-59. 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 in a bluish tint of the map. A negative k-component could indicate the presence of a cliff with an overhang, for instance.

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 the range -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 the intensity of the resulting image is affected; when using a 3-component detail texture map, the color is also varied.

Figure 6-60. 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.

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.

Reflection mapping (aka environment mapping) is an efficient image-based lighting technique for 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 the rendered object.

Figure 6-61. Environment Used to Produce Reflection Map

Figure 6-62. Resulting Reflection Map

Figure 6-63. 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 the exact reflection by tracing a ray and following its optical path. The reflection color used in the shading 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 computationally expensive since the radiance value of the reflection comes from calculating the angles of incidence 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 the real reflection. Environment mapping relies on four assumptions:

A gloss map is a texture that describes whether a surface is matte or gloss. The texture is used to modulate 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 shininess value found in the OpenFlight material assigned to a polygon. In this way, the gloss map can effectively modulate the specularity on a per-pixel basis. Note that if the material applied to the surface has no specular component, then the gloss map has no effect.

Material textures fall under the category of subordinate textures. They are mapped to Models the same way as any other textures. As such, the surfaces these textures are mapped to possess their own 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 a base 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 an implementation 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 is conceivable that multiple layers and mixtures of materials are required to represent the rich variety of materials found on the earth surface. However, for Models, a single material layer is probably adequate for the vast majority of man-made objects.

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.

For cultural features, their feature code is specified in the following manner:

<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 the feature attribute described in section 5.7.1.3.24 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].

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 texture name corresponds to the TNAM field in the texture filename as defined in Section 3.5.2.1, MModelTexture Naming Convention.

The <Dataset>, <Kind>, and <Index> fields correspond respectively to the dataset number and component 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 value of this field is used to compose the W field in the texture filename of moving models (see examples in section 3.5.2.4).

The texture resolution is expressed in texels per meter ^[31]. 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 to provide 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.

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.

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 a unique 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 the selected textures. Note that a state (e.g., a skin) may require more than one texture, hence the need to specify a list of textures associated with a state.

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>

</Configuration>

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

The location of a station is defined by its fully qualified name as specified in section 6.5.5, Model Zone Naming.

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.

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, the NATO 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 the following 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

<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 of such 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. Each missile 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.