Author: Ben Supnik

D9: You Sunk My Battleship

It has been almost a month since my last post on Vulkan and the state of development; a lot has happened since then, both for Laminar Research and the world.

COVID-19

First, at this point, no one working for Laminar Research has COVID-19. We have people working on X-Plane in at least six countries, including northern Italy. The team news on Slack as of Tuesday was that everyone is in some degree of lockdown and/or voluntary social distancing, varying by country. Schools in the US are temporarily closed, so both Chris and I have the kids at home.

Being sequestered at home has not affected our internal pace of development because our entire team is distributed and works at home; we have no office to close. This work-at-home pattern started almost twenty years ago when Austin had people like me working on part-time contracts to modify specific parts of the sim – it never made sense to relocate people to South Carolina and open up an office. Being remote also lets us hire people anywhere in the world who have the unique blend of skills we’re looking for.

At this point we haven’t seen any operational issues either; mostly running our business requires that our devs have internet and electricity and that the data centers we use for our cloud servers remain open and operational.

So in summary, we are very fortunate that the new coronavirus is not affecting our development and operations; other industries are paying a high price to stop the spread early. We have several things we are working on right now, and this spring is a critical time in our development schedule.

Vulkan and Metal

Update: I have gone in and changed Vulkan to Vulkan/Metal in a bunch of places – Mac users were confused as to whether we had silently dropped support for Metal at the last minute – we have not!

We are posting developer preview nine to our private testers today; hopefully this will be the last private build before a public beta candidate. We acknowledge we’re reaching public beta much later than we had hoped/wished/anticipated, but we are now aiming for a public Vulkan/Metal beta by the end of March. If you are already rolling your eyes at a public beta date that is less than two weeks away, I don’t blame you; having been this late, it’s on us to post the beta to show progress. With that in mind, I am going to describe what we’ve been doing for the last three months and why it has taken so long to get here.

The Vulkan/Metal public beta is several months later than we had anticipated because of “scope growth” – that’s manager nerd speak for “we added more stuff to it than we originally planned.” Scope growth (adding more features/code/tricks than you originally planned) is one of the big ways that projects miss original deadlines, so the big question is: what did you add and why did you add it?

The first thing we added was better handling of plugin drawing. The rewritten plugin compatibility layer provides better drawing compatibility for more plugins, including weather plugins on Windows. We went with the rewrite mostly because of the level of bugginess we saw with third party add-ons in the early developer previews.

Plugin drawing was definitely a case where we learned how to do a better job from the first version of the feature (plugin compatibility that went into the first private beta); if we had received that second-generation design via time machine we probably could have shipped faster. Adding weather support was pure feature creep–a new thing we didn’t plan on, but something that we thought was worth extra schedule time.

The second thing we added was better handling of texture paging. Once again, this was a feature where we had to rewrite the feature (multiple times in fact!) based on the feedback we got from our testers to really come up with something solid.

Our first generation texture paging around the first private developer preview was very simple: most stuff lived in VRAM, with a little bit of code to move unused stuff out of VRAM. It was a minimalist strategy that let us develop the rest of the sim and worked great on high-end cards. It was clear from day one that it wouldn’t be good enough for public beta.

Our second generation strategy added automatic movement of texture res up and down with VRAM pressure and code to page out textures that weren’t being used. This shipped about half way through the private beta, and was better, but suffered from one fatal flaw: as you turn your head, the stuff behind you isn’t being used. Under heavy memory pressure users would constantly turn their head and see blurry textures that would then “res up”. The results were distracting and unacceptable quality-wise.

We now have finished our third generation strategy: besides automatic texture res control based on VRAM pressure, we now set the relative resolution of non-orthophoto textures by distance to the aircraft. A background task on another core “crawls” the scenery near your aircraft and reevaluates the texture res of nearby scenery constantly, effectively transferring VRAM to where it is needed most. This process is completely transparent; authors do not need to modify scenery in any way for it to work, and since it runs on another core (as does the paging), it does not affect framerate.

In these pictures, you can see the new pager at work. I have parked my aircraft on the ramp at SeaTac and moved the camera across the city, so that the distant autogen (from the pilot’s perspective) is now close and the airport is in the background.

In this first picture, green represents full-res textures, with the next levels down being yellow, then magenta. You can see some nearby autogen down one level and far-off autogen down two levels; the loss of res is put far from the user.

