This section discusses the proposal to use the Khronos GL Transmission Format (glTF) to encode and store 3D models in the CDB-X data store. This section also describes the prototype testing performed during the 3D Geospatial Series Tech Sprint II – OGC CDB 2.0. In CDB, 3D models are such phenomenon as trees (static), buildings, transmission towers, or helicopters (dynamic).
Currently, the OpenFlight specification is used to define all the 3D models in a CDB data store. The current OGC CDB 1.x core standard and Volume 6 CDB Rules for Encoding Data using OpenFlight specify all of the rules and requirements for using OpenFlight models in a CDB data store. The early advantage OpenFlight held over many 3d geometry model file formats (.obj, .dxf, .3ds) was its specific real-time 3d graphics industry design.
For CDB X, the participants in the Sprint agreed that a more modern 3D model encoding and transmission format should be explored. Based on wide adoption and use in many domains, the Khronos glTF 2.0 specification was selected for further research and prototyping. A key part of this activity was to perform a detailed analysis of glTF functionality as compared to OpenFlight capabilities. The participants agreed that no (or as little as possible) functionality should be lost. NOTE: glTF will not be a replacement for OpenFlight in a CDB data store. Instead, glTF is recommended as the preferred encoding for CDB 3D Models. There are a few OpenFlight to glTF conversion tools.
The remainder of this section discusses the findings of the comparison as well as lessons learned from the prototyping activity.
Following are some of the questions and suggestions for experimentation that the 3D Modelling Subgroup initially identified as needing further discussion and possible experimentation. These formed the basis for the specific questions and approaches uses in the CDB-X 3D Prototyping and Experimentation.
-
Models should also be stored as files such as OpenFlight or in GeoPackage.
-
Models preferred to be in glTF or OpenFlight but later consider I3S, 3D Tiles, CityGML and other encodings)
-
Textures shall be xxxx format (png, jp2). Question: Power of 2 enforced? {Not sure what this means}
-
UV Map with model?
-
Naming convention tbd - should have some metadata use - indexing? directory path? layer? featureID?
-
LoD Structure: MS LoD extention for glTF valid for CDB work? Model LoDs have vertex count, significant size etc… and have their own LoD table which is not the same as tiled LoDs.
-
Describe model placement.
-
Point features
-
Terrain Reconstruction
-
Elevation
-
Imagery
-
Polygon features (Formerly aerial features in CDB 1.1 and earlier).
-
Linear features
-
-
Is there a way to map glTF Material vs CDB physical material?
There was some discussion of whether there needs to be a CDB catalog service for 3D tile(s) referenced to a tile.
Based on the questions and follow-up discussion, the CDB X participants derived the following requirements for CDB-X model components.
Requirement |
Objectives |
Improve interoperability with OWT |
* Align 3D model geometry attribution in order to support conversion between the two standards. Test that conversion in both directions. |
Serve archiving/repository use case and runtime usage |
* Package 3D models LODs in an easy to edit manner while allowing fast runtime access of independent LODs. |
Modernize CDB |
* Support newer 3D encoding formats (glTF initially) |
Support SOF use cases : Same dataset for M&S and C2 including the mission command and TAK devices |
* ATAK: Support 3D view and attribution |
The following are the short and medium term objectives for the 3D Model Prototyping and Experimentation. These design objectives are based on the initial set of questions posed by the CDB-X participants.
-
Support more 3D model encoding with metadata detailing which is used. Preserve OpenFlight (and potentially improve its usage), add glTF with extensions.
-
Reduce file count and package models better while providing enough indexing data to allow readers to quickly extract only what they need. Metadata/catalog - support editing/replace use case.
-
Address GS, GT, model instancing.
-
Support Building interior with navigation mesh and collision mesh.
-
Encode 3D models in glTF.
-
Node grouping, LOD grouping in json.
-
Define CDB extensions for glTF.
-
Look at tools to allow CDB attribution editing.
-
-
Model packing with MetaData
This experiment uses a GeoPackage comprised of a point feature table with attribution.
The following current CDB attribute changes were explored.
-
CNAM - no longer needed
-
FACC - FSC - Change to GGDM - impact on field type
-
MLOD - (LOD of the model to use) This is closely linked to tiling and LODs of vector where each point features would point to a model at a given LOD (should be lower than feature vector LOD). Presume at the moment we keep this.
-
MODL - (Name of the model to use). In this case, we should point to a metadata file for the model. Alternatively, the content of the metadata could be encoded in GeoPackage - which is bad for tool operability.
A key challenge to resolve was how to link the model data with the feature data. Currently, the MLOD and MODL are composed and lookup into the tile index of the point feature. Is that functional capability (approach?) preserved? Do we use a model table in Geopackage with a primary key? As decided, models would remain separate files and not encoded in a GeoPackage. So, a unique file name was required for this experiment.
OpenFlight (or .flt) is an open, freely available 3d geometry model file format originally developed by Software Systems Inc. for its MultiGen real-time 3d modeling package and now actively maintained by the OGC member Presagis. OpenFlight is an open format, binary encoded with support for user extensions, which is supported widely in modeling and simulation community for dynamic and static 3D model. OpenFlight has numerous constructs that have no equivalent to date in other open standards. In CDB 1.x, OpenFlight is used for the representation of 3D static and dynamic models and RGB format for the 3D model’s textures. OpenFlight is now an OGC Community standard.
The 3D model group recommends that a new CDB standard adopts the latest version of
OpenFlight, leveraging the extended materials, hot spots and other important
constructs it brings.glTF is a royalty-free specification for the efficient transmission and loading of 3D scenes and models by applications. glTF uses the JSON standard for encoding most content except for geometry and animation data. glTF is an API-neutral runtime asset delivery format developed by the Khronos Group 3D Formats Working Group.
glTF 2.0 GitHub repo and description.
KHR_lights_punctual is an extension that defines a set of lights for use with glTF 2.0. Lights define light sources within a scene.
MSFT_lod is an extension that adds the ability to specify various Levels of Detail (LOD) to a glTF asset.
EXT_mesh_gpu_instancing is an extension that is specfically designed to enable GPU instancing which renders many copies of a single mesh at once using a small number of draw calls. It’s useful for things like trees, grass, road signs, etc.
FB_geometry_metadata is an extension that annotates glTF scene objects with a summary of the cumulative geometric complexity and scene-space extents of the scene’s associated scene graph. Editors note: While the computed total vertex and primitive count are metadata this is very limited metadata and may not meet the needs of the CDB X community.
KHR_materials_unlit is an extension that defines an unlit shading model for use in glTF 2.0 materials, as an alternative to the Physically Based Rendering (PBR) shading models provided by the core specification.
KHR_texture_transform is an extension that adds offset, rotation, and scale properties to textureInfo structures. These properties would typically be implemented as an affine transform on the UV coordinates.
AGI_articulations is an extension that adds articulations that define the names and ranges of allowable motions of nodes on a models. The extension includes articulation stages, pointing vectors, and attach points.
Original Prototyping Experiments - Keeping for now but will delete when this section is more mature.
Two profiles.
Profile 1 Storing the mesh in an 3D tile: Experiments to address:
-
Question: How to store LODs? In glTF extensions, In 3D tiles, in separate glTF
-
Question: Are there missing glTF constructs?
Profile 2 Storing the mesh in as 3D tile (Editor’s note: Why just 3D Tiles? Why not a more general approach that allows other encodings/approaches?)
-
Question: What is the ability to source edit the mesh?
-
Question: Mixing GeoPackage with 3D tiles?
-
Question: CDB catalog service for 3D tile inside a tile
Both Profile 1 and Profile 2
-
Question: What are the efficient format/packing for each different end-points:
-
ATAK
-
Mission command (wms/wfs)
-
Modsim
-
Gaming
-
One of the objective of the 3D model refactoring in CDB is to facilitate the editing {Update} process. In the CDB 1.X environment, 3D model encoding is hard because:
-
The OpenFlight format has fewer editing tools than in newer 3D formats {Give an example}. This situation led the 3D subgroup to investigate the glTF encoding for possible use in CDB-X.
-
The CDB 1.X model components (geometry, texture, metadata) as well as the Level of Detail (LoD) for those components are stored in different folders. This distribution is not well supported by editing tools and edits often require updating many files, including collections contained in Zip files. Therefore the 3D subgroup investigated a grouping for all 3D model components.
While investigating these potential solutions, understanding the motivation and design requirements behind the original CDB structure was required so as to properly assess the impact of the changes against the original design criteria. This would include a determination on the current installed CDB user base.
CDB 1.X Geospecific 3D models were likely motivated by:
-
A single encoding (OpenFlight) for 3D model geometry: At the time of the development of the original CDB specification, OpenFlight was the most adopted and used format for 3D models in the Modeling and Simulation industry. OpenFlight meet the requirements for an open format, an efficient binary encoding, and an editable source format supported by a number of tools. Having a single possible encoding increases interoperability by reducing the number of encoding to support on both the CDB producer and the consumer side. Supporting different encodings (OpenFlight and glTF) may result in less interoperability. In some cases, multiple versions of a CDB with the different encodings may be required as different consumers may only support one encoder.
-
Facilitate parallel access to all components as opposed to sequential access. By grouping all components into datasets (textures geometry, material etc…) into tiles and LODs, a client can assess which tile and component is required and fetch all components in parallel. In other words, without having to read the result of a request before sending a new request (like waiting for geometry to identified {Confusing here. Not sure what to write} referred textures and materials).
Focusing on GeoSpecific models
The initial experimentation targeted Geospecific models inside the CDB structure. This was because they represent the greatest challenge. The GeoTypical models still need to be reviewed. However, the belief is that a sub-set of the GeoSpecific concepts can also be applied to GeoTypical models. The tasks describe below document the investigation along with the results:
OGC CDB 1.X relies on a number of OpenFlight constructs that have no equivalent in glTF. One of the first task of the group was to list all OGC CDB 1.X requirements with regard to 3D model encodings and assess whether glTF has equivalent constructs. The following provides details of the resultes of the analysis.
Some thoughts on supporting more than CDB 1.X: OpenFlight capabilities that could be leveraged:
-
Extensions
-
Extended Materials
-
Hotspots
-
LOD Transitions
-
Cultural Footprint
-
Point Nodes (Model Points instead of using tranforms)
EXT_CDB is a draft glTF extension that adds required CDB simulation capabilities identified as missing from glTF. The new (and prototype) capabilities include:
-
Indicating that a glTF node is a certain type of CDB point: Attachment point, anchor point, center of mass, DIS origin, or viewpoint.
-
Referencing light points from glTF nodes.
-
Attaching CDB zones to glTF nodes.
-
Assigning switch nodes to a glTF node to represent damage states.
-
Storing model attributes on a glTF node.
-
Extending materials with CDB texture types: Detail texture, contaminants texture, and material map texture.
The full schema can be found here.
The CDB glTF extension contains most of the required CDB-specific features. However there are some possible additions that could be made:
Coordinate reference system (CRS) Openflight can store the CRS of a model in its header and this capability is currently not possible in glTF. While not strictly required for CDB (A CRS of WGS 84 (EPSG 4326 and EPSG 4329) is mandated by the CDB standard), the 3D subgroup determined that this would be useful for interoperability. There is also interest in such an extension for One World Terrain (OWT). Therefore, specifying a CRS should likely be done as a stand-alone extension and not as part of the CDB glTF extension
Per face metadata The current OpenFlight specification allows for storing materials or relative priority per-face. However, in glTF faces are usually collapsed into meshes so there is no way to store information per polygon. With the current extension, the solution would be to group polygons with the same relative priority and material into a single mesh and store the information at the mesh level.
There is an OWT extension in progress to enable storing metadata at the feature level. This extension currently supports storing per-vertex metadata but that extension could possibly be expanded to support per-face metadata and used in a CDB datastore.
External References This is one of the larger challenges encountered during our investigations. In the past there was discussion about including an external reference extension in glTF but the Subgroup decided not to include such an extension. In past cases, separate index files were used to reference multiple glTF files from a common source. This is sufficient for some cases but does not help for the use case of sharing geometry between multiple models. For example sharing common roof clutter objects between different buildings
One of the challenges was deciding which CDB capabilities belong in EXT_CDB and which belong in standalone extensions. This is especially true when judged by an extension’s utility to the wider glTF ecosystem. The 3D subgroup also investigated whether leveraging existing glTF extensions is possible. Finally, the 3D subgroup determined that some capabilities should go in the model indexing file rather than in the glTF. Our recommendations are below:
The EXT_CDB extension
-
CDB-specific constructs such as points, zones, lights, light maps, and extended texture types.
Possible standalone extensions
-
Coordinate Reference System - Shared interest with One World Terrain and possibly wider glTF ecosystem
-
Switch nodes - Shared interest with One World Terrain moving models format
-
External references - Some interest in wider glTF ecosystem, but many unresolved implementation details
Leverage existing extensions
-
Articulations - AGI_articulations
-
Metadata - EXT_feature_metadata - extension for storing metadata at different levels of granularity - per-mesh, per-face, per-vertex, and per-texel. This could be a good candidate for CDB model attributes and material map textures.
Model indexing file
-
Model LODs
-
Interior and exteriors
-
Navigation and collision mesh
The initial approach was to create a monolithic CDB glTF extension so that editors and viewers would only need to support a single extension to load CDB glTF models. However, the 3D subgroup determined that there was a significant amount of overlap between CDB and OWT requirements and shifted towards a more granular approach to avoid multiple redundant extensions being developed. Generally glTF extensions that have seen wider adoption are both simple and useful to a wide variety of vendors. Suggested next steps are to collaborate more closely with OWT stakeholders and reach out to the wider glTF community for review. This review would be followed by practical experimentation in runtime engines. After OGC review and agreement, the extensions may be formalized as either ratified Khronos extensions (KHR prefix) or, more likely, Multi-Vendor extensions (EXT prefix), and be listed in the glTF Extension Registry.
Another key topic for adoption is editor support. glTF has seen increasing adoption in 3D modelling software such as Blender, 3DS Max, and Maya but extensions are often lost during the import/export process. Workarounds have been proposed such as storing extension information outside of the glTF container (see The glTF Metadata File (GMDF) for Systems Tool Kit (STK)). Some capabilities like per-face feature assignment are not possible in standard modelling packages and would require plugins. The most likely path of adoption is native support for the extensions in simulation editors and plugins for more general purpose 3D modeling software.
Above are some images of a tank 3D model in both formats. This model was selected as benchmark as it contains a number OpenFlight specific constructs leveraged in the CDB standard. Converting this model will exercise {exercized?) many of the proposed glTF extensions.
Small CDB size comparisons (898 GS models - without textures)
Comparing the size of the 300_GSModelGeometry and 303_GSModelDescriptor folders from the source CDB to the 999_ModelGeometry folder in the converted CDB {models?}:
Format |
Size |
Openflight |
11.0 MB |
Ascii gltf |
9.16 MB |
Binary glb |
6.83 MB |
Size comparison for a single very large model
Format |
Size |
Openflight |
16.7 MB |
Ascii gltf |
9.27 MB |
Binary glb |
10.78 MB |
In the CDB test case, the Ascii glTF file is slightly smaller than the Openflight file and the binary glb is almost twice as small. In the test case with a single large model, both the binary and ascii glTF provide a significant improvement in space savings. However, in this case the binary file is actually slightly larger than the ascii glTF. The reason for this is not entirely clear, but it seems to be an outlier based on teh results of the other tests.
Storing the 3D models in a CDB datastore can be either in files and folders or inside a GeoPackage. Where the prototype stopped short of packing {Packing where} the resulting glTF files, a number of elements need to be considered when this gets {When what gets?} investigated. Those are:
File based approach
-
Use zip: One challenge of using the CDB 1.X stadnrd is the large number of files that are created. Where many small files are not optimal on I/O, putting all datasets into one large file would lead to a large volume of data needing to be scanned to extract what is needed {NOTE: This was investigated in the OGC Testbed 16 GeoPackage activity. Some interesting recommendations}. A ZIP is a good format to allow quick access to the content index in order to decode only the required data. As such, a recommendation is to group each model data into a zip (all LODs, textures etc…) while keeping the xml (index file) separate. A quick access to the index file would allow identifying what is required to be loaded into each ZIP. This way, a client server could work with a scheme similar to the OGC getCapabilities to query the available data prior to accessing the actual payload.
The grouping of all components of a 3D model together requires an index file that indexes and references all those components. The list of components proposed include: Feature attribution (GGDM), reference to source model used, model exterior, Model interior, Collision volume, and nav mesh. Splitting those constructs into separate component follows the current logic in the CDB standard of splitting the dataset in order to quickly access only required data without having to load larger component(s) that include all {All what?} only to reject most of the content. This approach also serves the purpose of rapid update by allowing changing one element without the other (update nav mesh, or interior without changing the complete model) needing to be updated.
Some consideration should be made to ensure all existing GSModelDescriptor information is migrated into this file {The index file?} (texture mapping info being one).
Duplication of information There was a request to also store the model georeferencing inside this file {The index file?}. The challenge with this is the duplication of information such as CDB positions models based on the point feature. Changing the georeferencing in this file would not lead to a change in the model position. The CDB standard typically avoids duplication of information as duplication creates confusion. In this same idea, one could argue that the model attribution (GGDB) should not be there either as this would also be duplication.
This file content and structure requires a review and alignment with the rest of the CDB metadata.
task: convert sample {sample what?} to object model and produce associated schema.
<?xml version="1.0" encoding="utf-8"?>
<!-- "Model" node includes encoding statement. Should this info be pushed down,
maybe in the geometry node? Do we allow multiple encodings all referenced
in the same indxing file?
-->
<Model encoding="OpenFlight" multi-instance="false">
<!-- "Name" has to be unique in a tile. Do we need this info or we rely on the filename
or geopackage entry name.
-->
<Name>cdb_swa_gs_hotel_03</name>
<Identification>
<GGDM>
<Code>AL015 </Code>
<Subcode>0 </Subcode>
</GGDM>
</Identification>
<!-- model_complete_source - Do we allow uses/users to store this in CDB? Where? Any format?
This model would typically include all LODs and possibly constructs not supported
by CDB. This would likely also require the storing of the source textures. As such,
a zip is likely a better container. Still, inclusion of this will increase CDB size
-->
<model_complete_source file="My_hotel_model_full_Detail.obj" encoding="obj"/>
<!-- model_exterior - Following current CDB, exterior (shell) of a model should be seperated
from interiror and other mesh representation for load/stream efficency.
-->
<model_exterior>
<LODherarchy coarsestCDBLOD="1" finestCDBLOD="5">
<RootModel> <!-- root model points to all LODs -->
<geometry file="cdb_swa_gs_hotel_03_ROOT.flt"/>
<Metadata>myFile.xml</Metadata>
</RootModel>
<LevelOfDetail LOD="2">
<geometry>
<file>cdb_swa_gs_hotel_03_L02.flt</file>
</geometry>
<Metadata>N12E044_D303_S001_T001_L02_U1_R1_AL015_000_cdb_swa_gs_hotel_03.xml</Metadata>
<!-- need to add provenance to metadata -->
</LevelOfDetail>
<LevelOfDetail LOD="5">
<geometry>
<file>cdb_swa_gs_hotel_03_L05.flt</file>
</geometry>
<Metadata>N12E044_D303_S001_T001_L05_U1_R1_AL015_000_cdb_swa_gs_hotel_03.xml</Metadata>
<!-- need to add provenance to metadata -->
</LevelOfDetail>
</LODherarchy>
</model_exterior>
<!-- model_interior - The linkage between exteriror and interior geometry currently relies on XREF in
OpenFlight in order to position/connect interior with exterior. (requirement for glTF)
Alternatively, model with the interior could be a higher LOD of an object. This is not precluded
by the standard (as long a geometry comply to CDB geometry LOD rules).
-->
<model_interior>
<LODherarchy coarsestCDBLOD="5" finestCDBLOD="5">
<RootModel> <!-- root model points to all LODs -->
<geometry file="cdb_swa_gs_hotel_interior.flt"/>
<Metadata>myFile.xml</Metadata>
</RootModel>
<LevelOfDetail LOD="5">
<geometry>
<file>cdb_swa_gs_hotel_interior_L05.flt</file>
</geometry>
<Metadata>N12E044_D303_S001_T001_L01_U1_R1_AL015_000_cdb_swa_gs_hotel_03.xml</Metadata>
<!-- need to add provenance to metadata -->
</LevelOfDetail>
</LODherarchy>
</model_interior>
<collision_volume/>
<navigation_mesh/>
</Model>This investigation was not done by the 3D group but the tiling group did experiement with merging all geometry in a time. A few different ways to encode the content are possible, each with their own implications.
-
A mesh of the terrain geometry, esentially converting the CDB elevation and imagery datasets into one dataset. Where a quick implementation is possible one must consider all sub-datasets combinaisons (bathymetry for elevation and all imagery variants) and their implications in teh CDB data model.
-
A mesh of only 3D models (not terrain) per tile. This has the benefit of improving rendering efficency as one tile. Some of the challenges to consider here are the ability to clamp individual models to terrain elevation while preserving the geometry grouping benefits. Also, the attribution on a per model basis currently contained in the vector would need to either move inside the mesh (to identify mesh segment per feature) or have a wait for the vector to reference part of the tile mesh.
Generally, this type of solution has significant impact on the CDB data model:
-
The mesh solution merges many CDB datasets into one. The elevation and 3D features along with the imagery are now all merged into one dataset.
-
The attribution to objects on the terrain is currently done in the vector, with a reference to the geometry. In a mesh case, the linkage will likely need to be revered and have the geometry link to the attribution.