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!!
Friday, October 31, 2008
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:
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:
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.
- DSFs - the files we distribute scenery in.
- XES - the "X-Plane Editable Scenery" file format, which you won't see very much of.
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:
- Import lots of data from multiple sources in multiple formats, so that it is all in one giant tile in our format.
- Process the data, deriving new information (like terrain type) from existing data (like slope) and fixing problems (like bumps on runways).
- Export the data as a DSF, which involves additional conversions (such as converting generic road types to x-plane roads) and DSF encoding.
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 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.
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:
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 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.
- 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.
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:
- 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.
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?
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.
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.
(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.
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. But...at 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.
Subscribe to:
Posts (Atom)