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.
Public beta 9 is now live – this should fix null texture crashes (we hope – if you still see one in beta 9, please do report it with log files!) and has a performance improvement we’ve been working on for AMD Windows hardware.*
10.52: We do have a back-port to X-Plane 10 for this fix; had we figured this out any later we probably wouldn’t have brought it back. I had 10.52 (which is just 10.51 with an external visual sync fix) staged on the servers when we figured out what to do for AMD cards. My new plan is to recut 10.52 with the AMD fix. This will probably not happen until at least mid February due to other deadlines that come first.
Physics: Austin’s flight model changes for bodies shadowing control surfaces is not in public beta 9; it should be ready for the next beta. While I don’t know exactly how much more beta we have, my hope is that we get to RCs in a few weeks.
Scenery: I have a mostly recut scenery set, but it still has one bad tile. Besides fixing the bad DSF tile, I am still working on how the installer will handle the update. Digital download customers will be able to download this updated global scenery; we are working to make the download separate from sim updates, so that you don’t have to download a 50 GB scenery update to get a 26 MB sim update.
The good news is: the new scenery set will meet our size requirements even with northern latitude included. So we don’t have to decide between DVDs and Alaska; we can do both.
Alpilotx also has an import of tall buildings outside the US from OSM – this is a really great improvement, particularly for European cities.
Servers: we moved the master copy of X-Plane to a new server, and we’ve gotten some reports of poor download speed from users. At this point we think that this is a temporary slow-down as the content delivery network re-caches the simulator, but we’ll keep monitoring the situation and work with our CDN provider if problems persist.
Clouds: I am still fighting with cloud performance, so this work is not in a public beta yet, because it’s not quite ready for prime-time.
* The short version, for OpenGL nerds, is that we’re using system memory and not an orphaned VBO, to source the quads for text. Because we draw a lot of text and the draw sizes are very small, we appeared to be exhausting the number of orphaned buffers the driver could provide, leading to stalls. I am working on a more advanced solution to the problem, but in the mean time, using system memory for small draws fixes the problem.
X-Plane 11.0 public beta 8 went up over the weekend. If you are seeing problems with the flight model, please report bugs ASAP so Austin can look at them! I think we are approaching the end of some major flight model updates; the last thing Austin is looking at is better body shadowing, which he will probably write up shortly.
Over the weekend, with the help of some very patient users, we found the cause of poor performance on some AMD hardware*. I have a prototype fix, and I hope to have it in X-Plane some time this week. This fix will only affect users who were seeing super-lousy performance on very light configurations.
In the most recent betas, the threaded driver no longer totally kills X-Plane performance. But it does still slow things down a little bit on some computers – I see 5% fps loss with the threaded driver on. My suggestion for now is: try it both ways and run with whatever works best for your machine; this bug is affected by both your particular CPU and the kind of work-load your settings induce in X-Plane.
I am still working on improving cloud performance, and a recut of the DSF tiles is rendering as I type. The first priority for the new DSF tiles is to fix blatantly broken tiles (e.g. YSSY) and get the file size down so we can put Alaska and friends back.
* I wouldn’t call the AMD problem a bug on either our part or AMD’s – it’s more in the category of “OpenGL makes no promises as to what might be fast, so app developers have to debug on all shipping hardware and try not to do painful things.
