Normally we try not to pre-announce new features before they are complete, but it’s been kind of an open secret around the company that we are working on native VR capabilities for X-Plane. Austin mentioned it on a Facebook Live stream, and Chris posted pictures of un-boxing his OcRift and Vive.
So today I’m going to show you a sneak preview of something that I’m just too excited not to post: X-Plane 11’s new Pirate-VR™ mode*.
There are two major challenges to integrating VR with a general purpose flight simulator:
- Performance. X-Plane typically runs at 30-40 fps on a high-end system on a single monitor. How do we render a stereo image to two eyes without cutting frame-rate in half?
- Usability. How do users interact with the complex cockpit buttons and switches using 3-d “wand”-type controllers that ship with today’s VR head-mounted displays?
Pirate-VR™ mode solves both of these problems.
When rendering to the head-mounted display, we simulate an eye-patch over the left eye.
By blacking out the left eye, we are able to recover quite a bit of framerate and run a stereo render at over 40 fps; minor optimization should get us to something fluid for the HMD.
In Pirate-VR™ mode, both of your hands are replaced by large metal hooks. Since it is pretty much impossibly to safely operate the over-head panel of an MD-82 with hooks for hands, we can skip 3-d interaction testing on most of the cockpit, simplifying VR interaction quite a bit.
I can’t announce when Pirate-VR™ will ship, but for scallywags who will be joining us at FlightsimCon in Hartford** this year, I think we’ll have something you’ll really want to get your hooks into.
* Yes, it is, of coarse, pronounced “Vee-ARRRRRRRRRR!”
** Update: my wife points out that the correct pronunciation is HARRRRRRRRtford.
…is available to test. May the good lord have mercy on our souls.
The rate of comments on this blog sky-rocketed when I mentioned that beta 16 was the last beta. (As it turned out, beta 17 is the last beta, because I had to fix a stupid bug I introduced in beta 16.) I would describe this as “fear of missing the train” as it leaves the station.
What will be the impact of actually shipping 11.0? The short summary:
- We will keep fixing bugs.
- We will be able to fix some bugs that we were not able to fix late in beta because the changes are complicated and need more testing time.
- X-Plane 11.0 users who don’t want to deal with unstable betas can simply stick with 11.0 until a patch goes final. This should make the whole beta process more pleasant for everyone.
- We will have to write compatibility code for add-ons that depend on 11.0’s behavior.
- The set of major features of 11.0 won’t change – we’ve made our “big plays” for the version.
In other words, post 11.0 will probably be like now but less stressful for everyone. I expect we will do at least one bug fix patch – we’ve had to do one for every major patch we’ve done but we don’t have a specific plan. We’re waiting to see what gets reported after 11.0.
Will It Blend?
We’ve pushed hard to get compatibility and SDK bugs fixed for 11.0 so that third party developers can “get going”. There is one area of the sim where we’ve had a pile of bug reports that, realistically, aren’t going to be fixed in 11.0 and might have some impact.
X-Plane draws translucent, blended effects (lights, smoke, clouds) in a fixed order. Because these are translucent effects, they must be drawn from farthest to closest or they won’t look right, but X-Plane draws them in a fixed order. The results are not good – when the order that X-Plane picks is backward, you get rendering bugs.
X-Plane has been like this for a very long time, and a lot of these bugs are present in X-Plane 10, and only more noticeable in X-Pane 11 because of lighting changes.
My concern about these bugs is that they may affect third party plugin interfaces. My goal is to get this resolved as quickly as possible to avoid surprising people.
The good news is that this is a pretty narrow part of the sim – if you’re not using plugins to draw, or you’re making an aircraft, or non-plugin-enhanced scenery, this probably doesn’t affect you.
And so should you if you use beta 16. X-Plane 11 public beta 16 is out now and fixes a whole pile of bugs. It also introduces one new big one: in HDR mode the overhead panel of the cockpit is totally lit up. Alex reported this to me about an hour after the beta went live; it’s caused by changing where in the drawing process the moon is drawn.
This will be fixed for a beta 17 in the next 24 hours; you can work around it by turning your effects down to medium. Please do not report this bug, as it’s already being fixed. (Do report anything else you find though!)
There are some things fixed in beta 16 though!
- Clouds should be faster. If you are having performance problems with the clouds, please re-report a bug against beta 16.
- We fixed a lot of bugs for authors. Third party developers: please read the release notes carefully – we’ve tried to document every change we’ve made. The new FMS should be a lot more compatible, as should various parts of the flight model.
- A number of rendering artifacts are fixed: sky banding, etc.
Beta 17 (to fix the lit up cockpit) will likely be the last beta of the X-Plane 11.0 series.
A few third party developers have noted that their X-Plane 11 aircraft icons are too small – that is, the size of the airplane in the icon square is tiny when using X-Plane’s icon making function.
We use the bounding sphere of the aircraft to size the airplane, but it can be thrown off. In particular, the bounding sphere we use is the bounding sphere for drawing, but it is precomputed at load time, and therefore contains any mostly-hidden weird stuff on your aircraft.
If you’ve made a GPU cart or push-back truck OBJ and attached it to the ACF, the size of the airplane with the vehicle is being taken into account and it can make the airplane small.
It’s actually a little bit worse – if the object is animated (so it can “drive”) then we consider the animation track. If you have a translate whose end key frames are far from the aircraft, that can really change your bounding volume.
My suggestion: temporarily delete these objects from the aircraft file and then take the screenshot.
After 11.0 ships, I have a few ideas to make this better:
- We can use the aircraft’s physics sphere to size the icon, which should be a lot more accurate and won’t be fooled by ground trucks.
- Some day we’ll have a new persistent OBJ API for plugins – when this happens, please migrate your ground vehicles to this system – there are real costs to having non-airplane objects on the airplane.
Don’t Be That Guy
Finally, third party aircraft authors: please use our icon generator and don’t just splat a screen-shot into the X-Plane 11 icons. The aircraft picker is going to look terrible if it turns into a tile grid of screenshots.
Our graphic designer spent a lot of time and care getting the presentation of the main aircraft picker to look good and be user-friendly; this includes balancing the relative brightness of the user interface elements, the icons, the airport list, etc.
If one third party vendor puts a screenshot into a v11 icon, it looks “louder” than all other aircraft. This tempts other third party developers to do the same thing and before we know it, we’re going to have the ugliest flight picker ever.
If you are having trouble getting a clean icon screenshot of your aircraft, please let us know. Sometimes a complex third party aircraft has to have a few features turned off to make it work, but we are looking at fixing remaining bugs, etc.
(General tip: for best results, load the aircraft first, park it with engines on, then take the icon picture. In theory we can take the picture from the main menu, but in practice your plugin will be in a more ‘normal’ state if you go to the ramp first.)
We’re reaching the end-game with X-Plane 11.0 public betas. Right now I am working to try to solve three problems at once:
- Users of the beta really want to see rendering issues solved ASAP. Besides the constant chorus of “you know your sky looks like hell” in the comments section, the cloud code has serious performance tuning problems that I have been working on. We definitely want faster clouds in the next beta so it is a useful beta.
- We are trying to get the flight model locked down ASAP. We’ve received a number of really good bug reports in the last week and fixed a bunch of compatibility issues; the sooner we get those fixes out, the sooner authors can confirm their planes work.
- There are some issues that really need to be resolved in 11.0 because fixing them mid-version (where backward compatibility requirements are much stricter) is a lot harder.
You can see where this is going – those things are totally at odds with each other. The longer we take to fix rendering artifacts, the longer aircraft authors have to wait for key flight model fixes. If we don’t fix cloud perf, the build isn’t useful. And if we go try to put more changes in (item 3) to get things fixed “at 11.0” we risk the flight model being more buggy.
I’ve sent private builds of beta 16 to third parties over the last few days in an attempt to confirm that we are fixing bugs and not creating them – my hope is that this will make beta 16 a much more usable beta and not a step backward. I also made some progress on cloud tuning last night; I don’t know if it will be the end of perf improvements for clouds but it should be a lot better. From the feedback I’ve received, the fixes from last night need to go out before we can tell what else is going wrong with cloud performance.
(Unfortunately there are a huge number of configurations that interact with cloud performance: number of monitors, resolution of monitors, FX level, reflection level, and position of camera, terrain type, cockpit and of coarse the weather itself all interact to affect final performance!)
I’m hoping to have beta 16 out Monday or Tuesday.
One Last Change
The changes to the flight model and systems code for beta 16 are all in the direction of better compatibility (e.g. they fix a bug new to X-Plane 11 or make X-Plane 11 more like X-Plane 10) with one exception: snapping of autopilot vales.
X-Plane 10 introduced a new, accidental, unwelcome behavior: it snaps certain datarefs (E.g. the autopilot VVI and altitude) to a fixed grid every frame. If you use DataRef Editor to set the autopilot altitude to 10,001 feet, it will jump back to 10,000.
The goal of this code was to allow panel knobs to freely spin an autopilot value for smooth animation – if the physical display in the cockpit is an animated mechanical roller, not snapping to the grid makes it look like it’s turning. When the user finishes spinning the knob, it “lands” on an even number like 10050 feet, just like the real aircraft would.
The behavior of always rounding the value to a nearest amount was an accident of how the code was structured. The down-side of this is that it makes it very difficult* for plugins to freely animate the dataref themselves, e.g. if the knob is being driven by a custom manipulator or command or some internal plugin path.
This rounding was new to X-Plane 10 (X-Plane 6, 7, 8 and 9 did not do this) but we kept it for the life of X-Plane 10 so that the dataref behavior would at least be consistent.
I have code that I am planning to put into beta 16 that puts the behavior back the way X-Plane 9 and earlier was: the value of these datarefs will be rounded to a grid only when Plane is done twiddling them. If you write to them with a plugin or manipulator, you’ll get exactly what you ask for – at least until the user touches a built-in panel instrument or command or some other pure X-Plane path.
This change is a little bit scary – there may be plugins or add-ons intentionally writing not-rounded values and counting on X-Plane to round them. This is a change that we can put in one beta and remove in the very next one if it turns out to cause too much chaos.**
But I am certainly hoping we can make the change – having X-Plane only round when needed makes a much better and more convenient interface for add-ons – add-on authors can get exactly what they want without having to wrestle with an octopus.
* Not impossible – just very difficult. To work around the problem, you have to inject your own values in a hook after X-Plane and manually track what the value should have been so that you don’t get fooled by X-Plane constantly snapping the value. There are a number of “unwritable” datarefs where you can write them by just shouting louder than X-Plane, but I strongly recommend against using this to make your add-on work. If you need to do this, contact us about what dataref you are fighting about – there might be a better way.
** This is going to be one of those cases where if one or two add-ons is broken by the change, we’ll declare it as “this is how X-Plane 11.0 is”, but if 100 add-ons are broken, we’ll put it back and I’ll have to go drown my sorrows. See also the usual joke about owing the bank $100,000,000.00 and all that.
We’ve been working on a single comprehensive document for aircraft authors – everything that changed in X-Plane 11. Jennifer has posted a draft here. This is still a draft, and we still have work to do, but there’s a lot already there, so we figured better to post it and let people comment and get started.
For entirely new features, we are creating separate articles on how to use them – it would be a little weird to have to look up “v11 aircraft checklist” to learn to use FMOD. This means that this document refers to some unfinished (and unpublished) documents that will be coming soon.
Changing Blending
One of the changes listed in the document is that we changed the blending in X-Plane from blending in sRGB space to blending in linear color space. This is a universal change. It affects: all 3-d drawing, including everything drawn with an OBJ and the 3-d drawing of the panel texture. It does not affect:
- Plugin-based drawing in any 2-d drawing callback, including plugin UI drawing.
- Drawing into the panel (either via Plane-Maker instruments or plugin code).
In other words, your panel is composited in 2-d as it was before, but the usage of the alpha channel of that final panel texture is different.
How Am I Different?
The notes say blending is now linear and not in sRGB space. What does that actually mean, and how does it affect you?
Take a look at the color gradients in this blog post. (The whole post is really good, but the gradients show this issue). When you have a surface with intermediate alpha, you’re getting the intermediate gradient of the thing behind your surface and your surface’s albedo, with some fraction determined by the alpha.
As you can see from the chart, the intermediate colors are all brighter with the new linear blending. This intermediate brightness is more like what you would really see when working with translucent materials; the old model was losing light energy.
(X-Plane 10 was linear in the entire rendering engine except blending – we kept blending in sRGB space – it was very complicated and messy to do and hurt performance. So it was a priority to make things both faster, more correct and less insane on the code side for X-Plane 11.*)
What Do I Have To Do To Tweak My Textures?
Let’s get practical: textures with alpha will not look the same as in X-Plane 10, and while sometimes the new result is just better (light colored alpha-based lettering on panels almost always looks better in v11 out of the box), sometimes you’ll need to retune your alpha channel.
In pretty much every case, the new blending is brighter in intermediate values than the old one, which was losing light. (When we stop losing light, the net result is an increase in light.) So these cases will all involve ways to back off the brightness; you probably made things overly bright in X-Plane 10 to compensate for non-linear blending.
Here are a few typical examples we saw when exploring this feature with our art team.
Tinted Glass: tinted glass typically suffers from two problems:
- It’s just not dark enough.
- The tint color itself is too bright and now “shows” a bit, e.g. non-colored tinted glass looks light gray.
First: make the RGB of your texture darker if possible. Dark tinted glass should almost certainly have a black RGB (and use alpha for “how much” tinting).
Then: adjust the alpha as needed – if darkening the RGB didn’t do it, increase the opacity.
Painted Reflections: if you’ve painted reflections onto your glass, they may look too bright.
First: consider letting the engine be the reflection source – you may want to use BLEND_GLASS for cockpit glass and/or use metalness to increase reflectivity. Do these things first before editing albedo and alpha textures; they have a much bigger impact on your scene than the new blending mode.
Then: when done (or if you will not make these changes) decrease the opacity to turn down the reflections.
Dirt and Grunge: we found that our black markings on the ground looked too light – they were using alpha to anti-alias the edge of the marks and simulate pixels that contained a mix of dirt and the underlying surface in a single point. (This particularly matters when you zoom away from the marking and it becomes small on screen).
First: make sure your RGB channel contains correctly dark colors around the edges of the decal. (In what I’ve seen, artists pretty much always get it right in this case.)
Then: increase the opacity of the effect to make it darker (by emphasizing the dark decal more than the lighter pavement.
As a general rule of all of these, the RGB of a blended surface should be very dark (decals, tinting) or very light (fake reflections) and not be mid-range. Then the alpha can be made more opaque to darken darks or more transparent to darken lights.
* Nerd’s Nook: If you known enough OpenGL to be dangerous, you might be asking “Ben you idiot, why don’t you just turn sRGB blending off and on based on whether the content you are drawing is new to X-Plane 11 or old from X-Plane 10? You can just use glEnable!”
Sadly we cannot. In the forward renderer we might be able to toggle the blending mode per object or something, but in the deferred renderer (HDR mode), we blend all albedos together, all lit textures together (during G-buffer setup) and then we add the total lit to the total albedo during the single lighting pass where we apply the sun.
Basically we’re taking the math of the blending equation and rearranging the algebra. This rearrangement only works if the color space for adding the lit and albedo together is the same color space as every blending operation.
So for HDR to work, we have to pick a single blending equation sim-wide because we have to pick a single way to add lit and albedo together. For X-Plane 10 we picked sRGB color space and for X-Plane 11 we picked linear. Linear is a total win here – besides looking better in a lot of cases, adding lit textures to albedos looks better when done in linear space too. After all, we are adding light.
I just found a bug in beta 15 (and 14, and 13, and 12..etc.): if you use ATTR_shiny_rat or GLOBAL_specular with an intermediate value, e.g. between 0 and 1, you get an oily effect when HDR is off.
This is a bug in one of the shaders. We didn’t see it early because I have encouraged our art team to set the specular ratio to 1.0 and leave it there and use the normal map to modulate specularity. You should take that advice too! The GPU is really good at reading textures, and the CPU is not particularly good at interrupting the GPU to change what it’s doing, which is what ATTR_shiny_rat does.
Beta 16 will fix this; in the mean time, what you see in HDR mode (the top two FX settings) is correct, for the purpose of figuring out if your art looks good.
Just a quick note: beta 15 is up and fixes a few key bugs:
- No more Plane-Maker crashes opening files.
- ACF files aren’t locked while the sim is running.
- Cessna takeoff should be a lot better.
I’ve heard a lot of chatter about FPS problems with the new clouds. If you are having FPS problems with the clouds, here are a few key things we need for a bug reports:
- Include a log.txt. We get enough bug reports that if you ignore the “always include a log.txt” note in the bug report, your bug report will go to the back of the line. Everything that we tend to ask users that can be gathered automatically is in the log.txt: your CPU info, GPU info, driver, version of X-Plane, add-ons installed, scenery…there’s a reason why we want it!
- Be sure to note your monitor configuration (how many, how big, what you’re doing with them).
- Include a full res screenshot of the clouds where FPS are bad, preferably with the FPS counter showing. Please don’t use JPEG or crop it – I need to see what the rendering engine is doing.
- Try setting the weather to clear – does that improve FPS? Try changing your window size. Does that improve FPS? These differentials are useful.
- For a given view where FPS are awful, does regenerating the weather (bind a command key) change things or is it always bad?
- If FPS are always bad, send us a .sit file where, in the cockpit of an aircraft that we ship with the sim, framerate is really bad. We can load the .sit file, regenerate the weather a few times, and see what’s up.
- Update: one more thing – if you are using a third party aircraft, does changing to one of ours fix the issue? Does changing the shape of the 3-d cockpit (which blocks out clouds) fix the issue?
X-Plane 11.0 public beta 14 is out. This one is a bit of a two-steps-forward, two-steps-back. Some notes:
- You won’t need a ton of thrust to start moving anymore – Austin was able to remove that hack from the tire model based on some new ideas for modeling low speed tire physics that get around a years-old problem.
- The Cessna apparently wanders around the runway like a drunken moose.
- Max’s new cloud art is in. Under some views and conditions, you may get significantly better performance.
- Under other views, they may kill your GPU. I’m looking into this.
Most importantly, I broke Plane-Maker, so public beta 15 will be out in 24 hours, and I’m going to sit in the corner and have a time-out for a few minutes. If we have a fix for the Cessna in that time frame, we’ll ship both, otherwise I’ll get a patch out to fix Plane-Maker and we’ll get to tires soon.
The State of Various SDKs
SDK stands for software development kit, but the term is now used more generally for the various interfaces, tools, and file format standards to make add-ons of any kind for X-Plane, even if there is no program (software) involved. I’ve been getting a lot of questions about what’s safe to start developing on top of, and what’s going to be ready for third parties. Here’s a quick update on the status of some of the V11 SDKs.
FMOD + Sound
FMOD-based sound is one of the biggest new features for third party developers in X-Plane 11. Here’s the status:
- FMOD support is feature complete in public beta 14. Therefore we expect to have X-Plane sound “third party ready” by the time we go final with 11.0.
- There’s a lot to document about FMOD. I have already started the beginnings of full documentation, but it will take time to get it on paper. I’m hoping to have draft FMOD docs that you can use shortly after we go final.
- There’s a lot of details to get right in making an FMOD-enhanced aircraft; please do not ship an FMOD-enhanced aircraft before the docs come out – there’s a very high chance of doing something wrong if you’re just trying to guess how the system works from our Cessna project.*
When we ship, we will have bare bones tools for working with FMOD, but we will publish everything we had when we did the Cessna, and this setup is adequate for creating production aircraft. Fortunately, most of the work is done in FMOD Studio, a rich, full featured sound editing environment. It’s great to use.
The ‘thin’ side is X-Plane support: the sound attachment file (.snd) that links FMOD events to your aircraft has to be built in a text editor. We also have some graphical debugging and it is possible to attach a live mixer to X-Plane while you fly. All of this will be covered in the docs.
In the long term, we’d like to make the sound attachment system visual and have it run inside X-Plane while you fly.
What you can do now: learn how to use FMOD! Download the FMOD studio editor (it’s a free download) and start working with its sound design tools.
Graphics – Aircraft, Scenery and Modeling
I still have a list of graphic artifacts, but I think the overall operation of the new lighting system is as it will be for shipping 11.0. You can start using the new material model now; until the exporters have direct support, you can always add the NORMAL_METALNESS directive by a text editor or add it to a PNG comment.
Probably the biggest weakness of the new lighting model right now is the lack of detailed control over the interior of aircraft; I expect we’ll have new techniques to cope with this in future updates, but they won’t be mandatory aircraft changes. Unfortunately I don’t have good work-arounds right now for aircraft where the interior lighting is unacceptably weird.
What you can do now: tune the brightness and alpha levels of translucent textures – they need to be adjusted for X-Plane 11’s linear blending. Fix any panel problems introduced
Aircraft Physics and Systems
One of our biggest pushes right now is to try to get to “done” on the aircraft physics and systems code. The engines should be done – we don’t have known open bugs. The tire modeling is still problematic as of public beta 14; Austin has a fix for the bad behavior of the Cessna in beta 15.
What you can do now: test your aircraft’s physics model with X-Plane 11. If you have a fleet of aircraft, pick one particular aircraft and carefully update it for X-Plane 11. If you find out that there’s a physics problem after we go final, we’re going to have a lot less flexibility to fix things.
We run the physics engine on our own fleet (and we don’t use plugins to modify the physics) but that’s a limited set of aircraft. If you have good data about how your aircraft doesn’t work right with our flight model and good input data in Plane-Maker, we’d like to hear about it.
Weapons
The weapons SDK is the one area where we have moved temporarily backward from X-Plane 10. X-Plane 11 features a new unified weapons system that takes technology from both X-Plane 10 desktop (for physics) and X-Plane 10 mobile (for multiplayer simulation). Unfortunately, we haven’t had time to create an appropriate dataref interface to these weapons.
Getting the interface to weapons finished is on our short list for after 11.0 ships; I do expect that the list of datarefs may be different for 11.xx than it was for X-Plane 10. The new system has new capabilities that make the old “fixed index of weapons” model not a great fit.
Unfortunately, this means that if your add-on depends on plugin-controlled weapons, you’re stuck in a holding pattern until we can post a new interface that we can maintain.
Plugins
As of public beta 14, plugins should just work – we’ve closed the remaining plugin API and major dataref bugs. There are a few areas of fine print:
- You can’t use drawing callbacks in the map in X-Plane 11 – the totally rewritten map doesn’t use the same coordinate systems, so there is no way we can make old code work.
- Some datarefs and commands are not available in X-Plane 11. This is a normal part of the evolution of the sim.
- Multi-monitor support has a pile of bugs when you put X-Plane’s menu bar on the second monitor. If your plugin works normally except in this condition, it’s probably an internal X-Plane bug you’re seeing.
Note that to control toe brakes in X-Plane 11, you now need to set an override. Once you do, you completely own the toe brakes – you can look at the raw joystick input datarefs if you want to write a plugin that “processes” toe brake inputs to create some kind of effect.
What You Can Do: Check the command and dataref lists that are in Resources/plugins. If you need a command or dataref that has been dropped (and is not weapons related), contact us to discuss your use case and we’ll figure out what to do. If you are still seeing plugin bugs, file them now!
What we will not have done for 11.0 is entirely new plugin functionality to expose new X-Plane 11 specific features. We will need to do a major API revision to allow plugins to undock windows (like our GPS and map does), to expose some of the new FMS capabilities (expect a limited API) and to restore map customization functionality.
Particle FX
The particle system SDK is kind of done, mostly. We use it in the shipping mobile product, and the editor is available in the desktop product now. I still have two features left to do that Austin considers “must-have”; I expect to get them in shortly after we go final, at which point we can start providing documentation. (One of those features is the ability to control aspects of the particle system from multiple datarefs – that will change the UI enough that it’s not worth writing docs now and then changing them.)
My suggestion is to stand by on this – it won’t take that long to get the system to a “tinker with it” stage.
* I am quite impressed with how far some people have gotten without docs! But shipping an add-on that “seems” to work but violates the SDK rules makes a compatibility mess later.
