Category: Development

Finishing 12.1.0 Features

If you’re at FSWeekend, say hey to our peeps there! In the meantime, we’re working to kill off the last 12.1.0 features. A few internal pics* from killing off the last features:

Author-controlled de-icing has had a series of bugs in 12.0.x. For 12.1.0 we’ve gone over it with a fine tooth comb; Alex ran the above tests with our Kingair, which has the unusual case of two overlapping de-icing zones. We’ll have updated docs, Blender exporter support, and builds for authors.

Some tests of real weather. In the first pic, the sky says clear but there’s a distant cloud…because the weather report is local.

Water turbidity is fixed for 12.1.0 and I am finishing documentation for authors. It looks like Oscar’s work on Ortho4XP is on GitHub. Please note that X-Plane 12.1.0 does not improve X-Plane 11 orthophoto water compatibility; v11 packs will only have 2-d water because their meshes are not triangulated properly for 3-d waves.

Based on the progress we done this week, I am hoping we will be able to test these features next week and start a private alpha in our developer lobby.

* Please note: these are internal pics from the developers that I am posting while the marketing team is too far away to object – literally what we were passing around while discussing the features. Don’t panic over FPS; the sim is running a debug build in those real weather pics, for example.

Posted in Development by | 5 Comments

We Are All Raster-farians Now

In my previous post I drew an analogy between a scenery system with its file formats and a turtle within its shell. We are limited by DSF, so we are making a new file format for base meshes so we and all add-on developers can expand the scope of our data and make better scenery for X-Plane.

The really big change we are making to base meshes is to go from a vector-centric to a raster-centric format. Let’s break that down and define what that means.

Vectors are fancy computer-graphics talk for lines defined by their mathematical end-points. (Pro tip: if you want to be a graphics expert, you just need the right big words. Try putting the word anisotropic in front of everything, people will think you just came from SIGGRAPH!) DSF started as an entirely-vector format:

  • All 3-d clutter is defined by lat/lon locations, so we have the vector outline of polygons, autogen blocks, etc.
  • The base mesh is pre-triangulated, so most base-mesh features are defined by the corners of the triangles forming lines (e.g between land and water).

This isn’t the only thing DSF does – we added raster capabilities and there is e.g. raster sound and season data in X-Plane 12, but DSF is fundamentally about vector data – saying where the edges of things go exactly.

This was great for a while, but now that we have more and more vector data (complex coastlines, complex road grids, complex building footprints) the DSFs are getting too big and slow for X-Plane.

Raster data is any data stored in a 2-d grid. This includes images (which in turn includes orthophotos) but it also includes 2-d height maps (DEMs), and the 2-d raster data we include in DSF now (e.g. sound raster data, season raster data etc). Any time we store numbers that mean something in a 2-d array, we have raster data.

Raster data has several advantages over vectors:

  • Raster data is what the GPU wants to consume.
  • Raster data has really good LOD characteristics for close detail with long view distances.
  • We can put more interesting and dense information into a raster tile without it getting bigger.

Twenty years ago, when I first worked on DSF, computers didn’t have the capacity to use lots of raster data – this was back when 8 MB of VRAM was “a lot”. But now we no longer need to depend on vectors for space savings.

Raster tiles are raster data broken into smaller tiles that get pieced together. Raster tiles have become the standard way to view GIS data – if you’ve used Apple Maps or Google Earth or OpenStreetMap or any of the map layers in WED, you’ve used raster tiles.

Raster tiles have a bunch of advantages too:

  • They have really great LOD/VRAM usage properties.
  • They can be loaded incrementally.
  • They provide an easy way to vary resolution and let authors skip providing data that they don’t need to provide. (E.g. “forest” raster data over the ocean? Just don’t provide any tiles!)

So our plan for the next-generation base mesh is “all raster tiles, all the time” – we’d like to have elevation data, land/water data, vegetation location data, as well as material colors all in raster tile form. This would get us much better LOD/streaming characteristics but also provide a very simple way for custom scenery packs to override specific parts of the mesh at variable resolution with full control.

