I am back from India — I seem to have done a particularly lousy job of telling anyone I was going off the grid this time, so if you were wondering where I was, well, now you know. I am sorting through about 700 emails now, so it’ll be a few days before I can respond to even just the “really time critical” stuff.
More ranting on the question of whether a file format is based on factual information or not. For the sake of taxonomy, let’s call this:
Apt.dat is actually a hybrid format – most of it is factual, with one glaring exception: pavement surface areas.
Pavement surface areas are simply an overlapping pile of bezier polygons with holes. There are multiple ways to create a given layout, and you couldn’t make an argument that one is “more factually correct” than the other.
Artistic file formats give us a way to be open-ended, and so they are particularly useful for problems that we cannot solve in a practical manner using factual file formats. When we worked on the apt.dat 850 format, I clung to a 100% factual approach for as long as I could, hoping to be able to truly describe “ground truth” about airport pavement. What I found in the end was that real world instances of airport pavement are so varying and weird in real life that almost any factual approach would fail to correctly model important real-world airports. So we punted and simply said “put pavement wherever you want, make it look nice.”
The result of going artistic instead of factual is two-fold:
That taxiways are “artistic” will probably always bug me a little bit from a theoretical viewpoint, but I think there is no question that this was the only practical standpoint.
Final thought: factual file formats are usually not precomputed – that is, if we have a list of runways described by their real-world properties (and not modeled as a collection of textured triangles) then there is probably work that still needs to be done to make the file useful for X-Plane. (That work is done by X-Plane’s file loading code.)
Okay – I’m OOTO for a while – see you before thanksgiving!
/ben
Lines are a bit long here in Maryland, and we’re not even a swing state. Doesn’t matter! Go vote!
Previously I have blogged about a key choice in file format and scenery system design: will the file format be “specification based” or “reality based”.
Specification based: the format has an exact interpretation of the data. OBJ is an example of this…the format describes triangles and there is only one interpretation of what that triangle could be.
Reality based: the format models real-world concepts; the correct interpretation is “as close to the real world as possible.” The nav.dat file is like that.
I have been reading the OpenStreetMap Wiki and hit upon something I didn’t realize: you can’t use copyright to protect a derived work from a file that simply contains a list of facts!
Now I am a programmer – I am used to writing code, slapping a copyright notice up top, and assuming that it’s now mine…heck, I’m the one getting carpel tunnel from typing it out. But consider the nav.dat file; it contains a giant list of frequencies for navaids. It’s a fact that the BOS VOR is 112.7. Is my mentioning of that fact in this blog a derived work of the nav.dat file? Of course not, and it’s a good thing too because otherwise we wouldn’t be able to state facts without IP conflicts.
The OSM guys believe that they need to change their license to something weirder than the CC-BY-SA license they have now because the CC license uses copyright, you can’t copyright facts, and OpenStreetMap is really just a huge collection of facts.
Now at this point I’ve written six paragraphs too many without the obligatory “I am not a lawyer.” I am not one. And I must admit, my biggest concern with all of this is that it gets confusing and hard to interpret, and I’d be perfectly happy if there were only 3 or 4 licenses out there for everyone, you’d pick your favorite flavor, and everyone would know what it means.
Suffice it to say, it never occurred to me that a criteria of a file format might be “protectability” – that is, does the file format allow an author to specify something other than facts, so that it is elligible for copyright protection?
If you are an author, the good news is: pretty much all of our file formats would meet that criteria:
But who knows, I am not a lawyer.
(Oh yeah, this whole article is written from an entirely US-centric viewpoint…I am even less qualified to speak of such things outside the US than I am here at home.)
Starting Wednesday I will be out of the office – Lori and I are going on a 2+ week trip to India!
So first, the obvious: your comments to the blog won’t show up until I get back and can moderate them. Similarly, I will be even less on email than I am now. I am trying to dig out my tech support emails as much as possible before I go!
I will announce this before I go: I finally got an end-to-end render of a global scenery tile using CGAL 3.3.1. Andrew did the original work on this, modifying parts of the scenery generation code to handle his NZ scenery. I’ve been working on the rest of the algorithms and finished it today.
This doesn’t mean very much immediately, but it…
The next steps will probably be to create a new release of the tool set, including perhaps a bug-fixed Mesh Tool, etc.
The apt.dat 850 file format defines a polygonal “airport boundary”. But what exactly does it do? It does different things when creating DSFs and when rendering them.
Inside X-Plane it has relatively little effect:
The airport boundary has more of an effect during scenery creation.
There is one aspect of airport creation that the airport boundary is not involved in: filling in water to make land under runways. When we create an airport, we actually calculate three boundary polygons:
Why do we need two inner rings? Well, if an airport is next to the water but not at sea level, we need to induce two sets of mesh points, the outer ones which drop down to sea level and the inner ones which are at airport level. You can see the importance of this at KLGA, where one of the runways dropped to sea level at its midpoint in version 8, but not version 9.
Since the airport boundary polygon provides only one ring, it cannot be used for this purpose. At some point in the future, we might use the airport boundary for rings 2 and 3, or use a smaller version of the airport polygon for rings 1 and 2.
For now, my recommendation is: the airport boundary should trace out the entire airport premesis, not including water.
I’m never quite sure about naming names. There are users whose contributions to X-Plane and its scenery system have been immense – we wouldn’t have what we have without them.
But I don’t want to make the decision to blog for anyone else – this blog is part of Laminar Research’s communications to our users, and I don’t want to set up content that leads our paying customers toward third parties who may not want the extra questions/attention.
So I guess for now what I’ll say is this: the work I discuss here on this blog is not a solo effort – I have had the good fortune to collaborate with some really good people, and it has made X-Plane that much better of a flight simulator.
To everyone who has helped me with the scenery system: thank you!!
If you read the original X-Plane scenery web pages, you’ll see references to two file formats:
Here’s the story:
When I was first working on the scenery system design, we decided on a pre-processed approach, which implied two types of file formats: pre-baked (editable source data) and post-baked (distributable finished scenery). XES is a GIS container format for the source data.
When we create the global scenery, the process is something like this:
We keep our raw data partly in XES format, and partly in the original raw format, depending on how slow the importer is – some vector formats are very slow to import (or are not already tiled), so we preconvert to XES. Other formats, like SRTM, are so easy to import quickly that we just use the data as is.
If you have ever tried to use MeshTool, you may have used XES files yourself – the landuse and climate data that MeshTool needs are saved as XES files – it’s an easy way to encode a few variable sized raster maps with portable enumeration encoding.
WED does not use XES files – when I started work on WED, I realized that the XES container format was too GIS oriented and not application-oriented, so I created a file format particular to WED. WED will continue to use .wed files, which can contain anything that WED can edit.
In the long term, I don’t see XES as being used by anyone except for LR internally; WED will continue to have a WED native format, and we will try to use common simple GIS formats for import/export – most likely SRTM hgt files for elevation and .shp (shape) files for vectors.
This thread on X-Plane.org sparked off quite the discussion. Now a lot of this is a discussion of when LR will have an overlay editor – there are a few overlay editing functions that Jonathan Harris’ excellent OverlayEditor apparently does not yet support, sparking this discussion.
(I am not saying that LR should rely on Jonathan to do an overlay editor. But I am saying that the complaints I hear about a lack of overlay editing go down when Jonathan’s overlay editor does everything that the file formats can do.)
But another part of the discussion focused on the problem of mesh editing. In particular, the basic terrain in a DSF is a fully baked output of a complex process that starts with higher level GIS input data. In other words, we start with a raster DEM, polygon coastline, apt.dat file, vector roads, and a bunch of config files and hit “bake” and a DSF comes out the other side, with a lot of processing.
This is very different than FS X, which integrates its data sources on the fly. Why did we choose a precomputed route for scenery? It has some pros and cons. (In understanding how we made these decisions, think back to what scenery was like with X-Plane 7 and ENVs and single-core machines.)
Performance
The main benefits of preprocessing scenery are performance related. When you process scenery data into the final scenery while flying, that computer power takes away from the rendering engine, thus cutting down fps. At some point you have a zero-sum game between how much cost there is to loading scenery and how complex the scenery integration can be; you have to pick very simple scenery integration algorithms to keep fps up.
(This is less of an issue as more cores become available, but is still a factor.)
When pre-processing, we can use algorithms that take minutes per DSF without affecting framerate.
Similarly, there might be scenery processing algorithms that improve fps by optimizing the output triangles – but do we have time to run these algorithms during load? With preprocessing we have all the time in the world because it happens once before the DVDs are burned.
Preprocessing also breaks a similar zero sum game between scenery data size and quality; the source data we use to make the scenery is a lot bigger than the 78 GB of DSFs we cut; if we had to ship the source data, we’d have to cut down the source data quality to hit our DVD limitations. With be-baking we could use 500 GB of source data without penalty.
Format Flexibility and Stability
The second set of benefits to preprocessing are flexibility benefits. (Consider the file format churn of the ENV days.)
– With a preprocessed scenery file, what the author creates is what the user sees – X-Plane does not go in and perform subjective integrations on the scenery later that might change how it looks in a negative way.
Integration Issues
There are some real limitations to a pre-processed format, and they are virtually all in the bucket of “integration issues” – that is, combining separate third party add-ons to improve scenery. In particular, in any case where we preprocess two data sources, we lose the opportunity for third parties to provide new scenery to replace one of those data sources and not the other.
Airport is the achilles heal where this hurts us most; while airport layouts are overlays and can be added separately to the scenery system, the elevation of the base mesh below the airport needs to be preprocessed. This is something I am still investigating – a tolerable fix that other shave proposed is to allow an overlay scenery pack to flatten a specific region regardless of the user setting (so an author can be assured of a flat base to work from).
Preprocessing does fundamentally limit the types of third party add-ons that can be done; with version 9 and overlay roads, we are getting closer to letting road add-ons be overlays (see this post).
It appears to me that integration isn’t the primary complaint about the scenery system (the primary complaint is lack of tools) but we’ll have to see once we have mesh editing tools (mesh recreation tools really) whether preprocessing still limits certain kinds of scenery.
Note that a lack of tools or a lack of tool capability is not an inherent limitation of pre-processed scenery. We have an incomplete tool set because I have not written the code for a complete tool set, not because it cannot be done.
(The complexity of writing base mesh editing tools is a function of the complexity of a vector-based base mesh – this is also not related to pre-processing per se.)
Tools
In the end, I think the question of tools is not directly tied to the question of pre-processing. Whether we have scenery that is processed by X-Plane or a preprocessing tool, we have the same issues:
I don’t think either option (pre-processing or in-simulator processing) reduces the amount of work to be done to create a good toolset.
As a final thought, using scenery file formats that are “easier to edit” (e.g. a file format that contains a polygon for water rather than triangles) doesn’t make the total code for scenery tools + simulator any easier; it just moves the task of “processing” the scenery from the tools to the simulator itself.
I always have to hesitate before posting a possible future direction to my blog – our future plans are a road map, a direction we intend to follow, but if circumstances change, our plans change. (This is one of the great powers of software: the ability to be flexible!) Unfortunately in the past, I’ve posted ideas, and then when we didn’t productize them, gotten back “but you promised X” from users. So now I’m a little bit gun-shy.
But let’s try the reverse: what about a feature that I am now pretty sure won’t go into the sim?
So why not code it? (Even if the improvement in framerate would be pretty low, it would be more than zero.) Well, besides the opportunity cost of not coding something more useful, there’s one thing that makes a threaded flight model very expensive: plugins.