Time for an upgrade. Ben Supnik discloses the future of X-Plane Panel Rendering and UI SDKs, including some long-awaited requests!

For the last few months, I have been working on our road map for user interface and avionics. This effort is now far enough along that I can share what it looks like.

We have two goals with this roadmap:

1. Improve performance by allowing plugins to create user interface and avionics without OpenGL. OpenGL drawing requires expensive bridging and is impossible to make multi-core, so I see it as a roadblock to faster FPS. We want something that can be faster.
2. Make it easier to create user-interface and avionics. OpenGL is high-level for a graphics API but low-level as an avionics API; plugin developers often have to add libraries on top of it, like ImGui , or use slower alternatives like Cairo.

The roadmap addresses both of these, based on three bits of tech:

1. XPLM Panel Graphics
2. Native ImGui Integration Support
3. Browser-Based Windows

The rest of this post describes these three things and how they fit together.

Panel Graphics: an X-Plane Native Drawing API

Panel graphics is a new set of APIs in the plugin SDK that supports high-level drawing into an avionic or XPLM window. The AP supports:

• Vector graphics (outlined and filled shapes) with anti-aliasing, line width, and stipple, e.g. the things you need to draw avionics.
• True-type font rendering (rendered as MSDFs, so they look good at multiple scales and rotations).
• Texture atlasing – you give us some PNG files and we batch them together and draw textured meshes for you. This is the technology underneath Plane-Maker’s generic instruments.
• Scissors, stencil clipping and 2-D transforms to make complex avionics.
• Hot zones, e.g. the ability to recover touch-screen clicks and act on them.
• The ability to save bits of panel graphics and re-run them for efficiency.

Panel graphics meet our goals because:

1. It is implemented directly by X-Plane using Vulkan, so we have a fast, potentially thread-safe path to the hardware.
2. A bunch of problems are taken care of for you. We will load and render the true-type font into our shaders; you just name your file. We will load your PNG files, atlas them together, DMA them to VRAM, etc.

While panel graphics is not a general-purpose 3D drawing API, it should be better suited to avionics than OpenGL was.

Panel graphics will be an opt-in option for both windows and avionics.

Aside: Why Roll Your Own?

It’s a question you have to ask: why would we create a graphics API when there are already so many out there?

The short answer is: we looked at the other options, and none of them met our needs. We looked at Cairo, Skia, GLES, NanoVG, ImGui and we considered exposing Vulkan directly (but came to our senses in about 15 µsec). We have looked at a lot of stuff.

The biggest problem was integration: to meet our performance needs, we needed a graphics API where we could really get fine-grained control over how it interacted with the rest of our rendering engine. This, for example, was why we rejected Skia – we looked at how it rendered and concluded it would likely have similar integration pain as Zink. (They’re both great technologies – but they’re not meant to be “thin middleware for games” the way ImGui is).

Other APIs had the opposite problem: integration would be great, but they wouldn’t be useful to our users. For example, ImGui contains a “graphics API” in there somewhere, but it’s not the library you want if you want to make avionics. The libraries small enough to integrate well often didn’t have the functionality, and the really big APIs that could do everything were hard to integrate.

Having made it a significant way through implementation, I have no regrets; it’s not trivial to make a full-featured API, but we have most of the tools we need inside X-Plane, and straight implementation is much less hairy work than, for example, debugging Zink.

Native ImGui Support

Dear ImGui GitHub: https://github.com/ocornut/imgui

ImGui has become a de facto way to do UI in X-Plane plugins, for obvious reasons: it’s fully featured, easy to use, and is about 1000x better than the old “widgets” API I created (and then abandoned) in 2004.

To support ImGui natively, the panel graphics API (which can be used in a window as well as avionics) has an API designed to consume and draw ImGui draw lists directly. To upgrade an ImGui plugin to draw natively, a plugin developer would need to:

1. Set the drawing type for their XPLMWindow from OpenGL to Panel Graphics.
2. Replace the OpenGL draw callback that calls glVertexPointer, etc., with two XPLM panel graphics calls to draw.

My expectation is that the change will make the plugin smaller, and we can post sample code showing how to do this.

Aside: Why Not Just Put ImGui Into the SDK

We looked at compiling ImGui directly into the X-Plane SDK – heck, we had it working internally for a while.