Why is there so much green (full res) near the magenta autogen? Texture reuse. If a texture is used near the user and far from the user, it gets high res because it might be seen up-close.

In this next picture, I artifically lowered my machine from 4 to 1 GB of VRAM using a developer tool. Now you can see magneta autogen close to the airport, yellow even closer, and some really dark green (the next level down) where we had magenta. In other words, everything got a little bit lower res because we were tight on VRAM, but again nearby sceney is prioritized.

It looks like this third strategy is a keeper – it combines the careful management of VRAM to use it where it is most needed with a stable heuristic that isn’t constantly changing, which avoids chaos and unreliable behavior.

So at this point we are just fixing bugs. This is a big step forward for the private beta because past betas were dominated by coding new things, which in turn creates new bugs. At this point we just have to kill bugs off to the point where the build is high enough quality for a public beta.

I cannot promise a particular build number or date will be the public beta full stop, because I do not know yet what other bugs we may find. But I can say that we are in the part of bug fixing where things are getting locked down.

Vulkan is Not the Only Iron In the Fire

A flight simulator is more than its rendering engine (or at least, people tell me that). While we are pushing as hard as we can to get Vulkan and Metal to public beta, we also have several other irons in the fire. This includes new features for mobile, next-gen features for desktop in several feature areas, and even a few extra non-Vulkan/Metal features that have snuck into 11.50. We’ll post more about the mobile and 11.50 features as they become available; the rest is still in stealth mode. Often when the dev blog is quiet, it means we’re working on new things and putting features in the bank; this is the case right now.

Posted in Development, News by | 155 Comments

Cloud Add-Ons and Vulkan Episode IV: A New Hope

For the last few weeks we’ve had the Vulkan/Metal version of X-Plane in a private test program with third party developers, letting them kick the tires to discover the limits and bugs in our plugin compatibility code.

While the initial bridge to connect OpenGL-based plugins to X-Plane worked pretty well, compatibility wasn’t perfect and we had a few bugs. We also realized that we needed to change the design of that bridge to get much better compatibility. That rework of the bridge is now done and things are looking quite a bit better on all fronts.

We found one unexpected result from this redesign: when we finished rewriting the bridge, we ended up with code that could, in the case of Vulkan only, be used for 3-d drawing. This means we can now support OpenGL-based weather/cloud plugins from inside a Vulkan render, which we did not think was possible before.

The Skymaxx and xEnviro developers are in our private test program and have been great about jumping on new builds while remaining radio silent while we test this new tech. I am pleased to now be able to say: it works!

Those pics are a special build of SkyMaxx running in 11.50 in Vulkan mode. No more having to pick – you can have your third party clouds and Vulkan at the same time.

The Details: Vulkan, not Metal

3-d drawing compatibility will be available for Vulkan, but not Metal. The technique we are using is not available on OS X, so running a cloud plugin on Mac will require the OpenGL driver, not Metal. This isn’t something we can fix with some future bit of cleverness – it’s a limitation of OS X’s APIs. (We would revisit this if Apple introduced a new API but I do not expect this to happen.)

To be clear: on Windows what we are supporting is 3-d OpenGL drawing by plugins inside the Vulkan renderer, not native Vulkan rendering by plugins inside the Vulkan renderer. Native Vulkan rendering by plugins is an incredibly complex SDK problem, and not something we are looking at for 11.50.

2-d Drawing Just Works; 3-d Drawing Requires a New Plugin

For plugins that draw in 2-d we’ve gone for a “just works” level of compatibility; while we have seen some plugins that need to update due to illegal techniques and bugs, our goal is that a well-authored add-on just works even when Vulkan and Metal are in use.

By comparison, OpenGL drawing inside Vulkan is going to require plugin authors to sign up for a new 3-d drawing callback. We’re making this opt-in because, during the beta, we’ve found a lot of add-ons using 3-d drawing callbacks inappropriately, and 3-d drawing callbacks are no longer free. By requiring plugins to opt-in when they _really_ want 3-d drawing in Vulkan, we should get better performance.

The new 3-d drawing callbacks are really only meant for custom drawing like clouds. Other techniques like adding objects to the sim and drawing markings are better handled with other APIs. Our plan is to have detailed guidance on what technique is best for developers by the time we are ready for public beta.

