A user asked me to write a little bit about Vulkan. My first reaction was to not post anything for a simple reason: Vulkan is a feature for me, not for you. That is, Vulkan does not make you (the user of X-Plane’s) life directly better; instead it makes my development job easier and it makes it possible for me to create a better X-Plane.
Some day if we end up running on multiple drivers (e.g. Vulkan and OpenGL and Metal), you may not be able to tell the difference between the Vulkan and OpenGL version; the sky won’t be more blue, the clouds won’t be more puffy. I can’t think of any features exposed by Vulkan that aren’t in OpenGL 4.x with extensions now — we already have sparse memory, tessellation and compute in OpenGL. (But then, you might actually be able to tell because framerate might be higher.)
Anyway, having finished reading the (700+ page – that’s what down time in the airport is for) Vulkan spec last week, the rest of this post is my view on Vulkan as a 3-d graphics developer. This is definitely an “inside baseball” kind of post, so if you want to go surf cat videos, I won’t be offended!
The Problems with OpenGL
For an application like X-Plane, Vulkan is an improvement over OpenGL; to understand why we have to look at the problems with OpenGL as an API that allows applications to communicate with 3-d hardware drivers. There are a few:
- OpenGL’s approach to multi-core and threading are antithetical to performance. This is really the straw that broke the camels back for me and OpenGL. Developers who know me know that I’m not a “burn it down and start from scratch” kind of guy*. But the threading model in OpenGL requires drivers to hurt performance with safety checks and locks that an application can’t get away from. This isn’t something you can just fix with an extension.
- OpenGL’s object and binding model also make multicore performance difficult. The use of a “current” object in a context and the ability to radically change objects after they are built mean lots of driver paths require internal locks.
- OpenGL’s compatibility is its greatest strength and greatest weakness. The original plan to rebuild the object model in OpenGL 3.0 died before it was released. Instead the ARB came up with a plan to optionally deprecate APIs. Every vendor of OpenGL except for Apple has chosen to keep backward compatibility with everything. That’s great for keeping old apps working, but it means every change to OpenGL is expected to work with everything else there ever was, ever.
- OpenGL requires that shaders be compiled by the driver. This means an application is exposed to idiosyncrasies in the compiler of each driver we ship with. This isn’t as bad as it used to be, but writing shaders is still a matter of write-once, check everywhere.**
How Vulkan Helps: The design principles behind the Vulkan API address all of these issues.
- The biggest single feature of Vulkan is its new multi-core friendly threading model. Vulkan is “externally” synchronized, which basically means applications can do whatever they want, but have to talk to different parts of the driver from different threads. To use an analogy: OpenGL is filled with traffic lights. Vulkan doesn’t even have stop signs, and it’s up to two drivers to not be on the same road at the same time. (As application developers, this is a great setup, as we know what roads we are on and can plan to not have collisions.)
- The object model clearly separates expensive creation operations from inexpensive usage operations. Expensive object creation can be done on worker threads or at initialization time. Objects can’t be radically reconfigured once they are built, so the small changes that are allowed to existing objects aren’t slow.
- Shaders are compiled ahead of time into an intermediate representation; no more shader compile fails after a driver update.
Vulkan is a smaller, lower level API with clear performance guidelines and a focus on multicore from day one. This is a good fit for what we need with X-Plane.
The Problems with the OpenGL Ecosystem
The OpenGL ecosystem is the collection of all of the companies and programmers working with OpenGL. This includes the vendors of graphics chips who create OpenGL drivers (NVidia, AMD, Intel, Imagination, Qualcomm, ARM), OS vendors who provide OpenGL interfaces (Apple and Google), the major game engine developers that have the ear of the hardware vendors (think Unreal Engine 4, Unity, etc.), the major CAD application developers, etc.
More serious for OpenGL than the problems of the API is the state of the ecosystem.
- OpenGL’s API is underspecified: there is no comprehensive conformance test for OpenGL, so we can’t really know if an OpenGL driver works or is buggy.
- OpenGL’s API is underspecified: no performance guarantees or even recommendations are made. If you ever look at the tech blog Chris and I maintain, it’s full of posts about the latest witchcraft I’ve found to make vertex throughput go faster. That stuff isn’t part of the GL spec, yet you have to know it to build a real-time graphics application.
Given the lack of specifics, application developers and driver writers end up locked in a sort of death-spiral:
- Driver writers observe the behavior of applications and change the driver behavior to work around applications. This can include trying to improve performance and trying to bandage around broken behavior. (Since games are the typical benchmark for new graphics cards, NVidia and AMD are hugely incentivized to make games run faster by any means possible.)
- App developers observe the behavior of the drivers and change application behavior to work around driver issues. In X-Plane’s case this often means intentionally not using the optimal code path for driver stack X because it is slow. If the driver team ever fixes code path X, X-Plane still isn’t using it; when the driver team looks at performance they then decide to improve code path Y (that we are using, the backup plan) because that is what will make our app benchmark faster.
How Vulkan Helps: Vulkan helps by being much more highly specified in terms of both conformance and performance.
- Vulkan is a much smaller, simpler API – OpenGL has simply become too complicated to completely test. With Vulkan, we can hope to test the entire driver.
- Vulkan is being built with an open source test suite from day 1, with the goal being to build up a huge number of tests so we can know that a given driver is correct.
- The Vulkan API is very clear about what operations are fast and what operations are slow. An application that uses the fast API can expect fast performance on those code paths. Guessing is not required.
Downsides to Vulkan
For smaller OpenGL application developers like Laminar Research, I can think of just one down-side; it’s one that I haven’t seen a lot of application developers talk about, probably because it requires admitting that we (the app developers) might not be as smart as those driver guys.
OpenGL is a higher level API; OpenGL applications leave some of the hard problems of 3-d graphics up to the driver. This means that some of these very hard, very important performance problems are being solved by a team of engineers from the company that built the hardware. They have resources, they know everything about the particular hardware they are coding for, and performance is job one.
Vulkan is a low level API; with Vulkan, some of those hard problems will be solved by Chris.
Ha ha…no, I’m totally kidding. We don’t let Chris play with pointers or any other sharp objects. That code will be written by me, and it’s a safe bet that I know less about the hardware than the driver team and have less time to do pure performance work then all of the engineers at Nvidia or AMD who work on the OpenGL stack.
This is a calculated risk for Vulkan as an eco-system. The hope is that (1) with specific information about performance as part of an API, us application developers won’t screw things up too badly and (2) because we (the application developers) know more about our specific applications, we can optimize performance in ways the driver guys can’t because they don’t have the bigger picture. One of the hardest problems in a graphics API is conveying intent; OpenGL drivers spend a ton of code trying to guess what the application is trying to do. Vulkan solves this problem by letting the application make performance decisions itself.
Next Steps
If you know OpenGL but don’t know a lot about how 3-d graphics hardware really works, reading the Vulkan spec is a little bit like believing that Santa Claus brings your presents down the chimney and then [spoiler alert] one day reading a 700+ page PDF that explains how your parents actually buy the presents a month or two in advance, wrap and hide them, and then sneak them under the tree while you are asleep.
For X-Plane, the Vulkan spec makes clear what types of operations future drivers will support, what will be done for us, and what we have to do ourselves. This gives us a good framework to then incrementally build next-generation rendering code in X-Plane that is “Vulkan-friendly” – even if it is still using OpenGL. My guess is that this new code will be faster than the code it replaces even before we change drivers.
Once we have the rendering code restructured and modernized, we can then set it up to run on Vulkan or OpenGL, taking advantage of the Vulkan pathways where they exist.
One final thought: I have no idea how the actual experience of coding for Vulkan will be. It may be that everything “just works”, or it may be an exercise in frustration. Once we’ve been through a full port I’ll post a post-mortem, but I think it’s too soon for anyone out there to have good realistic feedback on a full Vulkan porting experience from OpenGL.***
* And when people suggest ground up rewrites I usually link to this.
** For what it’s worth, the driver shader bugs I see (and the ones that really take up my time) are bugs in the back end of the compiler, where optimized machine code for the GPU are generated. Vulkan isn’t going to fix this; Vulkan removes the front end of the compiler from the driver but not the back end.
*** Yes, there are games running on Vulkan now. But if your game is already running on multiple APIs, that’s different from porting a straight OpenGL app. The final spec and roduction drivers haven’t been out long enough for anyone to be able to say “I ported half a million lines of OpenGL code to Vulkan and here’s the result.”
Ondrej has posted a public thread about the new version of the Blender 2.7 exporter here.
The 3.3 release is the first release where we (Laminar Research) have worked closely with Ondrej to build what we hope will be one of the future cornerstones of modeling for X-Plane.
If you are currently using Blender 2.49 or AC3D, I expect that 2.73 will provide the best way forward for modeling in X-Plane.
New Stuff
The new release has a few major features, all aiming to create a new modern work-flow:
- All animation bugs are fixed. (At least,we think – if you find one, please report it ASAP!) This means animation is WYSIWYG. Armatures are supported for animation as well as animated data block containers.
- The exporter understands all modern OBJ features, including ones scheduled for release in X-Plane 10.50.
- Instancing is handled via a single option with exporter validation, so you don’t have to know how instancing works to get instancing.
- The material rules are validated, and materials are found automatically; you can simply model as you want and Blender will do its best to export it or tell you if there is a problem.
- Specular and Normal maps are ‘merged’ together from two separate sources. This lets you set specularity and normal maps in separate material channels in Blender for a more WYSIWYG approach. It also means no more messing with Photoshop to combine these layers.
The goal of many of these is to hide the idiosyncrasies of X-Plane’s modeling format and provide a cleaner, more artist-friendly view of modeling.
Regarding instancing: the model we have adopted is the one we used internally on the 2.49 exporter: you (the artist) tag an export as either “instanced” or not.
- If instancing is on, the exporter writes only data to the OBJ that will be hardware-instanced by X-Plane. If you do something that cannot be instanced, like animation, you get an export error telling you what you have to remove.
- If instancing is off, the exporter writes the object normally.
The win here is that you don’t have to know the (complicated) instancing rules; set instancing for the scenery objects you need to make fast in bulk (e.g. a luggage cart, a house, something that will be used many times in a small area) and you’ll get optimal output.
Optimization – Coming Soon
The goal of the 3.3 release was to set up an environment where authors could work using the new work flow. We have not finished optimizing the OBJ output.
If you are using the existing 2.7 exporter for airplane work, the output should be similar in performance. If you are using the 2.49 exporter, the new output is (like the current 2.7 exporter) not as well optimized.
In a future update, we will tighten up the generated OBJ code; this should not affect anyone other than producing better OBJs.
Compatibility
The new exporter should be fully work-flow compatible with the previous Blender 2.7 exporter; if you find your existing project does not work, please file a bug!
Our plan is to create a migration tool for Blender 2.49 projects; this will forward-convert the datarefs on annotations, manipulators, and object properties from 2.49 to 2.73 format. This lets authors using 2.49 move forward to 2.73 and have a migration path for existing content. (This work is not started yet, but is planned – we have our own aircraft we need to keep working on.)
Things have been quiet with the mobile product recently but that’s only because we have been working on some new features that we didn’t want to talk about until we had them running reasonably well on a variety of devices. Well, we have made some great progress and now I’m happy to start talking about it.
What’s the big secret?
So what have we been working on…..? Taking the entire X-Plane 10 Desktop flight model and aircraft systems! That means all of the physics, all of the systems, all of the datarefs, as well as 99.9% of the panel system and instruments*. I cannot emphasize enough how unprecedented this is on a mobile device…and it will be free of course. Read on for specifics…
Flight Model History
Let’s rewind time back to 2007 when the original iPhone was being released. We had about 25MB of memory to work with and a very limited processor. There was absolutely no choice but to prune the flight physics and all of the systems back to the bare minimum. This has been our mobile product’s foundation for the past 9 years…a reasonably good approximation of flight physics and systems that is adequate for mobile devices…but very limiting for us as developers and also a bit limiting for users as well. Lately, we’ve been moving over pieces of the desktop flight model a little bit at a time (for example, Airliners required a better slat and flap system) but it’s time consuming and tedious.
Where we’re headed…
Over the last couple of months we’ve been reorganizing our systems and now have most of the desktop systems running on our mobile product…even on the older devices that we support like the original iPad Mini/iPad 2/iPhone 4s. We’re still actively integrating the systems so it’s not ready for release just yet, but a lot of the work is done.
So what does this mean for users? Archimedes said “Give me a lever and a place to stand and I will move the earth.” The mobile product sharing the flight model and systems with desktop is a HUGE….MASSIVE….LEVER. It means that mobile instantly gets an FAA Approved flight model…the same one that real pilots train on. An instantly improved autopilot, no more bounced landings (unless you fly like Ben…in which case you’ll still bounce ;)) full electrical, hydraulic, engine, prop, fuel, radios, navigation, pressurization, starter, trim and gear systems.
With all of those systems available in their entirety, it means that the beautiful 3D cockpits that our artists have been developing can come to life with interactivity to touch and manipulate all of the same systems that you can on desktop. Start/Shutdown the aircraft the right way, tune all of the radios, operate the full autopilot etc.
This is the symbiotic relationship that we’ve been talking about since the launch of V10 Mobile. Mobile feature development will improve the Desktop product, and Desktop features will trickle down into the Mobile product.
When is this happening?
Soon? I expect much of this to be done and the first update to happen by the spring for iOS and Android. It will not be done in one release but over several.
The release schedule and contents are still not completely concrete at this point but if I were to take a guess, I’d say that the first release will include the complete flight model. This will be an incremental update for end users because while the flight dynamics will change, the interaction will not change much. It will have the same simple 3 button autopilot and minimal interactivity with the 3D cockpit.
The second and subsequent releases will start to expose much of this new system to users. I would expect to see a new 2D autopilot UI that exposes the complexity of the desktop autopilot…heading, altitude, speed, LNAV, VNAV etc. I would also expect that some of the aircraft panels will have been updated with manipulators that allow you to start touching all kinds of buttons and knobs.
With this kind of leverage, we can release new features faster than ever before. I’ll have more details on that specifically when the time is appropriate.
*We will not have a working 430/530 on mobile in the short term nor will we have a few very uncommon and extreme instruments.
Yesterday we had a bit of a digital download fire-drill: over a dozen Mac users filed bugs or contacted tech support to say that X-Plane couldn’t get their machine ID.
When X-Plane’s copy protection doesn’t work, that becomes the top thing on the priority list, full stop; we never want to see a paying customer unable to use X-Plane.
I contacted a number of users to request detailed information, and from those who I have heard back from, the answer has been consistent: the problem mysteriously vanished just as quickly as it appeared. Some of the users reported making the problem go away by reinstalling or rebooting, but each “work-around” was different, and some users made no changes, making me think the problem fixed itself.
So…the whole thing is a total mystery. While I’m happy to see users flying again as quickly as possible, not knowing what went wrong is disconcerting.
If you are on a Mac and you still can’t use your product key, please do contact tech support by email!
Update: turns out there’s a real explanation – see the comments section. I’m at least relieved that our code didn’t mysteriously go AWOL for one day.
I’m going to keep going with “random stuff I looked at today” and see if there’s something for authors mixed in.
I spent part of today measuring shader and texture changes in our engine under heavy load – my goal was to get a sense of how much data we’d be pushing through a next-gen API (e.g. Vulkan, Metal, DX12) if we just did a straight port of the engine. This was just a fact finding mission.
The only problem was: the numbers were just absolutely awful. Terrible. Unusable!
Then I noticed the other thing: the entire area of KSEA was littered with thousands of Fed-Ex trucks. Just tons and tons of them! Only Fed-Ex trucks on the road, and only Fed-Ex trucks parked on the street.
Wha?
Leftovers For Lunch
The Fed-Ex trucks were a left-over. I do this to myself all the time: I create a dumb custom scenery pack to test some part of the sim and then forget to remove it from my working X-Plane folder.
Before X-Plane 1040 there was a bug where cars and trucks on the road could crash the sim if you viewed them across a DSF tile boundary and the 3-d models were not instanced. This last point is why the bug went unfixed for so long; the car set we ship with is entirely instanced for performance.
So I built a library with a Fed-Ex truck that was intentionally not instanced to reproduce the bug and forgot about it. The custom scenery pack was why my traffic looked silly, and the non-instanced traffic was why my stats showed the rendering engine doing 4x more on the CPU work than it was supposed to.
(Since X-Plane was in debug mode, the framerate was expected to be terrible due to unoptimized code and debug checks running on an old laptop with the scenery cranked to the max.)
So there’s a take-away here and it is:
OBJs in a Custom Vehicle Pack Should Be Instancing-Friendly
There are a few custom vehicle packs for X-Plane floating around the web, and the quality of the objects with regards to performance is mixed and overall not very good – probably some of these packs pre-date X-Plane 10.
Instancing is the ability for X-Plane to draw more than one OBJ in a single instruction to the GPU. We implement instancing by observing your OBJ as we load it and noting whether the OBJ contains anything complicated (dataref usage, animation, lots of material changes) or if it is more or less just a big pile of triangles.
If we have the latter case, then we mark the object as instancing friendly, and when it is drawn, all objects of that type are collected and drawn at once. The instancing code path in X-Plane is thus separate and much faster for both X-Plane itself and the driver.
Since you can have a lot of the same car on the roads, even with a varied collection, it’s worth it to be instanced!
How to Tell If Your Object Is Instance-Friendly
To see if your object is instancing friendly:
- Make a custom scenery pack and place ten of the objects very close to each other (e.g. at an airport).
- Load the airport in X-Plane and in DRE set the art control “terrain/kill_clusters” to 1.
When you do this, all of the instanced objects that come from DSFs will disappear, and all of the non-instanced ones will remain.
Your object will be instance-friendly if:
- It uses no animations
- It uses no ATTRibutes mid-object – use the new GLOBAL properties instead
- For cars, LOD is okay (but non-additive LOD will make the WED test fail). For cars you should only use one LOD anyway.
- Only some named lights are instancing friendly; fortunately the headlight/taillight ones are.
Draped geometry is instancing-friendly, but don’t use it for vehicles.
In the new Blender 2.7 exporter (and our branch of the Blender 2.49 exporter) instancing is made quite easy: you mark an object as “instanced” and one of two things will happen:
- Blender will write only stuff that is instancing friendly or
- The export will fail with an error telling you what you did wrong.
Thus when you -need- something to be instanced (scenery objects, etc.) you just tell the exporter to enforce it.
Here are some things where instancing really matters:
- Repeated buildings in autogen.
- Static aircraft that repeat a lot.
- “Clutter” on the ramp (baggage trucks, etc.).
- 3-d modeled vegetation that gets repeated.
- Cars (both parked and moving)
Here are some cases where it does not matter:
- Aircraft-attached objects. Since aircraft attached objects aren’t usually repeated and almost always have a lot of complicated stuff, instancing doesn’t matter or work here. Instancing is really for scenery.
- Single extremely complicated objects like the Nimitz.
Right now objects drawn with the XPLMDrawObjects API call do not benefit from instancing, but this is probably something that will change in the future, as long as every “instance” is fed through a single XPLMDrawObjects call.
X-Plane 10.45 release candidate 1 is out (and will be available on Steam for users who have selected to get betas within a few days). If you aren’t running betas and would like to try it, run your X-Plane Installer, pick update and check “Get Betas”.
If you are the developer of an add-on aircraft and you haven’t tried 10.45 yet, please try it as soon as possible! We caught a few surprising systems-related bugs and fixed them for RC1, but overall beta bug reporting has been quite low; we can’t fix what we don’t know about, and some bugs might only be reproducible using your add-on.
X-Plane 10.45 is a “small” patch for us in that it doesn’t contain major changes to the code, but it contains a number of features you might like:
- An update to the global airports.
- The global airports won’t conflict with custom scenery – new exclusion technology prevents overlapping buildings.
- Nav data has been significantly updated – lots of bug fixes are in 10.45.
- The GPS data for the G430 now contains IAFs, so you can fly GPS approaches with proper transitions.
- Proper prop torque for aircraft that opt in.
I keep meaning to post about other stuff we’re working on; I’ll post an update soon. But for now, try 10.45 before it goes out the door!
MH1212, developer of the Prefab Airports for X-Plane, requested this feature, and it looks like we are going to be able to sneak it into X-Plane 10.45. (If we hit bugs, it might get pushed out to 10.50, but so far things look okay.) The feature is: the ability to exclude objects by airport ID without using exclusion zones.
Right now when a custom scenery pack replaces an airport (via apt.dat), the old apt.dat is completely ignored. But the DSF-based overlay objects, facades, etc. are included; the custom scenery pack has to use exclusion zones to kill them off.
With this extension, the DSF-based overlay objects in a scenery pack can act as if they are in the apt.dat file, disappearing when the apt.dat airport is replaced. This means that when you replace an airport (via apt.dat file) not only do the runways go away, but so do the overlay elements.
Here’s the win: we can export our global airports from the X-Plane Scenery Gateway this way, and custom scenery will remove the overlay elements automatically just by replacing the apt.dat, even if no exclusion zones are present.
Here are some details:
- The scheme works if the underlying airport is correctly marked as having its objects and facades “inside” the airport. So unlike exclusion zones, this scheme works if the underlying airport is modified, not the overlaying airport.
- This is a new scheme – no existing scenery already does this; scenery must be re-exported to gain access to this functionality.
- The functionality requires the latest version of X-Plane, but is harmless to old X-Planes – the DSFs will still load.
- Exclusion zones still work and are still recommended; if you are making custom scenery and you are on top of autogen or an old scenery pack that is not modified using this new scheme, only an exclusion zone will save you.
There are two big advantages of this scheme:
- We (Laminar Research) re-export our collection of thousands of airports on a regular basis, so we can tag the entire set of global airports using this new scheme and have them ready for by-airport-ID exclusion very quickly. So this scheme will start to help conflicts immediately.
- The scheme doesn’t require modifying the overlying scenery at all. There are freeware airports that are effectively orphaned – the author cannot be found and the license doesn’t allow the community to modify them*. Since these airports cannot be legally redistributed with exclusion zones, this technique will help.
Once X-Plane has this extension and the global airports are re-exported using it, global airports will fully disappear when any custom scenery pack replaces the airport by apt.dat, even if the custom scenery pack doesn’t have good exclusion zones.
This functionality will be available to third parties in WED 1.5 when it goes beta. In WED 1.5, if an overlay element is in the folder for an airport, it will be excluded when that airport is excluded. If an overlay element is ‘loose’ in the outer level hierarchy, it will not be excluded by airport (but will be affected by other pack’s exclusion zones).
Since gateway airports already have the objects “in” the airport folder, they are already authored to make this scheme work.
If you create your own DSFs using a low level tool like DSF2Text, the DSFLib source code, or something else crazy, I have posted the proposed schema here. That’s a technical link for people tinkering with the DSF format itself, but if you’re in that category, please do ping me to get early test materials. (The new code is also on GitHub.)
Two warnings to custom scenery authors: if you are creating a custom airport scenery pack, especially payware, please read these very carefully:
- This is not an invitation to stop using exclusion zones. There are plenty of scenery packs in the wild that do not have their objects tagged by airport, as well as autogen and all sorts of junk that can be under your payware. If your airport doesn’t have an exclusion zone and it conflicts with another pack, it is your fault. Go add exclusion zones, like I told you to do years ago.
- If a scenery pack from X-Plane Airport Gateway is removed by your pack (by airport ID) then our exclusion zones are removed too. This means that if trees on the runway have been removed by an X-Plane Airport Gateway airport, you will no longer get those exclusion zones for free. You must exclude those trees yourself! (If you put exclusion zones in from point 1 this is a non-issue.) Test your airport with global airports enabled and disabled to make sure your pack is good.
* As a side note I consider it a real problem that airports get uploaded and shared with the community under licenses that don’t allow for abandon-ware to be maintained. It’s clearly the right of the author to use any license you want, but as a community I hope we can encourage freeware authors to use a permissive open license.
X-Plane 10.45 Beta 1 is out – here are the release notes. This is a small update in terms of code change; the new feature is updated global airports and nav data, as well as a bunch of bug fixes; the beta period should be relatively short.
To get the new beta, run the X-Plane installer, update your copy of X-Plane and make sure “get new betas” is checked.
Prop Torque
Prop torque is fixed in X-Plane 10.45 beta 1; the calculation was incorrect (causing too much torque from props) in previous versions of X-Plane.
In order to get the new correct physics, you must resave your aircraft in Plane-Maker 10.45 beta 1.
We have heard of authors doing a number of things to lower the effects of prop torque in old versions of X-Plane, including having plugins apply a counter-torque and tweaking the physics parameters of the aircraft itself. Because we cannot know if an aircraft has such work-arounds applied, the prop torque fix is applied only to aircraft resaved in 10.45 beta 1 or newer. This way the fix takes affect when an aircraft author can remove work-arounds.
WorldEditor 1.4.1 is out – it’s a very small patch to 1.4.0 that increases the strictness of validation to catch a number of errors we found in the last export from the X-Plane Scenery Gateway.
Please upgrade! WED 1.4.1 will become the mandatory version to upload to the X-Plane Scenery Gateway in a few days if we don’t find any major bugs.
64-Bit WED
Last week I completed most of the work to modernize WED and the scenery tools for modern OS X/X-Code, which finally lets us build 64-bit Mac scenery tools. (This also lets anyone compile WED without having to find a Mac from the dark ages.)
WorldEditor 1.4.1 will be the last 32-bit build of WorldEditor. The next update (WED 1.5) will be 64-bit on all three platforms: Mac, Windows and Linux. This transition will also raise WED’s minimum operating system for OS X to OS X 10.7 (Lion).
Having WED be 64-bit on all platforms should solve problems that advanced scenery authors are seeing where WED runs out of memory when editing a custom scenery pack with a lot of textures or reference imagery.
WED 1.5 Features
I am not sure of the feature list for WED 1.5 yet; 1.4.1 has been kept intentionally small to get a quick patch out. (The longer we have a WED that does not properly validate airports, the more weird stuff ends up in the scenery gateway.) Two features are very likely for WED 1.5:
- 64-bit on all operating systems.
- Support for apt.dat file format extensions to coincide with X-Plane 10.50.
My plan is to have WED 1.5 ready for beta before X-Plane 10.50 is ready for beta, so we can test X-Plane’s new capabilities with WED.
We have internal notes on the apt.dat 1050 extensions; I’ll get an RFC posted in the next few days.
This is a “Request for Comments” post—please discuss the proposal in the comments. Per our standard procedure, if you comment asking about the Oculus Rift, your comment will be piped to /dev/null.
X-Plane started collecting anonymous usage data in version 10.40. I used some of that data to compile this infographic you might have seen around the internet. It’s fun and colorful and has some interesting tidbits of data. However, just because I thought that those statistics were noteworthy doesn’t mean that you did.
So, is there anything else you, as third party developers, want to know? Is there information missing from the infographic that would help you decide where to put your development energy? Do you want more specific details about anything mentioned in the infographic? We have all kinds of statistics available, from what languages are used the most, to the most popular screen resolution.
If you’d like to have more information, how often would you like to see it, and what format would be the most helpful? Spreadsheets are easy and can be processed often, and we could throw some graphs in there to make them less boring.
Any of this sound appealing to you? Let us know in the comments!
