Round-Earth VRSG Terrain Architecture

MVRsimulation's round-earth VRSG terrain architecture (US Patent 7,425,952) represents the earth’s surface in a geocentric coordinate system, which accurately represents the curvature of the earth and handles ordinate axis convergence at the poles. The VRSG terrain architecture provided in our proprietary .MDS format, solves a variety of problems associated with projection-based, monolithic visual databases, such that improvements are realized in database production, distribution, storage, and update, as well as in many runtime and mission function benefits. MVRsimulation has provided a round-earth virtual terrain for more than 10 years. 

MVRsimulation has built seamless geospecific VRSG terrain of:

• Continental USA plus AK and HI (CONUS++) at 1-meter per pixel resolution with high-resolution insets of areas of interest (AOIs) that include several ranges, urban training sites, and airports and airfields.
• Most of the world at 15-meter per pixel resolution with many high-resolution 60 cm insets of AOIs.

Background

Most simulations represent the terrain database using some type of map projection.  A map projection projects the earth's curved surface onto a flat X-Y plane, allowing the simulation to operate in a simpler coordinate system. This is very common in game engine based simulations where there is an assumption of a bounded gaming area which limits your overall ability to simulate large regions of terrain. Common map projections used by visual simulation systems or game engines include Flat Earth, and Universal Transverse Mercador (UTM).  While map projections simplify the mathematics of the simulation, they come at a significant cost of fidelity, leading to negative training. 

The shortcomings to map projections include:

Inability to represent earth curvature.  A credible JTAC simulation includes manned aircraft and UAVs, operating at distances and altitudes where earth curvature is a factor in accurate line-of-sight calculations. Close air support (CAS) simulation requires very large areas at very high altitude down to the ground level. Credible CAS mission simulations are not relegated to the bounding area of the training range.

Inability to accurately calculate target coordinates. Target coordinates must be calculated using known aircraft location, orientation, and sensor pointing direction. A terrain representation that models earth curvature and does not use a projection is required to accurately calculate target coordinates from aircraft telemetry.

Inability to properly handle axis convergence. Map projections suffer from the problem of non-uniform scale. Map projections are most accurate at their origin, with the projection error increasing as the location gets increasingly distant from the origin.  This creates fidelity issues for any gaming area of significant size.  

The round-earth geocentric coordinate system used by MVRsimulation's VRSG terrain overcomes all of these shortcomings and incorporates some unique features as described in our patent. The representation is projection-free and accurately accounts for earth curvature. There are no axis convergence issues, even at extreme latitudes. The representation ensures that intervisibility queries accurately account for earth curvature, and target location computations are accurately computed.

Most image generation systems have difficulty working in a geocentric coordinate system. Furthermore, since there is no XY plane onto which the database has been projected, classic tiling schemes used for database paging do not map well into the geocentric environment.

The following goals of VRSG terrain address all the shortcomings of the classic projection-based database architecture:

• A geocentric terrain representation to accurately represent earth curvature and handle polar regions correctly.
• A pageable format to enable databases of arbitrary resolution and geographic coverage.
• Support for sparse coverage where the areas to be included in the database need not be rectangular.
• A metadata-free design whereby the indexing overhead of the terrain data does not scale with geographic coverage or resolution of the source data.
• The ability to update small regions of the database in short periods of time without the need to restart the run-time system.
• The ability to incrementally update the database by adding to its coverage or updating pre-compiled regions with newer source data.
• A more robust database generation process that can be parallelized and restarted following computer or software failure.

VRSG terrain format defined

Projection-based database architectures typically subdivide the XY extents of a desired geographic region into small, uniformly-sized, rectangular areas commonly referred to as tiles or patches. The geographic coverage of the entire database is then a mosaic of these tiles, provided in our proprietary .MDS format. Database tiles typically represent a unit of database compiler output, a load module or unit of paging by the runtime system, and/or a unit of culling by the runtime system. A key and enabling component to VRSG terrain is the use of a more general atomic geometric primitive as the database tile: the triangle.

