We’ve been working for the last few weeks to get X-Plane 10.50 ready for public beta. My goal was to get 10.50 posted before I go to FlightSimCon 2016, but it looks like it’s going to be Monday or Tuesday of next week by the time it’s live.
A bunch of us (including Austin, who is presenting) will be at the Conference, and most certainly at the bar after – if you’re there, come say hi. We’ll be talking about the latest stuff in X-Plane 10.50, and possibly some stuff from the lab as well.
Getting the Planes Moving
As part of the ATC tune-up for X-Plane 10.50, Austin and I have worked on a number of features and bug fixes that should hopefully improve the rate of arrivals and departures at our airports. The current code can get pretty backed up, and we’ve had complaints from users about very long taxi times. (Ironically, this totally happens in real life, but I understand that you don’t want a simulation of KDFW when a thunderstorm passes through or KLGA on a Friday afternoon of a long weekend.)
Here are a few of the changes that help move traffic:
The AI drive better. And the better they drive, the less likely they are to bring traffic to a standstill.
ATC has a more realistic estimate of the speed of the AI aircraft. In 10.45, X-Plane launches AI aircraft as if they were real pilots at O’Hare. The actual AI drives more slowly and tries to err on the side of safety; by giving aircraft bigger margins of safety, ATC avoids go-arounds.
Simultaneous parallel-runway operations are now supported for VFR weather. One reason for go-arounds is that 10.45 has the hard-ball IFR rules (think socked-in) for runway separation, which means that very close parallel runways can’t operate at the same time. This is no longer a constraint on a nice day.
ATC uses same-runway-separation rules. These rules let ATC launch aircraft faster when they turn off the runway heading or when the aircraft are small. This means that if a C172 departs on a 10,000 foot runway, you don’t have to wait (five hours) for it to get to the far end of the runway.
There’s one more thing that really helps expedite traffic that you can do: make custom ATC taxi routes in WED for your airport. Having clean, correct taxi layouts with well-planned runway flows makes a huge difference in terms of ATC efficiency and AI operations.
To help you do this, we’re adding more tools to WED to easily edit and understand ATC data and diagnose problems. WED 1.5 should be in beta in the next few weeks and has these enhancements. We will also put together articles showing some common problems with ATC layouts and the best way to author them in WED.
He even got on slash-dot! Anyway, if you want to see a short six minute explanation of why we are being sued, here you go.
And to state the obvious, we are not discontinuing any of our products, we are not dropping Android as a platform, and we are in no way backing down because of the lawsuit. As you can tell from the video and Austin’s posts, Austin has some strong feelings about standing up to patent trolls.
First, we are making progress toward X-Plane 10.50. I sent out a private beta a few days ago; how soon we get to public beta will depend on how buggy the private beta turns out to be. (I am assuming that it will have zero bugs, because I have decided to not write any more bugs in my code. So…there, I fixed it.)
Coming in 10.50: X-Plane supports new manipulators.
In 10.50 you can add scroll wheel to any of the existing manipulators that takes one dataref. This is done via a second directive that sets the amount the dataref changes when the wheel moves.*
There are six new manipulators (they form a set) to support knobs and three-way switches. Each one takes a pair of commands and provides a consistent UI experience.
The no-op manipulator now takes a tool-tip, which lets you make tool tips for gauges and other unclickable geometry.
I want to make two things clear here:
This is support for these manipulators in the engine. This means that we can use them in our aircraft and third parties can use them in their aircraft. Adding these manipulators is a separate task, one we are working on, but which won’t be complete as of 10.50.
Third parties are welcome to use the new manipulators, and they are welcome to follow our internal usage guidelines. They are also welcome to keep doing what they are doing; none of this is binding, everything is opt-in. Nothing about this breaks compatibility with any existing aircraft.
Why Did We Add These?
We’ve had a long term internal goal of making the 3-d cockpit as usable and user-friendly as possible. We’ve reached a point where 3-d cockpits are the norm, and all of our new aircraft development is 3-d only. But you can’t deny that 2-d cockpits are incredibly usable from a user interface standpoint. How do you make 3-d usable?
We already have view presets to let you get to a particular cockpit view easily. Once you have a good view of the surface you want to interact with, the next step is to have a mouse gesture that’s easy to use.
This is where the new manipulators come in. Rather than describing a mouse gesture (drag, click, etc.) they describe a type of physical hardware, one of a rotating knob, left-right multi-way switch or up-down multi-way switch.
Because the manipulators describe the physical hardware and not how the UI should work, we can change the interaction mode based on user preferences, available hardware, etc.
One of the big UI questions is: should you change a knob by clicking and holding or dragging? I built a test airplane with some of each and the company was split down the middle. By using knob manipulators (and not click or drag manipulators) we can change the way knobs work in the cockpit for all airplanes with one change of the code, rather than having our art team redo every single manipulator in every single airplane.
I don’t know whether we’ll use dragging or clicking-based knobs – or whether a user preference will be exposed. But by having a higher level manipulator type we make this a small programming problem and not an unmanageable authoring problem.
(The new knob manipulator automatically uses the scroll wheel – since we know it’s a knob, we can figure out how the wheel should work. The new command to add scroll wheel to legacy manipulators is necessary to provide the data the sim needs to make the user interaction good.)
The new higher level manipulators also give us flexibility for new input devices. For example, if we someday want to support multi-touch tablets and track-pads, we could map a pinch-rotate gesture to a knob – since we know the manipulator really is a round knob (and not just ‘something that you drag’) we can know that a rotating gesture makes sense.
How Do I Add Them?
The new manipulators are already supported in code in the Blender 2.7, Blender 2.49 and and AC3D. The manipulators are released in the newest Blender 2.7 exporter; I need to post newer 2.49 exporters. I do not know if/when there will be a public release of the AC3D exporter, but I can probably find the time at some point to do one more compile.
All aspects of the new manipulators are opt-in; if you don’t change your airplane, its functionality should not change.
What Aircraft Use Them
I’ve buried the lead a little bit here: X-Plane 10.50 will have a heavily upgraded Kingair C90 and Baron B58 that will use the new manipulators. We have not (yet) upgraded the rest of the fleet, and this upgrade will happen over a very long time-span. The goal of 10.50 is to lay the groundwork and make cleaner user interfaces possible by making the new manipulators available to our art team and third parties.
The guidelines I’ve been advocating for our artists are:
Large things that move a lot like throttles are dragged via an axis that tracks the actual 3-d motion.
Yokes track via a 2-d XY manipulator.
Anything that toggles or has only two states is a single click, particularly for small things.
Rotary knobs and rheostats use the new knob manipulators. The mouse wheel can turn them.
Linear switches with three or more positions use the new left-right and up-down switch manipulators. The mouse wheel can click them.
There’s no reason why third parties have to use these guidelines; I post them only to show how we are thinking about usability. A more “3-d” approach is possible, e.g. drag a banana switch up and down to toggle it; my view is that for Laminar’s default fleet, which are the first aircraft users are going to use, single clicks provide a more direct and less surprising user experience.
For power users, having single clicks for switches may also mean you can get more done in the cockpit faster. (In real life, a pilot can reach up and flip four metal banana switches on the overhead panel very, very quickly.) We’ll still use dragging for big 3-d motions.
*This feature targets one-wheel clicking Windows-style mice. 2/3 of our users are on Windows, and Apple has shipped a wide variety of strange input devices, so the one-axis clicking mouse wheel is the most consistent hardware target for us to aim at. And frankly, I think it’s the most useful since you get clear ‘detents’ as you scroll things – good for changing a radio by one notch.
When we put out the request for comments on publishing X-Plane usage data four and a half months ago, I had the best of intentions for creating nice, web-based, automatically-published, interactive graphs & charts with all the data we have.
Unfortunately, I’ve been head-down working on top-secret features for X-Plane Desktop (believe me, when you see this stuff, you’ll understand why!), and my analytics data project has just languished (and will continue to languish for many months more as I finish the Desktop features).
So, after a gentle kick in the pants, I’m publishing the data as I have it. It’s not pretty, but I think it will still be useful to third-party developers. We have a handful of easy-to-digest charts, plus a whole bunch of raw data at the bottom of the post for those that are interested.
Note that all data in these charts are for users of the full version only—I’ve filtered out demo users.
Do let me know in the comments if you have questions about the data!
Aircraft
Hardware
Raw Data
There are two files here: hardware data, and aircraft data. Each contains all the information we have since September 2015, for paying customers only (no demo users). I’ve provided two formats for each file: an XLS, and a simple CSV.
Signs in the hierarchy are shown as a rendered preview of what the sign will look like.
When you click on it (as if it was text) you get a WYSIWYG editor with two “text” fields where signs can be directly typed, and a palette where signs can be added by clicking.
I just fixed a problem in DDSTool: DDSTool was calculating mipmaps in sRGB space instead of linear space. This was wrong, but didn’t make a huge difference when grinding day-time textures.
It does make a big difference for LIT textures though. Let me show you.
Old: darker lit textures
New: brighter lit textures
That’s a night LIT scene (at PHNL I think) with some new autogen from X-Plane 10.50. (To answer your question, some of the AG has LIT textures, but not 100% of objects do.)
In the lower left corner are thumbnails of the raw textures – what is interesting about them is that they show the smaller-sized images in the mipmap pyramid of the image. And you can see that in the old image, the small thumbnail of the buildings is almost completely black – the building light has been lost with down-sizing.
Note that the buildings are a little bit darker in the old grind on the left but the tiny thumbnail is much darker. That’s because making mipmaps is a recursive process – each next-smallest-size mipmap is processed from the previous image; by the time we get to a really small size image, if we have lost brightness, the effect has really built up.
The result was that in the old grinds, as you flew away from the buildings, they’d get darker. In the new grinds, they stay at consistent brightness.
What Changed: the Math
Here’s the funny thing about images in sRGB color space (which is what X-Plane uses) – the mid-point between black (0) and white (255) is not 127 or 128. That’s too dark! The actual right color is 188 – pretty bright!
This happens because sRGB images are encoded in a non-linear manner for even perceptual spacing for humans, and our eyes are more sensitive at lower light levels. But the average between two pixels should be the average of the actual amount of light coming from the pixels. The half-way point of sRGB is too dark because a lot of numeric space in sRGB is spent in the dark regions.
The problem is that lit textures are made up of a few really bright pixels and a lot of black; when averaged together the wrong way the smaller sized images end up too dark, making slushy, dark, munged night lit textures at small sizes.
The solution (in the new DDSTool code) is to convert the colors to linear space, down-size the image and convert them back. There’s no change to how you use the tool – the images just look better at small size.
This is a tiny feature coming in X-Plane 10.50, but it will make a big difference for a few key plugin use cases: X-Plane will provide the current world model-view, projection, and aircraft model-view matrices to plugins via datarefs.
If you aren’t a plugin developer, or you don’t like matrices, or you don’t write your own OpenGL code, then the rest of this post is going to be boring, so go watch FrooglePete interviewing two funny looking guys. [Edit: link fixed – why that was pointing to airport flattening is totally beyond me!]
For the three of you still here: three matrices will be available:
The OpenGL projection matrix – that’s the one that is currently set up when your 3-d draw callback is called.
The OpenGL modelview matrix – we call it the “world” matrix, it maps the official X-Plane OpenGL coordinate system to eye coordinates, and it is also set up when your plugin is called.
The Aircraft modelview matrix – this is a matrix that maps aircraft coordinates (0,0,0 = CG, +X = right wing, -Z = nose) to eye coordinates.
You already are using two of these, the third is new. So who would even care? There are two use cases for this.
Stop Calling glGetFloatv!
Calling glGetXXX is bad. Modern Windows GL drivers send GL commands to a worker thread for execution, freeing up the rendering thread to keep going, improving framerate. But every time you ask OpenGL a question, our thread has to wait for that driver thread to catch up, slowing everybody down. The rule is simple: don’t call glGetXXXX.*
But there’s one case where your plugin might really need glGet: to get the current matrices for culling 3-d drawing.
This is where the datarefs come in – by reading our datarefs instead of calling glGetFloat, you can get the transform matrices without stalling the driver.
(If you have other glGetXXX that you can’t get rid of, ping me and I’ll try to find a work-around.)
Drawing On the Aircraft Without Jitter
The third matrix (the aircraft model-view matrix) is the matrix you would get if you translated to the aircraft’s location and then rotated around its orientation.
Here’s the key difference: when we do that calculation, we do the calculation in double-precision. We do this because the OpenGL origin can be tens of thousands of meters away from the aircraft, which in turn can be very, very close to the camera. In that situation, precision loss from single-precision floating point when multiplying together two very large matrices (that result in a very small matrix) results in apparent jitter when drawing.
The problem is: even if you wanted to do this calculation yourself in double precision, you can’t – the world matrix isn’t available to plugins in double precision.
So starting in X-Plane 10.50, the aircraft matrix is simply provided.
I did an experiment where I attached a green cube to an aircraft and then drew a blue cube at the same location from a plugin. With glTranslate/glRotate there was a ton of Z artifacts and slop that changed per frame because the two cubes were in slightly different positions. With the aircraft matrix, the green cube was invisible (except when disabling the plugin) because the blue cube overdrew it pixel-perfectly.
What about glGetError? Call this only in debug mode (to catch mistakes in your GL code); use #if to make sure you’re not calling glGetError in release mode.
I’ve been way behind on blog posts over the last few weeks. Basically, the more we are doing, the less I manage to blog about what we are doing. (Instead I put off writing a blog post until it’s really late and then decide at 11 pm that I’m too tired and I’ll do it tomorrow.)
So here’s a partial list of X-Plane 10.50 features. This is not even remotely complete, it’s just some “headline” features that I can think of now; the release notes will be comprehensive.
New Autogen: We have new US tall building art assets that will make cities look better.
apt.dat 1050 with Static Aircraft and New Models: A new revision of the apt.dat file provides information on parking spots so that we can place static aircraft models inside X-Plane, based on the library and rendering settings. X-Plane 10.50 will ship with a bunch of additional static aircraft models, and third parties can add more via the lbirary. WED 1.5 will have new features to edit this information.
For airports created before WED 1.5 (which is nearly all of the approved airports), we are working on tech to auto-upgrade the gateway airports to use the new static aircraft; third party scenery will simply not participate in the new feature until updated by the authors.
Global Winds Aloft: X-Plane 10.50 will use global NOAA data for winds aloft, rather than a US-only data source.
ATC Fixes: X-Plane 10.50 has a number of ATC bug fixes to make ATC a lot more usable. No more “you are off course!”
New Manipulators: We have added a few new manipulator types as part of an effort to make 3-d cockpits more usable. Yes, the scroll-wheel is accessible. (We have not rebuilt every 3-d cockpit in our fleet. The feature here is the capability in the engine, for us and third parties to use.)
Update King-Air and Baron: we have, however, redone the Kingair and Baron, fixing a number of issues and getting them to a whole new level for IFR flight. These planes use the new manipulators for their 3-d cockpits.
More Airports from the Gateway: as with all releases, we’ll include the latest airports from the X-Plane airport gateway.
Those are just the “big” things – there’s some huge number of other changes, some of which may be really important to some of our users. I still have about half a dozen items on my todo list to get to a 10.50 beta, so I haven’t worked up complete release notes yet.
X-Plane 10.45 fixed one of the big “ecosystem” problems with the global airports by excluding airport objects by ICAO code. This makes the global airports much less likely to conflict with custom scenery, even if that custom scenery lacks exclusion zones.
For 10.50, I am looking at another change to how we manage airports that should help gateway authors: per airport control of flattening.
As of X-Plane 10.45, airport flattening is a user setting; a user can pick to have all airports flat, or all airports follow the terrain contours.
This is a rather silly setup. One size does not fit all for airport flattening, and the author of the airport is more likely to know how the airport will look with/without flattening than a user who is flying to that airport. It certainly isn’t efficient to have everyone in the X-Plane community set flattening individually without authors being able to set up their airport the way they want.
From what I’ve seen, there are two legitimate uses of airport flattening.
To fix bugs in the underlying terrain, e.g. if the DSF is screwed up, then the airport may need to flatten it to make the airport usable at all. We want this to be the exception, not the rule. (X-Plane 10 is more buggy than past X-Plane releases WRT bumpy runways, so this may sound funny right now, but overall we aim to have users be able to fly with non-flat runways.)
To accommodate highly customized airports where the 3-d models depend on a flat surface.
In X-Plane 10.50, it should be possible (using a new version of WED) to mark an airport as “always flatten”. The expected usage is:
Users leave “runways follow terrain contours” on, all of the time.
Authors mark individual airports as needing flattening, e.g. to fix bugs or accommodate custom scenery.
There is one use case that isn’t handled well by this: if an airport needs different flattening based on different base meshes, there is no way to tag that in the airport. But I view this as a fairly difficult problem to solve with existing technology – we would need a 2-d grid matching every custom version of an airport against every version of the mesh ever to exist.
Fixing the Mesh
Please note that this feature is not a replacement for being able to customize mesh elevation at a local airport from an overlay. “Mesh patching” is what we want to be able to do in the long term, but for X-Plane’s engine, it also means a lot of complicated internal changes to how the rendering engine works; customizing flattening is something I can ship now in 10.50 that at least helps.
Flattening is also not a replacement for fixing bugs in the base meshes themselves; one trend I have observed over my decade+ working on X-Plane (!) is that the accuracy of source data keeps getting better. Ten years ago it would be silly to say “how about if everyone just uses the real world values for their scenery and it will just work”. At this point that’s not actually a pipe dream, it is often completely manageable. So my hope is that someday we can reach a point where the terrain is just accurate and everyone uses it.
As of right now I have this code working in X-Plane but I do not have a build of WED that supports it. We are still in the middle of working on 10.50 apt.dat features, so I’m hoping to post something on that soon.