Posted in News by | 87 Comments

All Your VRAM Is Belonging To Us (and Plugins)

One thing I have learned during my time here in the matrix is that users often find new bugs to be significantly more annoying than existing ones; trading an existing bug for a new one is often seen as a big step backward, even if the new bug isn’t that bad. I think this is just human nature – we get used to things – it’s what humans do – and this takes the sting off of some bugs that have been around a while.

I bring this up to put in context the problem of texture paging, blurry textures, and VRAM management in 11.50. To understand what makes VRAM paging hard, you have to understand how the OpenGL driver solved the problem, and ask yourself: what was the old bug, what is the new bug?

What Is Texture Paging?

Texture paging is when textures are moved between the memory on your graphics card (VRAM) and the memory in your computer (“system memory”). At any given time, X-Plane may have more textures loaded than you can fit on your card, but it doesn’t need them all at once. As you fly, different textures are needed, and the textures have to be moved around.

If this sounds a lot like moving data from RAM to your hard drive (virtual memory), it is. When I get the question “how can X-Plane be using 2.5 GB of texture memory when I only have a 2 GB card” the answer is…texture paging.

How Did the OpenGL Driver Do It?

In an OpenGL based app, paging textures to VRAM and back is entirely up to the OpenGL driver. The algorithm goes something like this:

  1. Start drawing.
  2. Realize something you need is in system memory.
  3. Move something you haven’t used in a while out of VRAM.
  4. Move the thing you need into VRAM.
  5. Continue drawing.

The OpenGL driver pages during drawing when we need something new, and the result is a stutter – the frame takes longer because it cannot be completed until the texture is moved to VRAM.

Now NVidia, AMD, and Apple have spent a lot of time and effort to make this work as well as they possibly can, and I’m definitely selling short the complexity and sophistication of the drivers as they try to guess really well what should be moved out of VRAM. Still, two key facts will be true:

  1. If we need to page stuff into VRAM to draw, and we don’t figure that out until right when we need it, there’s going to be a stutter. Maybe a really short one you barely notice, maybe a really bad one, it’s a question of “how much”, not “if”.
  2. What you see on screen always looks fantastic – never blurry – because the driver won’t cut resolution to save VRAM.

So…the old bug in this case is stutters due to VRAM containing the wrong stuff.

How Does X-Plane 11.50 Do It?

With Metal and Vulkan, it’s up to us, the app, to decide what goes in VRAM and what doesn’t, and to schedule the movement of data between VRAM and system memory. Our strategy is:

  1. Keep an eye on how much memory is free.
  2. If it looks like it’s getting too close to full, shrink textures to a smaller size. Prefer to shrink textures you’re not looking at. Do the shrinking in the background.
  3. If it looks like VRAM has empty space free, grow textures, preferring ones you are looking at now. Do the growing in the background.
  4. If we have to load new textures in the background (e.g. new DSFs as you fly), wait until old textures can be shrunk.

We have a huge advantage over the drivers in this game: we know the textures we might need in the future, long before we actually need them. We can also shrink textures. This means we don’t have to stop and shuffle things around, and that means we can avoid stutters. So we can fix the old bug: stutters while you fly.

(To be clear: this is not the only source of in-flight stutters while you fly – OpenGL and 11.41 are full of them.)

The down-side is: if VRAM gets tight, we’ve made some of the textures lower resolution. This is a new behavior (blurry textures), so my fear is: users aren’t going to like it.

In particular, the OpenGL driver uses the exact optimal set of textures for every single frame – at the cost of stuttering. We may not have things shrunk and grown in exactly the best way while you fly, so for the same VRAM and no stutters, we may not be as visually sharp.

What About Plugins

Add-ons that use OpenGL (e.g. aircraft with custom glass displays) use VRAM too – this is one reason why we can’t pack 100% of VRAM with our textures; we need to have enough free that if a plugin needs VRAM, it won’t crash us.

My expectation is that fighting blurry textures and crashes due to running out of VRAM is going to be a long, iterative process and one of the main reasons to have beta testing. It’s one thing to have an algorithm that works good in the lab or on paper – it’s another to have thousands of hours of test time in real-world conditions on user machines with lots of add-ons and anarchy.

