In X-Plane 11, the new lighting and material model, which uses Physically Based Rendering, is always on. Even at the lowest settings!
In X-Plane 9, 10 and 11, we have introduced major changes to the lighting model at new versions, so we could have a reasonably stable lighting environment for the life of the product. Each time we introduce these new features, we need to decide if they are always on or optional.
My preference is “always on” when possible; having these kinds of big features be optional makes life difficult for authors, who can’t be sure how their content will look in the simulator.
When we introduced HDR with global night lighting in X-Plane 10, it was (and still is) an optional feature. This is because deferred rendering mode uses a lot of GPU memory bandwidth, and many Intel GPUs simply can’t handle this rendering load. Because Intel GPUs represent a non-trivial percent of our install base, we can’t make features that don’t run on Intel hardware mandatory. Thus HDR remains optional. (We checked this in X-Plane 11 and we still can’t make HDR mandatory. Maybe in X-Plane 12. 🙂
The new lighting model ties three features together: (improved) volumetric fog, atmospheric scattering, and physically based lighting equations with the new material model. These features are always on in X-Plane 11, and this makes life easier for our artists; the lighting environment is always the same no matter what the settings.*
With physically based rendering, we support lower end systems by reducing the quality of the effects, rather than by removing the effect entirely. Most of the cost of PBR is in calculating the processed reflection textures to make PBR work. At low settings we can reduce the texture resolution and remove detail.
This tuning is still in progress; testers who were in our private beta program know this because they saw significantly worse framerate in beta 1 than in the public beta. A lot of this performance tuning is finding ways to make the lower end settings do less work than the high-end settings.
I’ll post more next week on how to use the new PBR rendering, but for now this is posted and a good start.
* It makes life easier for me too by greatly reducing the number of combinations to debug.
I have seen this in the forums:
Tried X-Plane 11, ____ was wrong with it. Reinstalled and it [did/did not] fix it
You almost never need to reinstall X-Plane to fix these kinds of things. In particular, if you haven’t installed an add-on, you definitely never need to reinstall.
To get X-Plane back to its clean state, you can do this:
- Run the updater. If you’ve modified a file by accident it will ask if you want to replace it. Say yes.
- Delete all of the files in Output/preferences.
That’s all you have to do. Our installer just dumps files on your disk. It doesn’t set any registry settings or other hidden voodoo that can only be fixed by reinstall. So you can just clean out your prefs, make sure the files are up to date and not modified, and you’re good to go.
In particular, in beta 1, if something is messed up, reinstalling isn’t going to fix it; beta 2 is going to fix it! (Or maybe beta 3. 😉
(I think everyone reading this blog knows this, but you also don’t have to reinstall to get another 15 minute demo.)
Today X-plane 11 went public beta! Here’s what that means:
- Anyone can get a beta copy of X-Plane 11. You don’t have to be in our private beta program, you don’t have to have a special beta key, you don’t have to sign an NDA. If you want to try the public beta, go ahead.
- Users who pre-purchased X-Plane 11 can use the full simulator; users who did not can use the demo.
- X-Plane 11 is still quite full of bugs. That’s why it is labeled as a public beta and why the release notes list a number of known open bugs.
So at this point we are in a situation that is not that different from a regular public beta. If you want to try the new stuff, you can do so, but if you want to get flying, you may need to wait for a later beta. Bug reports can be filed in the bug report form,
I’ll post more in the next few days, but for now if you email and don’t hear much back, please bear with us – a major release is like a flood, and everyone’s in-box is buried right now.
Starting with X-Plane 11, all aircraft must be installed in a folder within “Aircraft”.* We’re taking this opportunity to normalize where Aircraft are installed (all other files have to go in ‘the right’ folder, e.g. Weapons, Airfoils, Custom Scenery, etc.). This will let us search a much smaller footprint of files to find installed aircraft, which speeds up the UI.
Our aircraft are in a folder called “Laminar Research” within Aircraft; my suggestion is that vendors (and a lot of you are already doing this) have your own folder in Aircraft where aircraft go.
The goal is to have a file structure where it is not necessary to reorganize where files live or deconflict, so that automatic updaters (ours and third parties) can find the files they installed. The old folders-with-categories-of-aircraft are now gone.
You can make any set of folders within Aircraft you want, and when you search in the UI, you can search by folder names. But we also provide a bunch of other ways to find aircraft, e.g. type, studio, number of engines, or file name search.
*If you thought X-Plane already required it, well…nope – X-Plane 10 will load an aircraft anywhere in the X-Plane folder. This is only true for Aircraft – everything else has to go in the right bucket.
There’s an old joke in finance: if you owe the bank $100, you have a problem. If you owe the bank $100,000,000, the bank has a problem.
This holds true for X-Plane add-ons: if one-add on has a problem, it is the add-on maker’s problem if the add-on stops working. But if every add-on has a problem, we have to change X-Plane to solve the problem. This is what happened with SASL/Gizmo and the 64-bit move: we built 64-bit Lua support directly into X-Plane so that LuaJIT (which is used in most major aircraft add-ons for X-Plane) would keep working.*
This brings me to what might be my least favorite dataref ever: sim/weapons/x (and friends).
The sim/weapons datarefs gave you access to various flight-model data of 25 weapons attached to the user’s plane in X-Plane. The array dim doesn’t make a ton of sense – the last entry is an unused dummy slot for Plane-Maker editing and should never have been exposed.
What if there are no weapons on the aircraft? It turns out that variable behind the dataref would sit there and do nothing, so authors used these as “scratch pad” datarefs to implement cockpit tricks on aircraft that didn’t use weapons.
“Gave”? Yes, the past tense is intentional – virtually all of these datarefs are gone in X-Plane 11.
Now if reading this has caused you to hyperventilate, stop and read the dumb joke at the top of this post again. If you were the only add-on maker who abused the weapon location datarefs for misc cockpit data, I’d tell you that you did a dumb thing and you should go fix your add-on.
But as it turns out, many add-on makers all did the same thing, so in X-Plane 11, the location datarefs point to dummy variables that continue to provide the same behavior for aircraft with no weapons. So add-ons using weapons for scratch-pads can keep doing this for a bit.
What Happened to Weapons
For X-Plane 11 we have a fairly major internal revision of the weapon system, a hybrid** of the X-Plane 10 desktop and X-Plane 10 mobile weapon systems. The internal changes were significant enough that the old datarefs do not work and would need to be completely re-engineered in a backward compatibility layer.
What We Need To Know
If your add-on uses weapon datarefs other than X, Y, Z as scratch pads, please email me a list of the other sim/weapons datarefs you do use, so we can increase the amount of scratch-pad stuff.
If your add-on uses the weapon datarefs for some actual intended purpose, please email me and let me know what you were doing. Providing dataref backward compatibility isn’t out of the question, but it’s not something we want to do unless there is a real demand for it. The old weapon datarefs were part of Sandy and me just dumping everything into datarefs, so my guess is that a lot of the data in there is of no use to anybody.
Don’t Abuse Datarefs
I’ve said this before and I’ll say it again: do not abuse datarefs. If something appears to be unused, that does not mean “dump random data into it.” Use a dataref for its intended purpose only, and write values that make sense given its docs. If the docs don’t say what the dataref is for, back away slowly.
What if you need more dataref storage? For X-Plane 11, my recommendation is XLua.*** X-Lua is an extremely simple, portable, light-weight plugin to run Lua scripts that lets you create new datarefs and commands, and interact with the sim. Our art team uses it to do animation behaviors in the cockpit that are too weird to put into X-Plane itself. Once X-Plane 11 is out we’ll make an official binary distribution of XLua in case people want to use it.
* This isn’t a perfect example because we also had to do this work ourselves because 64-bit LuaJIT support can only be implemented in the host app, not plugins.
** This hybrid still has some rough edges from fusing the two systems together, and is not always described charitably within the company. You can think of it as one of those alien-human hybrids from X-Files.
*** Why XLua and not Gizmo or SASL? If you were using Gizmo or SASL you wouldn’t be saying “but I need more dataref storage”, you would have already made your own. So XLua addresses the authors who don’t need/want these heavier, more complex plugins that are aimed at larger scale add-ons.
We posted the system requirements for X-Plane 11 today. Here’re a few notes on the requirements for X-Plane 11.
64-Bit Only
This should be a surprise to no one: X-Plane 11 will be 64-bit only. Add-ons have already gone 64-bit only, over 90% of our user base is already running 64-bit operating systems, and we need 64-bit to be able to utilize the RAM that we need and everyone already has.
Windows: No More XP or Vista
For Windows, we are dropping XP and Vista support and requiring Windows 7 or newer. XP has been end-of-lifed by Microsoft for a while and is therefore not safe to use (due to a lack of security updates).
OS X: Yosemite and Newer
For OS X, we are dropping a number of OS X versions and requiring Yosemite (10.10) or higher. Apple has increased the tempo for OS releases in the last few years, and they don’t provide new drivers to old operating systems, so we are pre-emptively cutting down the set of supported operating systems to cut down the number of different 3-d drivers we have to test.
Linux: Proprietary Drivers Required
On Linux, we will continue to support only the proprietary 3-d drivers from AMD and NVidia; these drivers use the same OpenGL stack, so they let us support Linux without the cost of additional 3-d driver testing. We don’t officially support the Mesa/Gallium stack for Intel GPUs, but X-Plane Linux users have done a bunch of work to make this unofficially work, and we do our best to not undo their work.
Graphics Cards
We’re setting the minimum graphics card at the AMD HD 5000-series line for the red team and the GeForce 400-series for the green team. This ensures that we only support cards with reasonably current drivers, DX11-class capabilities, etc. For Intel, you’ll need at least an HD2000 series or newer; figuring out your Intel motherboard graphics is really tricky because their numbering scheme is crazy, but if you don’t have at least some kind of “HD” graphics, you definitely can’t run.
We recommend a newer graphics card, e.g. at least from the DX12 or newer generations. When it comes to graphics, basically more is more, so whether you need a Titan or Fury or similarly monstrous card depends on things like how big your monitor is.
CPU
CPU requirements are the messiest part of the spec and the source of most of our internal discussion. Simply put, there really aren’t good ways for us to simply state what CPU is going to work well or not with X-Plane. X-Plane itself has a huge range of CPU uses based on configuration, and CPUs have a huge range of actual performance that can be hard to predict from some of the simple headline numbers. Clock rate is absolutely not indicative of performance, nor is core count.
A recommended system is pretty simple: we recommend the Intel i5 6600K, which is the current top-speed gamer targeted i5. You can go lower or older and lose significant performance, or you can go faster and really start to pay a lot more money. If you want to invest in 8 Xeon cores, it may help… but we aren’t going to go tell you to spend that kind of money for a little more performance.
Practical Recommendations
Here are my practical recommendations for X-Plane 11:
- If your machine is just barely getting by with X-Plane 10 at the lowest settings, and those hardware requirements seem high because your machine was built several years ago, you may need to upgrade for X-Plane 11. In this case, it could be a good time to upgrade OS and multiple components.
- If your machine runs X-Plane 10 well, it will almost certainly run X-Plane 11 in some form, with the exception of the very oldest graphics cards. (If you have one of those, I would say your definition for ‘run well’ is a lot lower than mine is.)
- If you need to purchase new hardware, I strongly recommend running X-Plane 11 on your existing hardware first and examining performance of the demo (when available) to see where you’ll need to upgrade.
Real hardware performance is hugely varied by what you are doing and your particular system components, so trying the demo will tell you more than we can hope to figure out from specs.
Now that we have announced X-Plane 11, I can finally post goofy screenshots and videos from v11 development. Sometimes a bug makes delightfully goofy results, and Austin liked this one so much he wanted me to share it.
I am working on 3-d water for X-Plane 11 – we have a working prototype, but I am not sure if this will make the shipping 11.0 product; it still has a lot of bugs and rough edges.
Traditionally in X-Plane if you don’t have terrain installed, you just get water. This isn’t really an intentional design decision; we just defined “no DSF” as “all water” so that we could avoid shipping DSFs for the huge chunk of the Earth’s surface that is covered with ocean.
But we always have airport data, so in X-Plane you would get an airport floating in the middle of the water! While this was completely goofy and is a huge source of tech support calls (which is why X-Plane 10.50 now offers to install scenery whenever you hit this case) you could, if you really wanted to, land at this water-world airport.
Until now. Now that the water is 3-d, the peaks of the waves actually cover the 3-d buildings and make the entire airport as usable as…well, as it really would be if built in the middle of the ocean.
(This is about the point in the post where I would insert a snarky climate change comment, but I’ll let XKCD do the talking.)
Scenery developers might wonder: why is it that when the water level falls the runway lights and signs are revealed – but where is the pavement? The answer is in the comments.
The second release candidate of X-Plane 10.51 is up – I’m hoping this will be our final X-Plane 10.51. build. If you are having problems with 10.50, please use the installer with “gea betas” to get 10.51, then report a bug if you still have problems.
WED 1.5.1 is now out – this is a quick bug fix patch to 1.5. Besides fixing a bug where the downloadable preview packs from the gateway were missing static aircraft info, there’s a nice usability enhancement:
When a polygon fails validation due to a zero length side (two adjacent nodes on top of each other) the validation command selects the second vertex in each pair. Just hit the delete key once and your polygon is fixed! (Thanks to Michael for submitting the patch to this.)
We already have some working WED code to support X-Plane 11’s dynamic ground vehicles; Ted is working on it and we’ll get it moved to the public servers at some point. I am aiming to have WED in public beta condition by the time X-Plane 11 ships.
WorldEditor 1.5 release candidate three is now the official WED build; you will need to use it to upload to the gateway, and you can now upload WED 1.5 projects to the gateway.
WorldEditor 1.5 supports the new static parking and ATC features of X-Plane 10.50, and adds a visual taxi sign editor. WED can be downloaded here and has full release notes with the app.