The main drawback for this approach is that ImGui really, really, really wants to be a C++ API, and shipping C bindings for it would mean plugins couldn’t use any custom widgets in their ImGui code (because the custom widgets are almost always meant to be compiled against the C++ API).

By leaving ImGui inside plugins and making the actual drawing native, we are leaving more complexity in plugins, but we’re making adoption, versioning and upgrading easier while hitting the thing we care about: performance.

Browser-Based Windows

The third way to make window content will be to use a browser: plugins can specify the contents are a browser than set a URL for the window. We use CEF (which we ship with) to render. Browser-based windows will have some limited communications ability to send JavaScript messages to the browser and receive plugin callbacks from it for integration.

This is one area where I am not sure of the full extent of what we will offer because while we have this working, we have not worked through all of the security implications. One thing I can say is: a plugin window browser is not an appropriate secure context; every key stroke the user can enter will have gone through X-Plane’s event loop, so maybe don’t use a browser-based plugin window to access your crypto wallet.

Aside: What About Your Own UI Framework?

We have our own custom, fully built native-drawing-based UI framework inside X-Plane. (It’s name, “GUI”, is not my most original work.) GUI was born to support the Plane-Maker panel editor, then grew to support the current X-Plane mobile UI, and then grew again to support the X-Plane 11 user interface rewrite.

For a while, we were considering providing a wrapper around our UI, which would provide a look matched to X-Plane’s native UI and native drawing. But there are a few things that would make this not that great:

• The interface isn’t that mature; we add features as we need them (which would be API-disruptive).
• The interface is wide so it would be a lot to wrap (locking us into compatibility issues).
• There isn’t a widely developed ecosystem to support UI using our tools, the way there is for ImGui and browsers.

In fact, my own coworkers complain regularly about developing using our own internal UI (“why the hell is GUI doing this? This sucks, ima rewrite everything using HTML”), which doesn’t bode well as a developer-friendly framework.

We could still potentially add our own native framework as yet another option, but at this point, we are not pursuing it at all; my guess is that ImGui , panel graphics, and browser-based windows will be a good foundation for the future.

Timeframes and Adoption

I do not know what the time frame is for shipping the panel graphics API. What I do expect is that we will have some kind of not-yet-released developer preview for our developer lobby by this summer at the latest. So there are a few situations where, if you are an add-on dev, you might care:

1. If you are starting or designing a new project that uses avionics or has UI, you should consider whether you should be using panel graphics for the avionics, panel graphics, ImGui, or a browser for the UI.
2. If you have an ImGui -based plugin, you should plan to swap over to panel graphics for drawing when possible.
3. If you support an existing product (particularly middle-ware), you should consider whether any of your APIs can be moved over to panel graphics for better performance.

ImGUI is currently scheduled for 12.5.0 (However may be subject to change.)

The post X-Plane SDK Roadmap | User Interface and Avionics appeared first on X-Plane Developer.

In this post, Julian wraps up all the X-Plane Gateway news and airport developments for X-Plane 12.4.2!

NOTAMS

• WorldEditor 2.7 is now available, with new polygon flattening features and a new UI
• WED artists are advised to only do minimal changes with polygon flattening at airports only when required. This will not be suitable for 95% of airports, and improper use may result in a rejection

Airport(s) featured in X-Plane 12.4.2

The following is a small sample of notable submissions to the Gateway that feature in X-Plane 12.4.2.

With each X-Plane release, there are many outstanding submissions from our talented pool of artists. We can only show a handful here, but extend our gratitude to every Gateway contributor.

KFLL – Fort Lauderdale Hollywood International

LIRN – Naples Capodichino

O85 – Benton Field

EGHR – Chichester Goodwood

KAUN – Auburn Municipal

KMVY – Martha’s Vineyard

EGAA – Belfast Aldergrove

KSRO – Sarasota Bradenton International

KHPN – Westchester County

KLEB – Lebanon Municipal

Laminar Workshop

Airports recently completed by Laminar Research and available now in X-Plane 12.4.2

PAJN – Juneau International

An iconic and frequently visited airport. An addition to our Alaska demo area.

LOXA Aigen im Ennstal

An addition to our Alps demo area.

EDMS – Straubing

An addition to our Alps demo area.

PHMK – Molokai

An addition to our Hawaii demo area.

PHHN – Hana

An addition to our Hawaii demo area.

Approved Airports

Here is a complete list of new or updated airports captured into X-Plane 12.4.2. You guys have been killing it!

