Tuesday, August 28, 2007

Why Don't the Cars Drive Backward?

Why don't the cars drive backward when you pull the slider backward in replay mode? The short answer is "because we don't care enough to fix it", but a better answer might be "it would take a lot of programming time and suck up more resources from X-Plane to fix this...and we think our customers would rather that we focus our programming and your hardware resources on framerate."

The cars are an interesting special case of a whole number of sim phenomena that we don't attempt to track carefully in replay. Replay is designed to allow you to watch your flight - it would be cool if the scenery was doing the exact same thing during replay as during the flight, but I don't think it's essential for training purposes and it does come with a cost.

First remember: replay mode works by saving past values of the sim to RAM. So the more we save, the more RAM we chew up saving past history, and the less time we can save before we run out of virtual memory.

Now in some cases, the motion of dynamic sim objects is at least somewhat random. In this case we can't easily "reverse" the algorithm that generated the motion.

But the cars are more problematic.

Not only is their motion somewhat random (each time a car makes a turn at a fork in the road it randomly decides which way to go), the cars are maintained in memory in a way that allows us to figure out who has to make the next turn very rapidly without using a lot of CPU. As much as the cars are a CPU hog, they would be much much worse without this memory structure.

The problem is, the memory structure is organized based on time flowing forward. That is, we can only tell you which car needs CPU attention next if the cars are driving forward. Put time into reverse and we now know which car needed our help last! Not useful!

So to make the cars drive backward we would have to transform this data structure every time the flow of time changed. I think it would be more annoying to have this massive CPU recomputation each time you rewound the replay than it would be nice to have the cars move backward. Why not have two data structures, one for forward, one for reverse? Well, now we've saved CPU but burned RAM. Either way, we're talking about hardware resources that could be used for more scenery or more framerate.

The cars have yet another behavior that makes them hard to reverse: they are born and die! A car is born any time we realize that there aren't enough cars on the road for the given rendering settings. A car dies any time it gets too far away from the user's plane or reaches a point in the road where it can't procede. (Typically these are 1-way streets that dead-end. This happens because the road data we use has very poor flow information, leading to some really strange streets.)

This cycle of cars being born and dying maintains a reasonably constant car population over time, and a car population that is near your plane as you fly. But to reverse traffic, we would have to reincarnate cars that had died previously. This would mean spending memory on remembering what cars had died. (Even if the algorithm to decide where a car is born, the algorithm to predict where a car will die is quite complex, because it requires looking at the entire set of steps the car would make during its life until it reaches the "point where it is killed". So computing this information is out of the question.)

That's probably more information than you wanted to know. Generally speaking, if someting unrelated to the flight model doesn't replay in replay mode, it's probably because it would be too "expensive" to remember its history. The cars are the most complex example, but definitely not the only example!

Monday, August 27, 2007

Dual Core? Definitely

Austin hinted on the X-Plane news list that X-Plane will in the future use a second core to load scenery much more smoothly than it does in the past. Each time we take a whack at the scenery load code, we reduce the load time by a significant multiple, so we're still not at truly no-pause flying, but we will be getting a lot closer in the future.

A few years ago when people asked "should I get a dual CPU machine" (this was before dual-core chips were ubiquitous) I hesitated to say yes. This is on longer the case - dual core is definitely the way you want to go.

The price performance curve is such that dual core chips are definitely in the sweet spot. In the past a true dual CPU machine costed big bucks, but now unless you buy the absolute cheapest machine, you're going to get a dual core chip. I never recommend buying the absolute cheapest hardware -- usually to get those last few dollars of price savings, the machine (or GPU) has been stripped down of major features, so you're losing tons of performance for really marginal savings in dollars.

X-Plane's usage of the second core has gone up too, already in 860 and the second core will be even more important in version 9.

