Now that we have user-contributed airports with buildings in X-Plane 10.25, I have a few topics to cover regarding airport authoring. The first is taxi routes. (I will get to the contribution and sharing process in a few posts – please bear with me.)
The short of it is: if you do not provide taxi routing in an airport layout, X-Plane will generate a taxi route, and the route X-Plane generates is not particularly good. The algorithm is slow, so it hurts loading time, it produces a relatively ugly layout, often with errors, so the AI behavior is bad, and I suspect that sometimes the whole algorithm crashes.
While all of these things can be improved, there will always be a trade-off between load time and algorithm quality. For example, the layouts could be rendered using more memory, but the loading would be even slower.
And we don’t want to be generating AI layouts – we want this data to be in the apt.dat where it can be built by smart humans who can carefully author.
For example, consider an airport with a huge tarmac, where the taxi routes are simply painted onto a big slab of concrete. The AI algorithm doesn’t understand this line structure at all – it isn’t smart enough to ‘get’ the taxi instructions. So the AI network lets the plane drive straight across the slab of concrete, traffic flow be damned! The AI also has no idea what any taxiway is named, so ATC can’t provide good route names.
The pictures above show the actual generated taxi layout at KJFK – red indicates active segments where the aircraft hold short before crossing runways. Nerds will recognize that this layout is created by a straight skeleton erosion algorithm, a strategy for analyzing images that comes from OCR.
The moral of the story is: while the AI taxiing behavior can be quirky, a lot of the problems come from X-Plane trying to auto-generate layouts off of the apt.dat file without a real taxi route structure. If you create such routes, the sim loads faster, provides better directions, and provides more plausible taxi routes.
I’ve marked WorldEditor 1.2.1 as final. If you are a WorldEditor user, please upgrade from 1.2 to 1.2.1. Besides fixing a bunch of bugs (including annoying usability bugs), it changes the format of the zip files for submissions to the global airports to a format that is a lot easier for us to handle on our end.
The next version of WED will be 1.3 and will include more usability features; we’re not sure what else will go in that bucket or when we’ll cut it off and kick it out the door.
We’re on release candidate three of WorldEditor 1.2.1. RC3 fixed export of 970 airport files to include frequencies and fixed a bug where you could end up with a two-point hole in a polygon (which would then cause the airport to fail validation).
Hopefully this is the last RC and we can call WED 1.2.1 done shortly.
The addition of airport buildings to the default installation of X-Plane in 10.25 makes it much more important than it used to be to prioritize your scenery packs. It also makes it much more important that custom scenery exclude the scenery below it.
I have heard reports of users going into X-Plane and deleting the airports we ship to deal with conflicts. This is way more work than necessary, will be undone by the updater, and simply isn’t necessary. So this post will explain how you can sort out scenery conflicts without having to change content.
Some Light Reading
I try not to write up documentation in the blog – it’s not really useful to require users to search 900+ posts to find something I mentioned off-hand in a beta four years ago. So I wrote a knowledge base article. Please go read the entire article. I’ll go get another cup of coffee.
Let me summarize how things are supposed to work:
Custom overlay scenery packs should be higher priority than our airports. If you went out and got a custom scenery pack, you almost certainly want to see it, not our work. (Note that if you get X-Plane, run it once, then install custom scenery, this is what happens automatically.)
Custom overlay scenery packs should have exclusion zones to mask out the scenery below them, whether it is autogen, airports we ship, or rogue trees that have decided to invade a runway. (The need to exclude what is below you is not new – this has been in the sim since X-Plane 8.
Mesh scenery packs should be lower priority than our airports if you want to see our airports on top of custom mesh scenery. (This step is not automatic.) Mesh scenery excludes everything (think of the mesh as one giant excluzion rectangle) so you can’t have overlays below meshes.
Where Theory Meets Practice
My favorite Farside cartoon ever is a picture of two sets of engineers standing next to the ends of two highways that were clearly meant to connect – the highways are misaligned and do not connect. The caption: “Where theory meets practice.”
And like the cartoon, the reality of scenery packs doesn’t meet the theory in a few ways:
Some custom airport overlays don’t have exclusion zones. There was nothing under them in the past, so the authors didn’t bother to exclude.
Some users have their global scenery at the wrong priority level. The easiest way to have this happen is to delete scenery_packs.ini – the prioritization is lost and our airports end up on top.
If you install a base mesh into X-Plane, it goes to the top of the priority list, which is stupid; it needs to be below all of the overlays.
What is particularly concerning is that users way of fixing this (going in and editing the actual scenery packs) is probably making the situation more complicated, not less. Here’s what I think needs to happen:
Custom scenery authors need to start excluding their scenery. This isn’t a new rule; I consider it a bug to ship an airport without exclusion zones. If you have a custom scenery pack and it doesn’t have exclusion zones, ask the author to add them. It is not that hard to add a few exclusion zones in WED.
Users need to stop deleting their scenery_packs.ini. The .ini file is there to help you resolve conflicts, but it won’t work well if you constantly delete it. Once you set up your priorities properly X-Plane will not change them! Put your base meshes on the bottom, default airports in the middle, custom scenery in the top, and you are ready to go.
X-Plane needs to get the priority of base meshes correct when they are first installed – the fact that users have to go and ‘fix’ the scenery packs list is really annoying. We are looking at ways to fix this now, but unfortunately we don’t have any plan that we can execute in 10.25. This is high priority for a future update.
X-Plane needs to keep its own overlay scenery (the airports we ship, the demo areas) at a lower priority than any custom overlays that users add. This is the expected behavior and should be totally automatic.
Exclusion Zones and Custom Scenery
A number of authors have rightfully complained that the exclusion zone is a blunt object and doesn’t provide a way to carefully integrate autogen and custom scenery.
I agree, but I consider the problem to go significantly beyond exclusion zones; there is no way for a custom overlay to “edit” base vector data (e.g. to say “I want to move that road over there.”) The underlying data doesn’t have any kind of identifier to refer to it, and the underlying data can change if we recut and take newer OSM data.
I think the future solution to this lies not in more precise or powerful editing in overlays, but rather in the fact that we’re getting more network bandwidth, and the global data we have access to is getting better. Therefore the solution is to (1) push updates to the base scenery and (2) ensure that the base scenery is correct. With this process working, misalignments between custom scenery and the default scenery will be less important, and authors can simply fix small but ugly bugs in the base scenery (via OSM) and the result will be better scenery alignment in an update.
Exclusion Zones and Shared Global Airports
It is possible to include exclusion zones in an airport you share with the global airport database for inclusion in X-plane; some authors have already done this.
There are some cases where an exclusion zone is a must-have:
If the airport gets a new runway, there will be autogen in the location where the old runway used to be; a draped polygon + exclusion zone can “clear” the area for airport.
If the airport has trees on the runway (a bug in the default scenery) you can “fix” the bug with an exclusion zone.
The global shared default airports are one case where I don’t think we need complete exclusion in an overlay – they are meant to be the lowest priority overlay, and therefore don’t need to exclude other scenery.
I just built a release candidate of WorldEditor 1.2.1r2; if you work on airports, please try it and post a WED bug if something is really borked.
There are a few minor bug fixes, some usability tweaks, and two major ones:
The export format for sending zip files to Robin is modified to make things easier in the collection process. For this reason, we’d like everyone submitting airports to go to WED 1.2.1.
The library view now hides the resources marked private or deprecated in X-Plane 10.25 or earlier. So WED 1.2.1 and X-Plane 10.25 provide a much less cluttered library view. (WED 1.3 will have a nice improvement to filtering as well.)
For more details on what changed, all commits to WED 121 are visible here. (The commit notes are listed, and the yellow tags tell you the version where we then re-shipped the code.)
We are discussing internally how to handle a more permanent airport submission tracking system. My current thinking is that eventually we’ll build file transfer directly into WED – that is, you’ll say “share this airport” and WED will call up our servers directly and send the airport; no zip files and email. But that’s for the future.
X-Plane 10.25b2 should be “real soon” I think – I’m just waiting on one more change to cut the new beta.
I just posted a beta of WED 1.2.1; hopefully it will only take one beta to get this quick “bug fix” patch done.
Some usability fixes:
Locked and hidden items don’t cause clicks to select their parents.
The interior of an airport boundary is not selectable – it never should have been.
The marquee tool will never select the “world” entry on the hierarchy.
The click hot spots of handles don’t shrink at low zoom – they were doing that before, which made clicking hard.
(Basically Chris tried to use WED and got really annoyed*, so we dug in and fixed some of the smaller annoyances. The ones we left (like how locking works) need a major rework and can’t go into a bug fix.)
1.2.1 also filters out the private and deprecated library items (once you have X-Plane 10.25, beta coming “real soon now”). This should make the library display a lot cleaner. Also, hidden airports won’t export or fail validation, which is what you would expect.
The only other changes are a bug fix for exporting polygons on a DSF edge, and a bunch of changes to help Robin collect global airports.
If you are using WED 1.2r4 to make airports, please try 1.2.1b1 this weekend, and file bugs here.
* Which was difficult to differentiate from his normal state.
10.25 is coming along well; if nothing really bad happens, we should have a beta either for this weekend or next Tuesday. There are just a few remaining bugs left.
I’ve been looking through the collection of submitted lego brick airports, and I am impressed with what the community has done. In the collection I count 237 customized airports, with a total of 32,152 object and .agp placements. So I am thrilled that people are using WED and starting to bring life to their local airports.
(I’ll post some pictures and we’ll have an official list later; right now I’m still in the process of checking the airports to make sure they don’t crash the sim, etc.)
There’s a lot more to blog on the subject of airports and WED, but one thing has become immediately clear from seeing people’s work and the questions that have come up from LR employees: the library is a big cluttered mess and it makes it hard to find and use art assets properly.
The WED 1.3 code (available in GIT for nerds) already has better library filtering and sorting (another one of Ted’s contributions) but I’m trying to get a very basic quick filtering feature into WED 1.2.1 and X-Plane 10.25: categorization of the library.
In my current design I have three categories:
Public. This is the stuff you should be using to make scenery packs. The lego airport bricks are all public.
Private. This is stuff we meant to use as sub-parts of other art assets; they really should not have been exposed in the library. (The right thing to do is to use the parent art asset.) Often the private sub-parts contain fractions of a complete art asset and don’t make any sense on their own.
Deprecated. This is stuff that used to be public, but now isn’t a good idea to use. Often the deprecated art assets contain empty stub objects, in place only to keep old scenery packs from crashing. For example, there are actually library paths for X-Plane 7 ENV radio towers – these would be marked as deprecated.
The categories affect WorldEditor, not X-Plane! If your scenery pack uses a private art asset, it will work just as well under 10.25 as it did under 10.20. The goal is to filter the library in WorldEditor, so that authors can:
Find the good stuff faster.
Not use internals and old stuff by accident.
In its first revision, WED 1.2.1 won’t yell at you or flag you if an art asset is private; it just won’t show it in the library for additional use. We’ll work on a more refined set of interfaces in WED 1.3.
This is a major architectural change to the library, and I’m not thrilled to have to shotgun it into X-Plane 10.25. But the situation right now is pretty unmanageable, and I hate to see people adding private art assets into their scenery for any longer than necessary.
Authors: comments welcome! If this is going to break how you make scenery, please say so. If there are other ways you think this feature should work, please say so.
Everyone else: I’m going to be a hard-ass and delete off-topic comments. This post is for authors to discuss public, private and deprecated library paths only.
Over the last few months we have been lucky to have Ted Greene working for us as a summer co-op student. You may have seen his commits if you look at the open source WED repository. Ted is heading back to school now, so this post both discusses a little bit of what he accomplished and serves as public recognition of his hard work.
Ted spent the summer working on ‘workflow’ items for WED – that is, things that make WED easier for authors to use. One of the main features he implemented was a new ortho-photo importer.
If you have a GeoTIFF you wanted to use in WED 1.2, the process goes something like this:
Make an overlay image out of your TIFFs.
Run the “make orthophoto command” which will create .pol files and place them in the project.
Delete the original overlay image, which unfortunately looks almost exactly like the POLs in WED.
Resize the TIFF to a power of 2.
Grind the TIFF in XGrinder.
Edit the .pol file in WordPad to use the DDS file.
Edit the .pol file i WordPad to add LOAD_CENTER (if you remember) – good luck getting all of those numbers right!
Export your scenery pack.
Get some astonishing error in X-Plane, because the odds of getting all eight steps right is approximately 0%.
The new process with Ted’s code is much better:
Import the TIFF files into WED as orthophotos.
Hit control-B to build your scenery pack.
Go get a coffee – WED is grinding your TIFFs to DDS for you, which is a time-consuming operation. Don’t worry, it won’t grind them again unless you change the source file.
Open in X-Plane and enjoy your orthophotos – with correct load-center directives!
No hand-editing pol files, no chance for human error, and of the four steps, two you already do now and one involves beverages. What’s not to like? This screenshot shows the results of importing the TIFF files into WED and the resulting scenery pack.
This level of automation is how all of the scenery tools should work and it’s nice to finally reach a point in WED where we can add this level of convenience.
For The Nerds
WED is an open source project, and this next part only affects users trying to work with the WED source code. (If you are not a programmer, you may want to skip to the next section.) Ted’s finishing the new Orthophoto importer completes the removal of CGAL from WED.
CGAL is an open source library that is critical to the DSF generation code that makes the global scenery. CGAL is also a very complex, heavy-weight library that can be quite finicky about compilers, brings in a lot of dependencies, and is generally hard to work with on Windows.
By dropping CGAL for WED, it makes the WED code significantly more accessible. Ted created a complete MSVC 2010/2012 project for WED, so you can just download MSVC Express, open the project and hit ‘compile’ – all of the libraries are included in the repository in binary form.
(For Mac users, unfortunately we are still stuck on X-Code 3.2/10.6 – to move WED to the modern development tools we will have to purge old APIs that Apple has dropped – just like we did on Desktop.)
We are not dropping the makefile system we use on Linux, and it should even still work on Windows, but finally mingw is no longer a requirement to get started.
Removing CGAL from the project should make a Lion-compatible Mac build possible too at some point.
At this point I expect to do a WED 1.2.1 bug-fix patch relatively soon with a few usability fixes. Ted’s work will go into WED 1.3; I don’t know what the release time frame for 1.3 will be.
Laminar Research, creators of the X-Plane flight simulator franchise, is pleased to announce the availability of WorldEditor for X-Plane (WED) version 1.2.
WorldEditor is an airport scenery creation and editing tool for Laminar’s X-Plane. WED is intuitive and easy-to-use, as it features drag-and-drop scenery creation in a graphical environment that is designed for the typical X-Plane user.
WorldEditor takes a graphical CAD-like approach to creating airports. All airports are made up from a collection of different items or entities of a specific type. For example; runways, taxiways, windsocks, signs, and buildings. A runway has length, width, surface type, lighting and taxiway signs for example. WED is organized to create and edit each of these different items on an individual basis, so a user can add an item, then edit it’s characteristics or attributes at will.
A key feature of WorldEditor is the ability for a user to create an airport scenery and then send his or her creation to Laminar’s airport scenery database service. Once checked by Laminar for acceptability it is then included in the airport data when X-Plane users receive automatic X-Plane updates from Laminar.
Robin is ready to accept submissions of airport layouts including ATC traffic flows and default airport object placements using the new “Export for Global Database” function. We are also working on tutorials and additional documentation beyond the WED user manual.
I posted WorldEditor 1.2 release candidate 4 a few days ago. If you are using a WED 1.2 beta, please grab this latest release candidate. If we don’t see any show-stopper bugs in a few days we’ll call it final.
Thanks to Mathias for finding and helping squash the last few bugs; the bugs in the release candidates have all been oddball cases where clicking with multiple mouse buttons induced multiple commands at the same time; the program was usable by avoiding these cases, but in the rare case WED could crash. Release candidate 4 should fix that.