In the VRSG terrain architecture, an ellipsoid model is subdivided into a set of triangles using what is known as a "geodesic tessellation." A geodesic tessellation of an ellipsoid has the property that the triangles generated are nearly equal in area, and nearly equilateral in shape. A geodesic tessellation starts with a seed polyhedron consisting of a handful of triangles. Each triangle is subdivided into four by bisecting each of the three triangle edges. Upon bisection, the newly created vertices are then placed on the ellipsoid. This recursion continues until the desired level of tessellation is achieved.

The above set of images illustrates how a seed polyhedron converges to a target ellipsoid after 3 levels of recursion in the geodesic tessellation process. We have determined that for a fixed-wing simulator application with a visibility range requirement of 200 km, the surface area of each database "tile" should be on the order of 100 km2. A 100 km2 tile with a 200 km visibility range strikes an efficient balance between the number of addressable tiles in the scene, and the manageable unit of data to demand page from disk in an atomic operation. To achieve a tile size of approximately 100 km 2, nine levels of recursion over the WGS84 ellipsoid are required, yielding 5,242,880 total triangles. Across the entire set of triangles covering the WGS84 ellipsoid, the areas of these triangles range from 90.0 km 2 to 117.3 km 2.  

Textured view in the Model Viewer of a terrain tile from the Yuma Proving Ground terrain dataset.

Wireframe view in the Model Viewer of a terrain tile from the Yuma Proving Ground terrain dataset.

Each tile is represented on disk by a single file. The filename is a bit pattern that records the recursion history of the tessellation process leading to any given tile. This naming convention ensures that unique and repeatable filenames will be generated. It also negates the need for explicit indexing information. Recall that eliminating metadata from the database representation prevents overhead that would grow with geographic extent or increased resolution of source data. Thus, a metadata-free design is an important property that helps achieve this goal.

Each tile is stored in a coordinate system that is a linear transformation of the Earth-Centered, Earth-Fixed (ECEF) reference ellipsoid. The geometry is stored in a local floating point coordinate system to reduce the dynamic range of working values. In this local transformation the Z axis is the tile’s local surface normal and aligns with the ellipsoid normal. The local origin is the center of the tile, and the X and Y axes lie in the plane of the tile’s defining triangle. The orientation of the X and Y axes can be chosen arbitrarily and is optimized under other considerations. When rendered by the runtime system, each tile is rotated and translated into the current viewing coordinate system.

Implications for terrain database compilation

For the terrain database compiler, each tile represents a single unit of work. Thus the database can be updated or extended in 100 km2 chunks. The database compilation process only ever risks the time required to generate a single tile (on the order of minutes). Multiple database compilation processes work in parallel on independent tiles within the desired geographic region(s) of interest. In the event of a hardware or software failure, the database compilation process can be restarted, picking up where it left off. The only work lost is the time taken to produce the last partial tile at the point of failure.

Another attractive property is that a given database compilation process, working on a potential sub-region of the entire area, need only see the source data that is relevant to that sub-region. This enables the database generation process to begin before the entirety of source data has been received or pre-processed. This also allows source data to be spread across multiple computers, each computer contributing to a different sub-region of the entire area mitigating the need for very large single volume storage such as a RAID.

The VRSG terrain compilation process also affords a more pipelined visualization process. Under monolithic database generation processes, the procedure was serial in nature where the time to produce the database was the sum of each of the following subtasks:

1. Acquire source data.
2. Modify, correct, or enhance source data.
3. Compile the visual database.
4. Verify the visual database in the run-time system.

The round-earth VRSG terrain architecture is fundamentally a pipeline where all four steps occur in sequence but on time scales in the range of a few minutes. For example, as source material is acquired, it can immediately be modified, corrected, and enhanced for the compilation process before all source material arrives. Whatever source material is available can be given to the compilation stage to produce any covered tiles. When each tile is compiled, the result can be immediately validated in the run-time system without waiting for any other portion of the desired coverage area to be completed.