So when 11.50 is public beta and you see your blurry texture, don’t panic. VRAM management is a very new part of X-Plane, and it’s a very important part, and it’s something we will iterate on over time.

(Finally, I want to mention that while the port to Vulkan/Metal has been a joint venture that Sidney and I have worked on together, there are certain parts of it where Sidney basically did 100% of the work, and my only contribution was to complain about bugs. The shader compiler, the OpenGL plugin bridge, and the VRAM pager are all big lifts that Sidney has done on his own that make the Vulkan/Metal port possible.)

Posted in Development by | 148 Comments

The Vulkan/Metal Public Beta Will Be in 2020

As I announced in my previous post, X-Plane 11.50, featuring native Vulkan and Metal driver support, is in a private beta made up of people in our dev-rel program (E.g. third party developers). We’ve gotten some really good bug reports from them – the reports are good, not the bugs – and based on that, it’s clear that 11.50 will not be ready to go public this year (meaning tomorrow).

This is disappointing to us – we burned candle at both ends to try to get all the way to public beta this year, but at this point the build just isn’t ready yet.

I’ll describe in detail below what the one bug is that is really holding back public beta, and I’ll try to do a general FAQ about Vulkan and Metal tomorrow; based on the 150+ comments from the last post, I think it’s clear that we have a lot of basic info to get out there, some of which has only been shared with third party developers until very recently.

Please don’t bombard me with “can I please be in the private beta” (or even “you’re a giant pile of moose poop for not letting me into the private beta”). Here’s the thing about the private beta: our goal is to kill off the bugs so everyone can use the beta, and to kill them off as rapidly as possible.

At this point the dozen or so third party developers who are banging on the beta are generating bug reports faster than Sidney and I can fix them – if we add more people to the beta, our bug fix rate will slow down as we have to spend more time triaging the reports coming in. So as long as we’re fixing the worst bugs productively, more people in the private beta means everyone waits longer to get to public beta. I think the best thing here is for Sidney and I to just try to fix things ASAP.

(I think there’s also a win to getting this into the hands of third party developers – in some cases we’ve seen add-ons that accidentally use the wrong APIs for processing and are thus incompatible with Vulkan when they don’t need to be – developers can get a head start on updating this code.) If you are a third party developer, we can get you into the beta program – I don’t want to favor some third party developers over others.

Blurry Textures

A short summary of performance feedback from our internal beta might go like this: smoothness and FPS are good, VRAM management is not.

Most of the crashes while flying we have seen look like the sim runs out of VRAM and isn’t able to recover, and for users with smaller GPUs (e.g. 4 GB of VRAM) X-Plane gets into a tight VRAM situation and solves it by making everything on screen low res and blurry.

The VRAM management path, which is entirely new code written for the Vulkan/Metal back-ends, is…well, it’s entirely new, and it’s going to need a bunch of testing, debugging and iteration to get solid. On an 8 GB card, VRAM is so plentiful that X-Plane’s somewhat naive VRAM allocation scheme works fine. On a 4 GB card, we’re just a tiny bit short (a few hundred MB) but the result is an alarming loss of texture resolution.

This is something we can make better! It is under our control and is thus being worked on now. (By Sidney that is – I’m writing this blog post while he gets the real work done here.) But until we have better VRAM management, it’s too soon to go public. If we did, we would just be inundated with hundreds of “my textures are blurry” reports. It’s a bug too noisy to ship with.

Why Wasn’t This a Problem on OpenGL?

One might ask: why don’t you just do whatever OpenGL did to manage VRAM? The problem is: OpenGL’s solution is to stutter.

The OpenGL driver swaps textures between VRAM and system memory based on what you really need to draw now. If you are looking away from Seattle, the space needle’s texture can live in system memory, but you might need mountain textures for Rainier.

We try to do that too – the big difference is: OpenGL will stop rendering while it moves the textures around, and we will not. The result is that OpenGL always shows you a perfect image at the texture resolution you picked – no blurred images. But you might have stutters! You can see this if you’re on the margins of VRAM by flying and then changing views or circling the camera – if your FPS go “chunk chunk chunk VROOOM” you’re eating some stutters while textures move around, then you go fast again.

The OpenGL way is a solution that we never thought was acceptable – our goal is the best image quality without sacrificing smoothness. It’s going to take a little more time to iron out low VRAM situations, but once we get there I think it will be worth it.