Raster tiles are not the same thing as orthophotos. A raster tile is any data contained in a 2-d array, not just image data cut into squares (e.g. orthophotos). So while a raster-tile system may make it easier to build orthophoto scenery, it does not mean that the scenery can only be orthophotos.

Posted in Development, File Formats, News, Scenery by | 27 Comments

A Few Notes on 12.1.0 for Developers

Thomson and Dellanie posted a preview of what’s coming in X-Plane 12.1 – click over to the news blog to see the pretty pictures. Short story long, it’s a graphics-intensive release, but it’s also a big release, with weather, systems, avionics and ATC updates too. What follows here is a few details for developers.

Private Alpha Builds Soon

As with all past X-plane 12 patches, we are planning to do a private “alpha build” test run with the developer lobby before public beta. We do this both to find out about add-on compatibility and to get the worst bugs fixed with a smaller test group. As of this writing, ATC is at the end of bug fixes, the last graphics changes are being tested, but my weather work is still mid-development.

New Toys for Scenery Developers (and Aircraft Modelers)

This release turned out to have a lot for scenery developers:

  • Water bathymetry and turbidity should be sorted out, making orthophoto base meshes with 3-d water possible.
  • The material system now features normal-map decals. These decals add high-frequency ‘texture’ to a surface by perturbing the normals (direction of light bounce) instead of just “painting’ them. This means better looking materials at different lighting angles.
  • LOAD_CENTER is now usable on OBJs. This means you can set the resolution of an OBJ to be based on distance to the aircraft (just like draped polygons and orthophotos); I think this has the potential to ensure that “land mark” OBJs (models used exactly once) are at their highest resolution when the user is near them without hurting VRAM in general.
  • If it passes test (crosses fingers), particle systems can be used directly from DSF objects.

The entire DECAL system (existing and new normal map decals) are also usable in OBJs for aircraft as well, and the particle system has received some upgrades that can be used everywhere.

One warning: the old “smoke puff” directive for OBJs from X-Plane 8 is now inoperative; with 12.1.0 we finally removed the old particle system completely. I suggest using the new particle system as it will give you real control over what kind of smoke comes out of your models.

New Plugin APIs

Two new plugin APIs are planned for 12.1.0:

  • New navigation APIs
  • An extension to XPLMAvionics so add-ons can create their own glass screens.

We are still putting finishing touches on the avionics APIs now, but this tech is very close to complete, and definitely usable.

Unfortunately we will not have a low level weather API in 12.1.0 – R&D on this is ongoing, but at least in better shape than it was before due to fixes to the internal weather code.

Posted in Development, News by | 18 Comments

The Turtle Needs a New Shell

At the X-Plane Developer Conference in Montreal this year I gave a presentation sharing my thinking on our next-gen scenery system. This has created a lot of interest but also a lot of confusion. So in these next two blog posts I want to start by clarifying two fundamental ideas about scenery.

Here’s the key point for the first one:

A new scenery format is not the same as new scenery.

This can be confusing because we haven’t changed either our scenery file formats or our scenery in quite a while, and often the two change together. Let’s break this down.

A scenery file format is the way we represent scenery in our simulator. It consists of several things:

  • A file format specification, describing how scenery data must be encoded.
  • A file parser inside X-Plane that can read those files.
  • A renderer inside X-Plane that can render those files.
  • Tools that help people encode those files.

My first work for Laminar Research (two decades ago) was building all of those things: I invented DSF files, wrote the DSF reader inside X-Plane (DSFLib), worked on the rendering engine, and created the tools to write the files (DSFTool).

When we talk about just the scenery, this is the final rendered files that people fly with. Remember when we shipped 60GB worth of content in 12.0.9? That was new scenery rendered out with all the latest and greatest data.

