Paged Terrain Format (PTF) Draft Specification 2007-10-09

Len Bullard

First, I compliment Forterra for beginning this forum with a technical submission and to the company officers for signing up to the forum. The participation of Forterra in international efforts to create standards for 3D On the Web will be welcomed. Given that such efforts are judged by the participation agreements of the members of new and existing organizations, my analysis of the specification starts here. As the author has taken the time to differentiate PTF from existing standards and languages based on what it does, I begin with what it does not do:

1. Provide human-editable/readable formats or transforms to the runtime from human-readable/editable formats.

2. Does not guarantee reversibility.

3. Given 1 and 2, does not ensure in accordance with best practices, a long life cycle guarantee for the information.

The following statement is close to a PAS specification release although it does not indemnify extra-Forterra implementations and Forterra customers.

"...no royalties charged by us to read or write the format. We may
even provide a small, simple reference library to do basic operations on PTF terrains, although this is likely to not use the advanced Olive interfaces, but instead use the 304 PTFDraftSpecification 2007-10-09 Page Documentation
lower-performancestandard C library."

So this is a PDF-analogue for terrain with IP conditions similar to Adobe's for PDF (can create implementations but cannot extend or modify the design).

This is a runtime machine format which can/will incur loss of information so is not 100% reversible. This is not a long lifecycle archival format.

This is not a human editable format enabling a tiered approach to editor suites.

This is not a profiled format.

Where does this fit into the international standards efforts? If it does not, is this a keiretsu standard candidate (eg, MHEG) for interlocking technologies?

Thanks for the detailed comments, Len!

Some brief replies on how we (Forterra) thought about this while developing the proposal:

First, a text-based format (such as COLLADA or X3D) requires a reader to parse the entire file to understand its structure. That goes against the primary goal of, conceptually, enabling paged access to a database covering something as large as the entire Earth. To do paging in text-based formats, you have to split the database in a zillion little files, which then becomes quite cumbersome to manage. Text-based formats also do poorly at representing data such as DEMs or texture images. Couple this with the fact that nobody will actually use a text editor to edit data on any real scale, and we realized that a binary format was a better match for the requirements.

Second, we initially thought we'd include enough information to allow full round-tripping. However, we then realized that this added significant heft to the downloadable file size. Thus, we decided to drop that. While we do store a lot of the interesting information (SEDRIS feature attribution, material classification, etc), any processing done in a tool emitting PTF is not necessarily reversible. However, you can use the extension mechanism to store round-tripping metadata if you wish.

Third, we (Forterra) fully intend this specification to achieve life of its own, once a working baseline is available. I don't yet know what the forum is -- Khronos Group comes to mind, as does W3C, and some other standards bodies. If the Interoperable Virtual Worlds initiative takes off, that may be a new standards body that could own this standard.

I would say that we go a step and a half further than the PDF file format: We will provide an open source library to read and write the data. With that library will likely come utilities that can convert .OBJ mesh files and DEM or GeoTIFF rasters into PTF. Forterra will license higher-level tools to anyone interested (we are working on support for 3ds Max and COLLADA sources in the first iteration), but we also hope other vendors will choose to support the format. We would be willing to lend assistance to people working on such tools.

Fourth, the specification includes a number of extension points, all the way from the basic record format, up to the minutiae of how materials and geometry are stored in the file, that allow a third party to add functionality without even needing to change the standards document. Conformant readers (which the open source library will be one) will know to ignore the data, but make it available to anyone who has knowledge of those extensions. The hope is that extensions that prove popular and useful, can be folded in as official parts of future standards. In a way, it is similar to how the OpenGL specification uses extensions, first defined by a vendor (EXT), then by the standards board (ARB), and finally folds functionality into a new version of the API. This lets the implementation follow developments in technology, and then standardizes on the agreed-upon best practices.

I appreciate the feedback you've provided so far, and I hope that this description of how the goals map to the implementation helps. We all look forward to your further contribution!

(Speaking of which, we should probably add a questions-and-answers section to this document in the next version)

Len Bullard

Thanks for the reply. Taking the points one at a time:

"...First, a text-based format (such as COLLADA or X3D) requires a reader to parse the entire file to understand its structure. That goes against the primary goal of, conceptually, enabling paged access to a database covering something as large as the entire Earth."

True. On the other hand, this is a conflict in goals for a particular file format with existing languages. This is about performance for a very large dataset in its proprietary runtime vs performance of libraried assets in an open human readable format. So this is apples and oranges until we start blending the drinks. I am not dismissing the requirements for high performance particularly in the markets where Forterra is strong. My background in Homeland Security from Intergraph Public Safety (have moved on since then) and years in the DoD domains do make me aware of the performance requirements at runtime. Design time, however, has a very different set of requirements and we have to bridge those for these particular markets.

"...Couple this with the fact that nobody will actually use a text editor to edit data on any real scale, and we realized that a binary format was a better match for the requirements."