Posted in Development, News by | 116 Comments

Vulkan and Metal: Testing and Bug Fighting

Last week we sent out our first build of the Vulkan/Metal ready X-Plane (which will be version 11.50) to an external sight, and last night we sent out the first private beta.

Our plan is to move to an open public beta soon once we have some feedback on how well the build is working. When that is will depend on the bug reports; I’m crossing my fingers.

How It Works

In X-Plane 11.50, there is a check-box in the rendering settings that enables Vulkan or Metal; you’ll have to restart for the change to take effect. If the sim crashes really early (e.g. before the main menu) it will revert to OpenGL to keep you from getting “locked out” but random crashes while flying won’t do this. There are also command line overrides to control the driver for people running performance testing scenarios.

I should also mention that we’ve changed what the reflections slider does – it’s now like X-Plane 10 and does not attempt to update the environment cubemaps in real-time. (If you really like flying at 5 fps, you can re-enable this in settings.txt – the underlying tech has not been removed.)

What we have found over the last few years is that users will drag every slider all the way to the right, and then be surprised that the sim has poor performance. While I have in the past dismissively claimed that they are doing it wrong (“don’t put every topping on your pizza”) the inevitable truth is that we are violating an industry UI norm by having the highest possible settings run beyond the scope of the fastest possible computers our users can get their hands on.

Now that we have Vulkan and Metal running, we can make some judgments about what will and won’t be real-time. Full scenery shadows are still available and are helped by the Vulkan and Metal driver; a decent machine should be able to run full autogen + scenery shadows at 30 fps.

The Vulkan and Metal back-ends change their approach to running out of VRAM. With the OpenGL driver, when VRAM is exhausted, textures are moved to system memory, and the application stutters while the driver makes this mad last-minute shuffle.

When running with Metal and Vulkan, X-Plane will reduce the resolution of your textures while you fly, in the background, without stutters, preferring to reduce resolution on textures that are not being used right now. The result should be smoother and generally less disruptive. You can still lower the overall texture resolution to better fit your card’s budget.

This new “on the fly paging” is…well, it’s completely new, and I suspect it will need a lot of debugging during beta. It’s an area where we just need to collect use-case data to better tune the algorithm.

X-Plane 11.50 no longer allows for uncompressed textures – if a DDS is present on disk, we will use it. I have to recommend texture compression in the strongest possible terms; while the artifacts are annoying, when we turn it off, everything looks worse due to the VRAM pressure – uncompressed just isn’t a good way to use our VRAM budget. Pre-compress your textures for best results!

A Detailed View

One of the great things about running with the Vulkan/Metal back-end is that there isn’t any dark matter in the rendering path – everything that takes time takes that time when we say so. This means that when we have a stutter we can take the frame apart and figure out exactly why that happens.

One of the last fire-drills before sending out a build happened last week – with the Vulkan back-end and memory paging working correctly, we would still see these violent stutters flying over downtown LA. As it turned out, the code to delete autogen as you flew away from it was too slow and was causing hitching every time a 3 km AG square had to be torn down.

That code is now rewritten and the results are much smoother. Here’s what winning looks like:

This is my old iMac running at 60 fps – it can’t do that with everything maxed out, but when it does hit 60 fps you’ll note the dead even orange bar at the top – that’s consistent framerate. The bottom of the screen shows a block diagram of some of the tasks that went into the current frame render.

With “weird driver behavior” removed, when something stutters, so far we’ve been able to identify it, e.g. the autogen stutters from last week. Here’s what stutters look like:

The orange spikes you see are the stutters – I induced these by command-tabbing to other apps while flying; when the window manager swaps apps it’s pretty disruptive. That big blank space in the middle of the screen is time spent doing something (probably in the window manager) that we do not yet track.

One last show-and-tell pic: for some reason when running at 45 fps, the sim is actually running at a mix of 60 and 30 fps every other frame, which is not good. We can easily see this with our tools:

Here we can see two frames, a long one on the left and a short one on the right. The difference: “acquire surface” is taking a ton of time. The long frame is stuck waiting for the window manager to give us some VRAM to draw into. With this kind of detail, we can at least understand the bug and try to fix it.

Next Steps

