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.
Over the past month people have reported to me all sorts of weird things:
OBJ geometry moving with every export
Blender Objects moving after every export
Animations spiraling out of control
Even simple renaming Blender Objects and restructuring of the Blender hierarchy might trigger a bad export.
And the only cure was to apply all transformations or restart Blender!
Thanks to your bug reports and e-mails I was able to track down the source: all these problems were facets of the same bug!
To make a long story short: I have a fix for XPlane2Blender, but
other Blender exporters and users may not be so lucky. I’ve filed a bug
with Blender itself, but that is nothing to worry about for X-Plane
artists.
Please continue to send me your bug reports! I do read every one of them, even if I don’t get back to you right away.
XPlane2Blender for 2.80 has crossed a new milestone! Exportable Collections are in! They work just like root objects (which we are now calling Exportable Objects), the settings for them are just where Layers Mode settings used to be, and Layers Mode projects keep their OBJ settings automatically. More details down below.
As always, make backups! This is still an alpha and how collections work could change!
New Name For Root Objects
As mentioned, Root Objects – the concept – has been renamed to
“Exportable Objects”. Everything is the same, it is only the name that
is changing in the UI and the docs. This was done to let people know
there really isn’t much difference between using the new Collections and
the old Root Object system. Half the name is the same! Otherwise it
sounds like “Root Objects vs Exportable Collections” are as different as
how it used to be with “Root Objects Mode” vs “Layers Mode”. From here
on I will use the new names – Exportable Collections and Exportable Objects.
New Features
Exportable Collections
We’re very excited about this: Collections are in! Many thanks to the people who talked about it on #450. I think the feature will be able to do all or most of what you wanted. Here’s how to use them.
When you open a 2.79 file in 2.80, the contents of Layer 1 will be
put into a collection called “Layer 1_{the scene’s name}”, the contents
of Layer 2 will be put into a collection called “Layer 2_{the scene’s
name}” and etc.
Blender has new and exciting ways of using Collections and the 3D View. If Show is on but you can’t see the contents of a collection, try right clicking on it in the outliner, go to Visibility and ensure Render and Viewport are enabled.
You’ll find the exact same OBJ settings in the exact same layout where Layers Mode used to put them.
The updater will have copied the previous settings if the layer had
some object in it or the OBJ settings was changed in some way.
Collections can be marked as “Exportable” or not. Non-Exportable
Collections can be used as a way to organize your project, similar to
using Empties. Unlike empties
An important terminology note: Datablock Objects (Meshes, Lights,
Armatures, Empties) can have 1 Object parent and many Object children.
Collections can have 1 Collection parent and many Collection children.
This means a datablock objects can have 1 parent and be in multiple collections. When an object is linked to a collection, it is in that collection and all that collection’s chain of parents.
Collections do not have a location or rotation.
A mesh, armature, or other objects can have a blender parent and
be in multiple collections. A great opportunity for re-use that
XPlane2Blender supports. Also key for another new feature called “Split
Animations”.
Every object inside the exportable collection and its chain of child
collections is collected and exported together as one OBJ. Any children
of those objects found outside the exportable collection are ignored,
just like how Layers Mode used to work.
Each object is included once. Attempting to make duplicates by
putting an object in multiple sub-collections of the exportable
collection won’t work. In this example Cube only appears once in the
OBJ.
What is exported only depends on what objects are in what collection and the value of that collection’s Exportable Collection checkbox. Viewport visibility doesn’t matter.
Everything inside the exportable collection and any of its child
collections will be exported. If any object has a child that is outside
of the exportable collection, that child and all its children will be
silently ignored.
There is no more “Layers Mode vs Root Object” divide, and projects
can use Exportable Collections and Exportable Objects at the same time
(just not nested).
Here is a picture showing a side by side comparison of the relevant
UI in 2.79 and 2.80, using the BD-5J Microjet. After opening the file I
hit export and it just worked!
In this picture I’ve unchecked Exportable Collection on Layer 2_Scene. Now it won’t export.
Split Animations
Split Animations is one of our most exciting new features – something
never before possible in XPlane2Blender! See the guide in the manual, click here to find more.
Other Bug Fixes
#493 Unit test system slowly healing and getting back to usable.
Caveats
Things Move On Every Export
There appears to be a Blender bug in 2.80 where sometimes after every
export (of any exporter) the objects drift apart. It is unknown why
this happens but there are two ways to fix it.
Restart Blender and try again and hope it works
Select all objects and bones and use Apply > Transformations > Scale. And if that doesn’t work, Apply > Transformations > All Transformations. These are drastic, but, if it works, please e-mail and help confirm this bug that we can report to Blender.
Updater Changes
The updater has had some changes and not all of them tested 100 times
over like I normally like. I don’t think it will be a problem however.
Please e-mail me if you have trouble. If you have a multi-scene project,
double check your updated OBJ settings and tell me if you see an
automatically made collections with names like “Collection.001”. They
should have been renamed.
For those of you patiently waiting for an e-mail back from me about a
problem you’ve had with your .blend file, thank you for your patience.
I’m going to try to respond to all of them this week!
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.
Release Candidate 2 is now available for LR customers, and we expect Steam to be available within 24 hours or so.
This is a very small patch with a few minor fixes. At the risk of sounding like a broken record: if you haven’t tried your add on aircraft in 11.40 yet…do it now! The reports have been pretty quiet the last couple weeks, and nobody enjoys a last minute surprise bug.
Release Candidate 1 is now available for LR customers, and we expect Steam to be available within 24 hours or so.
We are moving towards the end of the beta period, so we’re minimizing the number of code and flight model changes at this point. If you haven’t tried your add on aircraft in 11.40 yet…the time is now!
This update contains mostly tweaks to AI & ATC interaction to improve landings, replay sound improvements, and includes a few new datarefs requested by devs.
Beta 9 is now available for LR customers, and we expect Steam to be available within 24 hours or so.
This update includes a few more fixes for crashes and issues with third party add ons. The rate of bugs and crashes reported has slow down dramatically in the last week or two, and we don’t have open third party compatibility bugs, so we are getting ready to wrap up the beta.
Developers: expect r1 soon, and make sure you test your add ons.
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.
