As some of you know, it was my plan to end-of-life the AC3D exporter for X-Plane; the decision was based on having limited resources to develop exporters.
The good news is: Andy Colebourne of Inivis has taken over development of the plugin, and has released the latest version of it – you can find it here. I am linking our download page to his forum link for easy access.
The AC3D plugin shares OBJ import/export code with WED and the rest of the Laminar Research C++ tools; my goal is to not break Andy’s work when working on WED. We use this code not only for WED object preview and the AC3D plugin, but for internal tools that pack up art for the iPhone version of X-Plane, so hopefully there will be some good leverage between the AC3D plugin and other Laminar scenery tools.
Our original plan for adding more X-Plane scenery gateway airports to 10.50 was to add two batches: one at the beginning of beta and one at the end.
We are changing that plan – I think our new plan is going to be an X-Plane 10.51, a week or two after 10.50 goes final, with new airports.
The reason to wait is that X-Plane 10.50 is further along than WED 1.5 – we have an RC for X-Plane but we’re still on beta 1 for WED.
New airports uploaded for X-Plane need to come from WED 1.5 (for both new features and much stronger validation checks) but they also need to come from a better tested WED 1.5. So we’ll wait for WED to be a little bit more mature.
I’ve said this before, but I’ll say it again: don’t panic if your airport isn’t going to be ready; X-Plane 10.51 will not be the last time we add more airports to X-Plane.
For now if you are working on an X-Plane 10.50-compatible airport my suggestion is:
- Use WED 1.5 beta 1 and X-Plane 10.50 rc 1.
- Don’t upload to the gateway yet.
- Do test your airport and report bugs against WED and X-Plane – especially X-Plane.
I will post here when we have a WED that we think is solid enough to upload airports with.
The first beta for World Editor 1.5 is now available to download.
This version features numerous bug fixes, along with major improvements to make editing airports easier and faster by providing more visual clues. It’s also the first 64-bit version of WED!
Some highlights of this version include:
You can see the full list of bug fixes, improvements and new features in the README.WorldEditor file found in your downloaded WED folder.
Please try the latest version as soon as you can and let us know if you find any bugs by filing a report on the Scenery Tools tab of the Gateway (not the desktop bug reporter for once!).
We’ve posted a Request for Comments for the apt.dat 1050 file format. You can see the proposed changes. Please comment on that article with feedback about the file format.
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.
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.)
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.
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.
