X-Plane 10.36 has a button in the rendering settings screen labeled “set all rendering options for maximum speed”. Our recommendation for tuning your X-Plane settings has been to start low and build your way up, so that you don’t end up with one setting “hanging” the system at a low framerate (which stops you from seeing the affect of other changes).
This button was a good idea in principle, but in practice it had a few problems:
The lowest settings are really just astonishingly ugly.
Some of the settings that get turned off are nearly free, so pressing the button hurts graphics quality unnecessarily.
Once you minimize your setting, what do you turn up? I’ve seen too many forum posts where users have picked a few random expensive settings and complained about a poor trade-off (e.g. poor performance for the hardware and quality).
So in X-Plane 10.40 we’ve replaced this single button with five pre-made presets: minimum, low, medium, high, and extreme. Each preset is hand-built to try to make good settings trade-offs; instead of having to fish for better visual quality after minimizing, you can simply try 2 or 3 presets, based on your hardware. If you have a very new system, try “high” and “extreme”. If your system is really old, try “low” and then go on to “minimum” or “medium.”
The settings aren’t coded into X-Plane; they come from a config file, and this is important for the process of tuning the presets. The truth is: the presets as picked in beta one are probably not that great. I did run them on my machines, but with only a few computers, it’s hard to know what a good setting is for most users.
In X-Plane 10.40, it will be possible to run the framerate using one of the rendering setting presets instead of one of the fps-test numbers. This will let us get direct, controlled measurement of the performance of specific presets on real machines. My hope is that by collecting this data and tuning the presets up and down, we’ll be able to dial in good compromises in terms of speed and quality.
I’ll post details on how to use the fps test once 10.40 goes live, so that we can start collecting data.
In the long term, the rendering settings need a lot more than just presets; they need a massive simplification. But within the scope of X-Plane 10.40, the presets will hopefully provide a better user experience, less time spent tuning X-Plane, and be a good stepping stone toward a better UI.
Finally, for advanced users who like to tweak things: it will be possible to edit settings.txt and change the presets. I see this in the forums a lot:
User 1: I have an Intel i7 clocked at 1675 ghz and I’m getting 10 fps. What’s wrong with X-Plane?
User 2: that’s weird – I have an Intel i5 clocked at only 900 ghz and I’m getting 350 fps!
With the presets, user 2 can build his settings into a preset and send the file to user 1, who can then try those exact settings and see how performance runs. Both users could also run our presets in the fps test and see if the performance problem is due to different hardware, different rendering settings, or different add-ons.
One new addition to Version 10.40 is almost guaranteed to be controversial: at the user’s discretion, we now collect anonymous usage information.
Before you light your torch and grab your pitchfork, let me explain why we have not become the next Spyware Kings.
Whose information are we collecting?
The X-Plane 10.40 installer has a screen to explain the data collection, and a checkbox to opt-out. If X-Plane is already installed, you can toggle data collection on or off using the Operations & Warnings window in 10.40 and later.
We will only collect usage information from users who have that checkbox enabled. If you upgraded to v10.40 from an older version of X-Plane, for instance, the checkbox in the Operations & Warnings window is disabled by default.
(But, read on to find out why you should go turn it on!)
What does “anonymous usage information” mean?
In our case, we collect two main types of information:
system configuration (including your operating system, CPU model, graphics card model, amount of RAM, what language you’ve selected, and so on)
X-Plane usage (including which aircraft are flown, which airport you start at, and so on)
This information is 100% anonymous. Essentially, all we ever learn is that some user, somewhere was running Windows with a Core i7 CPU, 8 GB of RAM, etc. and they flew the C172 from KBFI. We cannot trace this information back to a specific person.
Will I be contacted or be spammed if I participate?
No.
Since everything we collect is anonymous, it obviously does not include contact information like your name or email address. We can never use the information collected to contact you in any way: no marketing, no spam, no way to bug you.
Why does X-Plane want this information?
In essence, your usage data helps us make better decisions about the future of X-Plane.
For instance, if we found that 50% of users were running 10 year old machines, we would need to think long and hard about increasing the system requirements in future versions.
Similarly, if we found that only 10 people ever flew a particular aircraft, we could conclude that users weren’t very interested in it, so we probably shouldn’t create a new aircraft that was very similar. Likewise, if 25% of flights involved the 747, we might decide that people really like big airliners, so we should probably create another.
This is roughly a billion times better than the way we currently make decisions about this type of thing (both in terms of hardware support and sim features). The current model looks like this:
Make a guess about what users want
Argue with the other developers who guessed differently
Ship something that users may or may not actually like
I can’t stress how much having actual data will improve our ability to make X-Plane the product that users really want.
Why you should participate
Sending this anonymous usage information is like casting a vote—in this case, a vote for us to support the way you use X-Plane. When you send your usage information, you cast your vote for us to support your hardware configuration, to build more of the planes you like to fly, or to improve the airports that you like to fly at.
Just like in electoral politics, you have every right to abstain. But abstaining means we’ll hear other people’s voices and not your own.
If you’d like to participate, you just need to do the following:
Get the 10.40 update and launch X-Plane
Open the Operations & Warnings dialog
Check the box labeled “Send anonymous usage information to help make X-Plane better.”
One of the new things in X-Plane 10.40: more modern OpenGL code. I mention this because that new code will probably create chaos during the early betas; we’ll get the bugs fixed as quick as we can.
The problem is that OpenGL can be an exercise in “code it once, debug it everywhere”, and while I have tried to set myself up with a wide range of hardware, I don’t have one of every combination of drivers and GPUs that X-Plane runs on.
X-Plane 10.40 will be a longer beta, like 10.30 was, so we should have enough time to work out the kinks in the new code. Having to do this kind of debugging during beta is annoying for everyone, but it’s also necessary to advance the sim forward.
When 10.40 comes out, if the beta doesn’t run on your hardware, please do report a bug; often users assume that if they see the bug then everyone does, so someone else will report it. Not only is this often wrong (because everyone assumes someone else will report a bug), but it might be that your combination of hardware and drivers is the only one that shows the bug!
Update: yesterday at the 2015 WWDC Keynote, Apple announced that they were porting Metal, their Apple-specific low level high performance 3-d API, from iOS to OS X. I will comment on this next week, after the WWDC sessions on the desktop version of Metal are available on the web. In the meantime, don’t panic – this definitely isn’t the end of the Mac, Windows, X-Plane, or the universe.
Next week is FlightSimCon 2015 in Hartford, CT, and it looks like a bunch of us will be there. Austin is speaking on Sunday, and I think Chris, Philipp, Marty and I will be there too. So if you are attending, come say hi – we’ll be at Austin’s talk and if there’s a cocktail party, we’ll be there too!
(Chris is a total hermit and prefers to communicate with us via a series of grunts, but since it’s face to face, he’ll have no choice but to acknowledge you with at least shifty eye contact! 🙂
I’ve been meaning for weeks now to write up some notes about 10.40. I’ve also been trying to put the hood back on 10.40 so we can get it to public beta; instead the last few weeks have been a flying circus of driver bugs, expiring certificates, etc.
But we are making progress, so I’ll start off in this post by describing a change in how DSFs are loaded and the wide DSF box.
A Tangent: Stuttering and Pauses
A post that involves X-Plane pausing during flight is going to invariably bring up a bunch of blog comments: “X-Plane stutters while I fly on my really expensive machine!” This is not good, and from what I’ve been hearing, it sounds like something got worse recently; this is something that we are investigating now.
But I also want to mention that historically, X-Plane has never been “no-pause”. What we have done is periodically made the pauses much shorter; our goal is to get down to zero pauses, ever, but this will happen by finding every source of pausing and fixing them one at a time. In other words, we’re in the middle of a process of improving smoothness, but even if one source of pausing is fixed, another source might still be causing problems.
DSF Loading: the Old Way
X-Plane has, since X-Plane 9, loaded DSFs in the background on a second core while you fly. This cuts down the amount of time it takes to change scenery. (Older versions of X-Plane would pause while scenery was loaded and shifted.)
The old DSF loader did have a few weaknesses though:
The sim pauses while DSFs are deleted. As DSFs become bigger, this pause is becoming more noticeable.
If the loader ever gets behind by two scenery shifts, it just waits until it catches up. This is where the dreaded “Async load timed out after 30 seconds” comes in – it indicates that the DSF loader was so far behind that it locked up for half a minute and didn’t catch up.
The old DSF loader loads one DSF at a time, tops.
DSF Loading the New Way
X-Plane 10.40 has the new DSF loader, which both loads and unloads DSFs on worker threads to keep flight smoother. It also will load more than one DSF at a time, limited only by the requirement that adjacent DSFs not be loaded at the same time.
X-Plane 10.40 also has the option of an extended DSF scenery region for sharper terrain; with this option off, two DSFs are loaded at one time during sim boot and one or two are loaded at a time while you fly. With the extended DSF region on, up to four DSFs are loaded at once during sim boot and one or two are loaded while you fly.
The extended DSF scenery region is optional; don’t use this if you’re using HD meshes or you’re short on RAM. The new DSF loader is always on.
Update: WorldEditor 1.3.2 is out now and has new certificates to work with the gateway; get it here!
I screwed up: WorldEditor 1.3.1 contains a certificate that allows it to authenticate that the X-Plane Scenery Gateway is who it says it is before WED transmits your user name and password during an airport upload. And this certificate expires in about two hours.
Last night we cut a new build (1.3.2) with a new certificate with a much longer time range, but Tyler said that for some reason the new certificate did not work. So it’s most likely that we’re going to run out of time before we get a new WED build posted. Here’s what this means:
You will not be able to upload airports to the gateway with WED 1.3.1.
Once WED 1.3.2 is available, you will be able to upload airports using WED 1.3.2.
Every other function of WED will keep working.
The Gateway’s public web page will keep working.
I’ll post an update here when we can get WED 1.3.2 “live” – unfortunately it will probably be more than two hours. I’m hoping to have this solved by the end of the day.
I will also cut a new WED 1.4.0 beta with the latest bug fixes and an updated certificate. That should be available tonight.
As a side note, I think that everything that is “must fix” for WED 1.4 is fixed, so this will be a WED 1.4 release candidate. We are deferring jpeg-2000 support out of WED 1.4 entirely so we can ship it.
TL;DR: 10.36 works around the latest NVidia driver – let X-Plane auto-update and everything will just work the way it should.
X-Plane 10.36 is out now – it’s a quick patch of X-Plane 10.35 that works around what I believe to be a driver bug* in the new NVidia GeForce 352.86 drivers.
10.36 has been posted using our regular update process and has been pushed to Steam, so if you’re running 10.35, you’ll be prompted to update. The update is very small – about 10-12 MB of download.
With this patch, you can now run the latest NVidia drivers. I have no idea if those drivers are good (I have anecdotal reports that they’re both better and worse than the last drivers, but these kinds of reports often have a large ‘noise’ factor**).
We patched X-Plane because we can cut an X-Plane patch faster than NVidia can re-issue the driver, and the driver issue was causing X-Plane to not start at all for any users, which was turning into a customer support mess. Past NVidia-specific patches have been to fix bugs in X-Plane, but in this case, we’re simply avoiding a pot-hole. I hope that NVidia will get their driver fixed relatively soon so that people installing from DVDs with older versions of the sim won’t be stuck.
Update: NVidia fixed this bug in the new 353.06 drivers!
[OpenGL, Windows 8.1 -x86/x64]: GLSL shader compile error. [1647324]
* The bug is that #defines defined within a function body don’t macro-substitute, but #defines outside a function body too. The work-around is to move some #defines out of function bodies. If anyone can find a reason why #defines can’t be in function bodies, please shout at me, but it’s a pre-processor.
** We’ve had reports of huge fps improvements and losses on beta updates where we’ve made only cosmetic changes to the sim.
Note: this issue has been resolved – please see here!
I’ve received a few bug reports about this today: NVidia’s new 352.86 WHQL drivers for Windows do not work with X-Plane 10. I’m contacting Nvidia now to figure out what has happened.
In the meantime, to fly X-Plane, use the previous 340.52 WHQL driver.
I’ll post more when I learn more; we’ll resolve this with either a driver update or an X-Plane update, based on what has actually gone wrong and which can happen first.
Update: NVidia was able to suggest a work-around in our shaders that avoids what I think is a driver bug. Since we can cut an X-Plane build faster than NVidia can re-release their drivers, I have cut X-Plane 10.36 rc1.
You can get 10.36 rc1 by running the updater and checking “get new betas”; the updater will run even with the newest NVidia drivers.
10.36 rc1 is identical to 10.35 except for version number and a single shader change, but it’s also highly untested; I wanted to get it posted ASAP to accelerate the process. So please give it a try and file a bug if it doesn’t work like 10.35 (but working with the new NVidia drivers.)
Update 2: Sigh…this is what happens when I try to rush out a patch. The 10.36 patch’s free space calculation is totally borked. This will be fixed some time today. (This will be the third time I cut a patch.)
Update 3: the meta-data on the 10.36 rc1 patch is fixed – if you haven’t installed it yet, try again; you’ll need 30-40 MB of disk space, not 30-40 GB. 🙂
Update 4: Steam users – 10.36 will be available for Steam in a day or two; until then, please run older, functioning drivers.
Tyler is migrating the website to new hosting, and so the old server has decided to flip us one last middle finger. Needless to say, if you’re seeing this page, you probably waited for 30 seconds to get it. 🙁
I have WED 1.4b2 ready, as well as a cut of the command line scenery tools pack and MeshTool; I will post all of them once the server is migrated. Not a lot of good posting the files if you can’t download them.
Hopefully the website will be full speed again early next week, if not sooner.
UPDATE: Tyler says the site migration is finished. If you’re still having problems accessing X-Plane.com, demo downloaders, or sim updates, give him a shout at tyler@x-plane.com.
X-Plane 10.40 will have an option to load a larger local region of DSF scenery. For as long as I have been involved in X-Plane (back to X-Plane 6 as a user) the local scenery region was 3×2 tiles (each 1×1 degree in latitude and longitude). With this option, the region is 4×3.
What this gets us is the option for a longer viewing distance before we have to transition from the higher detail DSF scenery tiles to the lower resolution whole-planet render. In X-plane 10 the planet render actually has shape, but the resolution is low; if you see it up close, it does not look good.
Some fine print:
You will only be able to use this option in the 64-bit build of X-Plane. The 32-bit version does not have enough memory.
Combining extended DSFs with heavy third party scenery may be unacceptably slow. For example, Alpilotx was able to run extended DSFs with the HD meshes, but his computer has monstrous amounts of RAM (64 GB I think??). I’m pretty sure extending with the UHD meshes is a non-starter.
Load time shouldn’t be too bad; this change also includes a re-work of the DSF loader that takes better advantage of multi-core hardware. If you have a 4-core machine your DSF load time shouldn’t be worse, even with extended DSFs.
Here are two sets of pictures taken over the demo area at extreme res on my PC; this shows the interaction between atmospheric scattering and loading more DSFs. The camera is at about 30k feet.
Normal DSFs, no scattering
Normal DSFs, with scattering
Extended DSFs, no scattering
Extended DSFs with scattering
The combination of pushing the transition to the planet “out” away from us and using scattering to remove color detail starts to get something that looks more like the real world.
Note that to get the match-up in the lower right, you must have Earth Orbit textures (which come with any full install) and you must be in extreme res or the planet starts to get fuzzier.
Here’s another set.
Normal DSFs, No Scattering
Normal DSFs, Scattering
Extended DSFs, No Scattering
Extended DSFs, Scattering
In the long long term, I expect the planet to improve in render quality (with at least a 2x boost in image quality, and perhaps better than that in mesh shape), and I expect scattering and other lighting to improve in quality.
I do not expect to further extend the DSF box beyond 4×3; I think that the planet can improve to further “bridge the gap.”
