Since X-Plane 8.50, airports have had a border polygon that defines the boundary of the airport surface area. The airport boundary polygon is probably the least understood aspect of airports, particularly because it takes effect when we cut DSFs, not when you load X-Plane.
The airport boundary does a few things:
If sloped runways are not enabled, it defines (roughly) the area that X-Plane will flatten to the airport elevation. If you have ever entered a silly field elevation in WED and then turned off sloped runways, you’ll see that the flattening process is not exact.
When we create base mesh DSFs, the area of the boundary polygon gets a grass surface texture.
When we create base mesh DSFs, the area of the boundary polygon has no autogen buildings. (These two points are actually one in the same – the zoning of ‘airport’ in the DSF creation tool adds grass and removes autogen at the same time.)
When we create base mesh DSFs, the elevation under the boundary polygon has large bumps and spikes removed.
No More Bezier Curves
If you’ve used WED 1.2, you may have noticed that it refuses to validate airports with bezier curve boundaries. This is because we are trying to stop the use of bezier curves for airport boundaries.
The problem with bezier curves is that they can very easily be self-intersecting, but WED has no good test for this. The result is (apparently) valid WED airport layouts that later crash the DSF generator. Every time we cut DSFs, we find a handful of boundary polygons that need to be hand-fixed due to bad bezier outlines. There were 3 in this last batch.
Furthermore, the DSF generator cannot actually use bezier curves – it has to convert them to polygons. So the author will not get a surface area like the one they expected – there is a conversion that must take place.
Faced with a bezier curve technology that produces crashes and isn’t actually used, I decided to switch to straight polygonal airport boundaries. So: when you work on new airports, please remove bezier curves from your boundary polygons.
One of the top 5 bug reports I see: two AI airplanes starting in the same ramp start position, or worse, an AI airplane starting on top of the user’s plane. The pictures are often quite spectacular, if not what we intended for the ATC system.
The code that allocates AI start locations is much improved for X-Plane 10.30, so in the next major update, we should get less cluttered ramp starts.
But the code change isn’t enough; there’s something that you have to do now if you are working on an airports.
You need to provide more than one ramp start! In particular, if there aren’t enough ramp starts for a given airport, X-Plane cannot sanely allocate AI airplanes with space between them.
In the past, X-Plane’s UI didn’t have room to show a lot of ramp starts, so authors would include only a handful. This has been fixed for a while, so I encourage you to add lots of ramp starts to your airports. This will give the AI planes room to park and the user a choice of all of the real-world gates.
Types of Ramp Starts
X-Plane 10 introduced type and equipment codes to ramp starts. One thing Chris found while working on the ATC system was that users were putting ramp starts in silly locations. For example, some airports have ramp starts on the active runway! He had to write specific ATC code to untangle the disaster that happens when an airliner decides that “on the runway” is a good place to park.
X-Plane 10 lets you define your ramp start as a tie-down, a gate, the interior of a hanger, or ‘misc’. The misc category was designed for ramp starts that might be interesting to humans (e.g. “in the run-up area for runway 7”) that are not appropriate for AI/ATC use.
I am not a fan of ramp starts near the active runway; I figure if a user wants to minimize taxi time, X-Plane lets you start on the runway, and a start anywhere but the ramp is inappropriate for realistic flight. But whatever you make, consider marking real parking spots as gates, tie downs, etc. and the random starts as “misc”.
Static aircraft (3-d models of aircraft that don’t move) are a nice way to make an airport look busier with less impact on framerate than AI planes. But this presents a problem: if a static airplane is at gate C4 and a user wants to park there, what do we do?
I believe the solution to this is to automatically place static aircraft based on ramp starts. This is not something we have coded now, and I don’t know when we will get to it, but my design idea for static aircraft is to have the airport include a lot of start positions and no static aircraft; X-Plane can then place static aircraft at ramp starts based on a rendering setting, with the user picking more static aircraft if hardware permits.
The advantage of this scheme is that (because X-Plane places the static aircraft), X-Plane would know where they were parked and could make sure the static aircraft aren’t in the user’s spot and the AI aircraft aren’t using a spot taken by the static aircraft.
The todo item for authors to someday support sim-placed static aircraft is, fortunately, the same thing authors need to do now to prevent future AI collisions: just make sure that there are a lot of ramp starts, modeling how the real airport works.
Edit: Just to clarify, 10.30 is not scheduled to contain a big pile of ATC bug fixes. The slight improvement in AI ramp start placement that I put in was a one-off bug fix; more ATC bug fixes will come in a later patch.
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.