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.
Plugins can use OpenGL to draw directly inside X-Plane; this capability is almost fifteen years old and goes back to X-Plane 6. Plugin drawing typically falls into four categories:
- Drawing user interface (floating windows, HUD-like UI, map details, etc.).
- Drawing custom panel instruments (particularly 2-d glass displays).
- Drawing effects in 3-d (custom smoke or fire, or maybe diagram marks showing lift).
- Drawing solid stuff in 3-d (e.g. pushback trucks, parts of the airplane, etc.).
These first two use cases work pretty well; the third case works barely, and the last one is a bit of a train wreck.
Problems With Plugin Drawing
OpenGL an 3-d hardware was very different when Sandy and I created the original plugin SDK 1.0. Hardware had a fixed function pipeline built into the GPU itself, and your computer had one CPU core, so the issues I’m going to describe weren’t a problem back then. Here are some problems with plugin drawing:
- Increasing overhead just to draw. It used to be that we could just send a message to the plugin system at “good times” and let drawing happen. X-Plane now has to do a bunch of work to prepare OpenGL for plugin use; this synchronization work slows down X-Plane, and it’s getting worse as X-Plane’s internal design diverges from the canonical OpenGL 1.5 pipeline. (Example: we have to copy our matrices into the fixed function pipeline matrices before we call you, then copy them back if you call us with a drawing routine. Slow!)
- Plugins don’t have access to the fastest drawing paths. The less our drawing looks like OpenGL 1.5, the less efficient plugins are in comparison to X-Plane. This is getting worse over time too. (For example: if we want to render two VR eyes at once, we have to call your plugin twice, once for each one.)
- Plugins don’t have access to our lighting environment or G-Buffer formats, and thus can’t easily draw in a way that integrates with our 3-d world. This is getting worse as our rendering engine becomes more complicated.
So…this is not fantastic. The first two use cases (UI and panel) aren’t that badly affected because the two of them require only 2 or 3 call-outs to plugins, drawing in a very simple manner. The second two (3-d use cases) are quite problematic.
These costs are going to get worse when X-Plane moves to Metal and Vulkan drives; the cost of syncing over to OpenGL will be higher, plugins won’t even be drawing on the fastest APIs, and we may have to do some expensive texture synchronization.
Fixing The Problem
My goal isn’t to completely eliminate the costs of plugin drawing; rather just to minimize the costs by providing better alternatives for common tasks.
So in the long term, my plan is to add something to the SDK that we should have had for a while: the ability to create persistent object and effect systems in the X-Plane world.
Right now if you want to draw an object, you call XPLMDrawObjects – hopefully you’re doing this from just the right callbacks, but if you get this wrong, I forgive you; the rules for how to do this correctly in the v10 and v11 renderers are insanely complex, because the plugin API was invented fifteen years ago.
In the future, you will be able to simply create an object and X-Plane will draw it at all the right times, for any rendering mode, handling all of the special cases for HDR, shadows, reflections, you name it. You’ll just need to tell us when it moves. The same idea can be applied to particle systems for effects.
The one open issue with this scheme is how animation will work. Currently animations is handled by reading datarefs – if you want to animate multiple instances from a plugin, you have to figure out (inside your dataref handler!) which instance is being drawn and return the right animation values.
Not only is this a complicated mess, but it’s also slow; it requires us to call your dataref callback many times from inside the drawing loop, slowing everything down.
What I’d like to have in the future is some kind of ‘animation block’ where:
- Your plugin queries the object to find out which animation values it needs.
- Each time you update a particular instance of that object, you provide a packed block of the values of all of those animations.
- We use the block directly and never have to call datarefs.
This technique isn’t just faster, it also is easier to make multi-core and will play nicely when we can instance animation in the future.
The time frame for this is “during the v11 run hopefully” – that is, a new object API is not going to be in 11.0, and I can’t guarantee when it will be. I expect to support the old way (XPLMDrawObject and drawing hooks) at least through the entire v11 run, if not longer; our expected failure mode is ‘if you do it the old way, the sim might be really slow’. The new APIs will be designed to be completely friendly with multi-monitor, VR, Vulcan, and multicore.
X-Plane 11.00 public beta 12 is out. A few notes on the engines:
- Jet engine thrust at low N1 should be fixed; you should no longer have to kill the ground crew to taxi around the ramp. If you find weird jet engine N1 behavior, please report a bug ASAP!
- Reciprocating props will need to have their idles adjusted, perhaps a bit higher, particularly if your idle adjustment is < 1.0 in Plane-Maker. We had to bump up our Cessna, which was set to about 0.8 and was stalling if not given a little extra throttle.
- The engine start code has some kind of bug that is stopping engines from starting.
If you’re hitting this last case, please file a bug and include the aircraft that won’t start.
From what I can tell, the beta 11 code is actually correct for some airliners, but is wrong for others. I’ll have more details later and I suspect we’ll have a beta 13 that addresses this by Tuesday.
In a previous post I noted that we weren’t attempting dynamic ambient occlusion inside the 3-d cockpit, due to problems of quality, availability, and because it wasn’t really better than what authors do now: prepare the AO offline using a high quality render in their 3-d modeler.
I’ve been thinking about this a while: while I like to get up on my soap box and shout that X-Plane is not like a first person shooter any time we get compared to a AAA console title, there is one case where X-Plane kind of is like one: inside the user’s aircraft.
First person shooters often specialize in rendering highly controlled, closed, constrained, claustrophobic environments in ludicrous detail at very high framerate. To achieve this, they take advantage of optimizations specific to those closed, controlled environments: lots of things are pre-computed, pre-baked, and pre-calculated.
X-Plane’s scenery engine mostly focuses on throughput; once you climb through 500 feet you can see everything at an airport, so we just try to draw really fast. But the inside of the aircraft is different. Baking at least part of the interior lighting is pretty much a standard practice. We provide object-kill datarefs to let authors script their own culling algorithms to squeeze framerate out of a confined space.* We define sound spaces within the aircraft that can change how sound effects are filtered.** We let you mark which parts of your aircraft receive interior and exterior light. (This feature is called “light groups” in a regular 3-d game engine and it’s very common, particularly in older forward-rendering engines.)
All of this stuff is a lot more like a game with a 3-d level editor than the rest of X-Plane. Techniques that focus on interior spaces are a good fit inside an airliner.
Better Baking: one of the features planned for our next-generation modeling format is to allow multiple UV maps for a given model***. We can then add an ambient-occlusion texture to an object’s shader and you can bake your aircraft interiors at a much lower resolution than you albedo textures.
For example, you could use a high-res repeating texture to draw the seats inside the aircraft, copy-paste the seat down the cabin, and then unwrap a second UV map that covers the entire cabin uniquely. Bake to this second UV map, down-size the texture to super low res (it’s ambient occlusion, “soft” is okay) and you’ll get high-res detail with unique correct lighting queues all over the aircraft. This is a standard work-flow for 3-d game engines and seems like a good fit for aircraft interior.
Edit in the Sim: we can take another clue from game engines and provide editing of graphical aircraft information inside X-Plane. We already do this for the particle system – the editor is built into the sim itself.**** The advantage of editing in the sim is that you can see your work exactly how it will look in real time.
* Engines that focus on interior spaces often have techniques like portal culling built-in and tools to precompute the information for this culling automatically.
** This is part of the new FMOD SDK – we will get this documented around or shortly after 11.0 goes final.
*** I realize this isn’t very “next-gen” in the world of rendering engines – it’s just the next major modeling revision for X-Plane.
**** The particle system isn’t documented because it isn’t quite finished yet. It’s shipping in mobile, enabled on desktop, but it is not running the default effects right now.
This has been a point of confusion for third party developers, particularly ones who were in the private beta (and saw versions of the sim that…cough cough…didn’t work right).
Screen space ambient occlusion (SSAO)*, when enabled by the highest rendering settings, only affects exterior objects. This means scenery and aircraft-attached objects marked “exterior” for lighting.
I tried SSAO in the cockpit interior, and it had a few problems:
- The scale for occlusion in the interior and exterior of the cockpits is really different – I couldn’t find one size for the effect that fit all cases.**
- When I went to apply the effect to our fleet, I found that virtually all of our aircraft already had occlusion baked into the cockpit by the artists. The dynamic AO thus provided almost no value and made the cockpit even darker than it already was.***
- SSAO only works at the highest rendering settings (and requires HDR to function at all), so if artists remove their baked AO, they’re taking a pretty big visual loss in a bunch of settings.
So in net, it just wasn’t worth going to dynamic AO in the cockpit. Our AO isn’t as high quality as what you can bake in a 3-d program (given a few days of rendering time), and it’s not always available.
The real win for SSAO is outside the aircraft, e.g. to cast AO around the wheels of the aircraft on the ground. That’s an effect that you can’t bake, and it helps a lot with lego brick scenery too.
* Nerd note: I’m pretty sure that what we do is actually HBAO
** We could, in theory, apply the effect twice with stenciling at two different scales.
*** The cockpit tends to be dark both due to errors in our approximation for indirect light (because most of the cockpit is in shadow, and thus only lit by indirect light) but also because cockpits are actually pretty dark compared to the great outdoors. But that’s another post.
X-Plane 11.00 public beta 10 is out today – if you are an X-Plane 11 user, you should get an auto-update.
Linux Users: Beta 10 won’t run on Linux. Something went wrong with the build process, truncating the last 1/3 of the executable. I’ve been building X-Plane releases for over a decade now, and I have literally never seen this happen. I’ll get this fixed as soon as I can. In the meantime, you can download the correct executable here. You may need to chmod it to run it. Correct MD5 signature is 985dc19a246f303fbb0d484937cfab7c.
Update: Beta 11 is out and fixes the bad Linux version of X-Plane. If you hand-installed the fixed version, you’ll need to tell the installer to replace the previous version you downloaded.
As we get toward the end of the public beta program, one thing we’re trying to do is get our interfaces in order for creating airplanes and scenery with X-Plane. Beta 10 brings two new features for authors.
Metalness in Scenery. Finally, you can now use NORMAL_METALNESS in any art asset that uses the standard shader. That means facades, roads, forests, draped polygons, line-work, draped objects, and anything else I forgot can all mark their normal maps for the metalness work-flow and use the blue channel to specify the metal/dialectric property.
What about BLEND_GLASS? Sorry, not only is BLEND_GLASS limited to objects, but it is limited to objects that are attached to airplanes and set to glass-interior or glass-exterior lighting. Basically the airplane rendering code has a special “blending” pass that runs outside deferred rendering, only for glass, and only aircraft have access to it.
Someday we may have scenery-system access, which would let us finally solve translucency problems in control towers, etc., but until that happens, BLEND_GLASS simply won’t work in those cases. So that’s a scenery system extension for another da – it won’t be in 11.0.
One more note on the scenery system: When X-Plane 11 calculates the smaller mip-maps for a normal map, it will increase the roughness of a normal map’s alpha channel based on the bumpiness of the’s normals themselves. In other words, if you burn rivets into your normal map, it will mark those spots as rough in the reduced-res version where the normals aren’t visible.
This process runs on PNGs; you can also convert your normal map to an RGBA-format DDS and pre-build the mipmap chain yourself with DDSTool; if you do this, you can customize the roughness of the lower mips. If you find your bumpy models look “too shiny” from far away, this can help. If you find a case where X-Plane’s reduction doesn’t do a good job but your hand-built mipmap works well, please let me know!
2-D GPS Units
Public beta 10 features pre-made 2-d instruments for the X430, X530, and FMS CDU, all with the bezel and buttons attached and fully functional; simply drag them onto your 2-d panel and fly.
These new 2-d instruments exactly match the pop-up window versions of the instruments, and this gives you a way to customize the pop-up window’s appearance. Simply customize the 2-d instrument’s textures the way you would any other pre-made instrument, and the popup window will match its appearance. You can use this technique to customize the popup even if you don’t use the 2-d instrument on your panel.
We now have both 2-d and “screen-only” versions of both GPSes and the CDU. The screen-only version is meant for use in a 3-d cockpit, where panel space is only used for screens. The 2-d versions are meant for users building their own 2-d panels at home and as a way to skin the popup windows.
If you are building an advanced 2-d panel, you can either use the pre-made 2-d instruments or use the screens and build your own bezels out of generic instruments.
Plane-Maker 11.0 does not provide access to the legacy FMS and GPS – while they will work in v10 aircraft for compatibility, new aircraft must be authored with one of the new GPS or FMS choices. Our goal is to set a time-frame for deprecating the old FMS/GPS code and getting to an entirely modern GPS/FMS implementation.
Can I pop up my plugin windows? Not yet, and not for 11.0. This is a high priority for us for the next X-Plane SDK revision, but it isn’t quick to do; we need to write a bunch of new code to expose some of the new UI tricks to plugins.
While everyone looks at the new UI in awe, X-Plane 11 also had a few important changes under the hood. With Aerosoft Navdata Pro now also supporting X-Plane 11 beta, let’s talk about one of the most boring technical features of X-Plane 11: The completely redesigned database for navigational data, which makes it much easier for data providers like Aerosoft and Navigraph to supply data updates for the X-Plane navigational facilities, while preserving scenery compatibility.
The most important goal when designing the new database was to eliminate the duplication between data in X-Plane’s world and X-Plane’s navigation systems to leave less room for subtle inconsistencies. I also wanted to address compatibility of navdata updates and global scenery (mostly concerning localizers at airports). Other improvements were the integration of SBAS path points (needed for LPV approaches) and RNP service volumes. Last but not least I wanted the ability to work with ARINC424 data directly, and eliminate most of the subtle encoding differences that result from different providers generating files with slightly different converters.
Work on the new database started in April 2016, when I got in touch with FAA representatives at the FAA Aviation Safety Center at SUN ‘n FUN where the External Data Initiative (EDAi) was launched. Preliminary work was completed by end of April, and feedback was provided to the FAA at the EDAi stakeholder meeting in Washington (the whole trip was quite a memorable experience). I cannot emphasize enough how valuable the open data initiative of the FAA is – this is an example of your taxpayer money at work.
The specification of the database was finalized in September, and both Navigraph and Aerosoft were provided the tools they needed to create navdata for X-Plane 11 in the new format. Actually, we are not limited to those “big two” – as the tool is available for everyone, open-data purists can actually generate their own navdata for the US and Canada using the FAA’s file.
With the great power of the unified database comes great responsibility: The navigational data can only be as good as the world scenery it is placed in, especially the airports. Some of X-Plane’s airports in the default scenery have not kept up with the pace the real world is evolving at: runways are renamed (due to magnetic shift), extended, built or closed and X-Plane’s airport scenery is only as good as the community who cares for it. To make their life easier, we are currently working on a big automated scenery update on the server side. We will rename several thousand runways all over the world on the scenery gateway soon, and this will solve the most annoying issue people are currently facing with the new database: runways not being found because they have been renumbered.
This automatic scenery update is however only part of the solution – because we can only rename runways we have! If an airport is extended in the real world because new runways are built, we rely on the scenery gateway and its incredible community for updated airports.
I took the time to write an even more boring technical article on how everything works together in X-Plane 11: Navdata in X-Plane 11. If you are an end-user, you don’t need to bother, because here’s the TL;DR: It’s awesome. It gives you RNP approaches for airliners, and LPV approaches for GA aircraft.
Writing this article though, when I compare it to the new UI, I can’t help but feel like the poor guy in this webcomic because this is exactly how the end-user will experience the change: Most won’t even notice.
A user asked me whether we would ever have a conditional directive in the OBJ format to let an author vary the look of the object based on weather. My answer:
Definitely not – this is definitely not the intention of conditionals!
The goal of conditionals is to allow authors to cope with multiple “rendering modes” of the engine, where:
- The look of the sim is radically different between the rendering modes and
- The performance cost of working around the lower rendering mode is expensive.
So for example, when shadows are off, you have to use some ATTR state change to drop a fake shadow on an object. This kills instancing, so when shadows are on (and the sim needs more performance), leaving that double shadow is not only ugly, but slow.
The conditional works by fully “stripping” those commands for shadowing from the object, then re-analyzing it.
So the win of conditionals is that you do not pay for what you don’t use, because everything is done on load – it’s like shipping two highly optimized objects.
But the down-side is: conditionals require scenery to reload, which is slow, disruptive and annyoing. This is why we would never use them for something that is dynamically changing in the sim, like weather or time of day.
We do want to have weather effects, but our approach is going to be very different: to have a “weather map” texture on the object (same UV as the object) indicating what sections of the texture will receive changes to their material due to weather effects. This will allow the object to look progressively more wet over time without a reload as the rain falls.
I have written quite a bit on X-Plane 11’s rendering settings, but it has mostly been in the form of me being grumpy with users in the comments section. This post explains some of the thinking behind the decision, and what you can do about it if you really miss them.
Random Choices
Here’s a scenario that played out over and over and over and over during the last few years: a user with a high-end gaming machine would get X-Plane, max out all of the sliders, and find the sim ran like a slide-show. The user would then randomly reduce some of the sliders, find the sim still ran like a slide show and now also looked like hell, and would complain to tech support.
Tech support would forward me the report, and when I’d get a screenshot of the rendering settings, it was clear: the user was not getting even close to the best performance/quality trade-off possible for his hardware.
X-Plane 10’s settings were too numerous, too complicated, too esoteric, too astonishing, and way too low level. Users were setting them incorrectly, and this is entirely understandable, because you had to understand the underlying rendering engine’s implementation to set them correctly.
(If you’re going “I understand that some things affect CPU and some affect GPU”, then you’re one of a very small number of users who pays a lot of attention to this blog and the comments – you’re not normal! And you might still not know all of the weird fine print; the CPU-GPU divide is just never that clean.
No Wrong Answers
For a rendering setting to make sense, I think we can establish a few requirements that it must meet:
- No wrong answers. We don’t want there to exist any set of rendering settings that a user can pick where the sim is being inefficient in its trade-off of quality and performance. We can have settings that optimize for quality rendering and settings that optimize for framerate, but we should avoid settings that optimize nothing.
- Understandable. The rendering setting should control something that makes sense to the user. “Draw trees” is understandable – users know what trees are. This means the settings need to either control reasonably obvious things, or control settings that are industry standard. (E.g. not everyone knows what full screen anti-aliasing is, but virtually every 3-d game has this setting, so we consider it “standard”.)
- Not Astonishing. The setting needs to actually control what it says it will control. The “airport detail” setting in X-Plane 10 was a really terrible setting, because it did control slight improvement in the curvature of taxi lines, but did not actually affect the 3-d stuff at an airport. An airport detail setting that does not control airport detail…astonishing!
- Not Buried. We need to have few enough settings that users can find the ones they care about, and they aren’t lost in a sea of noise.
These rules place some limits on the kinds of things we can have as settings. We can’t have settings where picking the wrong answer will break the sim. We can’t have settings that are so low level that users won’t know how to set them. (The sim has a setting for how many shadow map cascades have 3-d objects, but do you know what the right answer for that setting is?) And we can’t have settings where their operation is so counter-intuitive that they aren’t going to do what users expect.
We took the existing settings and did a mix of moving them around, grouping them, and in some cases removing them in an attempt to meet these guidelines.
But I’m A Tweeker
Some of you really love settings. Some of you might even love settings more than flying the actual sim. If you are in this bucket, the good news is: settings.txt still exists in Resources and you can still hack it up to get complete control over everything in the engine. X-Plane has always been open to tinkering, hackering and exploration, and this is not going to change. If you modify settings.txt and get better performance at better quality, please let me know – I’d be happy to incorporate your tuning into the sim itself.
But please don’t tell tech support that your machine is smoking if you hack up settings.txt. Setting.txt and the art controls are for hackers who want to poke at the machinery with a stick and see what happens. (They are also not for pay-ware add-ons to mess with because they change frequently.)
Where Did My Settings Go?
What follows is a long list of specific settings that are gone and what happened to them. I’m posting this so you can get a sense of the “why” that went into this. The very fact that this list is so long is part of why this needed fixing.
Compress Textures: This is merged with the texture slider, so that uncompressed textures is now a “super-resolution” on top of the highest compressed resolution. This prevents the previous silly combination of a low texture resolution without compression. In any case where we can pick compressing vs shrinking the textures (each of which reduces textures size), compression is the better choice.
Gamma Control: The sim now runs in the sRGB color space, and gama “correction” of DDS compressed textures looks like absolute hell. If you’re a hacker and really want to mess with this, there are exposure art controls; my view is that it’s up to our art team to make the sim the right brightness. But hacking the color space makes absolutely no sense in an app that’s designed to run in a linear color space.
Draw View Indicator: always on – it’s for 2-d views only, so I’m not sure how much anyone cares; we may end up nuking the entire feature.
Dim Under Hypoxia/G-Load: always on.
Draw Hi-Res Planet Textures: always on; the scenery looks like a disaster without it – there’s no reason to be turning this off given X-Plane’s system requirements.
Runways Follow Contours: this is now always on; individual airports can be marked for flattening on a per-airport basis. This means authors can control how their scenery is viewed and users don’t have to toggle the setting mid-flight.
(This is one rendering setting that we may have to put back. While I am concerned that putting it back will slow the adoption of flattening control in the scenery community, there are some use cases that can’t live without it.)
Draw Forest Fires and Balloons: Off – we’ll turn it back on when we can get the balloons to only draw in appropriate locations, then always leave them on (in those locations and at the right weather).
Draw Birds and Deer: Always on. Deer are restricted by airport size; we do have an open bug to make sure that these animals always honor the sim’s overall reliability and failure settings, e.g. you’ll get hit by birds if you command a bird strike failure or if you allow the X-Plane world to throw curve-balls at you.
Draw Aircraft Carriers and Frigates: Always on – there isn’t a good reason to have them be off.
Draw Aurora Borealis: Always off. If we develop a modern renedering of the aurora at appropriate latitudes, we’ll have it be always on in the appropriate places.
Side note: one thing you might notice here is that a lot of these settings let you turn off and on “cute tricks” that would then draw everywhere without context. My view is that these things need to draw in the right locations only and then they can always be on.
Tree Density/Object Density/Road Density/Number of Cars: this has been consolidated down into a single “number of world objects” 3-d slider. The idea is to balance all 3-d so that CPU time is spent efficiently and the rendering looks plausible. We have some future work to do to make low-setting autogen and roads look better; we can be smarter about how we simplify the scenery, and that smarter simplification is not going to fit into nice buckets like “draw park benches” or “draw median strips”.
World Level of Detail: this was merged into the single 3-d slider. This one was a tough call, but in the end, I think that the use cases that people wanted for keeping this slider were almost entirely work-arounds for inefficient management of LOD in the sim itself. This will have to wait for a patch, but I think we can be a lot smarter about our draw distances and that will result in a better sim. Again, the smarter, better managed LOD isn’t going to be a single-dimension slider.
Runway and Taxiway Smoothness and Lighting: the lowest setting is gone; you always get 3-d light fixtures at airports. The “smoothness” code didn’t do much; you get slightly higher smoothing at the top 3-d setting. This slider didn’t do much and users tended to max it out for very little benefit.
Requiring 3-d light fixtures is an example of something that has happened a lot in v11; we’ve dropped the very-low-end rendering configuration from v10 that existed to support only the worst of the worst hardware – that hardware is now below system requirements. If you can run v11, you can handle 3-d light fixtures, and they’re really not expensive.
Shadow Detail – this was split: the detail of 3-d shadows is in the visual effects slider, and whether shadows draw on scenerty is a single check-box, exposing the one “trick” that was really useful: turn off scenery shadows, keep the airplane, and get a ton of fps back. The old overaly/static shadows (which just drew a quad with a dark shape of an airplane on the ground) are gone because it’s not 1995. The shadow resolution is often pixelated in v11; this is an open bug, not something that should be in a slider.
3-D Bump Maps/Gritty Detail Textures: these are now part of the visual effects setting; turning them off is a huge loss in quality and was only meant for the worst of the low-end hardware, so you get these unless you go to “minimal” GPU.
Draw Volumetric Fog: this is always on – even Intel GPUs can handle this and it’s a necessary part of the v11 rendering engine.
Draw Per Pixel Lighting: this is always on. It’s not 1995.
HDR Rendering: this is part of the visual effects slider – the idea here is a single slider that manages everything on the GPU; again, the goal is efficiency at all levels.
Atmospheric Scattering: this is always on, even for non-HDR rendering!
For volumetric fog, atmopsheric scattering and the new PBR lighting, these effects are all on al the time, giving authors a consistent single lighting model to target when authoring. We get our low-end fps by providing low-cost/lower quality versions of them.
Anisotropic Filtering: always at the default 4x. 16x isn’t a huge help, and 4x isn’t that expensive. If you want more control, your driver control panel will override us.
DSF Extended Scenery: always on, now that we’re always 64-bit.
Cloud Detail: this is supposed to be tied to the visual effects slider, so that we don’t roast your GPU with clouds if you turn this down. This is definitely broken in the public betas, but will be fixed before we go final; tuning this is waiting on me fixing cloud performance overall. When done, the visual effects slider will be able to modulate a whole pile of stuff to ramp or down the load on your GPU.
