While everyone looks at the new UI in awe, X-Plane 11 also had a few important changes under the hood. With Aerosoft Navdata Pro now also supporting X-Plane 11 beta, let’s talk about one of the most boring technical features of X-Plane 11: The completely redesigned database for navigational data, which makes it much easier for data providers like Aerosoft and Navigraph to supply data updates for the X-Plane navigational facilities, while preserving scenery compatibility.
The most important goal when designing the new database was to eliminate the duplication between data in X-Plane’s world and X-Plane’s navigation systems to leave less room for subtle inconsistencies. I also wanted to address compatibility of navdata updates and global scenery (mostly concerning localizers at airports). Other improvements were the integration of SBAS path points (needed for LPV approaches) and RNP service volumes. Last but not least I wanted the ability to work with ARINC424 data directly, and eliminate most of the subtle encoding differences that result from different providers generating files with slightly different converters.
The specification of the database was finalized in September, and both Navigraph and Aerosoft were provided the tools they needed to create navdata for X-Plane 11 in the new format. Actually, we are not limited to those “big two” – as the tool is available for everyone, open-data purists can actually generate their own navdata for the US and Canada using the FAA’s file.
With the great power of the unified database comes great responsibility: The navigational data can only be as good as the world scenery it is placed in, especially the airports. Some of X-Plane’s airports in the default scenery have not kept up with the pace the real world is evolving at: runways are renamed (due to magnetic shift), extended, built or closed and X-Plane’s airport scenery is only as good as the community who cares for it. To make their life easier, we are currently working on a big automated scenery update on the server side. We will rename several thousand runways all over the world on the scenery gateway soon, and this will solve the most annoying issue people are currently facing with the new database: runways not being found because they have been renumbered.
This automatic scenery update is however only part of the solution – because we can only rename runways we have! If an airport is extended in the real world because new runways are built, we rely on the scenery gateway and its incrediblecommunity for updated airports.
I took the time to write an even more boring technical article on how everything works together in X-Plane 11: Navdata in X-Plane 11. If you are an end-user, you don’t need to bother, because here’s the TL;DR: It’s awesome. It gives you RNP approaches for airliners, and LPV approaches for GA aircraft.
Writing this article though, when I compare it to the new UI, I can’t help but feel like the poor guy in this webcomic because this is exactly how the end-user will experience the change: Most won’t even notice.
[This post was co-authored with Tyler Young of Laminar Research to provide more insight into the design process for X-Plane 11, and cross-posted on the Blind Pig blog.]
A few years ago, we ran a survey of X-Plane users. One of the questions was: If you could improve one area of X-Plane, what would it be?
The most common response was, overwhelmingly… the flight model (cue rimshot). Yeah, right. Of course the number one response was the user interface. We took that criticism seriously, but we didn’t want to incrementally improve the user interface and the experience of using X-Plane when improvements were needed throughout the entire application.
So instead, we decided to redesign the user interface from the ground up. Now, two and a half years later, we can finally talk about it!
Back to Basics
Unless a strong brand is already established, I like to start with typography on most projects like this. Font weights, text colour, letter spacing and line height are carefully considered for each typeface option. And the results are always viewed on screen since that is where users will be experiencing the product. Often when going through this exercise, I frequently find a font family I think will work for the interface, only to discover its legibility is less than ideal. We explored several font families and decided on Roboto. It offered a comfortable reading experience for UI elements and the ability to easily extend the brand online. An updated colour palette was also developed for X-Plane 11. I tend towards monochromatic colour schemes with gradations of each colour filling out the palette. I started with the blue value from previous versions of X-Plane but created a darker overall scheme to use.
All of this was collected into a Component Library. This made extending the interface fast and easy and provided a consistent point of reference for UI elements.
A sample of the X-Plane 11 Component library
Let’s Get Visual
For X-Plane 11, we wanted to make everything as visual as possible—long, condensed lists of aircraft, airports and settings were dropped in favour of tiles, maps and ‘wizard-type’ user flows. Previously, if you wanted to pick where you were going to start at an airport, you had to navigate through a long text list of runways and ramps; now you can use the visual location picker and just click on the map.
For weather, there’s no more text descriptions of cloud and wind layer heights; just click and drag! You also get visual indicators of precipitation, and real weather gives you a preview that looks exactly the same.
Under the settings screens, joystick configuration has been vastly improved. We’ve worked hard to provide a comprehensive list of interactive images of your hardware, so you don’t just have a text list of buttons that don’t mean anything.
Filters, Search and Settings
In some cases, there’s no avoiding text lists. X-Plane is a very comprehensive and powerful flight simulator, and as such, there’s an incredible amount of configuration that needs to take place before taking flight. For version 11, all text-based selections support filters and/or search. Gone are the folder views and unmanageably long text lists; instead, users can now filter along all sorts of dimensions.
Ready for Takeoff
Overall, I was extremely happy with the re-design process—I really enjoyed working with the team at Laminar Research and we feel we really improved the user experience on X-Plane 11. But what matters most is what you think. So far, initial reviews are positive—if you’ve tried it out, please let us know your thoughts.
A user asked me whether we would ever have a conditional directive in the OBJ format to let an author vary the look of the object based on weather. My answer:
Definitely not – this is definitely not the intention of conditionals!
The goal of conditionals is to allow authors to cope with multiple “rendering modes” of the engine, where:
The look of the sim is radically different between the rendering modes and
The performance cost of working around the lower rendering mode is expensive.
So for example, when shadows are off, you have to use some ATTR state change to drop a fake shadow on an object. This kills instancing, so when shadows are on (and the sim needs more performance), leaving that double shadow is not only ugly, but slow.
The conditional works by fully “stripping” those commands for shadowing from the object, then re-analyzing it.
So the win of conditionals is that you do not pay for what you don’t use, because everything is done on load – it’s like shipping two highly optimized objects.
But the down-side is: conditionals require scenery to reload, which is slow, disruptive and annyoing. This is why we would never use them for something that is dynamically changing in the sim, like weather or time of day.
We do want to have weather effects, but our approach is going to be very different: to have a “weather map” texture on the object (same UV as the object) indicating what sections of the texture will receive changes to their material due to weather effects. This will allow the object to look progressively more wet over time without a reload as the rain falls.
I have written quite a bit on X-Plane 11’s rendering settings, but it has mostly been in the form of me being grumpy with users in the comments section. This post explains some of the thinking behind the decision, and what you can do about it if you really miss them.
Random Choices
Here’s a scenario that played out over and over and over and over during the last few years: a user with a high-end gaming machine would get X-Plane, max out all of the sliders, and find the sim ran like a slide-show. The user would then randomly reduce some of the sliders, find the sim still ran like a slide show and now also looked like hell, and would complain to tech support.
Tech support would forward me the report, and when I’d get a screenshot of the rendering settings, it was clear: the user was not getting even close to the best performance/quality trade-off possible for his hardware.
X-Plane 10’s settings were too numerous, too complicated, too esoteric, too astonishing, and way too low level. Users were setting them incorrectly, and this is entirely understandable, because you had to understand the underlying rendering engine’s implementation to set them correctly.
(If you’re going “I understand that some things affect CPU and some affect GPU”, then you’re one of a very small number of users who pays a lot of attention to this blog and the comments – you’re not normal! And you might still not know all of the weird fine print; the CPU-GPU divide is just never that clean.
No Wrong Answers
For a rendering setting to make sense, I think we can establish a few requirements that it must meet:
No wrong answers. We don’t want there to exist any set of rendering settings that a user can pick where the sim is being inefficient in its trade-off of quality and performance. We can have settings that optimize for quality rendering and settings that optimize for framerate, but we should avoid settings that optimize nothing.
Understandable. The rendering setting should control something that makes sense to the user. “Draw trees” is understandable – users know what trees are. This means the settings need to either control reasonably obvious things, or control settings that are industry standard. (E.g. not everyone knows what full screen anti-aliasing is, but virtually every 3-d game has this setting, so we consider it “standard”.)
Not Astonishing. The setting needs to actually control what it says it will control. The “airport detail” setting in X-Plane 10 was a really terrible setting, because it did control slight improvement in the curvature of taxi lines, but did not actually affect the 3-d stuff at an airport. An airport detail setting that does not control airport detail…astonishing!
Not Buried. We need to have few enough settings that users can find the ones they care about, and they aren’t lost in a sea of noise.
These rules place some limits on the kinds of things we can have as settings. We can’t have settings where picking the wrong answer will break the sim. We can’t have settings that are so low level that users won’t know how to set them. (The sim has a setting for how many shadow map cascades have 3-d objects, but do you know what the right answer for that setting is?) And we can’t have settings where their operation is so counter-intuitive that they aren’t going to do what users expect.
We took the existing settings and did a mix of moving them around, grouping them, and in some cases removing them in an attempt to meet these guidelines.
But I’m A Tweeker
Some of you really love settings. Some of you might even love settings more than flying the actual sim. If you are in this bucket, the good news is: settings.txt still exists in Resources and you can still hack it up to get complete control over everything in the engine. X-Plane has always been open to tinkering, hackering and exploration, and this is not going to change. If you modify settings.txt and get better performance at better quality, please let me know – I’d be happy to incorporate your tuning into the sim itself.
But please don’t tell tech support that your machine is smoking if you hack up settings.txt. Setting.txt and the art controls are for hackers who want to poke at the machinery with a stick and see what happens. (They are also not for pay-ware add-ons to mess with because they change frequently.)
Where Did My Settings Go?
What follows is a long list of specific settings that are gone and what happened to them. I’m posting this so you can get a sense of the “why” that went into this. The very fact that this list is so long is part of why this needed fixing.
Compress Textures: This is merged with the texture slider, so that uncompressed textures is now a “super-resolution” on top of the highest compressed resolution. This prevents the previous silly combination of a low texture resolution without compression. In any case where we can pick compressing vs shrinking the textures (each of which reduces textures size), compression is the better choice.
Gamma Control: The sim now runs in the sRGB color space, and gama “correction” of DDS compressed textures looks like absolute hell. If you’re a hacker and really want to mess with this, there are exposure art controls; my view is that it’s up to our art team to make the sim the right brightness. But hacking the color space makes absolutely no sense in an app that’s designed to run in a linear color space.
Draw View Indicator: always on – it’s for 2-d views only, so I’m not sure how much anyone cares; we may end up nuking the entire feature.
Dim Under Hypoxia/G-Load: always on.
Draw Hi-Res Planet Textures: always on; the scenery looks like a disaster without it – there’s no reason to be turning this off given X-Plane’s system requirements.
Runways Follow Contours: this is now always on; individual airports can be marked for flattening on a per-airport basis. This means authors can control how their scenery is viewed and users don’t have to toggle the setting mid-flight.
(This is one rendering setting that we may have to put back. While I am concerned that putting it back will slow the adoption of flattening control in the scenery community, there are some use cases that can’t live without it.)
Draw Forest Fires and Balloons: Off – we’ll turn it back on when we can get the balloons to only draw in appropriate locations, then always leave them on (in those locations and at the right weather).
Draw Birds and Deer: Always on. Deer are restricted by airport size; we do have an open bug to make sure that these animals always honor the sim’s overall reliability and failure settings, e.g. you’ll get hit by birds if you command a bird strike failure or if you allow the X-Plane world to throw curve-balls at you.
Draw Aircraft Carriers and Frigates: Always on – there isn’t a good reason to have them be off.
Draw Aurora Borealis: Always off. If we develop a modern renedering of the aurora at appropriate latitudes, we’ll have it be always on in the appropriate places.
Side note: one thing you might notice here is that a lot of these settings let you turn off and on “cute tricks” that would then draw everywherewithout context. My view is that these things need to draw in the right locations only and then they can always be on.
Tree Density/Object Density/Road Density/Number of Cars: this has been consolidated down into a single “number of world objects” 3-d slider. The idea is to balance all 3-d so that CPU time is spent efficiently and the rendering looks plausible. We have some future work to do to make low-setting autogen and roads look better; we can be smarter about how we simplify the scenery, and that smarter simplification is not going to fit into nice buckets like “draw park benches” or “draw median strips”.
World Level of Detail: this was merged into the single 3-d slider. This one was a tough call, but in the end, I think that the use cases that people wanted for keeping this slider were almost entirely work-arounds for inefficient management of LOD in the sim itself. This will have to wait for a patch, but I think we can be a lot smarter about our draw distances and that will result in a better sim. Again, the smarter, better managed LOD isn’t going to be a single-dimension slider.
Runway and Taxiway Smoothness and Lighting: the lowest setting is gone; you always get 3-d light fixtures at airports. The “smoothness” code didn’t do much; you get slightly higher smoothing at the top 3-d setting. This slider didn’t do much and users tended to max it out for very little benefit.
Requiring 3-d light fixtures is an example of something that has happened a lot in v11; we’ve dropped the very-low-end rendering configuration from v10 that existed to support only the worst of the worst hardware – that hardware is now below system requirements. If you can run v11, you can handle 3-d light fixtures, and they’re really not expensive.
Shadow Detail – this was split: the detail of 3-d shadows is in the visual effects slider, and whether shadows draw on scenerty is a single check-box, exposing the one “trick” that was really useful: turn off scenery shadows, keep the airplane, and get a ton of fps back. The old overaly/static shadows (which just drew a quad with a dark shape of an airplane on the ground) are gone because it’s not 1995. The shadow resolution is often pixelated in v11; this is an open bug, not something that should be in a slider.
3-D Bump Maps/Gritty Detail Textures: these are now part of the visual effects setting; turning them off is a huge loss in quality and was only meant for the worst of the low-end hardware, so you get these unless you go to “minimal” GPU.
Draw Volumetric Fog: this is always on – even Intel GPUs can handle this and it’s a necessary part of the v11 rendering engine.
Draw Per Pixel Lighting: this is always on. It’s not 1995.
HDR Rendering: this is part of the visual effects slider – the idea here is a single slider that manages everything on the GPU; again, the goal is efficiency at all levels.
Atmospheric Scattering: this is always on, even for non-HDR rendering!
For volumetric fog, atmopsheric scattering and the new PBR lighting, these effects are all on al the time, giving authors a consistent single lighting model to target when authoring. We get our low-end fps by providing low-cost/lower quality versions of them.
Anisotropic Filtering: always at the default 4x. 16x isn’t a huge help, and 4x isn’t that expensive. If you want more control, your driver control panel will override us.
DSF Extended Scenery: always on, now that we’re always 64-bit.
Cloud Detail: this is supposed to be tied to the visual effects slider, so that we don’t roast your GPU with clouds if you turn this down. This is definitely broken in the public betas, but will be fixed before we go final; tuning this is waiting on me fixing cloud performance overall. When done, the visual effects slider will be able to modulate a whole pile of stuff to ramp or down the load on your GPU.
Public beta 9 is now live – this should fix null texture crashes (we hope – if you still see one in beta 9, please do report it with log files!) and has a performance improvement we’ve been working on for AMD Windows hardware.*
10.52: We do have a back-port to X-Plane 10 for this fix; had we figured this out any later we probably wouldn’t have brought it back. I had 10.52 (which is just 10.51 with an external visual sync fix) staged on the servers when we figured out what to do for AMD cards. My new plan is to recut 10.52 with the AMD fix. This will probably not happen until at least mid February due to other deadlines that come first.
Physics: Austin’s flight model changes for bodies shadowing control surfaces is not in public beta 9; it should be ready for the next beta. While I don’t know exactly how much more beta we have, my hope is that we get to RCs in a few weeks.
Scenery: I have a mostly recut scenery set, but it still has one bad tile. Besides fixing the bad DSF tile, I am still working on how the installer will handle the update. Digital download customers will be able to download this updated global scenery; we are working to make the download separate from sim updates, so that you don’t have to download a 50 GB scenery update to get a 26 MB sim update.
The good news is: the new scenery set will meet our size requirements even with northern latitude included. So we don’t have to decide between DVDs and Alaska; we can do both.
Alpilotx also has an import of tall buildings outside the US from OSM – this is a really great improvement, particularly for European cities.
Servers: we moved the master copy of X-Plane to a new server, and we’ve gotten some reports of poor download speed from users. At this point we think that this is a temporary slow-down as the content delivery network re-caches the simulator, but we’ll keep monitoring the situation and work with our CDN provider if problems persist.
Clouds: I am still fighting with cloud performance, so this work is not in a public beta yet, because it’s not quite ready for prime-time.
* The short version, for OpenGL nerds, is that we’re using system memory and not an orphaned VBO, to source the quads for text. Because we draw a lot of text and the draw sizes are very small, we appeared to be exhausting the number of orphaned buffers the driver could provide, leading to stalls. I am working on a more advanced solution to the problem, but in the mean time, using system memory for small draws fixes the problem.
X-Plane 11.0 public beta 8 went up over the weekend. If you are seeing problems with the flight model, please report bugs ASAP so Austin can look at them! I think we are approaching the end of some major flight model updates; the last thing Austin is looking at is better body shadowing, which he will probably write up shortly.
Over the weekend, with the help of some very patient users, we found the cause of poor performance on some AMD hardware*. I have a prototype fix, and I hope to have it in X-Plane some time this week. This fix will only affect users who were seeing super-lousy performance on very light configurations.
In the most recent betas, the threaded driver no longer totally kills X-Plane performance. But it does still slow things down a little bit on some computers – I see 5% fps loss with the threaded driver on. My suggestion for now is: try it both ways and run with whatever works best for your machine; this bug is affected by both your particular CPU and the kind of work-load your settings induce in X-Plane.
I am still working on improving cloud performance, and a recut of the DSF tiles is rendering as I type. The first priority for the new DSF tiles is to fix blatantly broken tiles (e.g. YSSY) and get the file size down so we can put Alaska and friends back.
* I wouldn’t call the AMD problem a bug on either our part or AMD’s – it’s more in the category of “OpenGL makes no promises as to what might be fast, so app developers have to debug on all shipping hardware and try not to do painful things.
I would just like to add that this is one of my favorite WED releases not only because it’s a really strong release (we started with the goal of just supporting X-Plane 11 but ended up with fixes to long-time bugs, really solid validation, new authoring features for serious users, editing improvements, and complete support for the new X-Plane 11 apt.dat format) but also because of how little of the work I did. This release was a real team effort, with volunteers from the X-Plane community and LR developers all working on new WED features.
Framerate should be back to where it was in beta 3. Betas 4/5 were not deleting smoke particles, so over time the total number of particles in the world would grow indefinitely, until the particle system was using most of the CPU.
Flashing in the cockpit should be fixed. The environment maps for the new lighting use alpha in the interior render to indicate areas where exterior light comes through, e.g. the windows of the plane. Due to using the wrong variable, on every other recomputation of the environment map, the alpha channel would be left opaque, effectively covering the windows in black paper and darkening the cockpit.
Finally, perhaps most importantly, this beta features a rebuild of the XPLM, the DLL that loads plugins. Besides modernizing the XPLM to use the newest compilers, this rebuild fixes the interface with X-Plane for popup menus (needed to get menu check boxes and disabling to work) and for keyboard focus (e.g. so you don’t get two blinking insertion points at the same time when editing text in a plugin).
Plugin authors: the expected behavior for the keyboard in X-Plane 11 is:
You cannot get any access to the keyboard when X-Plane has a modal dialog box over the screen (E.g. free flight configuration). This matches X-Plane 10’s no-plugins-when-the-airplane-is-not-showing policy.
Plugin pre-window keyboard sniffers have highest precedence – with great power comes great responsibility – use them with caution.
At any given time only one of X-Plane or a plugin can have keyboard focus. So if you take keyboard focus for an XPLM display window or XPWidget, X-Plane’s floating UI (e.g. the flight planner window) will defocus. If the user re-focuses a flight plan window, you will have your focus removed!
Plugin post-window keyboard sniffers get keys when (1) a plugin window does not have focus and (2) X-Plane doesn’t use the keyboard for UI. X-Plane command bindings run last.
If you find a bug with keyboard focus and your add-on, please compare behavior in v10 and v11, and please be specific about what you are doing! Plugin keyboard handling can be very complicated and hard to tease apart.
Finally, based on data from Austin and Marty, I have slightly recalibrated the fog settings. The sim is now foggier in ultra-low visibility (think: RVR1000) and notably less foggy in intermediate (e.g. 10-15 sm) visibility. I am still looking at fog in ultra-clear days (e.g. 50 sm vis).
If you guessed “X-Plane 11.00 public beta four”, you are right. 🙁 I screwed up the shaders, and they work on AMD cards and OS X but not NVidia cards.
So: public beta three is the official public beta again, and we’ll have a new public beta five out tonight that will fix this.
If you got the broken beta four (in the hour it was out before we caught this) you can re-run the updater by hand and force yourself back to beta 3, or just wait for beta 5 and then let auto-update do its thing. Unfortunately there’s no work-around in-app.
This one is definitely a big omelette on my face; I regularly swap through all of the major driver stacks on my PC and Mac to try to make sure the shaders work everywhere. In this case, I had “one little last change” that I only tested in some places, and sure enough, it looked innocent, but failed only on the configs I hadn’t tested.
Update: beta 5 is out and works on NVidia Hardware – just run the sim and let it auto-update. Beta 5 does have interior cockpit flashing – until we fix this, you can set the reflection detail to its lowest setting to work around this.
OK the new engine modeling for X-Plane 11 is great, but what good is an engine to us pilots without a propeller?
X-Plane has historically done an excellent job of estimating the THRUST of propellers, typically to within just a few percent… but what about the SPIRALING SLIPSTREAM? This has been an area where X-Plane has been much weaker… I just don’t see any good solid references for determining the spiraling slipstream angles for propellers…
and it’s a real shame because the spiraling slip-stream hitting the vertical stab is so responsible for the left-turning tendency in single-engine props.
BUT, can we do better? How would we estimate the slipstream angle, exactly?
Well, as it turns out, there is a pretty darn cool way to do it, which is going into X-Plane 11 Beta-4: A spinning prop is just a spinning pair or trio or quartet of wings (as X-Plane has long understood) and those wings have LIFT and DRAG.
The LIFT from the propeller blade is referred to as THRUST. The DRAG on the propeller blade is what opposes rotation and makes them so darn hard to TURN. Read More
