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.
X-Plane 10.45 fixed one of the big “ecosystem” problems with the global airports by excluding airport objects by ICAO code. This makes the global airports much less likely to conflict with custom scenery, even if that custom scenery lacks exclusion zones.
For 10.50, I am looking at another change to how we manage airports that should help gateway authors: per airport control of flattening.
As of X-Plane 10.45, airport flattening is a user setting; a user can pick to have all airports flat, or all airports follow the terrain contours.
This is a rather silly setup. One size does not fit all for airport flattening, and the author of the airport is more likely to know how the airport will look with/without flattening than a user who is flying to that airport. It certainly isn’t efficient to have everyone in the X-Plane community set flattening individually without authors being able to set up their airport the way they want.
From what I’ve seen, there are two legitimate uses of airport flattening.
- To fix bugs in the underlying terrain, e.g. if the DSF is screwed up, then the airport may need to flatten it to make the airport usable at all. We want this to be the exception, not the rule. (X-Plane 10 is more buggy than past X-Plane releases WRT bumpy runways, so this may sound funny right now, but overall we aim to have users be able to fly with non-flat runways.)
- To accommodate highly customized airports where the 3-d models depend on a flat surface.
In X-Plane 10.50, it should be possible (using a new version of WED) to mark an airport as “always flatten”. The expected usage is:
- Users leave “runways follow terrain contours” on, all of the time.
- Authors mark individual airports as needing flattening, e.g. to fix bugs or accommodate custom scenery.
There is one use case that isn’t handled well by this: if an airport needs different flattening based on different base meshes, there is no way to tag that in the airport. But I view this as a fairly difficult problem to solve with existing technology – we would need a 2-d grid matching every custom version of an airport against every version of the mesh ever to exist.
Fixing the Mesh
Please note that this feature is not a replacement for being able to customize mesh elevation at a local airport from an overlay. “Mesh patching” is what we want to be able to do in the long term, but for X-Plane’s engine, it also means a lot of complicated internal changes to how the rendering engine works; customizing flattening is something I can ship now in 10.50 that at least helps.
Flattening is also not a replacement for fixing bugs in the base meshes themselves; one trend I have observed over my decade+ working on X-Plane (!) is that the accuracy of source data keeps getting better. Ten years ago it would be silly to say “how about if everyone just uses the real world values for their scenery and it will just work”. At this point that’s not actually a pipe dream, it is often completely manageable. So my hope is that someday we can reach a point where the terrain is just accurate and everyone uses it.
As of right now I have this code working in X-Plane but I do not have a build of WED that supports it. We are still in the middle of working on 10.50 apt.dat features, so I’m hoping to post something on that soon.
In my previous post, I posted a screenshot of X-Plane 10.50 with the new autogen update we are working on. This is an AG update that includes a bunch of buildings, particularly tall ones; I’ll post a lot more detail no that in a separate post.
One of the main questions in the blog comments was: “how are you getting this pic with 30 fps? Did you get new hardware?”
Well, I did get new hardware; a few months ago I finally swapped in the first-gen 5K iMac with the R295X GPU or whatever it is. (I thought this was latest but I see now Apple has revised the machine and bumped the GPU up a generation.) So that’s a machine with a bit more kick than my older 2008 Mac Pro.
But more importantly: X-Plane’s autogen engine is really fast. It hits the instancing path almost all of the time and as a result it can draw a lot of autogen at reasonable fps.
When X-Plane 10.0 shipped, I could run the autogen + roads maxed out my old Sandy Bridge PC – that was before optimization on hardware five years ago. I think this is one of the things that X-Plane 10 does really well that people tend not to notice; that code path was hot from day 1!
There’s a third thing going on here: I picked my rendering settings to promote AG + framerate; you can do that too. I see a lot of users running with relatively low autogen density and poor fps due to other settings. And clearly people like lots of buildings.
So here are some tips on how to get a lot of autogen and decent framerate.
- Make sure you haven’t overloaded VRAM. As long as everything that needs to be in VRAM, you’re done; there’s no “better”- you just need to not be overloaded. The way to do this is to turn texture res way down, tune up the system, and then at the end increase texture res until framerate suffers; then turn it down one notch. Remember to restart each time to get accurate texture use.
- Start with the GPU underloaded – small window, no clouds, low FSAA. You can turn those up later after you get the CPU utilized. (If the GPU is bogged down you can’t even see what you are doing.) Note that when you do go to crank GPU settings, do this first and crank texture res last, as the high GPU settings burn “extra” VRAM for off-screen buffers.
- Turn down settings that chew up CPU. Considering turning off AI aircraft and turn the cars way way down. If you use a payware aircraft that eats CPU (and many of them do) you may want to keep it so you can see what your “real” performance will be; saving 10 fps by throwing out the aircraft isn’t great if you want to actually fly.
- Turn down settings that amplify the cost of AG. This might be the most important one; in those pics, shadows are in “overlay” and water reflections are way down. When those settings go up, every autogen building is drawn for shadows and reflections, not just in the scene, making the AG many times more expensive. I suggest shadows on the aircraft in 3-d and the second lowest reflection setting.
You Can’t Always Get What You Want
The other day I was forwarded a very (cough) angry customer email; the customer had a gamer-class PC, turned everything in X-Plane up to max, got about 5 fps, and went absolutely ballistic. We see emails like this over and over and over and over again. “How much @#$@# money do I have to spend to turn everything up?”
In the long term, our plan is to change the rendering settings so a high-end gamer-class PC can run with every single slider topped out; if you want some of the super high settings in some areas of the sim by turning down other areas, this will be possible only by hacking the config files, not by the UI. The current rendering settings scheme is simply not friendly to users.
With that in mind, I look at what combinations of settings we can max out in hardware (to the point where the artists intended things to be) and still have good fps. My current view is:
- The AG system itself is there – you can have all of the AG, and assuming you don’t run out of VRAM, the artists aren’t going to create “more dense” AG, just more variety.
- AG + shadows is still not there, and this my next goal for optimization. My intention is to make shadows fast enough that a gamer class PC can run max shadows and max autogen at 30 fps. We’re no there, but I believe this is possible, and I believe that it is possible using OpenGL.*
- The cars are also not there – they’re just too big of a penalty. I certainly think we could get 2x to 3x the car density for the performance cost that the low setting cars have – and that would be a good place to be.
* Computers also just get faster over time, so I suppose I could solve this by taking a ten year sabbatical. 🙂 Seriously though, if the cars would run at playable fps at medium res, I’d be okay to let hardware improvements get us to really dense traffic.
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.
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.
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.)
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.
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.
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.
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.
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.
We’ve been doing some work behind the scenes to modernize our servers; as part of that, I have moved the scenery tools code to GitHub.
The GitHub public repositories are the official repositories for WED and the other scenery tools that live in the XPTools code base; I push my changes directly there.
using GitHub means much faster clone times (since the server we had the code on was getting long in the tooth), better public browsing, and you can do all of the normal GitHub things that you’d want, like forking, making pull requests, etc.
If you are using our CGIT browsing (at http://dev.x-plane.com/cgit/cgit.cgi/) please switch to GitHub; CGIT will be going away soon. Similarly, if you have the code checked out, you should change your remote’s URL to https://github.com/X-Plane/xptools.git.
I mentioned in a previous post that we are working with Ondrej on a next-generation Blender 2.7 OBJ exporter. I am excited for this work because I believe it will greatly improve the artist interface to X-Plane. Let’s use instancing as an example to explain the idea.
X-Plane 10 will sometimes draw scenery objects using hardware instancing. When an object is drawn with instancing, performance is a lot better than without it; the huge numbers of objects you can see in the autogen scenery are due to instancing. But the conditions for instancing are, to put it mildly, complicated.
- The object has to be attached to a DSF. Well, that’s not crazy.
- There’s a giant pile of things you’re not allowed to do in an instanced object – animation, material attributes, smoke puffs, bla bla bla. (The object has to be simple so that the GPU can draw a big pile of objects without the CPU intervening to handle things like smoke generation on a per-object basis.)
- Buuuuut…not every ATTRibute is a problem. You can use ATTR_hard in an instanced object, no problem! But don’t use ATTR_shiny_rat – that’ll kill instancing.
- But wait, there are these weirdo new attributes like GLOBAL_specular that seem to replace ATTR_shiny_rat that do work with instancing.
If you model, and this seems confusing, it’s because it is. You were never supposed to see this!
File Formats for Machines and Applications For Humans
My view is this: the file formats of X-Plane are meant to be seen by programmers, not artists. When was the last time you had to hand-edit an .acf? You just use Plane-Maker. You don’t hand-edit a PNG file or worry about its internal compression – you use PhotoShop.
OBJ should be the same way – you should export from a 3-d tool and never have to look inside the OBJ itself. This means the OBJ8 format can serve two purposes:
- Help X-Plane load models quickly and draw good looking content and
- Maintain compatibility so older scenery continues to load.
Note that “be really easy to understand in Notepad” is not on the list!
Blender the Transformer
Now here’s the trick: the rules for OBJ that a 3-d modeler can present can be different from the rules that the OBJ8 format itself has. And that is exactly what we are trying to do in the new Blender exporter.
Rather than expose global attributes and non-global attributes and all of the crazy complexity of OBJ8, our strategy with the new exporter is this:
- When you export a scenery object, you specify if you want the object to be instanced or not.
- If the object is not instanced, Blender creates the best OBJ it can for this case.
- If the object is instanced, Blender tries to create the best OBJ it can for this case.
- If the object is supposed to be instanced but you’ve done something that is not instancing-friendly, the exporter tells you, in terms you can understand.
So for example, if you make an animated radar dish that spins and attempt to export with instancing, the exporter can say “you cannot have animation in an instanced object.” Now you, the scenery designer, can make a decision: is it more important to have the radar dish draw really really fast, or is it more important that it spins?
This is the strategy we used for our modifications of Marginal’s 2.49 exporter* – the artist specifies instancing and gets a check that instancing requirements have met. This means instance-tagged objects will be fast. (It is possible to check instancing within the sim with DataRefEditor but it’s not easy, especially for large projects.)
Don’t Expose the Weird
This idea that Blender can transform your work, and thus hide weird X-Plane rules, is not specific to OBJ, not new to X-Plane, and not even specific to X-Plane. When you look at major 3-d game engines (e.g. for combat games and racing games) a ton of code goes into the “art asset pipeline”, transforming the artist’s original work into something already digested for the 3-d engine.
Another example of this is WED. DSFs have an annoying rule that polygons can’t cross DSF boundaries. There are also some even weirder exceptions for a few special cases, introduced in X-Plane 10.20.
WED knows all of these rules; you draw polygons wherever you want and set the export target for the version of X-Plane you want to fly in, and WED figures out the best way to export your work, chopping up polygons as needed.
Shedding Light on Things
Our current work on the Blender exporter focuses on WYSIWYG animation and the material model (which includes instancing support). There is one more area that I think will make a huge difference to authors that we haven’t started working on yet: lighting.
The lighting values for commands like LIGHT_PARAM are, to put it mildly, completely goofy. If you’ve ever tried to read this, you know that even when things are explained, they make no sense.
No author should ever have to write a LIGHT_PARAM. This is a classic case where the exporter should do the transformation for us. What I would like to get into Blender 2.7 is the ability to place a cone light in Blender and have the exporter write the spill light automatically, e.g. filling in the parameters from the position and shape of the light. You light your scene and you see the same thing in X-Plane.
For years we’ve been behind the curve on user experience when it comes to 3-d modeling. I think we’re starting to fix some of those problems in a major way, which should help make the power of X-Plane 10’s rendering engine quite a bit more accessible.
*As a side note, I have no idea what the current 2.49 script status is. We view the 2.7 scripts as the long term way forward, due to Blender 2.49’s not being maintained, so our effort on a truly user-friendly tool is going into 2.7. But we also maintain updates to 2.49 to support our internal team. X-Plane 10.50 will feature a few new OBJ commands, so I will try to post our branch of the 2.49 scripts (which do have this new support) for anyone whose aircraft is in 2.49.
In the long term the 2.7 scripts will feature a migration tool, but I expect we will have a useful 2.7 release (for 2.7 authors) without migration first, and then migration will come later.
If you have a computer that can handle more detailed base meshes, AlpilotX’s free HD and (for those with serious hardware, UHD) meshes are a really great looking enhancement to X-Plane. Alpilotx just released a new HD version of South America with more up-to-date land class and OSM data.
Here are comparison screenshots.