Look Mom, No Tiles

Since before I've been involved in X-Plane, scenery has been broken into tiles. You know the naming scheme...+42-072.XXX is some kind of file for Boston. Perhaps it's a .env or a .dsf, but what is unchanged is that the world is broken up into bite-sized pieces.

Tiling is very necessary for X-Plane...it allows the sim to rapidly load only the information we are interested in. The world is too big to go fishing for the relatively small amount of data that is loaded at one time.

The source data that is used to build global scenery is also tiled - if you look at the SRTM files, they often have names like N42W072. It's no surprise that global data requires tiling to make it manageable.

When we produce global scenery, we work on a per-tile basis. We load the raw tiled data* into source XES files (one per tile), then process and convert that XES file into a DSF. By working one tile at a time, we limit how much RAM we need.

But if you used WorldMaker on an airport or city that spanned a tile boundary, you know how annoying tiling can be. With WorldMaker you couldn't see both halves of an airport at once.

WED will not use tiles. For custom scenery packages, the total data is not so large that we have to tile. When you work on a scenery package in WED, you work on the entire package at once as a single seamless workspace. When you export your work, WED will split the data into tiles as needed. This will mean:

• You do not have to decide in advance where you are going to work. All scenery packages cover the entire planet, and DSFs are created only as needed.
• You will be able to work on more than one "tile" of area at a time, because there are no tiles.
• You will be able to work on airports that span tile boundaries seamlessly.

Hierarchy and WED

I just finished fixing some bugs in WED regarding the hierarchy view. (To get a sense of what a hierarchy view is like, try AC3D...)

In WED, the contents of your airport layout are viewed in a hierarchy view. This is where you reorder your runways and rename entities. You can also group entities (as many times as you want) to help organize your layouts. (The groups will not be visible in the final apt.dat.)

An airport is, in a way, sort of a super-group...it's a group of "stuff" (runways, taxiways, etc.) plus it has its own information.

But this leads to some tricky situations:

• You can't have an airport inside another airport.
• You can't have a runway outside an airport.

