OK I overhauled and upgraded the jet engine model as well.
Here is how it works: For SUBSONIC dynamics, I curve fit maximum engine thrust ratio to static max thrust as a function of density altitude, Mach number, and engine bypass ratio. This is pretty easy and boring and I have been doing this for years.
But here is where it starts to get good: As the inlet is dragged by an over-speeding airplane above it’s critical Mach number, normal shocks will now form across the inlet, DECIMATING the efficiency of the engine and robbing you of thrust.
No arbitrary losses above your critical Mach number, the normal shock, only a few atoms thick, slows all air that hits it across the space of a few atoms, dumping a huge amount of the incoming streams valuable kinetic energy and turning it instead into HEAT.. the last thing you want coming into the front of your engine.
So that is for subsonic inlets being dragged above their critical Mach number. What about supersonic inlets?
OK this gets good: As we move through Mach 1, we transition from the subsonic curve fit for subsonic engines to the pressure-recovery of the total energy of the airstream. Here is where this gets interesting: The faster you go, the higher the Mach number of air incoming to the inlet, and the more energy is available from the airstream to turn into THRUST!
So, the faster you go, the more thrust you get! This is one reason that supersonic jet airplanes just keep speeding up, and up, and up, and up!
Planes like the F-4 Phantom, for example, take about FIVE MINUTES to get from Mach 1 to Mach 2 (a long time because the thrust only builds as the speed builds) but darn they hit Mach 2 and are still slowly accelerating!
Now, nothing this good lasts forever. At some point, the aircraft speed overwhelms the inlets’ ability to accept the shockwaves, and losses occur. We simulate this with a normal shock, and the inlet efficiency gradually moves from ideal (total pressure recovery) to the worst possible (normal shock) as the inlet moves to and then past it’s maximum allowable Mach number.
Here’s the equation for the losses across the normal shock, by the way:
So, if you open the F-4 Phantom in Plane-Maker, go to the engines window, and then the Jet Curves tab on the right, you will be able to SEE EVERYTHING that I just talked about.
On the left, at Mach 0, you see the static thrust for each altitude.
Then as you move right to Mach 0.5, the thrust falls as the turbine can’t deliver much ‘oomph’ due to the rapid inflow of air… like trying to climb a rope ladder while the rope is falling, trying to get thrust from an airstream always coming at you is simply an uphill battle that does not work too well. So the thrust FALLS as you speed up.
Then, above Mach 0.5 or so, something interesting happens: the energy in the oncoming airstream becomes significant, and the inlet starts decelerating that incoming airstream, using that deceleration to INCREASE the air pressure inside the inlet, which actually helps the inlet do the job FOR the engine! Now, that thrust starts BUILDING!
Now as we move to Mach-1, it’s crazy-time. The airstream pushing at the airplane is packing HUGE energy from all that speed, and nice, efficient, oblique shocks start capturing all that energy, slowing and pressurizing that air efficiently, and handing that high-pressure to the engine. A well-designed inlet at this point might develop MORE thrust than the engine itself… the job of the engine is simply to pressurize the inlet here. And, the faster we go, the farther to the right we move on those curves, and the greater the thrust becomes as we speed up. This is a recipe for an airplane that just never seems to stop accelerating. Enter the F-4. And the SR-71.
But, at some point, the shockwaves overpower the design of the inlet, and we start heading to the (terrible) efficiency of the normal shock. Here you see the curves dropping thrust hugely, on the fast-side of the max expected Mach number for the inlet.
So, you can see the thrust curves in Plane-Maker and now know what forms them. Set the reference Mach number on the lower left for you inlet on your plane to get the thrust peak right around the top speed for your airplane.
And then finally, MAXIMUM thrust is not the only thing here: We also need thrust variation with N1, and DRAG from the engine at idle at various speeds. Those things have been tuned and tested as well.
For testing:
I have a full Citation Mustang POH with aircraft speeds and power settings, to test and tune the low subsonic flight regime for jets, and a recently de-classified F-4 Phantom Pilots Operating Handbook with subsonic and supersonic deceleration times (to tune the DRAG) and acceleration times (to tune the THRUST) to test and tune the high subsonic and supersonic flight envelopes of jet engines. All of the math above checked out very well with the POH’s for these airplanes… much of the accel/decel timing on the F-4 Phantom to within 1 second to get to and from various subsonic and supersonic speeds at full and idle thrust.
And a quick little detail: Low/high jet engine bypass types: GONE! Now we ONLY go off the bypass RATIO that you entered! This lets cool things like exhaust smokiness and engine mass for mass distribution all be floating point with bypass ratio for infinite variation, which is nice.
So, jet simulation has been improved now for V11, especially in the supersonic regime… because getting that F-4 PERFECT is just going to be soooooooo cool!
Thanks to a few hundred hours of flight experience in my Lancair Evolution so far, I am really improving the flight model in X-Plane in the area of PT-6 engines, electrical, and pressurization systems! And, while in the systems code, I’ve improved a lot of other systems simulations as well, which is always fun.
So, here is the new stuff done for 11.00 so far in the flight and systems modeling area! Read More
Chris just released X-Plane 10.4 for mobile today, and it’s got something pretty cool that we’ve been working on for a while: complete interaction with the 3-d cockpit!
I worked on the original X-Plane app for the original iPhone with Austin years ago, and when we were working on this, I kept looking at the 737 on my iPhone 6 and thinking “this doesn’t seem real”.
It’s not that the 737 doesn’t seem real – it’s that it looks too real. I didn’t think we’d see this kind of detail on a mobile device.
Over the last year we unified the flight model and physics engine of the two products, and that makes this kind of update possible; X-Plane 10 mobile has been running the full X-Plane flight model, and now that you can touch the planes, you can see that all of those systems really do work.
The title says it all: it’s too soon to update your add-on to X-Plane 11.
Here is why: if your add-on does not work with X-Plane 11, you (and we) do not know if this is because of an intentional removal of functionality (some of which has happened) or because of a bug.
If the problem is a bug and you modify your add-on to work around the bug, it’s very likely that a future public beta will simply break this new work and you would have been better off with the old functionality.
Updating to X-Plane 11 and the public beta need to follow some specific steps:
Testing and discovery. If you have an add-on, please do test it and report bugs and incompatibilities. X-Plane is incredibly complex and there are almost infinite combinations of features used in add-ons, so we can’t just look at the code and go “oh, X will work, Y will not” – sometimes we get surprised. The bug feedback we’ve gotten so far has been great.
Official Statements of Deprecation. We (LR) will provide solid guidance on things that are specifically removed and may require updates.
Updating add-ons. Once you know that an old feature is gone that you relied on, it is “safe” to invest in updating the add-on to use new tech, because you know the old feature is gone for good.
We have tried to keep good notes internally and we’ll get them posted as soon as we can. In the meantime, please hold off on reinventing parts of add-ons until it’s safe to do so.
Here is a short list of a few things that are and are not deprecated that have come up a lot with third party planes.
A few things on the “gone” list:
LIT panel backgrounds: _LIT panel backgrounds are gone in X-Plane 11. They look bad and have been obsolete since X-Plane 8. If you used the _LIT panel for 2-d lighting, make a -2 or -3 or -4 2-d overlay for lighting. If you need 3-d lighting, use 3-d cockpit lights in PlaneMaker.
3-d Panels: The panel texture, when used in a 3-d cockpit, is always built out of a day and night texture in X-Plane 11. If you used ATTR_cockpit_region or GLOBAL_cockpit_lit you were already getting this behavior in X-Plane 10. If you use GLOBAL_cockpit without ATTR_cockpit_region, your panel will be lit when it was not before.
The fix for authors is to put 3-d lights into the cockpit in Plane-Maker to cast light on the panel, and to use real instrument lighting (glass or additive/mechancial o the instruments themselves).
Gamma: X-Plane 11 does not support the old Mac 1.8 gamma from OS X 10.5.8 and 2008. If you have PNGs at 1.8 gamma you’ll need to convert them to sRGB. If you have DDS at 1.8 gamma, re-grind them with the latest X-Grinder. All authoring for X-Plane 11 (and 10) should be sRGB.
All of these removed features have had better replacements for at least five years, the replacement techniques are fully compatible with X-Plane 10 (or even 9), and produce significantly better results than the old techniques.*
Here are some things that are not supposed to be broken:
XPLMNavigation API: the XPLMNavigation API is now “powered” by the new FMS on aircraft saved in X-Plane 11’s Plane-Maker; however, our intention is full API compatibility. There are some known cases in X-Plane 11 public beta 2 where working XPLM code will fail with the new XPLM. Philipp has some fixes that should help in public beta 3 and beyond.
If we find that there are uses of the XPLM API that we cannot support, we’ll post docs in the future, but to start with we’re assuming that these are compatibility bugs.
Other Panel Stuff: other than two-texture 3-d panels and lit backgrounds, nothing else is deprecated in the panel system; transparency in panels was fixed in public beta 2. If you use ATTR_cockpit_region or GLOBAL_cockpit_lit in X-Plane 10 with no _LIT panel background, you should see identical results in X-Plane 11; if you don’t, please report a bug.
If you are looking at upgrading your add-on now, hopefully this list gives you some guidance as to where to spend time vs. where to wait.
Finally, the dataref list that ships with X-Plane 11 public betas reflects the included beta list. If a dataref has been removed and your add-on depends on it, please file a bug and try to describe what problem you were trying to solve with that dataref. We may be able to restore it or provide a reasonable work-around.
* One of my concerns about the public beta has been the number of aircraft I have seen that were developed or updated in the last year or two and yet use authoring techniques that were in the “obsolete but supported” bucket for X-Plane 10. The window of compatibility where we provide support for old and new features doesn’t help if people don’t migrate.
X-Plane 11.00 public beta 2 is out. Full release notes are here – please do read them to see what is changed. For beta 2, the team closed 39 bugs (plus however many we fixed but screwed up the fix version or fixed but were never in the database), so we’ve tried to keep detailed notes but a lot changed.
As always, please report bugs to the bug reporter – this gets your report into the official triage process.
Please do not report bugs in the comment section – No one spends any time trying to gather bug reports from the comment section.
First, thanks to everyone who has filed bug reports for the first X-Plane 11 public beta. One of the reasons to have a public beta is to get information about bugs that we don’t see “in-house” (e.g. literally in-house since everyone at Laminar Research works at home). We’re still a small company with a limited number of total computers, so feedback from the field is critical to us.
This post will list the status of a few of the more common issues that we have seen reported in the public beta that will be addressed in beta 2, which should be out next week.
Installing More Scenery: the X-Plane 11 installer had a bug that would cause it to hang when adding and removing scenery; this is now fixed! Download a new installer from our website and you’ll be able to edit what scenery is installed. The new installer is version 4.01r1.
I Can’t Type My Product Key: a small number of users have reported the product key entry field freezing in the installer. This appears to be tied to a specific GPU (the Intel HD 520) and possibly to specific drivers. If you see this bug, please contact tech support; we don’t have this hardware, so we need people to help test a fix. (Intel GPUs present a particular problem because you can only get them with a new motherboard; you can’t just drop a new GPU into a PC.)
Out-of-Date Nav Data: this isn’t really a bug; the FMS will (correctly) tell you that the sample nav data that ships with X-Plane is older than the current AIRAC cycle. You do not have to buy a navigraph subscription to fly; simply press “clear” on the FMC keypad to get rid of the message.
Crash After GPS/FMS Flight: fixed for beta 2!
Sparkling Cessna VOR Gauges: NVidia users reported all sorts of sparkly strange artifacts on the VOR steam gauges; this was caused by degenerate UV maps in the 3-d model. This is a subtle problem that artists sometimes hit,so I’ll write up a separate blog post for modelers on how to avoid this. Beta 2 will fix this, and the sim now features a new debugging mode to help artists detect this case.
Purple Planes: (or other colors in Plane-Maker) – that’s what uninitialized memory looks like in your GPU – fixed for public beta 2.
Wrong Joystick Configuration: Tyler has fixed a ton of bugs for this; we’re programming beta 2 to ignore beta 1’s joystick preferences; this forces everyone to recalibrate and ensures that the misconfigured prefs from beta 1 don’t stick around and cause further confusion and bug reports. Once we have stable joystick configuration, we won’t have to do this anymore.
Transparent Panels in Third Party Planes: I removed a v10 legacy code path from v11 that, as it turns out, everyone still needs – it’s back for public beta 2. I’ll write more about this in a separate post, but for now v10 aircraft should look less strange than before.
Supported Hardware: Beta 2’s diagnostics for what hardware is supported should be a lot better than beta 1. If public beta 2 tells you your hardware isn’t supported but beta 1 worked without hacking (E.g. command line work-arounds, OpenGL interceptors, ignoring the fact that everything on screen is pure red) then please do file a bug – it’s important feedback.
Threaded Nvidia Driver: I now know what you have probably known for a while: you have to turn the multi-threaded driver option off on NVidia hardware for X-Plane to function well. What is happening is: X-Plane is launching enough threads to use all of your cores for background processing, water processing, scenery loading, etc. and then the threaded driver is launching more threads. The result is too many threads fighting for too few cores.
What is astonishing here is how bad things get – when my i5 gets into “slow” mode with too many threads, it goes from 34 fps to 4.3 fps! I expected a slow-down proportional to the overloading of the cores plus a little bit of overhead for all the thrash. What actually happens is a lot more like “the machine grinds to a halt”.
Bottom line: the multi-threaded driver should be off – like you are already doing. I am looking at whether we can programmatically set this from within X-Plane.
Beta 2 should be out within a day or two – we’re working on final touches now. There are more bug fixes not listed here, and more bugs being fixed that aren’t in beta 2, and more bugs that aren’t fixed yet, so please be patient – we’re squashing bugs as fast as we can stomp.
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.
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.
