MetaVR Metadesic Visualization Architecture

Metadesic™ is MetaVR's revolutionary, patent-pending, virtual terrain architecture that is designed to solve a variety of problems associated with projection-based, monolithic visual databases. Through this architecture improvements are realized in database production, distribution, storage, update, as well as many run-time and mission function benefits.

MetaVR has applied its Metadesic Compiler to build a seamless terrain of North America from 100 meter elevation data with .3m, 1m, 5m, and 15m imagery covering a 1,037-geocell area.

This page provides some background to Metadesic's underlying technology, and enumerates the benefits of moving to the Metadesic terrain architecture.

Background

Virtual terrain databases for three-dimensional visualization are typically based on some type of map projection. Some common map projections used are Universal Transverse Mercator (UTM), Geodetic, Lambert Conic, and Flat Earth among several others. A database projection warps the curved surface of the earth onto a flat X-Y plane to create a local Cartesian coordinate system that simplifies the mathematics of a simulation.

A more ideal and accurate representation of the earth’s surface is an earth-centered, earth-fixed coordinate system that accurately represents curvature of the earth and deals with ordinate axis convergence at the poles. Such a coordinate system is often referred to as geocentric. Projection-based database formats do not handle these conditions properly, creating a motivation for a geocentric database. However, 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 goals of Metadesic are to address all these shortcomings of the classic projection-based database architecture. The following summarizes the goals of Metadesic:

• 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

Metadesic 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. 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 Metadesic is the use of a more general atomic geometric primitive as the database tile: the triangle.

In the Metadesic 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.

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.

    Click an image to see a high-resolution version of the image.

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 database compilation

For the 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 Metadesic 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 runtime system

The Metadesic 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.

Metadesic’s 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 Metadesic 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, the 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 Metadesic 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. 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 Metadesic architecture, specific and disperse geography can be brought together simply by addressing modular tiles built from source data of the desired regions.

Live terrain updating

Another radical capability of Metadesic is live update of the terrain. At any time, a given tile can be compiled or recompiled and automatically instantiated in a running visualization. For example, if new imagery became available from a sensor in the field, a new tile can be generated on a time scale commensurate with the communication channel (in minutes or even seconds) and rebroadcast to any listening 3D visualizations. The new or updated tile then populates the scene as appropriate. The implication is that operations such as mission rehearsal, distributed mission training, even battle damage assessment, are transformed by a living scene. When new information is available, it can be rendered in real-time from a 3D perspective.

Metadesic use in the field

The Metadesic architecture described above has already been reduced to practice and implemented in a cross-service exercise covering hundreds of geocells by one of MetaVR’s core customers. Using MetaVR's Metadesic Compiler, 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 Metadesic tiles (there is no monolithic database, hence no need for large single volume disks). Further, over the course of the fielding process, Metadesic 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 the run-time image generator’s list of available terrain.

The pay-off for the development of the Metadesic 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.