The result is that there are a number of grouping and drag & drop combinations in the hierarchy that are simply illegal. Cris and I debated this a bit and what we have now is: commands that would produce illegal results simply cannot be executed. (That is, the group command is grayed out if the new group would violate these rules, and the drag & drop won't show a legal drop if the new order would violate these rules.)

Once we get into beta we'll see how well this works. The alternatives include:

• Putting up a specific error message when an illegal configuration is made (annoying).
• Allowing illegal configurations and putting up an error message on export (by this time the whole file layout could be pretty badly messed up).
• Attempting to silently export the illegal configuration (unpredictable - there's really no good way to export an airport inside an airport).

Also, I am sure there are some illegal configurations I have missed...we'll have to catch those in beta too.

New AC3D Plugin

The new beta of the AC3D export plugin is posted here. There are a bunch of bug fixes, but the two big ones are:

Texture paths are exported without relative directories. This was a new "feature" in the first beta, but virtually everyone said that exporting relative paths was both confusing and annoying. The plugin is now back the way it used to be. (If you need a relative path, there is a "prefix" path that you can specify in the preferences that will be prepended before all textures.)

The popup menu for datarefs has been replaced by a combo-box. This has three advantages:

1. The popup can be built a lot faster.
2. You can type custom datarefs into the combo box.
3. It doesn't crash.

Here's a tip: if you type a part of a dataref into the combo box and then open it, only the matching datarefs are shown. Try typing "flightmodel" into the combo box and then opening it.

"Directories" of datarefs are shown first. So from flightmodel you can pick sim/flightmodel/position and then re-click. Now all of the position datarefs are shown. In this way you can navigate through all datarefs.

You can also use wild-cards in the combo-box. If you search for sim/flightmodel*x you will find all of the datarefs beginning with sim/flightmodel and ending with x. Note that when you use * your pattern must match the entire dataref.

(To search for all datarefs containing flightmodel and local with some text between them, you cannot just use flightmodel*local. You need to use *flightmodel*local*.)

You Can't Unbake a Cake

First, I just want to be clear: I am not announcing any future features for the scenery tools. I am not saying when they will be released, and I am not saying what they will do, because honestly I do not know. There have been too many cases when users have emailed me and said either "I thought you guys were going to do X" or "you guys promised you were going to do X", so now I am officially paranoid.

So this blog post is not about what the future scenery tools will do - it is simply a discussion of the difference between editing source data and compiled DSFs.

When we make the global scenery, we start with a bunch of source data that roughly consists of: road maps, coastlines, elevation, landuse, climate data, airport locations, etc. When we build a DSF out of it, we "bake" these items together into a single file. During this baking process, our tools apply some "integration effects". Here are a few of the more obvious examples:

• Terrain under airports is forced to be an airport grass texture, appropriate for local climate data.
• Roads are removed from airport areas.
• Intersections are computed for highways - that is, a highway and city street form an overpass, but two city streets become a real intersection.
• Generated Buildings are put around the roads, not under them.
• Buildings are oriented to "face" the slope of the ground they are under, based on their shape.

That's not a complete list, but it gives you an idea of some of what goes into making a DSF. All of this information is precomputed and represented in the final DSF. But consider this last point: the DSF contains the actual orientation (north/south/east/west) of each building. It does not contain the slope underneath the building and it contains no information about which buildings need reorientation. In other words, the results of the process, not the inputs to the process, are present.

So consider what would happen if you could simply edit the data in the DSF:

• If you moved an airport, the airport grass would stay in its own location.
• If you moved an airport over a road, the road would still be there.
  
• If you changed a city street to a highway, it would not form an overpass.
  
• If you moved a road on top of a generated building, the building would remain in place.
  
• If you changed the ground elevation, buildings would not change their orientation to face the new slope.

If you changed the source data and re-ran the DSF building process, these effects would occur. But remember, we need elevation, land use, etc. to build a DSF from scratch, and the DSF itself doesn't contain its source data.

So we have two possible strategies for editing DSFs:

1. We could build a DSF "retouching" tool that let us make very small changes to the existing DSF without having any source data. None of these effects would "work" so authors would have to make very small changes and then hand-fix any problems that appeared.
2. We could build a DSF "rebuilding" tool that let authors make new DSFs from source data. All of the effects would look good, but authors would have to get some of the source data. (We could post our source data, or provide links to places where it can be downloaded.)

Note that we can't have our cake and eat it...we cannot get the "integration effects" listed above unless we go back to the source data. If I can stretch my cake metaphor to the breaking point, once we make our cake, we can't easily remove the flour and add another egg - we need to start over with the raw ingredients.

Which strategy will the scenery tools use? I don't know yet. I am focusing on airport and overlay editing, which sidestep this issue a bit (we can easily edit an apt.dat 850 or overlay from the final product). We may do a bit of both strategies - it depends on what users want and what we can code efficiently.

Why don't the finished DSFs contain everything we need to edit them? The answer is size. The finished global scenery was about 56 GB of DSF. When I last checked, the raw data that forms the DSFs was at least 100 GB or more. So for each DVD we shipped of scenery, we'd have to ship two more DVDs of source data, for a 21 DVD set, most of which wouldn't be useful to most users.

It's the little things....

That take the longest to program. This may surprise non-programmers, but won't surprise anyone who has done UI development before.

Example: in WED, there is a spreadsheet-like view (the "property" view) that shows text-based information, usually with a list of runways or taxiways in one direction and different aspects of them (name, displaced threshhold length, surface, etc.) on the other.

In WED, if you press the tab key while editing text, WED will move to the next editable field, first across, then down. Furthermore, it will scroll the view as needed so you don't need to adjust the scrollbars while working. The result is that you can, for example, use the mouse to select all of your taxiways, and then rename every single one of them from the keyboard with the tab key without ever going back to the mouse.

It's a small UI feature that can make a big difference in how long it takes to work on a project, and takes surprisingly long to code.

European Buildings Everywhere

A user reported a bug: the 3-d buildings in all parts of the world outside the United States* are European-style, even in Australia, Canada, China, etc.

It takes two things to see 3-d objects in X-Plane:

1. Location data in the DSF you are flying over.
2. 3-d models (stored in OBJ files) that match the definitions called for by the location data.

Now we have location data for our "generic" objects (objects that are placed pseudo-randomly based on local topography and roads, to synthesize cities) for all urban areas that are covered by the 7-DVD global scenery set. But we only have two sets of artwork: a set of US-style buildings for use in the US, and a set of European-style buildings for the rest of the world.

So we had an unfortunate dilemma. Either we could have European style buildings everywhere, which looks funny, but at least it's 3-d. Or we could use the European-style buildings only in Europe and have no 3-d at all everywhere else. Both options make some users unhappy and neither is very good. We chose to have the European buildings everywhere - my guess is that it generated slightly less complaints.

Well, the silver lining is: it's actually really easy to remove the European-style builldings from the rest of the world (Canada, Australia, China, Russia, Africa, etc.). All you have to do is make a custom scenery pack that applies to the regions where you don't want the buildings and maps them to a blank object. I have built such a custom scenery pack and posted it here. If you install this scenery pack, then Canada will be devoid of 3-d, but at least there won't be mismatching architecture.

This begs the question: why not use the US buildings to populate some of those regions? The answer is that the US buildings are built to a different spec than the European ones, because the road grid data for the US is more detailed than the rest of the world. So amongst our current artwork, only the European buildings will work globally.

* When I refer to the United States, I really mean the continental United States. Sorry to everyone in the beautiful states of Hawaii and Alaska. This is just an artifact of how the data was imported - I could not get the Census data for Hawaii, Alaska, or the territories to import, so I reverted to the generic "global" data.