Blog

SDK News – 12.2.0 | “Chockingly” good fun

The X-Plane 12.2.0 beta is finally here! This update has been a labour of love from the team for many months, and we’re excited to see so many users enjoying the changes. The stars of this show go to Daniel, Daniela and Maya for their meticulous commitment to enhancing the atmospherics of the sim. Alas, this is a developer website. So let’s glance at some of the changes relative to our third parties.

Read More
Posted in News by | 7 Comments

SDK News – 12.1.4 | Scenery Gateway & New Assets

Hello everyone, and welcome back to the blog post (quite some time right?). We have recently released 12.1.4 as a beta, and we highly encourage you to check it out here. There is some nice content released, that makes for an exciting appetizer for the new year. Whilst we don’t expect to be on this beta for too long (famous last words), most of the new additions will likely be subject to long-term feedback. Please message in support!

One of the major additions for this release is more content and updates for our scenery gateway artists!

Read More
Posted in News by | 4 Comments

SDK Update : Web API v2

X-Plane 12.1.4 Beta is here! And with it, comes another extension to our WEB APIs. Both of which have received extensive powers surrounding commands.

Read More
Posted in News by | Comments Off on SDK Update : Web API v2

Around the Office: Friday the 13th Edition

Last week Marco and I were on a live stream and had a chance to talk about some of the upcoming developments we’re working on; next month Marco will be full time with us, but for now here’s a few notes on things making progress in the lab. I’m sure publicly discussing them on Friday the 13th will have no unexpected consequences. (Knocks on wooden desk repeatedly.)

We should hopefully have a release candidate for 12.1.2 next week – this week the team was fixing crash bugs, and we’re down to trying to finishing up stability. Crash rates in the beta look good enough to ship. (Please consider turning on analytics – we don’t collect your personal data but we do record crashed vs non-crashed sim runs – this is how we know whether stability is getting better or worse!)

12.2.0

Dark Cockpits: Art team is evaluating Maya’s exposure fusion work. Generally things look better than the shipping product, but we discovered yesterday that the indirect lighting environment is pretty weird on cloudy days. We’ve been fixing bugs, removing old hacks we no longer need, and I’m optimistic that the update should be both better looking and closer to reality.

We also have some fixes to the PBR material model that may get X-Plane closer to Blender and Substance Painter 2. This is a double-edged sword: we don’t want to change the material model such that everyone has to repaint everything (that would be too much both for our team and for add-on makers) but we do want X-Plane to be as close to WYSIWYG possible to make development faster. Art is evaluating these changes too.

We’re targeting 12.2.0 (a “major free update”) for these changes so we can run a substantial alpha and beta program and give add-on makers time to report bugs.

12.1.X

ATC, Weather: we have two minor releases before 12.2.0 making their way through testing. The first is ATC with SIDs and STARs – as of now it looks like that will ship next, but all releases are subject to change based on bugs.*

The other update is a weather update, and it looks like it may have some substantial features:

  • New in-cockpit weather radar, with SDK support.
  • Fixes for real weather bugs, including jumps in pressure altitude (which are driving the autopilots crazy) and some fixes to cloud visuals.
  • Plugin-controlled weather across multiple locations.
  • Better weather sync over the internet.

As of now the weather branch also has network sync of trucks and jetways to external visuals. This only affects users using external visuals but for those users, it’s a big feature, and it’s also an important foundational technology for us.

* In the past we have announced “X” is next and if that code was buggy, we’d just delay shipping anything until we fixed it. We’re trying to be more flexible and ship what’s ready first, so good code doesn’t have to wait for unrelated bugs.

Posted in Development, News by | 20 Comments

Webservers, Documentation, and Terrible Titles

X-Plane 12.1.1 is out! This is a quick “bug fix” patch on X-Plane 12.1.0. If you could not load the sim due to problems with XPLM_64.dll, please update using the installer to fix it. Full notes here.

Websocket-To-Me Time

Besides fixing bugs, X-Plane 12.1.1 enables X-Plane’s web API*. Basically we were asked for this so many times at FSExpo that Chris and Daniela put the remaining work on the fast track.

Our plan is to build several services into the web server; the web APIs will not be exact mirrors of the plugin SDK, but will cover enough functionality to build wide range of apps. We have plans for:

  • Datarefs (shipping now)
  • Commands (in developement)
  • Initiializing Flights (in development)

Documentation on the new web APIs can be found here.

Doc-It-To-Me Time

X-Plane alum and fellow X-Plane-10-survivor Tom Kyler is back working on developer documentation for us, and has finished a first release on some of the new X-Plane 12.1.0 features:

Tom has big plans for X-Plane’s documentation; one thing that’s great to see in these docs is really good illustrations based on real sample 3-d models and test projects.

The Devil Is In the Details

A detail texture is a repeating, high detail pattern that adds high-res detail to an otherwise lower resolution texture. Detail textures let us add fine detail at high resolution without using a ton of extra VRAM efficiently. We use detail textures with bits of “gravel” to make the runways look more realistic.

We introduced detail textures over a decade ago in X-Plane 10 to enhance ground detail around airports and in the new (at the time) autogen cities.

What we did not do was give them a good name. At the time we called them “decal” textures. This has turned out to be incredibly confusing, because in every other game engine ever, a high-res texture applied over the entire material (which is what we have) is called a detail, and a decal basically means “sticker that you stick on somewhere”. Detail textures make the ground look more rocky, decals add blood spatter and bullet holes to the walls in your zombie-shooter game.

So moving forward, we are going to try to call detail textures “detail textures” wherever possible, to be consistent with the norms of content creation. Tom and Maya will be updating labels in Blender and doc to be consistent about this.

For X-Plane 12.1.1, Maya has extended the detailing system in two ways:

  • Detail textures work on OBJs and not just in the scenery system, so aircraft authors can add detail too.
  • Detail textures can affect the bumpiness of normal maps and not just the color of albedo textures, so detail textures now interact with the lighting model in realistic ways.

You can get the 4.3.3 beta XPlane2Blender plugin here to use the new detail textures. Maya is planning on a release Real Soon Now™.

* Please note that while the dataref API does use websockets, most of our web APIs are conventional REST requests over HTTP. I did consider “The X-Plane developers never REST..until now” as a section title.

Posted in Development, Documentation, News by | 7 Comments

What Gets Released Before Vegas Stays Released in Vegas

The X-Plane 12.1 release candidate is out today!* The last twenty four hours have been a mad dash to get the release candidate posted before we head to Las Vegas for FlightSimExpo 2024. If you are attending, stop by the X-Plane booth – there will be a bunch of us there including myself, Austin, and Marco, our new release manager.

All of this is a little bit exciting because we can’t recut the release candidate while in Las Vegas – one of the machines involved still requires a human to sit in front of it. We’ve been racing to get the RC done while we still have access to those machines, and the build system responded as you’d expect – by failing in all sorts of new ways. My plan is to just not breathe until I’m on the plane tomorrow.

(*) Because this is a release candidate you still have to check “get betas” in the installer to opt in to getting the RC; once the candidate has been out for a week, if nothing huge goes wrong, we will declare it final and it will become the official update for everyone.

Posted in News by | 2 Comments

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 | 21 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