Our usage of the second core isn't about trying to raise X-Plane's system requirements, it's about not leaving "money on the table". We need to make X-Plane run efficiently as possible on as many combinations of hardware as possible. This means giving you the best flight sim experience you can get whether you have an older single-core machine with a low-end graphics card or a new dual-core chip with the latest huge graphics card and four tons of VRAM.

The important thing here is: usage of dual core chips requires code changes. We have to write new code in X-Plane to teach it how to safely run some work on one core and other work on another. This is all about efficiency - if you have a dual-core chip there is nothing efficient about leaving one core doing nothing! We'd be leaving half the computing power of the chip idle.

So if you don't have a dual-core chip, the sim will still run (just as it does now). But whereas the gap between single and dual-core chips is smaller now (because the dual-core users have half a chip idle a lot of the time), the gap will become larger as we utilize the second core more fully and dual-core users get to really take advantage of all of that computing power.

Friday, August 24, 2007

Image Formats and File Extensions

This goes into the bucket of "weird X-Plane behavior": X-Plane will try both PNG and BMP file extensions when opening images, no matter what is in your file. How we got to this state is, at best, confusing.

Originally, most X-Plane image files did not contain a suffix. So an ENV file contains "grass" and X-Plane would change that to grass.bmp.

Then we added PNG support. X-Plane would try grass.png and then grass.bmp. In this case, not having the extensions turned out to be handy -- authors could simply bulk-convert their images and go on with life.

With most new scenery system files, the extensions are a lot more rigid:
  • The extension appears in the referencing file.
  • The sim only tries that extension.
  • If the format doesn't match the extension, it's an error.
So if you want a DSF file to reference a facade, it's buildings.fac and if that .fac file is actually a forest file, it's an error. The sim won't try to decide which is more correct, the header of the file or the extension, it will just go "you're nuts" and bail out.

But (for historical reasons) images are an exception. Keeping with the "any extension goes" theme for images, X-Plane will actually try PNG and then BMP versions of your file. The extension has to match the format...that is if you call your bmp foo.png X-Plane won't load it at all.

We have PNG as our primary image format and BMP for backward compatibility. But it's imaginable that we could have DDS and PNG both as primary formats -- PNG for images that need lossless fidelity and DDS for images where compression is acceptable. In such an event, X-Plane's tendency to try every extension means authors can bulk-convert from PNG to DDS (making their packages load faster) and go home happy.

The case for DDS

Jonathan Harris suggested I look into .dds as an image format for X-Plane. I think he's got a good idea.

First, what is DDS? It stands for "direct draw surface", but as a file format, it's basically a file whose structure is the same as the memory layout for a texture in DirectX. It's a simple image format but it does two useful things for X-Plane (or any other 3-d application):
  • It can contain compressed images using the same compression OpenGL and DirectX use (DXT compression).
  • It can contain mipmaps - smaller versions of the same image.
Now before things get out of hand, using .dds files in X-Plane would not mean converting X-Plane to use DirectX!! .dds is simply an agreement about how to arrange a file. You can easily write code to load a .dds file into an OpenGL application, and that is what we would do.

There would be three fundamental benefits to using DDS files:

File size on disk (and download).

PNG is a losslessly compressed file format. This kind of compression (the internal algorithm used by PNG is the same as ZIP files) preserves the image, but the reduction in image size is a function of how "simple" the image is. Images with a lot of detail and high frequency information (rapid changes in color) do not become much smaller than the amount of VRAM they use when compressed in a PNG. A lot of the terrain textures we use (4 MB in VRAM) are still 3 to 3.5 MB on disk!

By comparison, the texture compression used by OpenGL is lossy - the image looks worse. But the image is reduced by a factor of 4 to 8, every time. So one of these images (4 MB in VRAM when uncompressed) would be 1 MB with S3TC compression (available in a DDS file). Even for very simple PNG files, you rarely see such a reduction in size, so .dds files would be smaller, meaning faster updates and downloads.

