For a long time, I've been annoyed that there is no comprehensive terrain runtime format that fulfills all of the following requirements: - Whole Earth capable - Allows geospecific terrain - Accelerates collision queries - Looks good ("game good") - Incremental download - Underground/overhang/indoors - Pageable/chunked file access - Open (not tied to a vendor) - 64-bit clean - Extensible - Robust So, I've worked for the last year, with the help of some engineers at my company (Forterra Systems), to build such a terrain runtime format. For those not familiar with simulation terminology: "terrain" is to simulations what "level geometry" is to games. We are now releasing the specification, as far as we've gotten it, for public comment. We are also planning on releasing an API that lets you open, read, create and write files in this format (we call it PTF). An implementation of this API will be released as open source later this year. If you are interested in simulation, virtual world, or game interoperability, and are interested in terrain geometry representation, please go register at the site where I've posted it, download the PDF, and post your throughts. File: http://www.interopworld.org/members/ptf Registration: http://www.interopworld.org/members/user/register [Edited by - hplus0603 on October 9, 2007 6:14:19 PM]

As an open runtime format, with support for paging, it has to be binary. You can't really do paged access into an XML document, because you don't know where things live until you've parsed the entire document.

Being 64-bit clean, you "could" store all of Earth in it, and get a petabyte-sized file. Still, when opening it (assuming you had a large, fast storage system), you would very quickly seek to the part that's interesting to you, and page it in, effectively ignoring 99.99999% of the data. You can't do that in XML.

I don't have screen shots yet. We don't have a fully developed data set, we mostly have programmer art -- once it's robust enough, we'll have real art :-)

The "looks good" part should really be "allows content to look good" -- we don't specify policy, but instead allow you to put in enough data to make it look good on your system, while still staying interoperable with others. Some standards out there don't really allow that (SEDRIS, c2db, TerraPage, etc).