The post X-Plane Gateway Update | 12.4.2 – April 2026 appeared first on X-Plane Developer.

In this blog post, Ben reflects on the SDK enforcement in 12.4.0 and 12.4.1, and an update going forward…

The X-Plane 12.4.0 and 12.4.1 updates have been disruptive to plugin developers, and the main reason why is that starting with 12.4.0 (and ending in 12.4.1) we have added checks inside X-Plane for erroneous plugin behavior. To use an analogy, the speed limit has always been 30 mph, but now we have a police officer pulling cars over and sending people to jail.

What Were Y’all Thinking??

There were a few things that went into our decision to increase enforcement:

First, we saw some bugs that were the result of really astonishing plugin behavior. The buggy behavior was bad, and it was really hard to catch because we weren’t checking for the erroneous behavior earlier. This is the equivalent of finding a Porsche lodged in someone’s second-storey bedroom and going “huh…I wonder how fast that guy was driving?”

Second, we did a lot of code restructuring for multi-core in X-Plane 12.4.0, and we needed to be able to tell when a plugin was breaking the rules and when we had broken the rules. A big thank-you to all of the plugin developers who tested their aircraft early before the public beta – that original alpha contained a lot of rule violations by us. But to really get to a final version of the sim, we needed to know who had crashed because they were speeding and who had crashed because we had left a brick wall in the middle of the road.

Third, not having rule enforcement for plugins makes things hard for developers. We see this ourselves all the time. Vulkan comes with an opt-in “validation layer” that (at the cost of FPS) checks our use of the driver and tells us when we screw up. This is great because it helps us fix X-Plane, and when there are things we do wrong that aren’t caught by this layer, it makes our lives a lot harder. Plugin development for X-Plane has been like this: there were lots of things that were inadequately documented and unclear, that would “appear” to work, and then the sim would mysteriously crash 20 minutes later.

And this brings us to our final reason: rule enforcement will take erroneous plugin behavior out of the sim and that will result in a more stable experience for our users. Sure, if a plugin violates an SDK rule that is the author’s responsibility, but if you are flying and the sim crashes on final approach, that’s a bad flight regardless of where the bug is. And I think this effect will compound: the more plugin-related crashes are removed, the easier it will be for us to see our own crashes in the crash reporter and fix them.

Plugin Developer Pain

While I would assert that every plugin that started crashing due to rule enforcement that needs an update represents a plugin bug to be fixed, I want to be clear: I am absolutely not here to blame plugin authors. The truth is, with the SDK before 12.4.1, with almost no rule enforcement (and often unclear, missing or ambiguous documentation), it was very hard to write correct plugin code.

Retroactive rule enforcement is not appealing. And for our third-party developers, I feel your pain. We’re putting them in now because it is the earliest time we can do so without a time machine.

In addition, it is definitely our future intent to provide more road map guidance and forewarning going forward, as well as rule enforcement for new features when they first ship. I appreciate the community’s fast response in jumping on these issues and fixing bugs – having had to fix issues in X-Plane due to OS updates, I know what it’s like to be on the receiving end of this kind of thing. And I think this effort is worth it – the result will be a more stable X-Plane experience for everyone, almost immediately.

The post Plugin Developers: We Are Done Stabbing You With a Fork appeared first on X-Plane Developer.

With X-Plane 12.4.1 now available, let’s take a deeper dive into some of the changes concerning X-Plane developers!

Hey everyone, this update is rather short this time around. Everything is striding along nicely this Spring! Let’s see what’s new here.

NOTAM – SDK Threading

As I’m sure you’ve all noticed by now, a raft of plugins did experience issues during the 12.4.1 beta. Thankfully, most have now been resolved, but a quick explainer about what’s happened here.

We’ve been logging erroneous plugin behaviour for a while, including XPLM calls before plugin init and unsafe thread access practices… but now that we are in the Glorious Future™ where X-Plane really is doing multi-threaded rendering (with more planned in the future), we now have to enforce thread safety on XPLMDataAccess and hard assert to ensure sim stability. The tldr here is that many plugins were incorrectly calling X-Plane before it was meant to.

A few notes here:

1. Please keep in contact with us. If you are a developer, please feel free to reach out and join our developer Slack. You can use support@x-plane.com

2. Do not delay in testing your addons. We still see a few developers attempt to defer testing until after an official release. We don’t want the disruption, nor do customers!

