Friday, October 31, 2008

Naming Names

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!!

Thursday, October 30, 2008

Whatever Happened to XES

If you read the original X-Plane scenery web pages, you'll see references to two file formats:
  • DSFs - the files we distribute scenery in.
  • XES - the "X-Plane Editable Scenery" file format, which you won't see very much of.
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:
  1. Import lots of data from multiple sources in multiple formats, so that it is all in one giant tile in our format.
  2. Process the data, deriving new information (like terrain type) from existing data (like slope) and fixing problems (like bumps on runways).
  3. Export the data as a DSF, which involves additional conversions (such as converting generic road types to x-plane roads) and DSF encoding.
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.

Wednesday, October 29, 2008

Precomputed Scenery - the Good and the Bad

This thread on 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.)


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.
  • There is no need to revise the scenery file formats to introduce new data sets, because new data sets and old are all processed to the same final DSF container format.
  • A wide variety of mesh generation techniques can be employed because the mesh generation is not built into X-Plane. This is a flexibility that I don't think anyone has really utilized.
  • Changes of behavior in the scenery generation toolset can never affect existing scenery because that scenery is already preprocessed; this help compatibility of old file formats.
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.)


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:
  • Good tools require an investment in coding user interface.
  • The code to convert source data which users might want to edit (like a polygon that defines a lake) to data the simulator might want to use (like a list of 78,231 triangles) has to be written.
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.

Tuesday, October 21, 2008

Threaded FM - Probably Not

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?

We were looking at running the flight model on a separate core from the rendering engine.  The idea is that the less work must be done in series with that main rendering thread, the higher the total frame-rate.  But now it looks like it's not worth it.  Here's my logic:
  • The rendering engine now runs best on at least two cores, because all loading is done on a second core.  So unless you have a 4+ core machine, X-Plane is utilizing close to all of your hardware already.
  • The flight model isn't very expensive - and the faster the machine, the less percent of time the flight model takes (because it does not become more expensive with higher rendering settings).
  • Therefore I must conclude: threading the flight model would only help framerate on hardware that doesn't need the help - modern 4+ core machines.
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.

Plugins can run during various parts of the rendering engine, and they can write data into the flight model.  I bounced a number of ways of coping with this off of Sandy, Andy, and others, and I don't see a good way to do it.  Basically every scheme includes some combination of a huge performance hit if a plugin writes data from render time, a lot of complexity, or both.

So the simplest thing to do is to not try to thread the FM against the rendering engine, and instead continue to use more cores to improve the rendering engine.

This doesn't apply to running more than one FM at the same time (e.g. AI planes and the main plane at the same time).  It's the question of the FM vs. the rendering engine that I think now is not worth the benefit.

Tuesday, October 14, 2008

Another Programmer

With the iPhone and X-Plane 9, we've been very busy...with this in mind, I am pleased to announce the latest engineer to join Laminar Research.

"Nubblet" would like you to know that the MacBook Pro is, in fact, "hers". :-)

Saturday, October 11, 2008

New Installers

The 2.05 installer is now released - this is a multi-language update that fixes a few bugs and makes the map interface more usable. If you have existing DVDs, you may want to use the new 2.05 DVD installer because it scans the scenery folder very quickly when you pick "add-remove scenery".

(The old installer would check the signatures of all scenery files - this one simply checks whether they exist.)

No URLs have changed - installers will always have the same file names and live at the same URLs; you can pick "Get Info" or "Properties" to tell their version (or run with --version on Linux).

I have a ton of emails I need to get through, so if you emailed me, I do apologize; I will try to clean out the pending tech support issues, etc. in the next week.

Wednesday, October 01, 2008

Releases, Bugs, and the iphone

Sometimes I have one of those weeks where all I do is look at crashes and weird behavior.  This is turning into one of those weeks.  So here's some status on the various bugs floating around.

I should say: you'll find a lot of developers blaming the technology providers for bugs (just look at how many OpenGL developers have blamed ATI for their apps crashing).  Sometimes it's the app, sometimes it's the driver.  More importantly:
  • You don't know who's fault it is until you fully understand the bug.
  • The fix for a bug might not be in the broken code.  That is, one piece of code can work around a bug in another. can't necessarily tell whose fault it was from new drivers coming out, us changing the sim, etc.  But...when it's my stupid code, I'll admit it openly - no one should think that a bunch of other smart programmers are screwing up on my behalf.  (This is also useful to other apps developers, who can know that my bug isn't the same as their bug, since my bug was in my code.)

X-Plane: we're happy with 921r2 finally...the final bug (crash on startup on the Mac) was due to an incompatibility between Apple's OpenAL implementation and special memory allocator (which is really just a wrapper around NEDMalloc).  I still don't know exactly what the rules should be (you try reading the C++ spec!) but for now we turned the allocator off on Mac.

(This brings up another issue about bugs - you can't tell whose bug it is by whose code crashes, since one piece of code can sabotage another.)

So the next X-Plane release will probably be 930, with new features.  We may have a few more language patches if needed.

iPhone: the 9.01 iPhone patch is out, and it improves framerate a bit.  We are still seeing crashes on startup for users who have just downloaded the app.  Rebooting the phone will fix this, but please see this post for more info!  We need your help to collect more data.

Radeon 9800 on Windows: for the longest time we've had users reporting "framebuffer incomplete" errors when using catalyst 8.x drivers, an R300 chipset, and Windows with X-Plane 9.x.  I have been trying to reproduce this problem "in the lab" off and on for months, but finally saw it this week.  From what I can tell, we're getting into some low-memory condition and the driver is freaking out in various ways.  The command line options people sometimes use to get past this are probably rearranging memory, not saving it.  I don't know why the Catalyst 7.x drivers don't have this problem. least I am making more progress than I was before.  Please see this post for more info.

Installers: I am working on the 2.05 installer.  I have seen a number of users report problems running a full install from DVDs, so I am just starting to investigate that.  I will post more when I have something to test.  Unfortunately the problems reported are not something we see here.