X-Plane ships with the “global scenery” – a set of about 18,000 DSFs that ensure land everywhere from 60S to 75N. But this is not the only scenery out there – there’s TrueEarth, HD base meshes, SimHeaven, and scenery made with Ortho4XP.

Lots of people can make scenery, often in many different ways (using land class, orthophotos, autogen, etc.) but all of that scenery must be in X-Plane’s scenery file format, e.g DSF.

The scenery is the turtle and the scenery file format is the shell. The scenery can only be as complex as there is capacity in that file format (shell).

So the first part of my talk was a tour of how we have outgrown DSF, and pointed out that there are some things that DSF can’t do. For example, several add-on makers want to stream custom scenery, but DSF makes that basically impossible. DSF also isn’t meant for really high detail vector data, so we’ve been having trouble using all of the latest OSM imports.

The second talk discussed our plans for a replacement to the base mesh file format, which is based on raster tiles. This part of the talk said nothing about what kind of scenery we (Laminar Research) would make, which raised a lot of questions.

But now that you understand the the turtle and the shell, you have a lens to understand what we’re saying. This wasn’t an announcement of next-scenery, only an announcement of a bigger shell that will make that next-gen scenery possible.

So the next-gen scenery format is all about potential. The scenery file format limits what is possible for all scenery (both what is built into the sim and add-ons), so we want to raise those limits quite a bit in the next-gen base-mesh format.

The way we are doing that is by moving the base mesh from a vector-centric approach to a raster-centric post; I’ll break that down in another post.

Posted in Development, File Formats, Scenery by | 25 Comments

Blog Post Walk of Shame

After the X-Plane Developer Conference in Montreal this weekend (thanks to everyone who came and especially ToLiss for hosting/making us feel totally at home in Montreal) I thought “I should probably post something to the dev blog talking about what we’re up to.” I logged in and saw…I haven’t posted anything in four months.

So that’s not great. The truth is the X-Plane team is larger than it was in the v10 days and I spend most of my communications time talking to the internal team and third party developers.

I’m going to try to post once a week here. This sentence may be an embarrassing monument to lofty but impractical goals in another four months, but putting it in writing is a way to commit to it, and it won’t be the most embarrassing thing I’ve ever done.

Two Quick Store Notes

We announced the X-Plane Store plan in Montreal; Dellanie’s got a great FAQ there, but here for developers I just want to make two points clear:

  1. We are not locking X-Plane down. I totally get why people might think this because the iPhone app store is (1) a very prominent way to do in-app purchase and (2) the iPhone is locked down. But we are not doing that. All of the ways you get stuff into X-Plane will still work, including add-on installers, dragging folders around, you name it. Going through the store is not a requirement, and everything that works now will keep working. You won’t have to pay for freeware or re-buy anything.
  2. You will not have to be online all the time. Our current policy is that if you have an online license (an “XDD key”) you have to log in every two weeks or more to renew it. We are not going to switch to “all online all the time” – we know that this is impossible for a lot of our users and we consider maintaining this “renew the key every now and then” policy to be a requirement.

What’s Next: 12.1.0 and 12.2.0

We have two “big updates” planned right now:

  • 12.1.0 will ship next and is primarily a graphics release. RCAS, bloom, DoF, shadow softening, cloud shadow fixes, new decals, you get the idea. This update will also address a number of real weather bugs and transition to the new real weather servers.
  • 12.2.0 will ship after 12.1.0 and is primarily a flight model release. All of Austin’s advancements in prop blade dynamics, stalling and turbulence, etc.

Both releases will have a bunch of other stuff too; they’re big patches. I’m pointing to the graphics/FM divide because the decision to push one of graphics or physics in each patch is intentional to keep the scope of the beta under control.

We are aiming to get 12.1.0 into private testing this month.

What’s Up, Docs?

Probably only three people on Earth care about this, but after a decade (more walk of shame) I was trolled into updating the .net file format specification. So if this is interest to you, I apologize both for the delay and for the pain you are about to suffer. The road art file format in X-Plane is incredibly complicated and I don’t actually recommend anyone try to hack it, but it’s also not meant to be a secret.

