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.
A crowded start.
The 7 engine Boing-Douglas DC-10-747 needs an escort helicopter.
A tri-tailed airliner?
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
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.
JFK auto-generated layout – note how irregular!
At T junctions, the aircraft ‘dip in’ to the T.
Large paved areas get near-random traversing route structures.
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.
In a past life, before I worked for Laminar Research, I was a plugin developer. So I’ll admit up-front that I might be the most guilty individual when it comes to this particular problem: log spam.
What do I mean by log spam? By log spam I mean printing information to Log.txt that isn’t necessary.
Log.txt exists so that we (and third party developers) can look at a single machine-generated file and get a strong idea of what a user did with X-Plane for diagnostic purposes. Therefore log.txt needs to contain three kinds of information:
Basic configuration information. We print your graphics card, your OS, etc. (In 10.30 we’ll even get your CPU type right on OS X. 🙂 It’s more reliable to log this than to send a user into ten different control panels to gather information.
Very basic event logging, e.g. what did the user do? Where did he start his airplane, what scenery was loaded.
All abnormal conditions, including error alerts that came up.
In particular, what we do not need to do is log the detailed blow-by-blow progress of loading in excruciating detail.
If I may use my own sins as an example, older versions of XSquawkBox shipped with debug code on that dumped the contents of its entire ICAO dictionary – thousands of lines of text. This information isn’t configuration (it’s not unique to particular installs), it isn’t an event – it is part of the event of loading XSquawkBox, and its not an error condition. What a mess! (Fortunately Wade has fixed this and turned such logging off in the newest XSB betas.)
Programmers write this kind of logging code to help trace program execution, but it’s important to turn it off – if we don’t, the log files get so verbose that everyone spends a ton of time just fishing through ten tons of junk.
Some more guidelines:
Log the presence of files or sub-modules that are user-configurable, but do so briefly. It’s reasonable for SASL or Gizmo to list scripts that do not come with the base package, or for XSquawkBox or Pilots Edge to list CSLs found. (This information lets a developer see what a user has done to modify the plugin.)
Don’t log the presence of required files unless an error condition occurs. An empty log can simply mean “everything went okay.” (The sim will already confirm successful plugin loading on a per-plugin basis.)
Log rare events, e.g. a flight starting, a network connection being opened. Don’t log events that occur at high frequency, like receipt of a single network packet.
X-Plane is guilty of log-spam too; I’m slowly trying to cut down on this. For example, spurious autogen-tree warnings are now gone from the log in 10.25r1.
Support Debugging
Sometimes you need all of that logging. My suggestion is: if your add-on is complicated, make a specific interface to get verbose diagnostics that users can turn on as needed. For example, X-Plane has an option in “operations and warnings” to dump verbose play-by-play network data to Log.txt. When you enable this, you can get a ton of information about network operations, but the log will also be totally over-run. The option is meant only for developers who are integrating with X-Plane’s UDP networking, and thus it has to be turned on by hand.
The OBJ engine actually also has such a trick – if you put the single word DEBUG (all caps) at the end of your .obj file, the entire OBJ contents will be output in detail to Log.txt. Again, this is a ton of information, available when needed, but off by default.
You can support verbose logging in your add-on with a script variable, a dataref, a change to a preferences file. Pick an easy mechanism, so that you can have users turn on verbose logging only when they need it.
Not Everyone Has Grep
Finally, a quick aside to my fellow professional programmers. You might be rolling your eyes and going: “Ben you idiot, it’s easy to filter the log. Everyone should just prefix their log entry and use grep.”
If we were all programmers, I would agree 100%. But please understand that aircraft and scenery authors have to look through the log to get diagnostic information about art-asset problems, and this is an audience that is sometimes not comfortable with command-line tools, huge 25MB text files, massive amount of text, etc. So we are trying to keep the log.txt more human-readable than, for example, dmesg on Linux.
X-Aviation just posted an update to SkyMaxx Pro – the new 1.1 patch brings big performance improvements and fixes rendering problems with HDR. From the user reports I’ve read, performance in HDR mode is good. (I hate to see users have to pick between HDR and third party add-ons; we want HDR to be the basis for superior next-generation aircraft and scenery.)
Getting a plugin that draws in 3-d to work with HDR mode requires some caution; the plugin APIs for drawing were designed in X-Plane 6, when ‘deferred rendering’ didn’t even exist as a concept.
I have updated the X-Plane SDK tech-note on 3-d drawing to contain modern guidance on how to cope with 3-d drawing callbacks. In particular, you get called twice when your plugin requests to draw in 3-d:
The first callback is for drawing “solid” stuff that will be affected by spill lights; the only safe thing you can do from this callback is to call XPLMDrawObject.
The second callback is after lights have been mixed; at this point normal OpenGL drawing works reliably (albeit without spill lights being mixed in). This is the time to draw translucent prop discs, coach marks and labels, clouds, smoke and particle systems, etc.
If your plugin does any 3-d drawing (e.g. custom particle system drawing or any kind of effects code), please review the tech note, and email me if you have questions. The next-gen CSL code sample that is linked from the article is tested and works correctly too.
Update: this bug has been fixed – see here for details.
For X-Plane users with an AMD graphics* card on Windows or Linux: there appears to be a bug in the 13.11 drivers** that cause corruption in HDR mode; the symptoms are square artifacts of missing clouds and missing windshield in aircraft.
If you can run the 13.9 drivers, stick with those; if you have one of the new Rx 290 cards and you must use newer drivers, turn HDR off for now.
These bugs are Win/Lin only – the Mac AMD drivers don’t have this problem.
* AMD seems to have fully rebranded ATI’s GPUs at this point, so I guess I should get used to writing ‘AMD Radeon’.
** The bug could very well be in our code, but since the code worked on old ATI drivers and a number of other driver stacks, it may very well be a regression in the driver itself. We won’t know until it’s fixed. And even then, maybe we won’t know.
The HDR check-box turns on HDR mode in X-Plane 10. But what is HDR mode?
High Dynamic Range( HDR) mode in X-Plane actually enables many features at the same time. We put in a single check-box because the features all fit well together, and we wanted to keep the interface simple.
High-dynamic range rendering. In HDR mode, the world is rendered across a wider spectrum of brightness (just like real HDR photography)*, to better capture lighting levels. The result is then compressed to low dynamic range (which is what your monitor does).
Tone mapping with real-time exposure. The HDR image is converted to LDR via a tone mapping algorithm that attempts to preserve the character of the image while keeping the dynamic range within limits of your screen. The level of exposure changes in real-time: if you look at a bright scene and then duck the camera behind a building, you’ll see your eyes slowly adjust up, then everything gets dark when you stare at the sun. (The level-adjustment algorithm runs entirely on the GPU for performance.)
X-Plane uses deferred shading for all rendering except for translucent glass in aircraft. Deferred shading is a 2-pass approach to rendering that is commonly used in today’s shooter games, because it allows us to efficiently draw huge numbers of real 3-d spill lights. In the case of X-Plane, you get a lot more night lighting.
The individual puffs in our 3-d clouds have soften intersection with the terrain to avoid ugly cloud-ground collisions in low-cloud conditions. (See page 1 and 4 of the article for before/after pics.)
We emit heat blur from the engine particles. The ability to add blur effects is a capability of the deferred rendering engine; something I’d like to do more with in the future.
Optional atmosphericscattering. This effect enables a more advanced lighting and fog shader that runs on the GPU and models the diffusion of light through the atmosphere as it hits oxygen and water particles. Atmospheric scattering is what makes the far view ‘bluer’ than the near view.
So the moral of the story is: the HDR check-box actually enables a lot of effects!
Why Did You Put Everything in One Check-Box?
We had a few reasons to put a lot of effects into one bucket:
Some of those effects require other effects. For example, you can’t have the heat blur or soft cloud puffs without the deferred renderer.
We wanted to keep the UI simple. Our view is that the rendering settings screen is way too complicated and hard to tune, something we’re still looking to improve. So any time we add features, we have to ask: can we make this simpler?**
There are fewer combinations for us to test if there are fewer settings. Sometimes we can have bugs based on combinations of features, so having the features all enable at the same time simplifies development of testing, which is extra important when we have to test GPU features against different hardware and drivers already.
* GPU nerds: The final render surface is in 16-bit floating point format.
** If you really want to get tweaky, most of the sub-effects within HDR mode can be accessed by settings.txt. But if you edit settings.txt and your computer transforms into an alien cyborg and destroys humanity, don’t hold me responsible.
If you’ve survived downloading the rather large 10.25 patch and you want to download even more data, good news! Alpilotx has just released version 2 of his X-Plane HD Mesh Scenery.
His scenery pack is a donation-ware recut of North America and Europe. Alpilotx’s HD scenery use the latest OSM and other global data sources, and are cut with the latest DSF generator; thus they contain better DSF generation with newer data. Alpilotx then cranks the mesh settings well beyond what we can ship with the global scenery (which must fit on a DVD set and not fill an entire SSD), bringing out wonderful terrain definition and other detail that we have to cut down for the global scenery that ships as a default with the sim.
One of the cool effects of cranking up the base mesh detail: it brings new detail to the terrain shading. In X-Plane 10 we moved the process of altering terrain with slope (from forest to grass to rock, or whatever the artist defines) from a CPU process calculated ahead of time to a shader process run on the GPU. The result is that more detailed meshes actually produce better shading, as the shading responds to the 3-d detail.
If you have a computer that can run them, these meshes look great, and they get you a source of recut DSFs now.
The recut DSFs that Laminar ships will be based on the same DSF generation code improvements and the same new data, but the resolution will be reduced to produce files of similar size to the default scenery we already ship. We have not decided exactly how we will ship recuts; I think that really important fixes (e.g. Sydney with the harbor fixed) will be automatic updates; I don’t know about a wider scale yet.
X-Plane 10.25, out now, is a big update by size – 1 GB compressed, if you were current to 10.22. The result on our servers is, well, higher than normal load. (That nearly flat top-out at 100 mbits is 10.25 kicking.) We’ll keep an eye on things; I expect that server load will settle down in the next few days, once the initial rush of auto-updates goes through.
X-Plane 10.25 went final today; if you’ve launched X-Plane you already know that from the auto-update notice. With this update we shipped the first set of lego-brick airports, and new urban and natural terrain. We also updated WorldEditor to version 1.2.1 during this beta run.
The Necessity of Saying Too Little
This post, like all “road map” posts, will almost certainly be too vague for your liking. What you’d really like to see is a list of features and a list of dates, e.g. “we will ship X on this day, then Y on this day” for future X-Plane patches. Unfortunately I cannot provide that. I also can’t expect you to be happy with only vague release notes. But I have to hope that you can at least see what things look like from the other side of the table; if you were in my position, you might not post too much either.
There are a few problems with announcing new features way in advance:
The penalty for being wrong is a lot higher than the benefit of being right. If I can predict our future features directly, at best everyone gets excited and impatient for the new release. But if my prediction is wrong, it will make everyone very angry. So if there is any risk that a feature might not come out when we think it will, I think everyone is better off without pre-announcements. (We are not the only tech company or even flight simulation to maintain this policy.)
It is really hard to predict when new features will come out for technical reasons. Or put another way, if what we are trying to do is new and novel, there aren’t good things to compare to in order to estimate schedules. We thought we’d ship real-time shadows in X-Plane 9.0, but when 9.0’s release date came around, they just looked awful; the technology we had picked was not good enough. So we put them on ice, re-coded them and released them for X-Plane 10.0. That kind of thing is hard to predict; we had working shadows for v9, they were just horrible. In hindsight I’m really glad I didn’t pre-announce “X-Plane 9 will have real-time shadows” – everyone would have been disappointed by the lack of shadows, and it would have drawn away from the real-time water reflections we shipped.
It’s also hard to predict when new features will come out for business reasons; if a feature isn’t being worked on “right now”, there’s the risk that some kind of high priority emergency will come up. For example, during the X-Plane 10.25 beta run, we realized we had to recut our installer, because it had a crash bug on certain OSX versions. That time wasn’t in the estimate, but the installer crash was an emergency. Had I said “X-Plane 10.25 will go final on November 15th”, I’d have been wrong, and you’d be mad that we had mislead you.
So my first point is that software is unpredictable, and I think it’s better to keep quiet until we’re sure we know what will happen. Thus, no statements about what we will release six months from now.
Guidance Is Important
If you develop third party aircraft, you’re probably jumping up and down at this point, going “are you freaking kidding me? I can’t plan my business this way!!!” And you’re right. What I can try to do is provide guidance about technical challenges that you might face as an author.
Our overall goal is to maintain add-on compatibility within a major version run. If your add-on follows the rules, we’ll try to avoid changing the rules. But sometimes add-ons bend the rules, and updates can affect those add-ons. I try to provide hints as to what is going to matter, far ahead of time.
For example, X-Plane 9 introduced the concept of ‘glass’ objects in an aircraft. Glass objects solves the problem of getting your cockpit windscreen and 3-d interior to render in the right order, which is nice. But it also is necessary to get high quality translucency in HDR mode in X-Plane 10. So we tried to get the ‘glass’ option into v9 and then encourage developers to adopt the new scheme, as it provides both better results and future proofing.
Big and Small Patches
Our patches to X-Plane come in two sizes these days:
Big patches have long betas (4 weeks or longer) and make significant change to the sim; we need the beta time to find and fix bugs introduced by the new changes.
Small patches change a very small amount of code; we test them for only 1 or 2 weeks. Because the amount of code change is very small, we don’t have to worry as much about strange bugs we didn’t expect.
X-Plane 10.10 was a (very) big patch, and 10.20 was a big (albeit not very chaotic) one. The bug fix releases (10.11, 10.21, 10.22) were all, of course, tiny – they just fixed 1 or 2 bugs that made it past beta.
X-Plane 10.25 is actually a small patch by our standards – while it provides a lot of great stuff for users (airports, cities, etc.) and it’s a big download data-size, the code changes are incredibly small; it’s mostly art files.
Future Releases
At this point our next “big” release planned is 10.30. We have a ton of stuff planned for it; it’ll be a big release, offer significant new features, and probably take quite a while in beta.
If you are a third party aircraft or scenery author, you will want to re-check your add-ons on 10.30. I know that this takes time away from working; we try to not have a “retest everything” patch that often; the last one was 18 months ago. Remember that if you find something broken, you will need to report a bug, not change your add-on!
(As a side note, I hear this from third party developers all the time for bugs that have been in the sim a while: “You mean no one else reported this bug?” Everyone thinks someone else will report a bug; some bugs that are visible only on third party content thus never get reported. Assume that no one has reported a bug – you’ll often be right!)
We may do at least one more small release before 10.30, either for DSF recuts, more lego brick airports, or to fix any crash bugs that we find. But at this point no code features are going into the sim before another “big” patch – small patches will be for art.
In terms of timing: I can say with some certainty that 10.30 will be next year, not this year – there are less than six weeks left in 2013, and we won’t be ready to public beta a big patch that soon. I think it is possible that we’ll have one more small patch in 2013, but we don’t have a firm plan yet.
The DSF recut work is mostly done, but I am going to wait for AlpilotX to release his latest HD scenery; his scenery is developed using the same tech as the global scenery, so it should give us a good idea as to whether the recuts are ready or need bug fixing.
