Plugins can use OpenGL to draw directly inside X-Plane; this capability is almost fifteen years old and goes back to X-Plane 6. Plugin drawing typically falls into four categories:
Drawing user interface (floating windows, HUD-like UI, map details, etc.).
Drawing effects in 3-d (custom smoke or fire, or maybe diagram marks showing lift).
Drawing solid stuff in 3-d (e.g. pushback trucks, parts of the airplane, etc.).
These first two use cases work pretty well; the third case works barely, and the last one is a bit of a train wreck.
Problems With Plugin Drawing
OpenGL an 3-d hardware was very different when Sandy and I created the original plugin SDK 1.0. Hardware had a fixed function pipeline built into the GPU itself, and your computer had one CPU core, so the issues I’m going to describe weren’t a problem back then. Here are some problems with plugin drawing:
Increasing overhead just to draw. It used to be that we could just send a message to the plugin system at “good times” and let drawing happen. X-Plane now has to do a bunch of work to prepare OpenGL for plugin use; this synchronization work slows down X-Plane, and it’s getting worse as X-Plane’s internal design diverges from the canonical OpenGL 1.5 pipeline. (Example: we have to copy our matrices into the fixed function pipeline matrices before we call you, then copy them back if you call us with a drawing routine. Slow!)
Plugins don’t have access to the fastest drawing paths. The less our drawing looks like OpenGL 1.5, the less efficient plugins are in comparison to X-Plane. This is getting worse over time too. (For example: if we want to render two VR eyes at once, we have to call your plugin twice, once for each one.)
Plugins don’t have access to our lighting environment or G-Buffer formats, and thus can’t easily draw in a way that integrates with our 3-d world. This is getting worse as our rendering engine becomes more complicated.
So…this is not fantastic. The first two use cases (UI and panel) aren’t that badly affected because the two of them require only 2 or 3 call-outs to plugins, drawing in a very simple manner. The second two (3-d use cases) are quite problematic.
These costs are going to get worse when X-Plane moves to Metal and Vulkan drives; the cost of syncing over to OpenGL will be higher, plugins won’t even be drawing on the fastest APIs, and we may have to do some expensive texture synchronization.
Fixing The Problem
My goal isn’t to completely eliminate the costs of plugin drawing; rather just to minimize the costs by providing better alternatives for common tasks.
So in the long term, my plan is to add something to the SDK that we should have had for a while: the ability to create persistent object and effect systems in the X-Plane world.
Right now if you want to draw an object, you call XPLMDrawObjects – hopefully you’re doing this from just the right callbacks, but if you get this wrong, I forgive you; the rules for how to do this correctly in the v10 and v11 renderers are insanely complex, because the plugin API was invented fifteen years ago.
In the future, you will be able to simply create an object and X-Plane will draw it at all the right times, for any rendering mode, handling all of the special cases for HDR, shadows, reflections, you name it. You’ll just need to tell us when it moves. The same idea can be applied to particle systems for effects.
The one open issue with this scheme is how animation will work. Currently animations is handled by reading datarefs – if you want to animate multiple instances from a plugin, you have to figure out (inside your dataref handler!) which instance is being drawn and return the right animation values.
Not only is this a complicated mess, but it’s also slow; it requires us to call your dataref callback many times from inside the drawing loop, slowing everything down.
What I’d like to have in the future is some kind of ‘animation block’ where:
Your plugin queries the object to find out which animation values it needs.
Each time you update a particular instance of that object, you provide a packed block of the values of all of those animations.
We use the block directly and never have to call datarefs.
This technique isn’t just faster, it also is easier to make multi-core and will play nicely when we can instance animation in the future.
The time frame for this is “during the v11 run hopefully” – that is, a new object API is not going to be in 11.0, and I can’t guarantee when it will be. I expect to support the old way (XPLMDrawObject and drawing hooks) at least through the entire v11 run, if not longer; our expected failure mode is ‘if you do it the old way, the sim might be really slow’. The new APIs will be designed to be completely friendly with multi-monitor, VR, Vulcan, and multicore.
X-Plane 11.00 public beta 13 is out, and hopefully it has restored engine operation that beta 12 broke. If you are developing an aircraft and your engines don’t work right in public beta 13, please let us know.
X-Plane 11.00 public beta 12 is out. A few notes on the engines:
Jet engine thrust at low N1 should be fixed; you should no longer have to kill the ground crew to taxi around the ramp. If you find weird jet engine N1 behavior, please report a bug ASAP!
Reciprocating props will need to have their idles adjusted, perhaps a bit higher, particularly if your idle adjustment is < 1.0 in Plane-Maker. We had to bump up our Cessna, which was set to about 0.8 and was stalling if not given a little extra throttle.
The engine start code has some kind of bug that is stopping engines from starting.
If you’re hitting this last case, please file a bug and include the aircraft that won’t start.
From what I can tell, the beta 11 code is actually correct for some airliners, but is wrong for others. I’ll have more details later and I suspect we’ll have a beta 13 that addresses this by Tuesday.
In a previous post I noted that we weren’t attempting dynamic ambient occlusion inside the 3-d cockpit, due to problems of quality, availability, and because it wasn’t really better than what authors do now: prepare the AO offline using a high quality render in their 3-d modeler.
I’ve been thinking about this a while: while I like to get up on my soap box and shout that X-Plane is not like a firstpersonshooter any time we get compared to a AAA console title, there is one case where X-Plane kind of is like one: inside the user’s aircraft.
First person shooters often specialize in rendering highly controlled, closed, constrained, claustrophobic environments in ludicrous detail at very high framerate. To achieve this, they take advantage of optimizations specific to those closed, controlled environments: lots of things are pre-computed, pre-baked, and pre-calculated.
X-Plane’s scenery engine mostly focuses on throughput; once you climb through 500 feet you can see everything at an airport, so we just try to draw really fast. But the inside of the aircraft is different. Baking at least part of the interior lighting is pretty much a standard practice. We provide object-kill datarefs to let authors script their own culling algorithms to squeeze framerate out of a confined space.* We define sound spaces within the aircraft that can change how sound effects are filtered.** We let you mark which parts of your aircraft receive interior and exterior light. (This feature is called “light groups” in a regular 3-d game engine and it’s very common, particularly in older forward-rendering engines.)
All of this stuff is a lot more like a game with a 3-d level editor than the rest of X-Plane. Techniques that focus on interior spaces are a good fit inside an airliner.
Better Baking: one of the features planned for our next-generation modeling format is to allow multiple UV maps for a given model***. We can then add an ambient-occlusion texture to an object’s shader and you can bake your aircraft interiors at a much lower resolution than you albedo textures.
For example, you could use a high-res repeating texture to draw the seats inside the aircraft, copy-paste the seat down the cabin, and then unwrap a second UV map that covers the entire cabin uniquely. Bake to this second UV map, down-size the texture to super low res (it’s ambient occlusion, “soft” is okay) and you’ll get high-res detail with unique correct lighting queues all over the aircraft. This is a standard work-flow for 3-d game engines and seems like a good fit for aircraft interior.
Edit in the Sim: we can take another clue from game engines and provide editing of graphical aircraft information inside X-Plane. We already do this for the particle system – the editor is built into the sim itself.**** The advantage of editing in the sim is that you can see your work exactly how it will look in real time.
* Engines that focus on interior spaces often have techniques like portal culling built-in and tools to precompute the information for this culling automatically.
** This is part of the new FMOD SDK – we will get this documented around or shortly after 11.0 goes final.
*** I realize this isn’t very “next-gen” in the world of rendering engines – it’s just the next major modeling revision for X-Plane.
**** The particle system isn’t documented because it isn’t quite finished yet. It’s shipping in mobile, enabled on desktop, but it is not running the default effects right now.
We’re looking to add two developers—one junior, one senior—to the Laminar Research team this spring.
As a member of our team, you would:
Work on stuff that matters. Real pilots fly safer because of training in X-Plane, and real aerospace organizations (like Boeing, Cessna, and NASA, to name just a few) prototype aircraft in X-Plane before they build them in the real world.
Work on a product that millions of people will see. You’ll get feedback from users, and that feedback will drive future development.
Have tremendous input on the direction of the product. Because X-Plane is an exceedingly small team, every team member has a lot of say about what we work on and how we make the simulator better for our users.
Set your own schedule. As far as we’re concerned, if you’re shipping features and fixing bugs, it’s your business when you do so.
Work remote. No commute, no cubicles, nothing to impede you from doing great work. (But the rest of the team is just a Skype call away!)
Work on a variety of technologies and products. At various points, you might work on X-Plane, Plane Maker, WED, the X-Plane installer, the Scenery Gateway web app, or even the X-Plane.com web site.
Qualifications
A qualified junior candidate will:
Have a computer science degree.
Be a quick learner. We expect most of what you need to know (beyond computer science fundamentals) to be learned on the job.
Have the self-discipline to work from home and set your own schedule. (It’s not for everyone.)
In additions to the above, a qualified senior candidate will:
Have experience shipping major features in production applications with minimal oversight.
Have specific experience relevant to X-Plane. There’s no exhaustive list of skills we could use, but some possible examples include:
Real-time graphics
Real-time C++ development
Mobile development
Game development
GIS data processing
Networking
The X-Plane plugin system
How to Apply
Send an email introduction to me that includes:
Which position you want to apply for
A brief overview of a project (or projects) you’ve enjoyed working on
Discussion of projects you have not enjoyed working on
The introduction is really just a means for me to get a handle on who you are as a developer, so do not stress over it!
My email is my first name at X-Plane.com. Please do not attempt to apply in comments!
(Not sure if this is a good fit for you? Email me anyway and we can talk. 🙂 )
This has been a point of confusion for third party developers, particularly ones who were in the private beta (and saw versions of the sim that…cough cough…didn’t work right).
Screen space ambient occlusion (SSAO)*, when enabled by the highest rendering settings, only affects exterior objects. This means scenery and aircraft-attached objects marked “exterior” for lighting.
I tried SSAO in the cockpit interior, and it had a few problems:
The scale for occlusion in the interior and exterior of the cockpits is really different – I couldn’t find one size for the effect that fit all cases.**
When I went to apply the effect to our fleet, I found that virtually all of our aircraft already had occlusion baked into the cockpit by the artists. The dynamic AO thus provided almost no value and made the cockpit even darker than it already was.***
SSAO only works at the highest rendering settings (and requires HDR to function at all), so if artists remove their baked AO, they’re taking a pretty big visual loss in a bunch of settings.
So in net, it just wasn’t worth going to dynamic AO in the cockpit. Our AO isn’t as high quality as what you can bake in a 3-d program (given a few days of rendering time), and it’s not always available.
The real win for SSAO is outside the aircraft, e.g. to cast AO around the wheels of the aircraft on the ground. That’s an effect that you can’t bake, and it helps a lot with lego brick scenery too.
* Nerd note: I’m pretty sure that what we do is actually HBAO
** We could, in theory, apply the effect twice with stenciling at two different scales.
*** The cockpit tends to be dark both due to errors in our approximation for indirect light (because most of the cockpit is in shadow, and thus only lit by indirect light) but also because cockpits are actually pretty dark compared to the great outdoors. But that’s another post.
You might have noticed we’ve been working our tails off to make X-Plane 11 an amazing sim, with tons of new features, and during that time we didn’t have the resources to do anything further with our proposal to publish X-Plane usage data. The good news about our delay is: we now have usage data for both X-Plane 10 and X-Plane 11.
Since one of us (ahem) remembered we had promised to provide this at intervals, here’s the latest data update. It’s still not particularly pretty, but we have a handful of easy-to-digest charts, plus the raw data at the bottom of the post for those that are interested.
Items of note
All data in these charts are for users of the full version only—we’ve filtered out demo users.
If an aircraft’s name, studio, or number of engine fields in Plane Maker are changed at any point, the aircraft will show up in the data as two different entries.
Aircraft
Hardware
Raw Data
There are four files here: hardware data and aircraft data, for X-Plane 10 & 11. Each contains all the information we have since September 2015, for paying customers only (no demo users).
X-Plane 11.00 public beta 10 is out today – if you are an X-Plane 11 user, you should get an auto-update.
Linux Users: Beta 10 won’t run on Linux. Something went wrong with the build process, truncating the last 1/3 of the executable. I’ve been building X-Plane releases for over a decade now, and I have literally never seen this happen. I’ll get this fixed as soon as I can. In the meantime, you can download the correct executable here. You may need to chmod it to run it. Correct MD5 signature is 985dc19a246f303fbb0d484937cfab7c.
Update: Beta 11 is out and fixes the bad Linux version of X-Plane. If you hand-installed the fixed version, you’ll need to tell the installer to replace the previous version you downloaded.
As we get toward the end of the public beta program, one thing we’re trying to do is get our interfaces in order for creating airplanes and scenery with X-Plane. Beta 10 brings two new features for authors.
Metalness in Scenery. Finally, you can now use NORMAL_METALNESS in any art asset that uses the standard shader. That means facades, roads, forests, draped polygons, line-work, draped objects, and anything else I forgot can all mark their normal maps for the metalness work-flow and use the blue channel to specify the metal/dialectric property.
What about BLEND_GLASS? Sorry, not only is BLEND_GLASS limited to objects, but it is limited to objects that are attached to airplanes and set to glass-interior or glass-exterior lighting. Basically the airplane rendering code has a special “blending” pass that runs outside deferred rendering, only for glass, and only aircraft have access to it.
Someday we may have scenery-system access, which would let us finally solve translucency problems in control towers, etc., but until that happens, BLEND_GLASS simply won’t work in those cases. So that’s a scenery system extension for another da – it won’t be in 11.0.
One more note on the scenery system: When X-Plane 11 calculates the smaller mip-maps for a normal map, it will increase the roughness of a normal map’s alpha channel based on the bumpiness of the’s normals themselves. In other words, if you burn rivets into your normal map, it will mark those spots as rough in the reduced-res version where the normals aren’t visible.
This process runs on PNGs; you can also convert your normal map to an RGBA-format DDS and pre-build the mipmap chain yourself with DDSTool; if you do this, you can customize the roughness of the lower mips. If you find your bumpy models look “too shiny” from far away, this can help. If you find a case where X-Plane’s reduction doesn’t do a good job but your hand-built mipmap works well, please let me know!
2-D GPS Units
Public beta 10 features pre-made 2-d instruments for the X430, X530, and FMS CDU, all with the bezel and buttons attached and fully functional; simply drag them onto your 2-d panel and fly.
These new 2-d instruments exactly match the pop-up window versions of the instruments, and this gives you a way to customize the pop-up window’s appearance. Simply customize the 2-d instrument’s textures the way you would any other pre-made instrument, and the popup window will match its appearance. You can use this technique to customize the popup even if you don’t use the 2-d instrument on your panel.
We now have both 2-d and “screen-only” versions of both GPSes and the CDU. The screen-only version is meant for use in a 3-d cockpit, where panel space is only used for screens. The 2-d versions are meant for users building their own 2-d panels at home and as a way to skin the popup windows.
If you are building an advanced 2-d panel, you can either use the pre-made 2-d instruments or use the screens and build your own bezels out of generic instruments.
Plane-Maker 11.0 does not provide access to the legacy FMS and GPS – while they will work in v10 aircraft for compatibility, new aircraft must be authored with one of the new GPS or FMS choices. Our goal is to set a time-frame for deprecating the old FMS/GPS code and getting to an entirely modern GPS/FMS implementation.
Can I pop up my plugin windows? Not yet, and not for 11.0. This is a high priority for us for the next X-Plane SDK revision, but it isn’t quick to do; we need to write a bunch of new code to expose some of the new UI tricks to plugins.
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.