Some plugins could also benefit from switching to easier data-access methods, like websockets. Any damage here would solely be on us!

We also know the communication/logging of this could be better; believe us, we’ve already hotly debated this internally, and we’ll work to fill out SDK deficiencies.

NOTAM – AMD Device Loss (We kicked its butt)

After reviewing the crash rate, Sidney is pleased to report that AMD device losses should be solved.

NOTAM – Steam Rollbacks

For the Steam users in the room, it is well known that you guys do not have the same special powers as LR Direct users. So starting with 12.4.1, you now have the option to rollback to the last previously available version.

I will caution that this is not a permanent workaround (Although the rollback method will always be available). Please attempt to resolve the issues with 12.4.1 first (At least 95% of plugins we’ve come across have now been resolved, or have a pending update)

TCAS API

As part of the A330 updates, we’ve now got an enhanced TCAS API for aircraft developers, put together by Philipp. Have a look!

New Assets

We keep ploughing through asset creation. Not only is this helping towards next-gen scenery, but also helping to unlock artists today!

Cab-Over European Style Trucks

My personal favourite, Justin (MisterX) has worked on these European-style trucks (and has brought some American vs Europe balance into this world). We’ve got a number of different liveries and truck variants for you to choose from.

lib/vehicles/static/trucks

Gravel Textures

Meanwhile, Petr has worked to finally give us new gravel textures. The new polygons come in different colors and a mixture of solid to patchy cover. You can use the provided lines and polygon patches to then blend in the gravel color.

This is really going to open up some of the more outback and GA airfields for scenery authors, and I can’t wait to see what you all come up with.

lib/airport/ground/terrain/gravel

lib/airport/ground/terrain_FX/patches/gravel

lib/airport/ground/terrain_FX/paths/gravel

Blue-Roof Hangars

A small update to our hangar library, which is now available with blue roofs.

Gateway Update

Finally, we have our latest round of Gateway airports by our incredible WED artists.

(Note: This list is not a complete representation of all changed/added airports)

That’s all from this update. Catch you next time!

The post SDK News – 12.4.1 | A Quick Check-In appeared first on X-Plane Developer.

Worldeditor 2.7 is out of beta and now available. The X-Plane Gateway will now also accept submissions made using v2.7!

This is mostly a bug-fix release, but there are two new features included, including a refreshed UI!

Download Page
More Information (Beta 1 Post)

The post Worldeditor 2.7 is now fully available appeared first on X-Plane Developer.

In our latest post, we discuss what happened when Laminar visited the Graphics Programming Conference in 2025…

In 2025, our resident Vulkanologist, Sidney Just, attended the Graphics Programming Conference (GPC) in Breda, Netherlands, to give a talk on how the X-Plane engine has evolved over the years. As we transition towards a modern GFX engine, the team has had to overcome sizable roadblocks while transitioning from OpenGL to Vulkan.

Just yesterday, the video was finally uploaded. So if you have some popcorn and a cup of coffee, enjoy 40 minutes of tech talk with Sidney, as we take you through where we’ve been, the work we did to improve X-Plane 12, and a glimpse at where we’re headed in the future.

Our massive congratulations to Sidney. We are very proud of the work he’s done (not only on this technical talk but also on his recent work on multithreading and Aftermath profiling). And thank you to the organisers of GPC for being an accommodating host, for the work they do, and the open provision of these talks.

Download Slides PDF

GPC Website

The post GPC 2025 | The Aircraft Of Theseus appeared first on X-Plane Developer.

With X-Plane 12.4.0 now available, let’s take a deeper dive into some of the changes concerning X-Plane developers!

I am unusually tardy with this post, so I would first like to apologize for the delay. I chose today’s title mostly because of multi-threading… but also because I’m all about family. And the X-Plane family has certainly come together over the holidays with our latest release.

12.4.0 is out now – Introducing some significant performance upgrades, A330 Improvements, Tobii integration, new art assets, and much more. We’ve been furiously working on this for quite a while in the latter half of 2025, and we are happy to see such a well-received reaction. I personally frequent Discord, Reddit, the Org forums, AVSIM, and other Facebook groups, and we want to make sure users are feeling more heard.

One thing that has impressed me of late is the amount of creations going on. RealOps is breaking ground with its ground-handling plugin. The wonderful scenery innovations by X-Codr. New career mode plugins. More people are trying out aircraft development. New developer tools/pull requests from XP2B. The community has been cooking lately!