At this point the only thing left to do is fix bugs, some of which are still open even as the private beta goes out. We will move to public beta once we have something where we think the initial experience isn’t a blue screen and tears.

Posted in Development by | 202 Comments

X-Plane 11.40 is Final

X-Plane 11.40 is now final! You will be prompted to update to X-Plane 11.40 when you start X-Plane; Steam users will receive the update automatically via Steam. Here’s what’s next in the pipeline:

We are working on a bug-fix update (11.41) to catch one or two bugs that didn’t make the RC, as well as the inevitable bug that will be reported after go final. I expect to cut an 11.41 release candidate some time next week, and it should be a pretty quick release.

In the meantime, we are pushing hard to get Vulkan/Metal ready so that we can do an X-Plane 11.50 beta. We may start private testing of Vulkan and Metal before 11.41 is done, depending on what gets fixed first.

The limiting factor on getting to a public Vulkan/Metal beta will be bug fixing – it doesn’t make sense to go public beta with known bugs that will be reported over and over and make the beta unusable. There are also two remaining areas of development we need to close up:

Load Times

Vulkan and Metal fight stutters by pre-loading everything they need to render the frame – this means whatever we need to draw, it’s ready. But this also means X-Plane needs to prepare every shader it might need to render a given aircraft and scenery pack.

Because X-Plane’s shaders are so flexible, this can mean tens of thousands of shaders, and that hurts load time. We have new code that tries to analyze exactly what we’ll need for a given frame. For example, if an object comes from a DSF, we never need an “interior” shader for it because the scenery object can never be inside an aircraft. By carefully applying this kind of logic, we can cut down the number of preloaded shaders and speed up load times.

Sharing Memory

With Vulkan and Metal, X-Plane manages its own use of VRAM – this is a totally new capability that we have had to code from scratch for the Vulkan/Metal port. We watch our total memory usage and reduce texture resolution dynamically (hopefully on less important and less used textures) to stay within budget.

While this code is working, it hits a wrinkle on Windows:

  • Third party add-ons that chew up VRAM via their OpenGL VRAM usage can use up part of our budget. For example, if you change to an aircraft with a plugin that allocates its own textures to render to, we can’t use that VRAM anymore.
  • The Vulkan version of X-Plane allocates VRAM in big blocks for efficiency. If we reduce our texture res to make room for the plugin, we might end up with a bunch of big pre-allocated blocks (that are mostly unused) inside Vulkan – the memory still isn’t usable by the OpenGL plugin.

Sidney is working on compacting our textures so that some of the big blocks can be given back to OpenGL – yet more new memory management code for Vulkan.

There Be Dragons

Once we have the number of shaders cut down and memory compacting working, we’ll begin heavier testing of the Vulkan/Metal build – I can’t say how close to public beta we are because we haven’t gotten the initial wave of bugs from this testing.

Posted in News by | 37 Comments

X-Plane 11.40 Beta 8 and a Roadmap Update

This post has been on my todo list for a while – long enough that X-Plane 11.40 came out before I had time to write up a post saying “X-Plane 11.40” is coming. But just to put 11.40 into context, here’s what our patch roadmap looks like for X-Plane 11 this year.

All Physics All the Time

X-Plane 11.40 is a physics release. Almost all of the changes in X-Plane 11.40 come from Austin’s work on the physics engine over the last six months. This is a new approach for us. In the past, when we’ve updated the physics or systems, it would be in a giant “omnibus” release, where everybody’s latest code went out at once (e.g. X-Plane 11.10).

The problem with the omnibus releases is that they would take forever to get debugged. With so many people changing so many things, we never knew what had gone wrong when a bug report came in. And with all of the code changed, we had to investigate every single bug report carefully (no matter how unlikely or vague the report) because anything could have been broken.

So far, at risk of jinxing the beta, it appears that the physics-only approach is working a lot better. It has been quicker to find bugs when they are reported, and the overall level of crazy is a lot lower than in past releases.

NaNNaNNaNNaNNaNaNNaN Batman!

There aren’t many open bugs left in the 11.40 beta, but one particular bug has caused the beta count to run up: we were seeing crashes due to NaNs in the flight model.

