Airport Layouts: Your Cutoff is 10/10/10

If you are planning on submitting an airport layout to Robin so that it is used to flatten terrain in the X-Plane 10 global scenery, please submit the layout to Robin no later than October 10th, 2010 (that is, 10/10/10).

If you have an incomplete but useful layout (e.g. the airport border is in place but not the taxiway signs, you can still submit it; we only consider border outlines and the pavement itself when flattening, not markings.

You do need both the border outline and all existing pavement. The reason for this is that the airport border is used to change the land class to grass, but water is only converted to land (if we have a coastline error) base on real pavement.

More info on airport layouts and how to submit data to Robin can be found here.

WED Roadmap

I posted a quick tip on how to create fence-like facades in WED. Basically WED doesn't handle fences and other non-closed polygons very well, but you can work-around this. A future version will address this more completely.

This is my thinking on the WED roadmap:

• WED 1.1 will relatively ship soon, without cosmetic and usability improvements. At this point the basic bugs (import/export) are fixed, so best to get out a finished, stable build so that people can at least edit overlays.

• A future version will provide editing ATC layout information for X-Plane 10. This shouldn't be too hard to get working, as we already have this in WED now so that we can develop test data for the new ATC system.

• A future version will provide usability enhancements (e.g. previews of facades, etc.). I don't have a ton of code done for this yet, but it's important for everyone using WED for pretty much any purpose.

• A future version will provide road editing since X-Plane 10 can drape roads.

I don't know what order those 3 feature will come in, but they will all happen relatively soon after version 10 ships I think.

A Better WED Beta (and friends)

On my way back from South Carolina a few weeks ago I had some time in the airport to fix the WorldEditor 1.1 export bugs. All of the reports pointed to a single cluster of bugs that are hopefully now fixed in beta 2, and today I finally had time to get the betas posted.

I also cut a new build of MeshTool (2.0RC2) while I was doing builds; this fixes a bug when using orthophotos with varying physics.

So first: you can get the new WED 1.1 beta 2 and MeshTool 2.0 RC 2 on the tools page on the wiki.

The wiki? Yeah. Tyler has been helping me migrate the scenery tools to here. At this point I believe that all of the content on scenery.x-plane.com is now duplicated on the wiki (which also has additional articles).

WED Bugs

If you should find additional WED bugs, after you get over your initial surprise, please file bugs in the scenery tools bugbase. Please do not email me bug reports. WED has to take second priority to version 10 work, so I don't have time to process bug reports now, and I will lose them. The bug base keeps your bug safe, keeps a record of what happened to it, and can take attachments.

Please do provide the minimal materials to reproduce the bug; simple packages with an earth.wed file are great. Thanks to all of the WED users who filed bugs with repro cases - this made it very easy to retest the export code.

My Polygon is Poly-Gone

It is illegal to have DSF polygons (or airport polygons) cross themselves; finally with beta 2, WED actually makes this case fairly easy to detect.

1. If a polygon cannot be exported (because it is self-intersecting), an error message will indicate that some polygons were skipped, and those polygons are selected.
2. If you pick "Error-Check Polygons" from the Edit menu, then for every polygon that has a self-intersection, an OBJ is added at the precise point of the self-intersection. Simply select and zoom in on those OBJs - they act as marker pins to show the problem. Delete the OBJs once you have untangled your polygon.

(I did experiment with error checking on the fly, e.g. simply showing red dots in the intersection points as you drag and resize the polygon, but the math is too slow. I am using CGAL to check bezier polygon intersections, and their algorithm is absolutely rock solid, but it can take up to a quarter of a second to recheck the polygon, which is too slow for interactive editing.)

UPDATE: beta 2 hangs when processing beziers. What is very odd is that this happens on the clean release code but not the working copy of WED I fixed the bugs in. Hence, when I checked all of the bug reports, they all passed. I have reopened all bezier-related bugs. I have not yet located the build environment differences causing the problem.

UPDATE 2: the hang on bezier processing was due to a bad compile configuration for a library WED uses, and was Mac specific. Having fixed this, I have recompiled and reposted WED beta 2 for Mac. If you already grabbed WED, re-download it, and make sure you get the version dated September 24th. You can tell you have the right one because the "compiled on" date in the about box will say "Sep 24 2010 19:34:09".

Performance Tuning and Future Proofing

I wrote up some performance tuning notes for OBJs on the wiki. A few notes on how these rules will change with version 10:

• Everything on that note applies to version 10 too. If you've tuned your model for version 9, that effort will be worth it in version 10.

• A few rules are even more important in version 10 than before. In particular, I've done a lot of performance tuning for OBJ drawing, but you don't get those wins if you use ATTRibutes. Clean your objects out for maximum speed.

• One special case: objects with very small vertex count are sometimes extra fast in version 10. For example, in version 9, a tree with 8 vertices and no attributes is horribly slow. In version 10, this tree will be quite fast. So in version 9 you might make the tree have 64 vertices and look nicer; in version 10 by keeping the tree lean and mean, you get a speed improvement.

  
  

Use Every Pixel of Your Normal Maps

Normal maps are expensive. A 2048 x 2048 normal map takes 22 MB of VRAM! So make sure you get every bit of image quality you can out of it. Two things to consider:

• Normal maps are uncompressed (because texture compression really screws up the normal map). So per-pixel detail will be preserved. Use it!
• VRAM is allocated for an alpha channel whether you use one or not. This is because the cards need 32-bit pixels for performance. So include an alpha channel in your normal maps and use it to modulate shininess; this can help create the illusion of different materials.

For scenery objects, do not include an alpha channel if you don't need it. When textures are compressed, the alpha channel does take more VRAM, and X-Plane will hit a faster rendering path for textures with no alpha channel.

Revisiting Texture Compression

For quite a while now, I have been advocating in favor of DDS compression. I am pretty damned obstinate, but eventually if enough people yell at me, I get a clue. I have come to appreciate that there are some cases where DDS compression is not a net win; this blog post explains when it happens and what we might do in X-Plane 10 to work around this.

DDS - The Good, The Bad, the Ugly

DDS is a file format that contains image data pre-mipmapped (that is, the smaller versions of the image that the video driver needs are included) in a format that may or may not be compressed. DDS is virtually always used with a compressed image format (like DXT1 or DXT5). This has three positive effects for X-Plane:

1. Because the image is already compressed, we save CPU time when loading the texture that would be spent compressing while X-Plane is running.
2. Because small versions of the image (the "mipmap pyramid") is already in the file, we save time down-sizing the image with the CPU, another win for load time.
3. Because the image is compressed ahead of time, it can be compressed with a slow high quality compressor rather than a fast low quality compressor, so relative to other compressed images we get an image quality improvement.

The bad is that the DDS file does not contain the original uncompressed file. If the user unchecks "compress textures to save VRAM", DDS files remain compressed. If the image file contains details that don't compress well, they're going to get splatted and stay splatted.

What If VRAM Grew On Trees?

My original heavy arguments for DDS were based on the idea that VRAM is a limited commodity; if we don't compress textures, the user runs out of VRAM faster and has to go down a level of resolution...and once that happens, everything starts to look ugly.

But what if the user has 1 GB of VRAM? At this point, we've limited the maximum quality the user can see because we don't have the original uncompressed image anymore, only the DDS/DXT version. This can be frustrating to authors who spent a lot of time on their textures.

If you ship PNGs with your airplane or scenery, turning off texture compression will reveal this beautiful, uncompressed image, but now when texture compression is on, the compression will be done by the video driver, and that will look extra ugly.

The Best Of Both Worlds

This is my thinking for version 10. (These are just musings, we haven't coded this yet.) Currently DDS are preferred to PNG files. We could relax the load rules in version 10 to prefer PNG over DDS when texture compression is off and DDS over PNG when it is on. This would allow authors to ship both PNGs and DDS files and have the right one be picked for the scenario: the pre-compressed one when texture compression is on and the uncompressed one when compression is off.

Feature Requests for X-Plane 10

Yesterday I got a bit cheeky regarding feature requests for X-Plane 10. Here are a few slightly more serious thoughts regarding the feature request process.

The major features that we are putting into X-Plane 10 were decided, for the most part, a long time ago. Those who we met in France two years ago won't be surprised by the major items on the list: weather, ATC, airports, and new scenery, new shaders. For that kind of major feature work, we have to start an initiative very early on. Heck - global sun shadows (which I believe we will ship in v10, God willing) were in the works before version 9.0 shipped - it took that long to get an implementation that was useful! (In fact, the v9.0 version was not released because the quality was bad, which is why I am always nervous about announcing features in advance; it ain't over until it's over.)

So while it's exciting to see so many people discussing X-Plane 10, realistically if a feature is a "big" feature and we haven't started it now, it's not going into 10.0. That train left the station over a year ago.

There have also been two complicating factors that have cropped up during the X-Plane 9 run:

1. Microsoft closed ACES, which definitely changes what we want our next major release to look like.
2. The iPhone came along - until the first iPhone release, we had no idea that it would be such a big product.

While we have to plan our big features in advance, the market we are going to ship into changes during development.

So bear with us - a lot of what I see are good ideas that we will get to soon, even if they don't go in the initial roll-out.

Feature Requests for Reality

With X-Plane 10 on the way, it seems that the various X-Plane forums are just filled with users listing off their favorite feature requests. If there is one uniting theme for these requests, it is this: they are pretty much all requests for X-Plane to more accurately model some neglected aspect of reality.

I would like this relationship to be two-way, with give-and-take. It doesn't seem fair that in every case, we should have to change X-Plane to model reality. So I humbly submit to the X-Plane user community: my requests for changes to reality to ease X-Plane development.

No Wind Near Water

My first request is a simple one: can we simply not have any more wind over the ocean? Ocean waves are hard to model. They are non-sinusoidal, they don't repeat, they're refractive, and they go for miles. If we could simply eliminate the wind, then we could model the ocean as a nice calm glassy lake, which would be quite a bit simpler to get right.

Only One Building

My second request is a modest one: from now on, I would like everyone to live in the same type of uniform house. It can be a nice house (several stories, with a pool in the house), but everyone's house should be the same. We have some new instancing technology for version 10; it reaches peak efficiency when a single building is repeated ad infinitum. So if you could all agree on a single house type, it would be good for everyone framerate wise.

(I realize that some of you in subdivisions in the US that already do this; hopefully the rest of the world can take a hint.)

No More Intersecting Roads

Alex and I have spent just a crazy amount of time trying to cope with what to do when two roads intersect. So my third request is: no more intersecting roads. I would like all roads to cross each other by some kind of overpass. This will eliminate a lot of artifacts.

In fact, for extra credit, if all roads could be aligned to be precisely north-south or east-west in a grid, that would be good for RAM use.

No Variation in Climate

This one isn't so important for me, but I think the art team might appreciate it. It turns out that different parts of the world have different temperature variations and rainfall, and that in turns makes the local color of grass, trees, etc. a bit different. This just makes work for our artists - they have to draw everything several times for the different climates. It would help us out a lot if you could all live in places with the same annual rainfall and temperature variation.

(Just in case this climate thing turns out to be true, I suggest everyone settle on the "hot dry" climate pattern - we have pretty good textures for that.)

Pave the Bay

Finally, when in doubt, use asphalt. We have some new shaders in version 10 that will make asphalt look pretty good.

Anyway, this is my list - I am sure the other X-Plane developers will have other requests. (I suspect Austin's life would be made easier if weather was always CAVOK, and Chris's life would be greatly simplified if there weren't any other airplanes in the sky.)

Do you have any hints as to when this new version of reality might be released, or what its minimum system requirements are?

More Airplanes

Quick airplane links:

• Carenado's Mooney M20 J is out, available on the X-Plane.org store.
• Javier's T34c Mentor is out, available at X-Aviation.com.

Pictures available in both links.