OK the new engine modeling for X-Plane 11 is great, but what good is an engine to us pilots without a propeller?
X-Plane has historically done an excellent job of estimating the THRUST of propellers, typically to within just a few percent… but what about the SPIRALING SLIPSTREAM? This has been an area where X-Plane has been much weaker… I just don’t see any good solid references for determining the spiraling slipstream angles for propellers…
and it’s a real shame because the spiraling slip-stream hitting the vertical stab is so responsible for the left-turning tendency in single-engine props.
BUT, can we do better? How would we estimate the slipstream angle, exactly?
Well, as it turns out, there is a pretty darn cool way to do it, which is going into X-Plane 11 Beta-4: A spinning prop is just a spinning pair or trio or quartet of wings (as X-Plane has long understood) and those wings have LIFT and DRAG.
The LIFT from the propeller blade is referred to as THRUST. The DRAG on the propeller blade is what opposes rotation and makes them so darn hard to TURN. Read More
OK I overhauled and upgraded the jet engine model as well.
Here is how it works: For SUBSONIC dynamics, I curve fit maximum engine thrust ratio to static max thrust as a function of density altitude, Mach number, and engine bypass ratio. This is pretty easy and boring and I have been doing this for years.
But here is where it starts to get good: As the inlet is dragged by an over-speeding airplane above it’s critical Mach number, normal shocks will now form across the inlet, DECIMATING the efficiency of the engine and robbing you of thrust.
No arbitrary losses above your critical Mach number, the normal shock, only a few atoms thick, slows all air that hits it across the space of a few atoms, dumping a huge amount of the incoming streams valuable kinetic energy and turning it instead into HEAT.. the last thing you want coming into the front of your engine.
So that is for subsonic inlets being dragged above their critical Mach number. What about supersonic inlets?
OK this gets good: As we move through Mach 1, we transition from the subsonic curve fit for subsonic engines to the pressure-recovery of the total energy of the airstream. Here is where this gets interesting: The faster you go, the higher the Mach number of air incoming to the inlet, and the more energy is available from the airstream to turn into THRUST!
So, the faster you go, the more thrust you get! This is one reason that supersonic jet airplanes just keep speeding up, and up, and up, and up!
Planes like the F-4 Phantom, for example, take about FIVE MINUTES to get from Mach 1 to Mach 2 (a long time because the thrust only builds as the speed builds) but darn they hit Mach 2 and are still slowly accelerating!
Now, nothing this good lasts forever. At some point, the aircraft speed overwhelms the inlets’ ability to accept the shockwaves, and losses occur. We simulate this with a normal shock, and the inlet efficiency gradually moves from ideal (total pressure recovery) to the worst possible (normal shock) as the inlet moves to and then past it’s maximum allowable Mach number.
Here’s the equation for the losses across the normal shock, by the way:
const xflt gamma =1.4 ;
const xflt gamma_m1=1.4-1.0;
const xflt gamma_p1=1.4+1.0;
xflt nrm_shock_press_rat= xpow((gamma_p1 * sqr(M_use) ) / (gamma_m1 *sqr(M_use) + 2.0 ) , gamma /gamma_m1) // //www.grc.nasa.gov/www/k-12/airplane/normal.html
* xpow((gamma_p1 ) / (2.0 * gamma * sqr(M_use) - gamma_m1 ) , 1.0 /gamma_m1); // normal shock total pressure ratio
So, if you open the F-4 Phantom in Plane-Maker, go to the engines window, and then the Jet Curves tab on the right, you will be able to SEE EVERYTHING that I just talked about.
On the left, at Mach 0, you see the static thrust for each altitude.
Then as you move right to Mach 0.5, the thrust falls as the turbine can’t deliver much ‘oomph’ due to the rapid inflow of air… like trying to climb a rope ladder while the rope is falling, trying to get thrust from an airstream always coming at you is simply an uphill battle that does not work too well. So the thrust FALLS as you speed up.
Then, above Mach 0.5 or so, something interesting happens: the energy in the oncoming airstream becomes significant, and the inlet starts decelerating that incoming airstream, using that deceleration to INCREASE the air pressure inside the inlet, which actually helps the inlet do the job FOR the engine! Now, that thrust starts BUILDING!
Now as we move to Mach-1, it’s crazy-time. The airstream pushing at the airplane is packing HUGE energy from all that speed, and nice, efficient, oblique shocks start capturing all that energy, slowing and pressurizing that air efficiently, and handing that high-pressure to the engine. A well-designed inlet at this point might develop MORE thrust than the engine itself… the job of the engine is simply to pressurize the inlet here. And, the faster we go, the farther to the right we move on those curves, and the greater the thrust becomes as we speed up. This is a recipe for an airplane that just never seems to stop accelerating. Enter the F-4. And the SR-71.
But, at some point, the shockwaves overpower the design of the inlet, and we start heading to the (terrible) efficiency of the normal shock. Here you see the curves dropping thrust hugely, on the fast-side of the max expected Mach number for the inlet.
So, you can see the thrust curves in Plane-Maker and now know what forms them. Set the reference Mach number on the lower left for you inlet on your plane to get the thrust peak right around the top speed for your airplane.
And then finally, MAXIMUM thrust is not the only thing here: We also need thrust variation with N1, and DRAG from the engine at idle at various speeds. Those things have been tuned and tested as well.
For testing:
I have a full Citation Mustang POH with aircraft speeds and power settings, to test and tune the low subsonic flight regime for jets, and a recently de-classified F-4 Phantom Pilots Operating Handbook with subsonic and supersonic deceleration times (to tune the DRAG) and acceleration times (to tune the THRUST) to test and tune the high subsonic and supersonic flight envelopes of jet engines. All of the math above checked out very well with the POH’s for these airplanes… much of the accel/decel timing on the F-4 Phantom to within 1 second to get to and from various subsonic and supersonic speeds at full and idle thrust.
And a quick little detail: Low/high jet engine bypass types: GONE! Now we ONLY go off the bypass RATIO that you entered! This lets cool things like exhaust smokiness and engine mass for mass distribution all be floating point with bypass ratio for infinite variation, which is nice.
So, jet simulation has been improved now for V11, especially in the supersonic regime… because getting that F-4 PERFECT is just going to be soooooooo cool!
Thanks to a few hundred hours of flight experience in my Lancair Evolution so far, I am really improving the flight model in X-Plane in the area of PT-6 engines, electrical, and pressurization systems! And, while in the systems code, I’ve improved a lot of other systems simulations as well, which is always fun.
So, here is the new stuff done for 11.00 so far in the flight and systems modeling area! Read More
First, we are making progress toward X-Plane 10.50. I sent out a private beta a few days ago; how soon we get to public beta will depend on how buggy the private beta turns out to be. (I am assuming that it will have zero bugs, because I have decided to not write any more bugs in my code. So…there, I fixed it.)
Coming in 10.50: X-Plane supports new manipulators.
- In 10.50 you can add scroll wheel to any of the existing manipulators that takes one dataref. This is done via a second directive that sets the amount the dataref changes when the wheel moves.*
- There are six new manipulators (they form a set) to support knobs and three-way switches. Each one takes a pair of commands and provides a consistent UI experience.
- The no-op manipulator now takes a tool-tip, which lets you make tool tips for gauges and other unclickable geometry.
I want to make two things clear here:
- This is support for these manipulators in the engine. This means that we can use them in our aircraft and third parties can use them in their aircraft. Adding these manipulators is a separate task, one we are working on, but which won’t be complete as of 10.50.
- Third parties are welcome to use the new manipulators, and they are welcome to follow our internal usage guidelines. They are also welcome to keep doing what they are doing; none of this is binding, everything is opt-in. Nothing about this breaks compatibility with any existing aircraft.
Why Did We Add These?
We’ve had a long term internal goal of making the 3-d cockpit as usable and user-friendly as possible. We’ve reached a point where 3-d cockpits are the norm, and all of our new aircraft development is 3-d only. But you can’t deny that 2-d cockpits are incredibly usable from a user interface standpoint. How do you make 3-d usable?
We already have view presets to let you get to a particular cockpit view easily. Once you have a good view of the surface you want to interact with, the next step is to have a mouse gesture that’s easy to use.
This is where the new manipulators come in. Rather than describing a mouse gesture (drag, click, etc.) they describe a type of physical hardware, one of a rotating knob, left-right multi-way switch or up-down multi-way switch.
Because the manipulators describe the physical hardware and not how the UI should work, we can change the interaction mode based on user preferences, available hardware, etc.
One of the big UI questions is: should you change a knob by clicking and holding or dragging? I built a test airplane with some of each and the company was split down the middle. By using knob manipulators (and not click or drag manipulators) we can change the way knobs work in the cockpit for all airplanes with one change of the code, rather than having our art team redo every single manipulator in every single airplane.
I don’t know whether we’ll use dragging or clicking-based knobs – or whether a user preference will be exposed. But by having a higher level manipulator type we make this a small programming problem and not an unmanageable authoring problem.
(The new knob manipulator automatically uses the scroll wheel – since we know it’s a knob, we can figure out how the wheel should work. The new command to add scroll wheel to legacy manipulators is necessary to provide the data the sim needs to make the user interaction good.)
The new higher level manipulators also give us flexibility for new input devices. For example, if we someday want to support multi-touch tablets and track-pads, we could map a pinch-rotate gesture to a knob – since we know the manipulator really is a round knob (and not just ‘something that you drag’) we can know that a rotating gesture makes sense.
How Do I Add Them?
The new manipulators are already supported in code in the Blender 2.7, Blender 2.49 and and AC3D. The manipulators are released in the newest Blender 2.7 exporter; I need to post newer 2.49 exporters. I do not know if/when there will be a public release of the AC3D exporter, but I can probably find the time at some point to do one more compile.
All aspects of the new manipulators are opt-in; if you don’t change your airplane, its functionality should not change.
What Aircraft Use Them
I’ve buried the lead a little bit here: X-Plane 10.50 will have a heavily upgraded Kingair C90 and Baron B58 that will use the new manipulators. We have not (yet) upgraded the rest of the fleet, and this upgrade will happen over a very long time-span. The goal of 10.50 is to lay the groundwork and make cleaner user interfaces possible by making the new manipulators available to our art team and third parties.
The guidelines I’ve been advocating for our artists are:
- Large things that move a lot like throttles are dragged via an axis that tracks the actual 3-d motion.
- Yokes track via a 2-d XY manipulator.
- Anything that toggles or has only two states is a single click, particularly for small things.
- Rotary knobs and rheostats use the new knob manipulators. The mouse wheel can turn them.
- Linear switches with three or more positions use the new left-right and up-down switch manipulators. The mouse wheel can click them.
There’s no reason why third parties have to use these guidelines; I post them only to show how we are thinking about usability. A more “3-d” approach is possible, e.g. drag a banana switch up and down to toggle it; my view is that for Laminar’s default fleet, which are the first aircraft users are going to use, single clicks provide a more direct and less surprising user experience.
For power users, having single clicks for switches may also mean you can get more done in the cockpit faster. (In real life, a pilot can reach up and flip four metal banana switches on the overhead panel very, very quickly.) We’ll still use dragging for big 3-d motions.
*This feature targets one-wheel clicking Windows-style mice. 2/3 of our users are on Windows, and Apple has shipped a wide variety of strange input devices, so the one-axis clicking mouse wheel is the most consistent hardware target for us to aim at. And frankly, I think it’s the most useful since you get clear ‘detents’ as you scroll things – good for changing a radio by one notch.
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.
In my previous post I mentioned that re-saving your aircraft in Plane-Maker from X-Plane 10.45 would opt you in to the new fixed torque model.
I’ve talked about this before, but it might bear repeating now:
Please do not ship an aircraft saved with a beta version of Plane-Maker. Instead wait for X-plane to go final or use the previous non-beta version of X-Plane.
The problem is that file formats change during beta and if they do we do not provide compatibility; the file format is only “for real” when beta is over.
So if you need the torque bug fix, plan to ship your aircraft in a week or two when 10.45 beta is over. If you need to ship now, use Plane-Maker 10.42. Test against the beta, but don’t save using it.
X-Plane 10.45 beta 1 fixes a bug in X-Plane’s flight model where props applied too much torque to the aircraft. The effect is most noticeable on single engine aircraft where the prop torque is applied along the center of the fuselage.
Authors: in order to have the new correct torque applied to your aircraft, you must resave your aircraft in Plane-Maker 10.45. When X-Plane finds an aircraft authored with an old Plane-Maker, which includes all existing aircraft already shipped, we preserve the old torque behavior.
We put in this compatibility because some aircraft have plugins and other work-arounds that try to get correct flight dynamics assuming X-Plane will apply too much torque. If we were to apply the fix to these planes, they’d then have too little torque (because we’d apply less torque and the work-around would already be in place). So this is an opt-in fix.
Authors: if you use Plane-Maker 10.45 to work on your aircraft, you will be opted in to the fix! There is no way to work on a new aircraft and preserve the old torque. Our thinking is: the old torque calculating is physically wrong, so we’re not letting anyone preserve this mistake when working on a new aircraft.
So when you bring your aircraft in for its next feature update, note that you will be getting the torque fix and you should make sure the results are useful.
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.
Update: the comments form is fixed – sorry about that!
I’ve been working a bit on scenery tools this week. Here’s a road map of some of what’s coming up.
WED and the X-Plane Scenery Gateway
We are working on a release of the latest scenery gateway airports for X-Plane 10.45. Like all releases, we’ve found problems with airports that WED does not detect. So I will try to release a new version of WED with stricter validation soon.
Airport Parking Spots
Austin is working on new code to place static aircraft at unused ramp parking spots. I’l describe this in more detail in another post, but here are some key points:
- As an airport author, you simply place ramp starts, not static aircraft.
- X-Plane will feature some new static aircraft in the update.
- Third parties can further add to the static aircraft and have them be used via the library system.
- There will be a revision to the apt.dat format that stores more data per ramp spot and a WED update to support this new data.
- Since there may be scenery now with static aircraft on top of ramp starts*, we will auto-remove static aircraft from ramp starts in the gateway export as a temporary measure until authors can resolve the situation and post the fixes to the gateway.
- We are not removing the old static aircraft from the library, but we will be hiding them from WED’s library so that authors use ramp starts instead of placing them by hand.
Static aircraft in parking spots will ship next year, not this year, but is planned as a v10 update.
Scenery Tools on OS X
I made significant progress this week porting WED for OS X to 64-bit and modern Mac APIs. This effort basically meant rewriting the OS-level UI code in WED to be new AppKit based calls instead of the old Carbon API.
What this means is that developers will be able to build all of the scenery tools on a modern Mac running Yosemite or El Capitan with X-Code 7. Since Chris has already updated the projects to compiled WED in MSVC, a developer can build all of the common scenery tools from the most widely used open source IDEs.
It also brings us closer to a 64-bit WED on Mac, which is desperately needed since OS X provides the least amount of usable address space to 32-bit apps. I am not sure of the 64-bit status of the Windows WED build; it may need more work on the libraries.
Will It Blend
This might be the most significant scenery tools development: we’ve been working with Ondrej (der-On on Git-Hub) on new features for the Blender 2.7 exporter. This will include:
- Much better animation support. Complete WYSIWYG animation of data blocks and bones, with no work-arounds needed. Bone animations match Blender 2.49 so you can move your projects forward.
- Modernized material support including instancing for a really clean work-flow that takes advantage of X-Plane 10’s features.
- Updates for the latest OBJ features.
- Our plan is to create a migration script to bring 2.49 projects into 2.7, converting the special tags used for an X-Plane 2.49 export into 2.7.
Many of our artists still use 2.49, but there’s no question that 2.49’s days are numbered. It’s a question of when it stops working on OS X, not if. With the migration step, we can move our projects forward without artists having to redo work.
Like the previous 2.7 exporter, this one is open source and will be free, and should be able to export existing 2.7-type projects with no modifications – we are trying to maintain full backward compatibility.
* This situation is slightly silly – if the user picks the ramp start to fly, the user will be on top of a static aircraft.