(Another thought: if a PNG file is smaller than its VRAM requirement, it means the PNG file has lots of areas with the same color. This means the PNG file is WASTING VRAM! We encourage our artists to make use of every little pixel in an image, and this means that PNG files that are well-created for X-Plane tend to get relatively little benefit from PNG's internal compression.)

Load Time

Image load time is a significant factor in X-Plane. There are several reasons why DDS files could load a lot faster than PNG.
  1. The actual DDS file is smaller - less data to load and process means faster performance.
  2. Because the DDS file can contain smaller copies of the image, X-Plane doesn't have to load a huge image and reduce its size using the CPU - it can just load the small version in the file.
  3. When compressed textures are used (and they almost always should be, see my previous blog post) it takes CPU power to compress the image, slowing down load. A DDS file containing a compressed image can be sent directly to the card!
Image Quality

Now one is a little bit tricky. First, please review my previous blog post, which argues that texture compression is the best way to maximize VRAM. A DDS file will look better than a PNG file when texture compression is on. Here's why:

The S3TC compression formats specify an EXACT way to "uncompress" and draw a compressed image. But there are MANY possible ways to compress the image. Remember that S3TC is a lossy compression - the compressed image is only an approximation of the original.

Well, it turns out that algorithms that find the best approximation of an image using S3TC are slow. So we can't use the highest quality compression inside X-Plane when compressing PNGs for the graphics card - it would be too slow.

But the image in a DDS file is already compressed -- because someone else has compressed it when creating the scenery. When converting the scenery from PNG to DDS that author can use a very slow, very high quality compression algorithm to make the DDS files. It might take 12 hours to convert the entire package from PNG to DDS, but who cares? It's something you do once and then everyone enjoys better looking images.

In other words, because the compression is done ahead of time for a DDS file, a higher quality algorithm can produce better approximations of the original images. Since we want to use compression anyway (to optimize our use of VRAM) this is a good thing.

When is DDS not appropriate?

Any time an image must not be compressed, DDS is inappropriate, and PNG is best. There are three basic cases in X-Plane where we avoid compression (see my previous blog entry for the real examples):
  1. Any time we need to preserve tiny detail accurately, like lettering and text.
  2. Any time the alpha channel needs to be smooth.
  3. Any time a texture is magnified so large that small color changes between two pixels is noticeable. (For example, compressing the color washes used for the sky make obvious artifacts.)
DDS wouldn't replace PNG, it would augment it.

Wednesday, August 22, 2007

What Doesn't Get Compressed?

Speaking of compression, X-Plane doesn't compress all textures...even if "texture compression" is on, we leave uncompressed certain textures that are flagged. A rough list:
  • Most textures in the sky, like clouds and color stripes, have a lot of alpha and get wrecked by compression. They get exempted.
  • Anything related to the 2-d panel, maps, and the UI get exempted.
  • Some of the overlays like rain and snow, smoke puffs, and lights.
  • Taxiway signs get exempted...S3TC does a number on letters and numbers.

Texture Compression Is Your Friend

Try this experiment: take three screen-shots (use ctlr-; to get a stable, clear view), with these settings:
  1. Extreme res, with tex compression
  2. Extreme res, without tex compression
  3. Very high res, without tex compression
Now consider the effect on VRAM. Each time you go down a texture resolution level, tex sizes are cut in half, and you cut VRAM use by a factor of 4.

If you use texture compression, you cut VRAM use by a factor of 4 for textures with alpha and a factor of 6 for textures without alpha. (Some textures are unaffected because they are internally marked as "never compress".)

Now look at your visual results. I would argue two things:
  • At extreme res, turning off texture compression doesn't make the image a whole lot nicer. (It does make the machine a whole lot slower!)
  • Texture compression is a lot nicer than going down a res level.
I suspect that if your machine can't handle extreme res, you can get similar results running the whole experiment down one notch.

I think that almost everyone who has a limited machine is running with texture compression these days - we default with it on and it helps fps. I would only argue that any users who are running with a huge machine and compression off might consider turning it back on. It doesn't hurt much and it does make the machine run faster.

(Even if you have a ton of VRAM, X-Plane can be limited by how fast texture data transfers from VRAM to the GPU, within the card. Texture compression helps this.)

Wednesday, August 15, 2007


Austin and I have this debate over and over when we find a case where third party content doesn't work right with X-Plane (but did in the past due to X-Plane's permissiveness):
  • If we code X-Plane to work around the problem, users get to enjoy the scenery, and authors will never fix the problem.
  • If we code X-Plane to abort, users get grumpy, and authors fix the problem real fast.
