Tuesday, January 23, 2007

Popup Blockers and the Installer

For a while we've been getting the rare report from a user that our installer won't download - usually it dies mid-download on a given file.

(Our servers transfer a complete 600 MB demo copy of X-Plane once every 8 minutes, all the time. So if we get a report of a problem from one isolated user, it's almost always specific to the user. Systemic problems like a bad server generate a ton of email.)

One user stuck with us through some via-email debugging and we finally figured out one of the causes of failed downloads: popup blockers!

The X-Plane installer is built around simple off-the-shelf technology where possible. In particular, files are zipped and sent via http. This means we're using openly available existing standards, and we get to leverage free code. (The biggest win is being able to use "plain old apache" for serving the installer.)

To the operating system and any firewalls involved, the X-Plane installer doesn't look that different from a web browser. It goes to a web server and requests a big pile of files, a few at a time.

It turns out some popup blockers will detect patterns in URLs and automatically substitute the web content! So we go out asking for an object called com_120_60_1.obj.zip and the popup blocker decides that (perhaps because it's a zip file and has 120_60 in it) the file shouldn't be made available. It substitutes a 1-pixel black GIF file that the browser can show inconspicuously..

Of course, that one-pixel black file doesn't look anything like a zip file - when our installer gets it, the installer has a fit.

This bug was a mystery before - what would cause our servers to send just one user a tiny GIF file, and only in one case. Now that we know that the software is designed to zap web advertising, it makes perfect sense.

Tuesday, January 09, 2007

Now We Are 3

With X-Plane 860, we now mark the X-Plane executable as being capable of using 3 GB of virtual memory on Windows. This means that if your copy of Windows can support large address spaces and you have a powerful enough PC, you can now use more add-ons. (Mac and Linux have always gone to 3 GB by default.)

You can read more about setting Windows up to handle large address spaces here. Please don't try this if you don't know what you're doing, and please don't contact our tech support if you destroy your copy of Windows -- we can't support the whole OS.

Please note that this change does not improve the hardware capabilities of your computer - it only enables X-Plane and Windows to take full advantage of what you have. You will not see a performance boost because of this.

Monday, January 08, 2007

Airport Flattening, the Untold Story

I've been meaning to write this blog entry for about a year now. X-Plane 8 allows the airport surface area to be sloped. Here's some of the back story and details.

Back when Austin and I were doing the design work for teh X-Plane 8 scenery system, we made a decision to allow sloped runways. The issue is that flattening the airport area requires the sim to edit the mesh on the fly, something we wanted to avoid.

(X-Plane's scenery system is based on removing the editing of scenery from the sim itself..."X-Plane is not a GIS". I did some slides on this once, I'll try to post them soon.)

Instead we decided to simply drape the airports over the terrain, no matter how it was built. We figured that the sim's engine could handle this (as it turned out, there were bugs that were fixed in the 8.20 patch) and in real life runways are often quite sloped!

Unfortunately when theory meets practice, things can get ugly...the biggest problem we saw was that in the original set of DSFs, the underlying terrain was very bumpy, and the smoothness requirements for a plane to take off are very high. (Flattening is also necessary to match the ground height with other sims for online flight.)

So we retrofitted the X-Plane engine with terrain flattening for airports. The flattening engine is meant as a last resort, to get absolute flatness and repair an already-flattened DSF. Its goal is not visual quality, but rather speed -- that is, we can't take 10 minutes analyzing the DSF each time we load one, or the sim will freeze pretty badly. (If this requirement that the flattener be fast ever goes away, we could do a much nicer job of flattening.)

The current flattening engine has two unfortunate properties designed to keep it fast:
- It flattens an area that is larger than the airport surface area (it rounds up) and
- It flattens vertices that are in the flattening area, not whole triangles.

The first limitation means that it may crush mountains around the airport, and is not appropriate for airports that are embedded in complex, hilly terrain.

The second limitation needs more examination. If a mesh triangle is partly inside the flattening area and partly outside, then the triangle is not flattened - one vertex is moved, and the others aren't, which cause it to be sloped.




In these pictures, the blue lights represent the airport area perimeter, but the red lights show the full area that is flattened. I have artificially set the airport elevation much higher than surrounding terrain, to make the flattening obvious. Notice how some triangles become highly sloped!

When we make the global base scenery, we use the default airports from Robin's database. So even if you do not want to submit your custom airport layout to Robin's database, consider submitting some kind of layout to Robin. If an airport is present in the default scenery, then the area will be pre-flattened, which makes the sim's flattening both work better and maybe even unnecessary.

Also, you can use the 130 code in a custom airport area to increase the airport boundaries, increasing the amount of flattening. But this is a mixed blessing - as you can see the mechanism is very imprecise. If you do use a 130 code in a layout and you submit the layout to Robin, please remove any 130 boundaries that have been set to a large area to flatten an airport.

Sunday, January 07, 2007

So Why is WorldMaker Still Around?

I realize this blog post will probably just inflame a bunch of email about how the scenery tools aren't available yet, but I'll answer the question and take the flames, because it's a fair criticism and scenery tools are a fair feature request.

The long term direction of scenery tools is this:
  • Scenery tools will be separate from the X-Plane distribution, free, and open source. (This separation allows us to post scenery tool source without posting X-Plane source, and to use GPL code in the scenery tools.)
  • A few very basic editing functions (like adding nav-aids) are integrated into the sim to allow instructors to correct nav data during a training session.
  • WorldMaker therefore is no longer a scenery editor at all.
So why haven't we killed it? We've been tempted to. But it will serve a long term purpose in the scenery tools ecosystem: it will be a small-footprint 3-d scenery previewer.

Because the scenery tools don't use X-Plane code, the scenery tools will have two limits to their previewing capabilities:
  1. There is always the risk that with different code, the tools will preview scenery differently from X-Plane's final render.
  2. Because the scenery tools don't use X-Plane's renderer, we basically have to rewrite viewing code in the scenery tools from scratch. That's a lot of code, so for a while the preview in the tools will be limited.
Running X-Plane and the scenery tools at the same time isn't a great option - since X-Plane loads a lot of scenery, and a weather model, and a plane, and then tries to run at max fps, it tends to be a bit of a pig in terms of system resources. WorldMaker will be a viewer that can reload your scenery quickly so you can have a 3-d view of what your end result will look like that will match X-Plane.