More importantly, we’re focused on giving you guys and gals more features to create in X-Plane. This is going to be a big focus for some upcoming updates of ours. (No, that isn’t a reference to scenery… that comes later). But more on that another day!

So let’s get into what’s new for this update…

SDK Changes

SDK 430

SDK 430 is now available and compatible with X-Plane 12.4.0 or newer.

Warning: the 4.3.0 SDK incorrectly identifies itself as version “421” in the version included in X-Plane 12.4.0. Despite this, all entry points are present. The version number is corrected to 430 to match published docs as of X-Plane 12.4.1.

Official Changelog

• The new XPLMInitFlight and XPLMUpdateFlight APIs in XPLMPlanes provide complete control over creating and editing how the user’s flight starts.
  
  These APIs supersede and expose deeper functionality than the previous XPLMPlaceUserAtAirport and XPLMPlaceUserAtLocation APIs.
  
• The third MDCU is exposed in the avionics API.

Other Noteworthy Changes

• Fixed an error where users might get the message “The sim destroyed an instance during the dag!” when using add-ons (XPD-17441)
  
• Improved documentation of XPLM_MSG_DATAREFS_ADDED (XPD-17317)
  
• Fixed return value of XPLMGetVirtualKeyDescription (XPD-17397)

Future SDK changes

We will/should be adding access to additional basemaps/terrain data in a future update.

What happened with plugins during 12.4.0?

The short story here is, we found quite a few plugins calling X-Plane functions before it was fully loaded, which is a big no-no. I’ve asked Ben to make a blog post in his free time about further details on this, and how you can best avoid such incidents in the future.

Can you improve documentation on this?

Short answer: Yes
Long answer: I don’t think it’s any secret that we’re in the middle of a large documentation revamp, so there will be plenty of forthcoming changes. When we’re ready to communicate more, we shall!

Performance Improvements

The glorious future is here! Or at least, partially. X-Plane now takes advantage of multi-threading for scenery only. I strongly encourage you to read Sidney’s post about it here, and make sure you understand performance here. But here are a few Q&A’s

Should I expect massive amounts of increases?
It depends on your hardware and what the bottleneck was in the first place. If you’re GPU-limited (which is your GPU Compute time taking longer than your CPU), you are unlikely to see any benefits

Is this the end of multi-core/threading improvements?
No! Please see Sidney’s post for a full outline. Additionally, 12.4.1 will have additional performance improvements.

Will this help my multi-monitor setup?
Not inherently, as this is geared towards the scenery system. We have plans to address multi-monitor displays and further parallelize that work. This is not a short-term item, and I would suggest you read Sidney’s article.

Are you working on device losses?
Yes, but with caveats. We know it occurs disproportionately more with AMD devices. However, we found user feedback to be particularly poor. Throughout 12.4.0 beta, we decided to enable a “partial flavour” of AMD aftermath by default, and this should help us get one step closer to diagnosing these issues.

For the bug trackers here, we have XPD-17857, if you want to follow along.

How can I help?
Contact us via support, and they will give you further instructions. And be prepared to submit Aftermath reports!

New Assets

WED artists, we won with this update. Petr and Justin have created a brand new round of assets, fulfilling some long-requested items.

Segmented Circle
lib/airport/markings/segmented_circle

Wind Tees (Currently Not Animated)
lib/airport/markings/wind_Tee

Signal Square (Common for small EU airfields)
lib/airport/markings/signal_square

New Glider Models: ASK-21 & Ventus 3
lib/airport/aircraft/gliders

Animated Cranes
lib/vehicles/static/tower_crane

Construction Material Objects: Cable Wires, Wooden Pallets, Steel Pipes, Concrete Pipes, Cement, PVC Pipes, Concrete Blocks, Steel Beam
lib/industrial_area/construction

VHF Dipole Antenna Tower
lib/airport/radars/VHF

RV/MotorHomes/Trailers
lib/vehicles/static/RVs

Camping Equipment: Tents, Chairs, Tables, Coolers
lib/public_area/camping

Completely Revamped Modern Cars
lib/cars

New Taxis
lib/cars

Pavements: Asphalt, Concrete, Grass, Mosaic, Tiled, Mulch, Grates (Pavements are 0.15m AGL, if you wish to place objects on top)
Documentation Here
lib/airport/ground/sidewalk_15cm