What to do? A few versions ago I implemented the scenery warning system (the spanking system) to try to get the best of both worlds. I just discovered another problem that illustrates how this works well.

Before WED some authors made apt.dat 850 layouts by hand using a text editor, and sometimes they forgot to include a closing code on their rings and chains. I can hardly blame them, writing an apt.dat file by hand is very difficult, and I am impressed (and grateful) that they did this.

The apt.dat 850 spec is clear:
  • Pavement chunks (line code 110) must comply with the following:
    • Chunks MUST terminate in a segment point of type 113 or 114.
  • Linear features (line code 120) must comply with the following:
    • Linear features must terminate in a point of type 113, 114, 115 or 116.
    • Linear features do not need to be "closed".
  • Airport boundaries (line code 130) must comply with the following:
    • Boundaries MUST terminate in a segment point of type 113 or 114.
    • Boundaries must be a closed loop and cannot contain holes. As with pavement chunks, the airport boundary cannot overlap itself.

So, you must have one of the closing codes at the end of a boundary, taxiway, or line. But X-Plane 860 doesn't check this and simply assumes a "closed ring" if no code is provided. With X-Plane not telling authors, the authors never caught this mistake.

So now that I know about this (and now that X-Plane needs the end codes to be right, due to other bug fixes) it's time for the spanking system. In future versions of X-Plane:
  • Custom scenery packages with no ending code on a polygon block will automatically be adjusted to be "ring"-type on load-in, for compatibility with X-Plane 860.
  • A detailed message will be printed per polygon in the log.txt file.
  • A single alert box will be shown to the user saying "there is a problem with the custom scenery pack XXX".
The idea is for the dialog box to walk a fine line between being unobtrusive enough for users and annoying enough for authors.

Monday, August 13, 2007

No more scenery in the Resources/Earth nav data folder.

Back in X-Plane 7 the default scenery location was the "Earth nav data" folder of the Resources folder. Custom scenery went into packages in the "Custom Scenery" folder, just like now.

In X-Plane 8 we introduced the concept of a "default scenery" folder in the resources folder. The default scenery folder acts exactly like the custom scenery folder, in that it holds scenery "packages", but it has two special properties:
  1. Packages in this folder have lower priority than any custom scenery package.
  2. It is in the resources folder and is therefore the turf of Laminar Research and our updater -- the Custom Scenery folder is for third parties.
Okay that's not really a special property, more of a convention. But the main idea here was to remove special cases from the scenery system...in X-Plane 8, all scenery comes in packages, no matter what it is and who ships it.

Scenery comes in packages, period. Repeat it like a mantra.

The original X-Plane 8.0 still installed legacy ENV files into the Resources/Earth nav data folder (but installed DSFs into a package). X-Plane 8.20 (when we shipped full DSF scenery) installs everything into packages, as will all future versions of X-Plane.

X-Plane 8 still looks in "Resources/Earth nav data" as a last resort. But this is going away! Future versions of X-Plane will only look for real scenery packages in the "Custom Scenery" and "Default Scenery" folders.