Scenery, Now and Future

I am working to get water and orthophotos sorted out, hopefully for 12.1.0. We will also have a DSF recut (hopefully for 12.1.0 but maybe for 12.2.0) to address gateway airport boundaries and runway undulations.

In Montreal I discussed a little bit about the future of the X-Plane scenery system, but that’s complex enough to warrant another blog post.

Posted in Development, News by | 33 Comments

Two Pain Relief Fixes Coming Soon

The next X-Plane update will focus primarily on flight-model and systems, plus external-visual networking and some ATC features. While that update is in beta, we can work in parallel on real weather and graphics.

But there are two graphics bugs we already have fixed in-house which should relieve some 12.06/12.07 pain:

  • Running out of memory mid-frame. Turns out if you got into a fairly tight situation VRAM wise (and we try to do that to max out the texture res you can have) then X-Plane might run out of memory trying to draw trees and…melt down like a toddler who can’t have any more candy.

    We have an interim fix: allocate memory statically so we always have it. In a future update we’ll reuse memory from other parts of rendering to be more efficient.
  • Popping out a window causes a big slow-down. When the arrangements of windows changes, we might need to allocate more VRAM for rendering. This is not a fast process – we have to halt all rendering, throw out the old memory, compact things, allocate new memory, and if a DSF is loading while this happens, the DSF loader is using up memory as we are trying to reallocate the windows, which can mean compacting memory again, paging down textures…you get the idea.

    The fix is pretty simple: don’t do this if the popped out window doesn’t require more VRAM. Most of the time, this is the case, so this is an easy fix for a silly bug.

Integration work for the next update is going on now and I’m hoping it will be done next week. More details soon!

Posted in Development by | 34 Comments

X-Plane 12.07 ARRsea 1 Has ARRived

Editor’s note: what follows is very, very, very, very, very silly.

Last week we shipped X-Plane 12.06; since then we have found a few straggler bugs; like typical lARRge patches from the days of X-Plane 11, a few bugs escaped us until after final, including some crashes we could see in the auto reportARR.

While it’s not great to be shipping a “hot patch” to our release, it is pretty fantastic to announce X-Plane 12.07 ARRsea 1 on International Talk Like a Pirate Day (the 19th of septembARR). The rest of this blog post only gets worse; you’ve been wARRned.

12.08 Is The New 12.07

Internally, nobody is happy about this, but the hot patch bumped all of our version numbers. So the new road map looks something like this:

  • 12.07: hot patch of 12.06.
  • 12.08: coming soon. Flight model and systems, ATC and Networking
  • 12.09: more graphics and real weathARR fixes.

12.08 (né 12.07) is almost completely integrated and should be ready for private testing as soon as 12.07 is settled.

Why Wasn’t I Notified

Since 12.07 is a new version, you won’t be auto-updated to upgrade from 12.06 while 12.07 is in testing; run the installer, update with “get betas” checked and you can get 12.07.

Crash Fixes

12.06 shipped with more sensitive internal detection for numeric problems. This is how we run the sim internally all the time – the goal is to find and squash bugs fast.

