X-Plane 10.50 Beta “Real Soon”

First, it was great to see everyone who came to FSConn 2016! Here’s a video of the conference: if there is another video that has better stabilization I’ll try to post it.

YouTube Preview Image

Now about X-Plane 10.50: I did just fix my last beta-stopping bug. So in theory the first beta will be live tomorrow.

But that’s only theory!  If the beta isn’t live, please refrain from being the 700th person to post “any ETA on the beta” to the comments section. The actual release date of builds is unpredictable because the existence of release-stopping bugs is unpredictable.  (If we could be 100% sure there were no bugs, we wouldn’t need betas at all.)

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in Development, News | 40 Comments

KATL At Night – X-Plane 10.50

KATL bkgnd

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in Development | 40 Comments

Pushing More Virtual Tin

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.

 

 

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in News | 31 Comments

Austin Goes Viral

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.

YouTube Preview Image

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.

X-Plane 10.50 update coming tomorrow.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in News | 23 Comments

apt.dat 1050 Proposed Format Changes Posted

We’ve posted a Request for Comments for the apt.dat 1050 file format. You can see the proposed changes. Please comment on that article with feedback about the file format.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in Development, File Formats, RFC | 5 Comments

New Manipulators and the Mouse Wheel

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.

  1. 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.*
  2. 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.
  3. 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.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in Aircraft, Development | 21 Comments

X-Plane Usage Data

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

Aircraft_categoriesFirst vs Third Party Percent third party flights

Hardware

CPU_cores flight_controls

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.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in X-Plane Usage Data | 24 Comments

Coming to WED 1.5: WYSIWYG Taxi Sign Editing

taxi sign editor

That’s the new taxi sign editor in WED.

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.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in Development, Tools | 42 Comments

Brighter Night LIT Textures

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.

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.

  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in Development | 14 Comments

Actually, You Can Be Told What the Matrix Is

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.
  • Facebook
  • Reddit
  • StumbleUpon
  • Twitter
  • Google Buzz
  • LinkedIn
Posted in Development | 10 Comments