What does this mean to you? Almost certainly nothing...but...
  • If you are an author and your scenery needs to be installed into the resources/Earth nav data folder, fer cryin' out loud, please put your scenery into a custom scenery package. It takes about 5 seconds and will make life easier for you and your users.
  • If you are a user and you have been moving files into the the resources/Earth nav data folder, please don't do this! Learn how scenery packages work and put whatever you've been moving into a custom scenery pack. You'll find things much easier to deal with.

Friday, August 10, 2007

WED beta 2

I've posted WED beta 2.

The executive summary regarding split beziers: use beta 2 and re-export your layout and you should be more or less fine. There is no need to avoid them anymore.

Also a note on the source code: I will update the source code base of WED about every two weeks during beta, or whenever anyone asks me to post latest, whichever comes first. If no one asks, this will mean the source code is slightly behind the latest binary beta, but I think we can live with that...it takes a while for me to ball up and post the source code. (Again, if you want the current source code now, you are absolutely entitled to it - send me an email and I'll post ASAP.)

I will make sure the code is updated when WED goes final, of course I expect a new binary beta about every 3 or 4 days until we get it mostly shaken out.

A thread on X-Plane.org referenced whether program should be labeled beta. I am definitely guilty of leaving some of my old programs labeled as beta, when I should have done one more build and marked them as final. I will try to avoid doing this in the future! But WED is definitely beta material right now.

Thanks to everyone who reported bugs in beta 1 - the feedback was very high quality. The new download's README contains the list of bug fixes.

Split Beziers Part 3: A Workaround

In my previous post I described a bug where, when we have a split vertex in an apt.dat layout, X-Plane would draw taxiway lights all over the place. Fortunately, there is a workaround.

Remember that a split vertex is represented as two or three colocated vertices with one or two zero-length segments connecting them. The bug is that zero-length segments cause lights and lines to go haywire.

The fix is therefore simple:
  1. Programs that write apt.dat files can simply set the attributes on the zero-length segment to none.
  2. Future versions of X-Plane (with a real bug fix) can join taxiway lines even when there is a zero-length "break" in the attributes.
This picture shows the results - a split vertex with no attributes on the zero-length segment.

The next WED beta will automatically export split vertices this way - there will be no need to patch X-Plane or change your WED layouts.

Split Beziers Part 2: The X-Plane 860 Bug

In my previous blog post I defined a split vertex in an airport layout and described how they can be simulated in an apt.dat pile using multiple points.

Now that WED is in public beta and people can easily make split beziers, many have noticed the "split bezier" bug in X-Plane 860:

This is a vertex that is split...on the left you can see what it should look like - on the right you can see what it does look like. There are two problems going on:
  1. The taxiway lights have gone crazy at the split vertex. (This is what everyone sees.)
  2. The taxiway line is a bit jumbled at the split vertex too.
It should be noted that this bug will can also happen for any vertex (even unsplit) in rare occaisions due to interactions with the mesh. Same symptom, same buggy code, different cause.

The good news is:
  • There is a workaround that will make the lights look correct and the lines acceptable in X-Plane 8.60.
  • The workaround will be implemented inside WED - no need to change anything.
  • When X-Plane is fixed, it will make the lines correct too.
In my next post I'll describe the fix and what the results look like.

Split Beziers Part 1: What's a Split Bezier

(This blog entry explains the background of split beziers - the next parts will explain the bugs that they cause and the workarounds.)

In apt.dat terminology, a split vertex is any vertex of a polygon where the control handles on either side of the vertex are not exact mirror images. (When there is only one control handle it is therefore by definition split!)

You need a split bezier any time you want to:
  1. Have a sharp corner between two curves and control the tangents of the curves or
  2. Have a sharp corner between a truly straight segment and control the curve of the next segment.

Split Beziers and apt.adt

Now here's the rub: the apt.dat format does not allow for split beziers - each curved point has only one control handle - the other is calculated by x-plane by mirroring...thus no vertex can ever be split.

(This is due to a total lack of brains on my part when working on the apt.dat format, which is quite embarrassing considering how long I spent thinking about it.)

The Hack

There is a way to simulate a split bezier: if you use zero-length segments (that is, multiple points on top of each other), you can create a shape that works as if it is split.

In its simplest, a split bezier can be created by using 3 vertices.
  1. The first vertex uses the control handle of one side.
  2. The second vertex is not curved.
  3. The third vertex uses the control handle of the other side.
Why does this work? Well, a bezier curve between a curved point and a straight point has zero length if the two points are on top of each other. So what we've done is inserted two zero-length segments. The result of this mess is that the control handles on either "side" of this cluster of points can be different!

Is the second point really necessary! Yes! The reason is this: if we simply had the first and third point (two bezier points with different control handles), X-Plane would draw a loop from the first to the second. Remember: two colocated points with ONE control handle form a zero-length curve, but two colocated points with TWO control handles form a loop.

(To see this for yourself, just draw some examples in WED or photoshop. :-)

Line Continuity

There is one more wrinkle we have to add to the puzzle in order to understand how this works, and what the pitfalls are: line continuity.

A bezier path (taxiway edge, linear segments, etc.) is made up of one or more bezier curves. Each curve has zero or more attributes.

When X-Plane draws the actual taxi lines and lights, it looks for continuous adjacent bezier curves with the same attribute and makes sure the linkage between those attributes is correct.

(This linkage is computed separately for each type of property. So if you have taxiway lines on two segments and lights on one, the taxiway lines will still link!)

The picture above shows a correct vs. an incorrect link. When dealing with unsplit beziers and non-curved points, linkage is pretty much automatic, it just works.

But there is a pitfall to our above hack for split vertices: we have three points on top of each other. They must all have the same attributes in order for linkage to work. A "break" in the continuity of the line for one of the zero-length segments still counts as a break in linkage. The picture on the right was produced by creating a split bezier and removing the double-yellow-line attribute from the second of three vertices.

In my next post I'll explain the bugs that this causes in X-Plane 8.60.

Another Confession - Exclusion Zones

An overlay DSF can define exclusion zones - rectangles where scenery from lower priority DSFs is not shown. Exclusion zones are organized by entity type - that is, you must make a separate exclusion zone for objects vs. forests.

The problem with exclusion zones in X-Plane 860 is that the implementation of exclusion zones isn't quite right for lines and areas.

Essentially any element of a DSF is zero, one or two dimensional:
0d - Points (objects, very small facade objects).
1d - Lines (beaches, roads, large facades with no roofs, bezier lines and bezier object chains).
2d - Areas (large facades with roofs, bezier pavement, forests)

The problem is that X-Plane eliminates any entity if and only if one or more of its vertices intersects an exclusion zone.

This can be wrong in two ways:
- If an entity intersects the exclusion zone, it is deleted entirely, rather than having the exclusion zone subtracted.
- If an entity surrounds or goes through an exclusion zone without a vertex being in the zone, it is left alone.

Thursday, August 09, 2007

So Why Doesn't X-Plane Look Like This?

Every now and then someone sends us this:


The question is of course, why doesn't X-Plane look like that yet?

Now there's a lot of reasons why flight simulators don't look like first person shooters...you can definitely optimize any game content for a specific viewpoint -- X-Plane's lack of constraints on the camera position (you can put the camera quite literally ANYWHERE on the Earth at any time of day, atmospheric condition, and orientation) means that there are going to be views that don't look so hot. And the global scope of X-Plane means that we have to focus on quantity to a certain extent over quality. (If we made KSBD look totally awesome and didn't ship any state but California in global scenery, where would we be.)

I've been working lately on pixel shaders and lighting...when you look at those shots, the total integration of a number of great lighting effects is responsible for a lot of the look. But...I think there's a more fundamental issue that pixel shaders and carefully made content wouldn't address.

Simply put, X-Plane's LOD system isn't scalable enough.

In order to get images that look that good you need to put a huge amount of detail up close near the camera, where the user can see it, but not put that detail in the background. (Imagine if every tree in those scenes was done in the detail of the foreground - the polygon count would be unmanageable.)

But X-Plane's scenery SDK (the interface by which scenery content is specified to X-Plane, in other words, "the file formats") lacks really strong LOD capabilities.
  • The terrain mesh is fixed - you can use LOD to eliminate overlay details, but you can't actually simplify terrain.
  • The cost of LOD in objects is high enough to prohibit really gradual LOD. No morphing is provided.
  • Textures are mipmapped but loading is not variable, so our VRAM budget doesn't benefit from LOD and locality of textures in X-Plane space.
  • Generated geometry (roads, trees, etc.) don't have any LOD except "eliminate whole feature".
  • There is no far view of 3-d clouds.
  • Airport layouts are tessolated at only one complexity.
I could go on and on...the bottom line is, X-Plane's rendering model is very static.

Why did we do that? Well, it seemed like a good idea at the time. In particular, recalculating LOD is very expensive on the CPU and at the time we had only one core. Recalculating LOD would cost more in lost fps than it would benefit in offloading the GPU. So we went for static meshes that we could blast out to the card "real fast".

What you might not know about those screenshots is what kind of hardware it's running on:


Yep...four cores, and overclocked by over a ghz. (I can only speculate that shortly after the clip ends the machine caught on fire. :-) In a multicore environment we can apply additional CPU resources to dynamically rebuild the environment to increase the "LOD range" (difference between the near and far view).

In fact, we already started to do that! In X-Plane 830 we modified the sim to build 3-d content (roads, forests, etc.) on a second core while flying, instantiating only the close ones. This saved RAM and improved the overall performance of the sim, and it increases our LOD range.

(Even if something isn't drawn, it has a cost just to exist - by saying that things that are really far away don't even exist we improve performance.)

As you can see from the above list, there's still a lot to do on the LOD front. But the scenery system is continually growing - new features for the various primitives and improvements to the engine will let us continue to improve sim efficiency.

That's one biiiiig polygon

Something I'm seeing now that WED is in beta: airport layouts with the entire taxiway structure made from one really complex polygon.

I'm not really sure if this is a good idea. First the potential problems:
  • I suspect that the creation of the taxiway layouts can get slow when the number of sides in the airport layout is really huge and there are holes. I don't know this for a fact because we let the OpenGL libraries do the heavy lifting. Because this loading is done on a second CPU, it might not be noticeable to all users.
  • The pavement can have only one texture direction per polygon, so multiple polygons may be necessary.
  • Certainly in WED having a few large complex polygons slows down editing -- if all else is equal, the tools work better with smaller polygons.
Now...overlapping pavement is generally bad (that is, there is a performance cost), but more sides are also expensive. More thoughts:
  • The more square feet of overlap, the worse. So a small overlapping intersection is not so bad, but avoid layering a huge polygon on top of another huge polygon, which just strains the video card.
  • Fewer segments are better. Consider two crossing taxiways...8 segments with overlap, but 12 by making a plus.
  • But wait - the above example is misleading...if you need to change the light types so the blue taxiway lights don't cross the intersection then you'll need to add 4 more segments, so now it's 12 and 12 - a wash. (In this case, having one big polygon is probably easier to manage.)
And for performance...
  • Try going to your layout from far away and watch the last step of loading...if it starts to take a long time to "preload" things it means your layout might be a bit complex.
  • Do not expect X-Plane to become faster at loading airport layouts...the limiting factors are proportional to complexity, so if you have a killer polygon now it'll be pretty expensive later too.
One other note, from a conversation with Tom...WED splits vertices into a fixed number of segments (per zoom level) so splitting a bezier makes it smoother. X-Plane does not! X-Plane splits beziers based on the overall curvature, so adding more nodes without changing the shape has no effect.

So please do not try to use the split command to make X-Plane "smoother". We'll provide a rendering setting for this some day. The current value was chosen because anything smaller looks awful and you have to make it a lot bigger (read: a lot slower fps) to get an even marginal visual improvement.

Wednesday, August 08, 2007

Scenery Tools and Compatibility

In my previous post I mentioned that the scenery tools are separate code with a separate release schedule from X-Plane. This implies that the updates to the tool won't be in sync with X-Plane. (The same thing is already true for the AC3D plugin and all of the wonderful third party tools that people have written.)

X-Plane's scenery compatibility strategy is "backward but not forward". In other words, if you open old scenery with a new X-Plane and it won't open or looks different, that's a bug (please tell us). You should never have to modify your OBJs or scenery if they are correctly made, and the definition of "correctly made" shouldn't get more strict over time.*

Why no forward compatibility? Well, it's possible to have syntactic forward compatibility (have X-Plane read a file it doesn't understand because at the time of release the spec didn't exist) but it's not possible to have X-Plane display that file with any kind of sanity.

You could say "just leave out stuff you don't understand". Well, imagine if we had done that with apt.dat -- imagine if X-Plane 840 tried to display an 850 apt.dat by simply skipping what it didn't understand. Since taxiways are fully replaced with a new code, 850 layouts would have no taxiways at all if shown in 840. This is certainly unacceptable.

The only way around this would be to require all new features to have "fallback" content, e.g. have the file contain two copies of all taxiways. Since the structure of 850 and 810 taxiways are so different, this would basically require the author to do twice as much work...similar problems happen for animation commands, and missing datarefs.

So the content has to be older than the sim. What about tools?

Well, first, I don't write the tools with forward compatibility. Since they are all free a user can easily get the newest tools to work (in a sane manner) with new content.

The tools do have to support old file formats though - we don't usually post old copies of the tools (the AC3D plugin is an exception, since old versions work with old host copies of AC3D). Instead the tools are designed to support restricted file formats. For example, the AC3D plugin will export to OBJ7 or OBJ8 - authors targetting X-Plane 7 can export to OBJ7.

WED only exports apt.dat 850 files - this is by design from day 1, and it will not ever be an apt.dat 810 editor. (Use TaxiDraw if you need to do this.) However, as new X-Plane features emerge (and I am sure they will), WED will have options to target future X-Plane versions, or restrict the export to only features supported by older versions, perhaps with a warning if the WED document contains features that will be lost in an old export.

* One problem we have with this is: X-Plane isn't a strict validator of scenery file formats, so it is possible to have mistakes in scenery that were always illegal by definition of the file format, but X-Plane doesn't notice at first. When I detect a case like this, I try to make the problem a "warning" rather than have X-Plane quit, so that authors can get information on buggy files without users suffering too much. X-Plane will print only one warning per package per scenery load to keep things streamlined.

Tuesday, August 07, 2007

WED Lives!!

WED went public beta yesterday. You can find it under the tools section of the X-Plane scenery web page.

I want to say thanks to the users who helped me with the alpha testing of WED. These users tested new builds quickly, wrote up great bug reports, and put a lot of effort into using WED at a time when it was really no fun to use.* Thanks guys!!

To reiterate a few points about WED:
  • WED 1.0 edits only apt.dat files, not DSFs or DSF overlays. WED will be the platform for additional editing features, but for now it only edits apt.dat files, and it will be like this for a while.
  • WED is still in beta, so use caution! Save backups, save often! Save earth.wed files and export to apt.dat for extra safety.
  • WED is free and open-source. It is not distributed with X-Plane, and you don't need to buy X-Plane to use WED.

* Remember, "alpha" software means "we can test all functions, but they could all be broken", while beta means "we think there are no bugs that would cause data loss or crashes". So...while WED was alpha, it tended to crash or trash files, so the alpha testers couldn't get any real work done.