NaN stands for Not A Number, and it’s what you get when you have divide-by-zeros run amok in the physics. To catch them, we’ve turned on a lot of auditing code and we’ve been collecting automatic crash reports. At risk of jinxing it, I think Austin has fixed one of the two root causes in beta 8. We are going to keep chasing them until the other one is fixed, then turn down the checks once we’re done. So we may make it to beta nine or ten and we may have another week with two betas; the high tempo is just to get more checks in fast.

Experimental Physics

There have been a number of questions in the comments on the state of the experimental flight model, so I want to clarify how it works and what is happening in 11.40.

Normally, new X-Plane features get beta tested during the beta of an X-Plane patch. This means we have somewhere between two and eight weeks to debug the feature and get it ready to ship. Once it ships, if we change the feature, we have to consider how this would affect authors using the feature and whether it would screw up their add-ons.

That’s not a lot of time to debug! In particular, it’s really not enough time for the flight model, where people need months just to develop the aircraft and measure the performance to get us feedback.

The experimental flight model is basically a giant year-long open beta of a future revision of the flight model that hasn’t shipped yet. By checking the “experimental FM” box, you’re getting to beta test the flight model of the future, now. By keeping the experimental flight model as an experiment for so long, this frees Austin up to simply fix bugs and improve it, as opposed to worrying how the X-Plane 11.40 experimental FM changes will affect X-Plane 11.30 users.

To be clear: there is no attempt at backward compatibility between the experimental flight model from one sim version to another! The goal is to have the experimental flight model not interfere with the “normal” flight model at all.

Physics changes in 11.40 fall into two broad categories:

  • Simulation changes that can change how an aircraft flies, improving the accuracy of X-Plane’s predictions about the airframe. An example of this is the delay in wash propagation from the prop to the tail of the aircraft. This makes the aircraft more stable, but may change how it flies; an author might have added artificial stability or reduced control surface efficacy to work around the lack of this feature in the past, and these work-arounds would be inappropriate with the new, more accurate physics.
  • Simulations that change how the aircraft flies in unusual circumstances that you can’t tune your aircraft to. Examples of this include stalls and wake turbulence. There isn’t going to be a book value for the effect, so all we can do is try to produce the most sane results given an aircraft that simulates properly in regular flight.

Features in the first category require the experimental flight model to be enabled, while the second category of features is always on.

At some point in the future, the experimental flight model will become the flight model for X-Plane, but we are not there yet, and we are not planning to do this as part of making X-Plane 11.40 final.

Third Party Aircraft

If you develop a third party aircraft, you need to test it now against both the experimental and non-experimental flight mode. If the non-experimental flight model doesn’t fly the same as 11.36, please file a bug, and please provide flight testing details. For the experimental flight model, you may see book numbers change a little bit; the real question is whether the overall physics response is better or worse.

Vulkan and Metal

X-Plane 11.50 will be the next major patch once X-Plane 11.40 is out of beta, and it will feature Vulkan and Metal support.

The marketing guys showed the Vulkan build of X-Plane live at Cosford last week; that build did not have any support for texture paging. Since then, Sidney has a basic texture paging implementation running, so hopefully we’re in good shape to get this into developer’s hands after 11.40.

Our expectation for add-on compatibility is:

  • Add-ons doing supported things, like 2-d panel drawing and UI should just work in Vulkan and Metal – we’ll take bug reports to fix compatibility issues.
  • Add-ons doing unsupported things won’t work in Vulkan and Metal at all. Your 3-d drawing callback won’t be called, or your attempt to grab internal GL resources will just fail (because none of our resources are GL).
  • X-Plane running under OpenGL should “just work” for pretty much every add-on, including ones doing sketchy things, and should be faster than 11.40 but not as fast as Vulkan or Metal.

I expect the Vulkan beta to be a relatively long one. We want it to start this year, but it probably won’t end this year, and my guess is that initially Vulkan will be fantastic for some users and will crash for others. During the beta we’ll gain useful information about how well Vulkan works “in the field” for different cards and drivers.

One reason I am looking forward to the Vulkan beta: we now have tremendous visibility into what the rendering engine and driver are doing. With OpenGL, the driver was often a black box. We still get reports of “the 3-d mouse in VR make my machine really slow” and frankly, we may never know why this happens to just some users and not others with the same hardware, drivers, and version of X-Plane.

With Vulkan and Metal it is going to be different. A lot more of the graphics work happens inside X-Plane, and the work that happens inside the driver is much more predictable, bounded, and can be viewed via modern profiling tools.