Planter Objects: Grass, Bushes, Rock Shrubs
lib/vegetation/planters

Fences: Mesh, Metallic, Stone Wall, Wooden
lib/vegetation/planters

Road Bumps
lib/airport/ground/roads/speed_bumps

We’ll certainly be back with even more assets in future updates (for those who attended our Discord Developer Stream over Christmas, if you know… you know). But my personal thanks to Petr and Justin for knocking these out of the park.

A Note On Grass…

Some of you will be looking at that grass polygon with a swooning desire to place large swathes of it over your airfields…

PLEASE, PLEASE, PLEASE…. DO NOT DO THIS!

This is a one-way track to performance degradation, and we will block gateway submissions that abuse this! We have also dreamed that one day the world will be filled with lush grass to touch. But this is not the device to get there. Keep your grass planter objects in small, localised areas.

Gateway Update

Finally, we have our latest round of Gateway airports by our incredible WED artists. I’m working with Julian to get more updates to you, but I’m in awe at some of the work being done by the artists lately.

Don’t forget that Worldeditor 2.7 Beta is also available to try (although you will not be able to submit gateway airports with this). This provides the ability to flatten the default mesh (default mesh only!)

(Note: This list is not a complete representation of all changed/added airports)

That’s all from this update. Catch you next time!

The post SDK News – 12.4.0 | Fast and Furious appeared first on X-Plane Developer.

We have new documents available for our new 3D sidewalks in X-Plane 12.4.0. Check them out!

These include

• Available sidewalk types/assets
• Best practices for sidewalks
• How to place assets on top of sidewalks
• New planter objects
• Recommended optimisation/performance information regarding the planter objects.

Special thanks to Petr and Tom Kyler for making this available!

The post New Documentation – 12.4.0 | 3D Sidewalks appeared first on X-Plane Developer.

Worldeditor 2.7-beta 1 is now available. This is mostly a bug-fix release, but there are two new features included, including a refreshed UI!

Download Page

Thanks to Marco and Cristiano, we can also join all the cool kids who have made their own dark themes. We also take a bit of a departure from a skeuomorphism design to try to bring more contrast. Have a go and let us know what you think! (Just don’t suggest a light mode)

Changelog

• Updated user interface with new “Dark Theme.”
• New “Flatten Polygons” ability for scenery
• New metadata property to define the altimeter setting for the airport (QNH/QFE)

About Polygon Flattening

Lets get this out of the way. THIS IS NOT A SURGICAL MESH EDITING TOOL! This is for light corrections to default mesh.

Polygon flattening can be activated using the “Polygon Tool” and inserting the attribute “::FLATTEN::.pol” into the “Name” and “Resource” boxes. The “Heading” attribute will define the height of the surface, and set all elevation nodes within its borders to the MSL elevation in meters that you put into the texture “heading” field

To get a better idea of where the (default) mesh elevation points are, go to View->Toggle Terrain to preview the wireframe

1. WED artists must take note that this ability is not a replacement for mesh-editing, and scenery submits using this must only be used where necessary! Be warned that the chance for rejection using this tool is quite high if improperly used!
   
2. This will not create additional vertices in your mesh. Artists are still limited by mesh resolution
   
   (Obvious points here, this is for current-gen scenery only. Not next-gen scenery. Breathe)

The post Worldeditor 2.7 Beta 1 is now available appeared first on X-Plane Developer.

Terms of service

1. Expectations

Let me get this out of the way first: Don’t bother asking what you can expect in terms of performance gains. You could see anything from none, moderate to a lot. Multi-threading inherently only affects the CPU, so if you are GPU-bound, you won’t see any improvements in terms of FPS because the limiting factor is still the GPU. Everything else depends on how you have configured X-Plane, your hardware, what add-ons you are running with etc. The only way to know what, if any, improvements you will see is by installing 12.4 and trying it out yourself.

2. Future Plans

Also, this isn’t the last multi-threading update. I’m very excited about it, but it’s a small fraction of what we have planned. There is more engine refactoring work to be done, more code to be optimized, but we figured “Why sit on improvements that we have right now when we could get them out to customers to properly battle test them?”

Where we came from

