Why CDB Matters (and yes, MAK supports it)

At its core, CDB provides a common terrain standard that ensures everyone is working with data that means the same thing across different systems. One of the biggest challenges with raw source data is inconsistency. A shapefile might store building heights in meters or feet, elevation may be above ground or sea level, and there’s no universal way to label it—one dataset might call it "Height," another "Elevation," and another might even label it as "How tall am I?" CDB eliminates that guesswork by predictably structuring terrain data.

Because of this, CDB is widely used in simulation environments, and many customers have simulators built around it. Changing terrain formats can be costly and time-consuming, sometimes requiring a complete simulator rewrite. With MAK ONE supporting CDB, users don’t have to worry about that. They can continue using their existing terrain in their existing simulators while adding a MAK ONE simulator to their system—without disruption.

Another big advantage of CDB is that it’s an open standard. Unlike other closed terrain formats, CDB is available for anyone to implement. And it’s incredibly well-documented—at nearly 1200 pages, the spec covers just about every possible use case. While that level of detail can make implementation complex, it ensures clarity and consistency across different applications.

In practice CDB is less of a single "database" and more of a structured file system. Terrain data is broken into a massive number of files, each with a specific name and place in the directory. This structure makes it easy to access and update specific pieces of terrain data without affecting the entire dataset.

By supporting CDB, MAK ensures interoperability with existing systems while giving customers more flexibility in how they manage their terrain.

MAK’s Approach to Terrain

At MAK we support various terrain formats: legacy formats like OpenFlight, Metaflight, and TerraPage, newer formats like FBX, and emerging standards like 3dTiles.  But with GIS data increasingly available everywhere we primarily focus on procedural terrains direct from that data, in the format and configuration in which it comes. Our focus on this raw source data makes our approach to CDB complementary. Instead of requiring extensive data processing up front, we load raw geospatial datasets directly into our system and use a “.earth” file to tell VR-Vantage how to interpret the data. This allows us to work with a variety of data sources, even when they store information differently. For example, if one dataset defines building height in meters and another in feet, our .earth file ensures the system knows to map those different sources into the coordinate system for the synthetic environment. 

This approach means less upfront processing, which has its advantages. With CDB, the heavy lifting is done early—you need specific tools to process the terrain before using it. MAK ONE, on the other hand, does that processing dynamically when the data is loaded. This makes it much easier to update or modify terrain without having to go through a long reprocessing step. The trade-off is that it takes a bit longer to load when you open your terrain the first time, since we define data attributes at runtime instead of baking them in ahead of time.

One of the biggest benefits of CDB is that it plays well with our procedural and dynamic terrain features. Since MAK ONE is built to work with raw source data, it naturally extends to CDB as well. At its core, CDB is just highly structured source data, so many of the things we do—like real-time terrain modifications—still work within a CDB environment. There are, of course, technical differences and limitations, but the high-level takeaway is that our approach aligns with CDB in a way that keeps things flexible and easy to manage.

At the end of the day, we like what CDB brings to the table, and by supporting it, we ensure that MAK customers can use their existing terrain without extra hassle. But we also think our approach—keeping things dynamic and flexible—makes terrain management easier, giving users more control without adding unnecessary complexity.