One of the major initiatives of X-Plane 10 was to add buildings to our airports – terminals, hangers, warehouses, control towers, etc. In X-plane 8 and 9 we had detailed taxiway line markings, lights, and signs, but most airports were devoid of structures. The plan we came up with went something like this:
Create a library of “lego brick” airport buildings. The library provides visually high quality, high performance art-work with moderate variety and ships with the sim.
Extend WorldEditor to edit DSF overlays as well as airports.
Extend the global airport database that Robin Peel maintains to include buildings and not just apt.dat data, so that we can collect, share, and redistribute the buildings.
Release airport building layouts (created by users, contributed to the database, using the lego brick buildings) as part of the sim.
In other words, take the process we have been doing all along for taxiways, and extend it to buildings. (Some would call this “crowdsourcing” the airports, but Robin has been collecting user-created airport layouts for us since long before such terms existed.)
So where are we on the project? As of now, it is more or less completed!
X-Plane 10 shipped with the airport library.
WED 1.2 provides the tools necessary to create airports using those lego bricks.
We have a provisional process to collect those layouts.
The first 250+ airports are now included in X-Plane 10.25 beta 1.
Next Steps
So what do we do next? We are working on a few separate initiatives.
Documentation, Instructions, and Tutorials. We are working on videos, tutorials, etc. to help explain the process. Some of the docs are done now – for example, Marty and Nick just finished their 13-part WED tutorial, which is a great introduction.
Automation and infrastructure. We’re looking into what we can do to provide a more automated submission process, real-time viewing of what has been submitted, etc. We haven’t made any decisions yet; we’re evaluating options.
More library variety and WED features. We wanted to wait on library extensions until we could see how people were using the existing elements; it makes sense to add more variety in popular categories. WED 1.3 has additional usability features to make navigating the library easier.
How to Participate Now
We’ll have better documents on “how to participate” in the near future, but for now if you want to create your own airport and share it with the community, the basic process is:
X-Plane 10.25 beta 1 is now live on the servers. Release notes here, bug reporter here. Please do not submit beta bugs on this post. There are a few big features of this update that I want to mention in a little bit more detail than the release notes go into.
Community-Created Airports
This is the first release to include airports with 3-d buildings submitted by the community. We have received over 250 submissions so far; last I counted there were over 35,000 objects placed in those airports.
If you are working on an airport that you have not submitted, do not panic; we will continue to collect airports and release patches regularly to get them to all users. We are also working on web resources, documentation and training to help make the creation process more accessible.
(A few pictures of default airports at moderate settings, airports picked at random.)
In these pictures I have tried to align the far views with the airnav overview pictures so you can get a sense of how closely people can and can’t match the real world with the airport library elements.
Urban Terrain
For the longest time, our cities have looked like a big green blob. We have been working on this for a while; the problem is actually a three-part one.
The urban terrain we shipped wasn’t very good – in some cases it wasn’t even meant to be released.
The application of urban terrain to cities errs on the side of vegetation (and not concrete) in the DSFs, due to problems with the DSF zoning algorithm.
The autogen footprints don’t persist when rendering settings are turned down.
The urban terrain in 10.25 beta 1 addresses problem (1) for wet climates. I am hoping we’ll get a working dry-climate urban terrain set before the beta is over, but that is still in progress.
What about the other issues? We have a fix for (2) in our DSF generator, so recut cities will have better far-view balance than the first generations do. We have ideas on how to fix (3) for a future update.
In these pictures you can see a far view of New York City in 10.22 (shipping now), 10.25 (new wet urban terrain), and 10.25 with a recut DSF fixing zoning, based on the current DSF generation code we hope to use.
Wide view of NYC area as ships in 10.22.
Wide view of NYC area with new urban wet terrain from 10.25 beta 1.
Wide view of NYC with 10.25 urban wet terrain and recut DSF.
Hopefully you can see from these images that while the new urban terrain helps, it works best when the zoning bugs are fixed in the DSF as well.
Edit: to be clear, 10.25 does not ship any DSF recuts. We have not yet shipped recut tiles. The NY City pictured is a recut DSF I made for myself last night for code testing purposes; it illustrates improvements to the DSFs due to new data and bug fixes in the generation algorithms.
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.
Now that the final season of Breaking Bad is over, we can finally all get back to work on X-Plane!
I kid – while it is true that we maintained an internal betting board on the ending of the fifth season of breaking bad, we’ve actually all been heads down working on new code for the last few weeks. A few bits of status update:
It looks like we will cut a 10.25 with new art assets after all. Currently in the queue: Albert’s new terrain textures, a few library tweaks to get the sim ready for DSF recuts, revised urban terrain textures for cold wet climates, and texture optimization for the airport scenery library.
About those urban terrain textures: Alex has revised urban terrain textures for cold wet climates, and they’re a nice improvement over what we shipped. Our goal is to use the new revised urban textures for all climates, but we don’t have the variants yet. I’m going to put the cold-wet ones into 10.25; we’ll get the rest out when they are available. (Why delay a fix for New York just because we don’t yet have a fix for San Diego?)
I’m working with Robin to try to get some user-submitted lego-brick airports into the update.
Alex has a bunch of partly done autogen work, but based on my last discussion with him, it looks like it needs to go into a bigger AG update and can’t be distributed in pieces, because a lot of the autogen shares common textures and objects for performance.
10.25 won’t be a big code change – we’ll have a fix for Foreflight compatibility and a few other small bug fixes, but 10.30 will be the next major code-changing release. The goal of 10.25 is just to get art out.
Alpilotx is re-importing OSM data this weekend; I’m not sure what the time frame will be for DSF recuts, but my goal is to make sure that 10.25 can run recuts. This way we can push recuts before 10.30 if that’s how things get done.
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.
Upcoming Releases
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.
…are greatly exaggerated. I was out of the office last week on vacation (for the first time in 2.5 years) and didn’t bother to post first. Austin and Chris were also out on vacation for at least a week each.
We are not dead, we are not out of business, and we are definitely not stopping development of X-Plane 10! Austin has been working on X-Plane since approximately 1637 (well, the 90s at least) and he is not going to stop now.
Stuff We’re Working On
I am still working with Alpilotx and others on DSF recuts. This work is moving forward, but my side at least is going slowly because I am also working on other features that are pre-release and have not been announced.
I also had some time to do some OpenGL modernization over the last two weeks before vacation. This code does not directly improve X-Plane, but it sets us up to improve performance: once we have more modern code we can get access to newer GPU features.
Upcoming Releases
At this point I am looking at two releases:
Some kind of short-beta release to roll out new terrain textures, some of the userr-submitted lego-brick airports, and possibly a few small bug fixes.
Then a long-beta release, where we could put a major feature or two, and also ship code that needs more serious testing (e.g. the OpenGL modernization).
Over the last few years that I have been working on X-Plane, the time between major patches has been steadily increasing. Back in X-Plane 7 or 8, we might have a major patch every three months; with X-Plane 10 that interval is more like six months. I think this longer time between major betas is good for X-Plane 10:
It lets us run longer 8-week betas without being in beta perpetually. This gives third party developers more time test.
Fewer larger patches means less work for third parties, since a major patch means retesting add-ons.
X-Plane 10 is a much bigger product than X-Plane 6 – it needs a longer development cycle.
Still On Fire?
The other factor making it seem quiet around here (besides slower major betas and the occasional time off is that we are finally moving out of fire-fighting bug-fix mode into doing structured development. When we were fixing bugs in X-Plane 10.0 as fast as possible, a bug fix was followed by a beta and announcements as quickly as possible.
Now that we have a stable 64-bit build out, we’re writing code that looks to build the future of X-Plane, rather than just fixing its past. So the quiet you hear now should hopefully turn into good features in the future.
X-Plane 10.22 release candidate two is now officially final – if you did not participate in the beta program, you will get the update via auto-update. This build provides X-Plane-managed memory allocation for Lua-based plugins on Windows, which should help the problem of Lua plugins running out of memory.
If you have add-ons based on SASL 1.0 64-bit, you will need to get an update from the airplane vendor that uses SASL 2.0! Please do not report SASL 1.0 64-bit crashing on Windows; this is a known problem with SASL 1.0 64-bit that was fixed with SASL 2.0 64-bit.
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.
X-Plane 10.22 release candidate one is now posted. If things go well, we should be final in less than a week.
Aircraft authors: if your airplane uses 64-bit SASL 1.x for Windows or Linux, update to SASL 2.0 as soon as you can! The old 64-bit SASL 1.x builds do not correctly support LuaJIT memory management, and will not run on X-Plane 10.22 and newer.
Albert has new terrain textures to release, but I think we will put this in a separate update (e.g. 10.25) to keep the 10.22 patch small. I think that the next autogen update is not ready yet.