This pipelined architecture is also highly scalable. Since each compilation is independent, the database engineer can devote an arbitrary number of compilers to the task at hand. In practice on datasets of varying resolution and constituent source data over using up to ten compilers, the performance is nearly linear in the number of compilers. We anticipate that for 1Gbps networks and commensurate storage media this performance would scale up easily to an N of 100 or more. At some point the theoretical bottleneck become the communication time (either reading/copying source data, or writing/flagging completed tiles). With 10 Gbps networks becoming commonplace, this bottleneck is further loosened and the linear range will increase further yet.

Implications for mission functions

Simulators are often dependent on the terrain database for such functions as elevation lookup and point-to-point intervisibility tests. While the VRSG terrain architecture may appear on the surface to be difficult to support mission function features, we have found this not to be the case. Optimized terrain elevation lookups and intervisibility tests have been developed that exploit the recursive and hierarchal nature of the design and are very efficient. For example, MVRsimulation's Virtual Reality Scene Generator (VRSG) implementation of an elevation lookup is as fast as 20 microseconds, and point-to-point intervisibility lookups as fast as 100 microseconds. These speeds are comparable to conventional, projection-based, terrain database implementations and in some cases even faster.

The advantages to the geocentric-based visualization architecture are quite obvious for point-to-point intervisibility tests. Particularly, long-range intervisibility tests, where curvature of the earth becomes an issue for the projected coordinate systems, are properly handled. The projected database fails to produce accurate results under such circumstances.

Custom compacting of terrain scenarios

The VRSG terrain architecture provides a convenient mechanism for assembling custom terrain databases that draw together disparate geographic regions. Within the architecture the population of geodesic tiles may be sparse at run-time. Each tile is in fact an independent database in our proprietary .MDS format. This sparsity can be exploited in situations where disparate training objectives need to be consolidated into a single scenario.

Consider an example scenario that includes ground attack, coastal over flight, surface-to-air missile evasion, and nap of the earth terrain following. In conventional database architectures, a database design and supporting source data would necessarily have to be contrived. The development process would not be re-usable and the resulting play-box would be geographically inefficient. Within the VRSG terrain  architecture, specific and disperse geography can be brought together simply by addressing modular tiles built from source data of the desired regions.

VRSG terrain use in the field

The VRSG terrain architecture is used for building 3D terrain with MVRsimulation's Terrain Tools for Esri® ArcGIS® for visualizing in MVRsimulation's VRSG. Such terrain has been has been implemented in numerous cases by MVRsimulation’s customers, such as cross-service exercises covering hundreds of geocells. The scalability and robustness of the architecture proved invaluable throughout the preparation, fielding, and training stages of the exercise. Not only were multiple hardware resources brought to bear against the magnitude of the terrain compilation on this geographic scale in order to achieve a short deadline, but the constraints on storage of the resulting terrain were relaxed due to the autonomy of VRSG terrain tiles (with no monolithic database, there was no need for large single volume disks). Further, over the course of the fielding process, VRSG terrain tiles built with initially low-resolution source data were updated with improved and higher-resolution source data and "integrated" simply by adding directory references to VRSG's list of available terrain.

The payoff for the development of this terrain architecture was realized in the visualization component of this exercise. The geocentric coordinate system used for the terrain representation enabled accuracy in simulation of targeting and intervisibility operations that did not degrade as a function of range. This was one of the key goals noted above and results in better training of operators, pilots, navigators, and drivers. Likewise, the terrain sparsity (distributed, non-rectangular nature of the virtual database) afforded modular configuration of terrain for each system being simulated. Any given simulator was burdened only with the terrain needed to accomplish its training task, but that terrain came from a central pool shared by all the simulator assets.

(April 2023)