So while we will have a lot of debugging to do based on user feedback, it should be straightforward to get the information we need to really make the Vulkan renderer scream.

After Vulkan

It’s a little too soon to discuss what comes after Vulkan, but I can say this: for almost two years now, Sidney and I have been rewriting the rendering engine with a rather strange goal: performance and predictability, but with the same visual output. So anything that looked ugly on the screen is supposed to keep looking ugly. Vulkan was a change of the how but not the what of our rendering engine.

Once Vulkan is out the door, that all changes. We have a number of fundamental changes we want to make to how we deal with light, with the atmosphere, with color, and with organizing our frame. Once we have Vulkan, we get to use it as our foundation for what comes next.

Posted in News by | 121 Comments

Cosford, Etc.

This weekend we’ll be in Cosford for Flight Sim 2019. Well, not me personally, but Philipp, Marty and Thomson are there.

This summer when Marty asked if we could run the Vulkan version of X-Plane on our machines at the show I laughed a bit and then said “hell no” – at the time we were running scenery packs in the sim with default aircraft, but Vulkan was still a work in progress.

Vulkan is still a work in progress, but there has been a lot of progress, so when the marketing guys asked again I said “sure, yeah, what could go wrong” and Sidney cut them a build. We also told them not to throw out the shipping version, but if the app is well behaved people at the show may get to fly the Vulkan build for the first time.

Betas, Betas, Everywhere

At this point I’d judge us to be in the middle of the X-Plane 11.40 beta run. Beta 6 is reasonably stable and has fixed a bunch of problems that broke third party aircraft, and it’s now available to steam users. We’re still tracking down a bug where the physics code produces a NaN value. Since it just happens while flying and we haven’t gotten any useful reproduction steps, we’re pursing it by adding more checks and looking at automatic crash reports.

Please, always auto-report your crash. We don’t need you to fill out the description text field – just the auto-report and email is enough. We are looking for as many reports as possible, and we will probably stick with two betas a week until we chase this one down.

Third parties: if you haven’t yet, please test your add-on with the experimental flight model off against beta 6 – we don’t have any known bugs with the legacy flight model and third party aircraft at this point.

We are also killing off the last beta bugs in the new version of X-Plane mobile. There’s some really cool tech going into the lighting on mobile that I’ll write up soon in a blog post.

Posted in News by | 18 Comments

“But with the blast shield down I can’t even see…”

Observant Steam pilots flying VFR noticed that the Cessna 172’s windows were completely solid gray in 11.35 release candidate 1 – not a huge problem for IFR, but not great for site seeing.

This should now be fixed – if you let Steam update the app you’ll get the clear windows back.

This bug was totally bizarre and astonishing. The interior glass texture for the Cessna was missing from the installation, but not from the master files we build the sim from or from the Laminar version. As best as I can tell, Steam’s tool for building the sim just lost the file randomly. I rebuilt the Steam install this morning and the file came back.

Posted in News by | 5 Comments

End Caps for Line Files

Here’s a feature that went into X-Plane 11.35 that will be really exciting to a very small number of scenery authors: in X-Plane 11.35, line files (.lin) can have custom painted end-caps on each end, and the texture repeats can be aligned to a grid.

Scenery authors who have gotten deep into X-Plane’s scenery system will already know from that first paragraph why this is useful, but for normal people who have seen the sun in the last 30 days, .lin files are the art files that define the look of thin linear features. X-Plane uses them for the painted yellow and white lines in the airport environment, but a developer can use them for anything linear.

Line files repeat, tile, and can follow the ground in a bezier curved path, which makes them great for curved taxiway lines. Their achilles heal up to now has been that when the line ends, the line just … stops. This makes them inappropriate for really thick uses, where that hard “cut” at the end of the line would be really noticeable and ugly.

In X-Plane 11.35 you can provide a start and end cap for each line definition. Like the line itself, it can be mulit-layered if desired. So, for example, you could use it to make dirt paths between buildings in a rural airport – where the path ends you can have a “soft” ending to the path and not have to worry about tucking the line under another scenery element to hide the cut.

We’re not using these in the default art yet, but the code is done, and I have updated the .lin file format specification with the new syntax.

Posted in Development, Scenery by | 3 Comments