Unfortuntately there are sections of X-Plane’s simulation that are:

  • Not present in an aircraft (e.g. the real aircraft doesn’t have X)
  • Not expensive to run, CPU-wise
  • Not visible to the user (since the aircraft has e.g. no gauges to show these systems.

As it turns out, these systems are often happily running away in the background producing absolutely bonkers values; with sensitive numeric checking, the sim can crash due to problems in a system that nobody cares about.

For 12.07, I solved the problem by muting the alarm. My expectation is that we’ll have sensitive numerics in most betas, turn them off in the releases, and work through the systems code over time. (The priority on this isn’t super high because the systems aren’t consuming framerate – if they were we’d see them in our profiling.)

The other area where we saw increased crashes was with TCAS plugins. 12.07r1 has better logging and shouldn’t crash as much – the goal here is to not brick third party add-ons.

Other Bug Fixes

Multi-monitorARR: data output was not working in full screen configurations, fixed now, and manipulators work for multi-monitor systems.

OpenXARR: HP Reverb fixed, and we finally figured out why the white board would sometimes disappear. (It wasn’t gone, it was just 20 km from the hangARR.)

GARRmin Bezels

X-Plane does not have a built-in way to remove the bezels from the pop-out avionics. To solve this, some of our user and some add-ons edit the ARRtwork inside X-Plane’s “resources” folder, setting the bezels to clear.

X-Plane 12.06 introduced new bezel variants for the G1000 to cover all of the real-world panel button configurations. This fixed the bug “the real aircraft does not have these buttons, but when you pop the panel out, the buttons appear and do nothing.”

A side effect of this is: those aircraft using the new bezels use new art files, so the hacked up no-bezel art files on longer work.

This is not a bug for us to fix; if your add-on works by modifying the internals of X-Plane, we cannot guarantee that it will keep working even when we change the sim. (The only way to make that work would be to never change the sim.) You can work around this by modifying the new bezel files.

In the future, our plan for this is to provide a real way to hide bezels in the sim as a built-in part of the UI, which should make hacking unnecessary.

What Comes Next

Hopefully 12.07r1 will be “one and done”; if so, we’ll move on to private testing of 12.08 almost immediately.

If you are a third pARRty and your add-on has problems with 12.06, please tell us four weeks agoas soon as possible!

Posted in Development, News by | 25 Comments

Addressing Plugin Flickering

X-Plane 12.04b3 ships with a new feature called “Zink”, which we hope is going to alleviate a lot of the long standing issues that many users, especially with AMD GPUs have suffered from. This hopefully provides a work around for both flickering plugin drawing, eg. EFIS screens that either flicker or are missing altogether, but also potential improvements in performance by decreasing driver overhead.

If this sounds like you, you are welcome to give this a try right now by upgrading to 12.04b3, going into the Graphics settings and checking the “Use Zink plugin bridge” check box. Restart X-Plane and if everything goes to plan, X-Plane should look exactly the way you are used to but most importantly your plugins should look right and your performance might be better too. Because Zink is built on top of Vulkan, it’s only available to Windows and Linux users and is not applicable to macOS and Metal.

If you only take one thing away from this blog post, I hope it’s this image showing the difference between native Vulkan/OpenGL interop as well as Zink interop gives you an idea of why we are excited about this:

Now that I hopefully have your attention, let me elaborate how we got here and what this means for both users and developers. First of, Zink is actually a graphics driver that sits between plugins and X-Plane and translates plugin OpenGL rendering into native Vulkan commands that get executed by the same Vulkan device that X-Plane is using for rendering. Of course, X-Plane itself no longer uses OpenGL, but it’s is still very important for plugin development. A long time ago, when X-Plane was still OpenGL based and the plugin SDK was first made, it seemed like an absolute no-brainer to just expose the X-Plane OpenGL context to plugins directly and let them handle all their drawing needs themselves. It gives the most flexibility and control over everything, and it also makes it easy for the SDK because there is no need to make fancy drawing routines to be used by plugins.

Fast forward to the Vulkan and Metal port and we suddenly have an issue: Neither Vulkan nor Metal is OpenGL, but there are now hundreds of plugins out there that all assume X-Plane uses OpenGL and the OpenGL context is there. Killing OpenGL for plugins would mean countless plugins would stop working, requiring potentially lengthy update processes or maybe they’ll just never work at all again because the author lost interest in X-Plane or developing the plugin. This is how we ended up with the OpenGL Bridge in X-Plane 11.50: We create a real OpenGL context, share some memory from within Vulkan to that OpenGL context, then let plugins continue to draw how they used to do. X-Plane takes care of all of the heavy synchronization and resource creation rules under the hood and everyone is happy. Everyone? Well, no, not quite…

The problem with Vulkan/OpenGL interop

The big problem with Vulkan/OpenGL interop is that it relies on the driver to support this properly. As it turns out, driver support for this is flaky at best, if you own an AMD card you can probably tell long stories about issues. The most prominent one is flickering or altogether missing rendering, in which case plugin drawing is either completely missing or flickering in and out of existence making it basically impossible to use plugins. The other issue is performance, captured in the screenshot above, where the OpenGL bridge adds almost 10ms per frame, although I have seen numbers as bad as 30ms per frame. For reference, 33ms is the time one frame can take at most to reach 30 FPS! This wasn’t always the case, it used to run much better, but driver regressions are a real thing and this isn’t really something the hardware vendors test. Not that I can be too mad about this, X-Plane is one of the very few applications that uses this feature at all. Despite having filed numerous bug reports with the vendors, unfortunately the problems were never completely fixed, so even during the 11.50 days we started thinking about alternatives. During the X-Plane 11 days it was at least somewhat easy to tell users to switch back to OpenGL to avoid the flickering, even though that usually meant a hit in performance because the Vulkan backend was just so much faster.

There are of course other open source OpenGL drivers out there that aren’t Zink. The most well known one is probably Angle, a implementation of OpenGL ES by Google. None of them work for us however, because of another terrible decision made many years ago: X-Plane has always used a compatibility profile OpenGL context. What that means doesn’t matter, but the end result is that X-Plane and by extension plugins, rely on the existence of OpenGL commands from the 90s! Most modern implementations of OpenGL will happily ignore everything from the compatibility profile because it’s a nightmare to implement and doesn’t map very nicely to modern hardware at all. But a lot of plugins make use of these old features and rely on the fixed function pipeline. Which, by the way, is also the reason we didn’t just expose Vulkan or Metal to developers. Writing either a Vulkan or Metal renderer requires a ton of overhead, is deeply complicated and error prone. Writing correct code requires testing on different hardware, reading a few thousand pages of specification text and having a good understanding of the underlying hardware. Most plugin developers don’t venture past the fixed function pipeline, it would be absolutely unreasonable to expect them to spend the time and effort involved in this.

What’s a Zink?

Luckily we don’t have to throw any developers into the deep end because there is Zink. Zink is part of the Mesa open source project and is a backend for the Gallium driver, which is the OpenGL frontend provided by Mesa. Okay, lots of big words here, let’s simplify this a bit: Gallium implements OpenGL 1.0 to OpenGL 4.6, which basically means “all of OpenGL”. But it doesn’t actually do anything with it, it just does all of the heavy lifting required to make OpenGL work. Backends are what actually turn the intermediate data that Gallium produces into real commands to be executed by a GPU. There are a lot of these backends: For example there are multiple software renderers that just use the CPU, there are implementations that talk to AMD GPUs, Nvidia GPUs, Intel GPUs, things I never even heard about, it’s all there. But among all of those backends there is also Zink. Zink just takes what Gallium produces and builds Vulkan commands out of it to be executed by any Vulkan capable hardware. This is what makes Zink so great for us, it’s a real OpenGL implementation that includes all of the hard and complicated bits we need to make plugins work.

Of course I’ve made it sound easier than it really is, “just” writing a Gallium backend that magically speaks Vulkan is a lot of hard work. The unsung hero of all this is Mike Blumenkrantz, head honcho and lead developer of Zink. He’s spent years getting Zink to the point it is at and is contentiously working on improving it, both in terms of supported features as well as performance. He’s also an absolute legend and none of this Zink interop X-Plane stuff would exist if it wasn’t for his help, not just in getting Zink to where it is but also answering tons of our questions during the integration. Big shout out to Mike! While I’m doing shout outs, it would be unfair of me to not also mention AMD. While they are partially the reason we are here today, they also provided us with help and driver updates to make Zink work together with X-Plane and every engineer of theirs that I have met along this journey has been nothing but kind and helpful.

I’m a user, how does this affect me?

If you are on X-Plane 12.04b3, open your graphics settings and enable the Zink backend. By default we run with the native OpenGL backend for compatibility reasons, although the long term goal is to switch to Zink exclusively, but not anytime soon. There is a chance some or all of your plugins will explode, we’ve done testing with third party developers on this, but the area touched by this immense and we can’t test every plugin out there. If it breaks, no worries, please file a bug report and let us know, fall back to the native OpenGL backend and try again in the future. The idea behind Zink is to make it as much a “it just works” thing as possible, but it’s the first step and if it isn’t perfect right out of the gate, I hope you have some patience with us. I’m saying this because like I said, the surface area touched is immense here and shipping a whole graphics driver with an application isn’t really something super common and, as I have found out, sometimes breaks stuff.

The good news is that Zink is open source and we are building it ourselves, which means that for the first time we can actually see under the hood when things explode. I have very high hopes that this will help us track down issues much faster than usually. Normally drivers come with all debug data stripped, so a few times I have seen bugs that just end somewhere in the driver with no way to tell what even happened or how to reproduce it. Sometimes we don’t even have any information at all because it got so thoroughly muddied.

I’m a developer, how does this affect me?

Well, same as above: Test your plugins, file bugs, be patient. But also, there are a few things you might want to be aware of in general:

First, X-Plane now finally lets you enable a debug GL context. If you run X-Plane with --debug_gl, X-Plane will make a debug GL context for you and then wire up the necessary callbacks. By default it’ll print all messages into stdout and errors get a big in sim pop up. But you can always redirect it to something of your choosing by calling glDebugMessageCallbackARB() with your own callback. Please don’t ship plugins with a handler enabled though, because it might lead to other developers not being able to set their own callback as there can only be one. The debug GL context is available when running through Zink and also the native GL driver.

Gotcha wise, there are two that I’m aware of:

  • In theory you can make a shared GL context for background GL processing, but it might not be 100% stable. I’m still trying to track down an issue somewhere in the stack that leads to resources being incorrectly deleted, so if you run into issues with a shared GL context, this might be it. Please try it though!
  • Don’t disable and/or enable GL_FRAMEBUFFER_SRGB, this will lead to all subsequent rendering to disappear. This bug I have tracked down further into Mesa and the problem is that the driver will create a copy of the image to add or remove the sRGB bit, but it never ends up copying the result back over. In theory this should be handled by just a view on the same image without any copies, but either way this is currently broken.

If you want to test Zink as part of some CI solution, you can also run X-Plane with --zink or --no_zink through the command line and it’ll override whatever was set in the graphics settings.

I’m on macOS and I feel left out

First of all, I’m sorry to hear that. 12.04 has great things for macOS users as well that I’m sure you’ll love. Long term, we are having ideas of running Zink on macOS too, just this time on top of Metal. GL on macOS is already emulated through Metal, it’s just done by Apple without visibility or ways to tap into that. We have a bit of a pipe dream of running plugins on top of Zink on top of MoltenVK on top of Metal, but this is purely in the ideas bin right now and no code for this has been written. There would be two advantages for this approach though: First, Apple has deprecated OpenGL already in macOS and while I do believe they will continue to support it, lest their pro users will climb on their roof and shout bloody murder, they clearly have no interest in expanding OpenGL support any further. Secondly, if we get OpenGL bridging down to just Zink on all platforms, it’d be a boon for developers because they can target just one OpenGL implementation and cover all platforms in one go. It’d also finally bring OpenGL 4.6 support to macOS, which is currently held back to OpenGL 2.1.

Posted in Development, News, Plugins by | 20 Comments

Free Form Friday: Lights, Water, Frost

First, I appreciate everyone’s cooperation with the RFC on scenery; we’ve had an ongoing discussion in our developer Slack as well as the comment section, and I don’t think I had to nuke any off-topic comments. The feedback was wide-ranging and there’s no one clear answer but it does give us a really good picture of how the scenery system is working (and isn’t working).

It’s Friday, so let’s do something completely different – her’s some show and tell from a few things people have been working on things week.

Light It Up

Alex has been recalibrating the runway and airport lights for the new photometric lighting engine. This spurred an internal discussion about how best to calibrate artificial light sources. Does the author specify the luminance of the bulb before a tinted plastic housing goes on top (this way is good if you have the bulb specs from the internet) or based on what you’d measure when the finished light is tested? (This way matches FAA specs for airport lights.)

After going back and forth a few times, our answer is “well, both”, and we have a system that now allows this, which should solve use cases for both aircraft (where often the bulb properties are known because you can look up replacement parts) and for airports (where the FAA has standards for the light’s final results).

Something to keep in mind: urban airports are quite dark compared to their surroundings. Ther are very few light sources near the runway that aren’t tightly controlled for brightness and direction. I used to fly over KLAX on a regular basis at cruise altitudes (commuting from San Diego to San Francisco for work) and KLAX was always an inky black void in the sea of lights that is the LA basin; at 34,000 feet no runway lights are pointed up at us.

Wet Surfaces

Petr and Sidney have been working on the weather surface shader, which applies water and other weather effects to surfaces. This is how we dynamically make the pavement wet when it rains.

The shader is tricky because the effect of a surface being wet changes a lot once the water forms a real puddle. When I took my kids to their swim lesson, I couldn’t help but notice the useful reference material all over the place.

A rough wet material – reflections change with angle in X-Plane and real life

Stop Writing on the Windows

I must be a dad, because I get annoyed when my kids get finger prints all over the windows when they “write” things in the frost on a cold day.

Turns out Sidney does the same thing.

What you’re seeing there is programmer art. Programmer art is when the programmers make their own texture files to test code. In this case, Sidney is testing the defrosting system for windscreens, which use a special texture to specify the pattern of defrosting. This lets artists control the defrosting effect and get faster defrosting near vents.

Another “behind the scenes” thing you can see here: that popup window is a set of internal controls for testing, debugging and developing the windscreen effects. The parts of these internal controls that are generally useful will become third party developer tools (like the texture browser and particle system editor in X-Plane 11).

Cessna In Spaaaaaaaace

Daniel rewrote the planet shader. In X-Plane 12, water is treated separately from land (so that it can be 3-d). The new planet shader shows a far view of water and a far view of land at the same time and correctly shows atmospheric scattering, which is normally pre-calculated in a special “froxel cache” for regular scenery.

If you haven’t noticed the pattern, it’s that the art team’s screenshots all tend to look good enough to ship, and the programmer’s screen shots tend to be very, very silly. In this case, the Cessna in space is pretty silly, but what we were looking for was the smooth atmospheric effects all the way out to the horizon.

Here’s one more goofy programmer screenshot:

I was calibrating the runway lights according to Alex’s spec, and typed an extra 0 into one of the internal art controls by accident. The result was this fantastic screen shot.

What you’re seeing is: the billboards for the runway environment are accidentally huge and are filling up the entire reflection cube map. The reflective underside of the Cessna wing picks up this blue lights and it looks like a rave.

Posted in Blooper Reel, Development, News by | 34 Comments

Have You Heard the Good News About Elixir?

[This post is a “behind the scenes” look at the tech that makes up the X-Plane massive multiplayer (MMO) server. It’s only going to be of interest to programming nerds—there are no takeaways here for plugin devs or sim pilots.]

[Update: If you’re interested in hearing more, I was on the ThinkingElixir podcast talking about this stuff.]

In mid-2020, we launched massive multiplayer on X-Plane Mobile. This broke a lot of new ground for us as an organization. We’ve had peer-to-peer multiplayer in the sim for a long time, but never server-hosted multiplayer. That meant there were a lot of technical decisions to make, with no constraints imposed by existing code.

Read More
Posted in Development, Really Really Really Really Boring Stuff by | 21 Comments