One myth is that X-Plane was not multi-threaded at all, which depending on your point of view is either patently false or somewhat true. X-Plane does a lot of work on background threads, especially scenery loading and texture paging. But those are all long running background tasks, what we lacked so far was true per-frame multi-threading. We had a few small tasks that could run in parallel, but the bulk of the frame was generated on the main thread.

It’s generally assumed that the flight model takes up the most time for X-Plane, but in practice, it’s usually scene graph traversal and rendering that make up the bulk of frame time, sometimes up to 75%. The more demanding your scenery, the more time will be spent on this task. For those not in game dev, scene graph traversal is the process of, well, traversing the scene and figuring out what needs to be rendered and what doesn’t. The second part is processing the data that needs to be rendered and then actually issuing all of the rendering commands, this usually involves sorting the render data in some way to reduce the number of material and state changes. All of this takes time and the more complex the scenery, the more time this takes.

There is one more thing to keep in mind: Shadows. Shadows get rendered by rendering the scene from the suns perspective, which is then used to figure out which parts of the scene the sun can see and which it can’t. By definition, everything that the sun can see is in the light and everything the sun can’t see is in the shadows. But that means that we actually have to traverse the scene twice, once for shadow rendering and once for the main scene, so while the cost isn’t double, shadows aren’t exactly free either.

You are here

^ This is a very simplified graphic demonstrating the concept of threading in X-Plane. It is neither a statement of the number of cores used nor the number of jobs created per frame.

Because the scenery traversal process takes up such a large amount of the frame time, it makes for an obvious target for multi-core improvements. And that’s exactly what’s in 12.4. As soon as the camera is resolved and we actually know where the virtual eye is and which direction it’s pointing, we kick off the scene traversal process for shadows and the main scene. It’s actually done in multiple steps across multiple CPU cores, so that we can minimize the time it takes from start to finish.

While this goes on in the background, we are now also running the panels and avionic devices. This lets us effectively hide slower avionic updates, since X-Plane can go wide on crunching the scenery at that time. You will especially notice this with add-on aircraft that have very high panel draw times, but even our Garmin and built-in instruments aren’t totally free either.

Additionally, we try to schedule things in an ideal way. So we aim to get the shadow scenery traversal and preparation done first, so as soon as the panels are done we can start actually encoding the commands for the shadow rendering. While this goes on, the much more expensive main frame scenery traversal can finish up in the background and ideally we can immediately hit go on its rendering command generation once that is ready.

Of course this is the theory, in practice things might not finish in time and then the main thread has to wait for results to come in. It should still be faster because the scene traversal itself is done in parallel, so it should be faster than if only the main thread was working on it by itself. But theory and practice don’t always line up. Again, the only way to know what perf you will see is by testing this yourself.

Additionally, we have also improved the drawing hot path and reduced the number of state changes X-Plane has to make in order to from one object to another. We also moved a lot of the just-in-time calculation for material parameters and data to the background thread so that once we are actually drawing things, we can just emit commands as fast as possible.

However, actual drawing of the scene is still single-threaded! Once the parallel scene traversal has concluded, X-Plane’s main thread will still create one command buffer to encode all of the rendering needed. Likewise, multi-monitor set ups could see a much bigger improvement in theory, but in practice we still have to traverse the scenery of each monitor in sequence.

Where we are going

The obvious two are parallel rendering of the frame and doing multiple monitors in parallel. The less obvious one is that we could also do the shadows and main rendering in parallel and then just submit the work to the GPU in the right order. All of these are on the roadmap, but they require more work to the engine itself. There is still a bunch of shared global state when it comes to actually rendering a scene, which we’ll have to clean up first.

One of the things that makes me really excited is the new job system that has actually been shipped in 12.3 and which is the underlying thing that makes the multi core work possible. Instead of carefully writing C++ that dispatches and joins all work in just the right order, we can now describe the frame as individual jobs and their dependencies and the computer can figure out the optimal way to dispatch them. This is analogous to the render graph system that we introduced in 12.06 which allows us to describe the scene rendering as a series of nodes with carefully defined dependencies and then the computer can figure out how to actually bake the commands and build the resources.

This gives us huge flexibility in terms of being able to re-organize the frame, since it’s no longer a massive monolithic chunk. Besides the obvious grand improvement that is parallel rendering, we also expect to be able to leverage this system to further improve performance by scheduling the frame more efficiently. But now that the initial work is the boring present, all of this is becoming the new glorious future.

The post The glorious multi core future is now the boring present appeared first on X-Plane Developer.