To quote Tim Berners-Lee on HTML, "I never believed people would actually type those tags in." This is a common mistake among developers. We said the same thing about VRML97. It turned out that authors can will and do hand code large sections of such formats. In fact, the harder one makes that for them to do, the lower the adoption of the format. However, the point is that the lifecycle of expensive data assets has to be reckoned with. DoD's worldwide are very sensitive to this. So is NASA and other organizations that have lost very expensive public datasets when the hardware or software became obsolete. It seems every generation of data owners has to relearn this lesson and every generation of new or existing companies take advantage of that.

"...Third, we (Forterra) fully intend this specification to achieve life of its own, once a working baseline is available. I don't yet know what the forum is -- Khronos Group comes to mind, as does W3C, and some other standards bodies. If the Interoperable Virtual Worlds initiative takes off, that may be a new standards body that could own this standard."

I note that the Web3DC responsible for the current ISO standards for 3D On the Web is missing from your list. Why? The Virtual Worlds forum led by IBM in no way constitutes a standards body. That is a keiretsu looking for a means to legitimize its efforts. The participation requirements of the consortium and the agreement with the international standards body will be examined critically here and OCONUS. The Europeans have a large head start in viewers and databases. I don't think they will be very comfortable with IBM's proposal given IBM has no products, services or credentials in this market.

"...Fourth, the specification includes a number of extension points, all the way from the basic record format, up to the minutiae of how materials and geometry are stored in the file, that allow a third party to add functionality without even needing to change the standards document."

That is exactly how a PAS works and how PDF is standardized. In effect, this is proprietary Forterra technology with liberal licensing. Possible that is a problem for the Forterra business model with the Web3DC and the W3C given that their participation agreements are unanimously royalty-free IP-unencumbered. Your lawyers will have to work that one out. We possibly should put this discussion to the side for the moment because it is really about market politics and sales, not standards. It wil however, affect the perception of Forterra's goals and the goals of the Forterra investors. Caveat vendor.

But the point of importance is that this proposal does not sufficiently address the lifecycle requirements for high cost data assets. I think it needs to be improved with respect to reversibility, lifecycle and editability. I think your design assumptions with respect to common practice are flawed.

Again, my compliments on beginning with an excellent technical submission. I look forward to the evolution of this.

I agree -- it's a runtime format, not a production format. I certainly appreciate the feedback you've given so far!

this proposal does not sufficiently address the lifecycle requirements for high cost data assets

The way we think about a runtime format is as follows: Movie studios don't archive their raw footage in DVD MPEG format. Game studios don't archive their assets in .nb3 or .bsp format. Similarly, large terrain projects will have a set of source data, and projects for whatever tool they're currently using (such as Terra Vista). Those tools will then be used to build runtimes for the intended audiences.

The intended usage for PTF is as follows:

1. User connects to virtual world A.
2. User moves around, and comes to an area served by virtual world B, for which user doesn't have cached terrain data.
3. User's client needs to download the data for that new area, before the user can interact in that area.
4. We're proposing PTF as an open, runtime format which can be used for this data transfer.

There are alternatives.

• One alternative is that every client implements every runtime format that's interesting to that client. That would be like having some web browsers that implement only TIFF and JPG, and others that implement only PNG and GIF. I'd like to avoid that.
• Another alternative is to download the source data from the new area, and re-process it into a runtime format, either on the client, or through some look-aside system. This is not only inefficient in network transfer (source data is generally bigger than runtime data), but it also takes a lot longer before the user can interact in the area. There is also no guarantee for what that the re-processed data will look like.
• Is there another alternative? We've been looking, but the world is a big place.

We looked pretty hard for an existing format that could serve this requirement, and all the formats we found were lacking in (usually) several important factors. Performance is not a luxury, it's a necessity. Same thing for whole-earth support, the ability to archive a scene and its dependencies in a controlled unit, the ability to page selected parts of a database, etc. Hence, PTF -- and we think we're not the only people in industry who have this problem, or at least can foresee running into this problem.

Regarding the standards body question, we really do not "own" any part of the spec, and we have no political agenda regarding which body will end up standardizing it -- we do, however, have a requirement to ship working code in the near term, and we would like to be as up-front and open about the workings of that code as possible, and establish a baseline of working practice, if you will. If nothing else, the open source code will be released with a very permissive free software license, which should show our good faith. I e, no "sun community license" deal. We own no IP for the implementation of that library (but we don't claim it's IP free from others' IP -- although it's just based on solid common practice).

Regarding user editability, I think we'll just have to disagree. Nobody edits a JPG file by hand in production. Nobody edits a Quake MAP format file by hand in production. Nobody edits even a COLLADA file by hand in production (and that's still XML). All of those formats have stronger adoption in practice and commerce than a format like VRML.

If you can live with the "trust me" on licensing terms and the "not in scope for this application" on text format, your experience would be very welcome and useful in guiding future development. I would also be interested in hearing how you would propose improving support for round-tripping as an extension section of a PTF file (which would leave to two profiles -- "runtime ready" and "runtime ready with reversibility support.")