XPlane2Blender is now X-Plane 11.30 ready! Not much has changed since beta.3, just some fixes to the particle stuff.
Sound Emitter has been removed from the Empty Special types menu. One day it will be back in!
XPlane2Blender is now X-Plane 11.30 ready! Not much has changed since beta.3, just some fixes to the particle stuff.
Sound Emitter has been removed from the Empty Special types menu. One day it will be back in!
As you saw at Flightsim Expo, X-Plane 11.30 offers a wide range of new features for airplane authors, who wish to make their airplane engines and systems more realistic. This post links to the documents with technical details that are of interest to aircraft authors mostly. End-users are encouraged to try the Cessna 172, King Air C90 and Boeing 737 of X-Plane 11.30 to experience more fidelity in true-to-life autopilot and other system simulation.
X-Plane has two separate oxygen systems, bottled/compressed O2 and chemical oxygen that can be used for both general aviation aircraft and airliners with separate crew and pax oxygen. How to set up the system for you airplane is explained here: https://developer.x-plane.com/article/the-x-plane-oxygen-system/
Airplanes can make use of electrical or bleed-air thermal anti-ice systems, inflatable boots de-ice or chemical TKS anti-ice systems, each with their own characteristics: https://developer.x-plane.com/article/the-x-plane-anti-and-de-ice-systems/
Besides engine-driven vacuum pumps, X-Plane can now also simulate venturi-powered vacuum systems as found on vintage aircraft and electrical backup pumps that are sometimes found in slightly better equipped general aviation aircraft. The interaction of all the pumps, manifolds and instruments is explained here: https://developer.x-plane.com/article/vacuum-systems/
The traditional vacuum-driven attitude indicator is now subject to the same limitations as in real life, and can be equipped with a caging or fast erect mechanism to help cope with them: https://developer.x-plane.com/article/vacuum-gyro-limitations-and-caging/
Propeller-driven aircraft can have distinct behavior of the prop governors reaction to engine failure or loss of oil pressure. Depending whether your plane is a single or multi-engine, whether it is driven by piston engines or propeller turbines, and wether the turbines are of the free-rotating or single-spool design, the equipment might be drastically different. X-Plane now features negative torque sensing in addition or instead of auto-feather, overspeed governors and fuel topping governors, to make turboprop aircraft even more true-to-life: https://developer.x-plane.com/article/propeller-feathering-systems/
Turboprop engines now have additional overspeed and fuel-topping governors for free turboprops, and fuel delivery control for fixed shaft turboprops. How to set up fuel delivery control is explained here: https://developer.x-plane.com/article/setting-up-a-fixed-turboprop-engine-governor/
X-Plane now comes with a few pre-configured autopilots for airplane designers to chose from, and offers more flexibility in creating a custom one.
X-Plane 11.30 adds support for single- and dual-axis rate-based autopilots, control over the trim servo, and a separate static system for an altitude pre-selector.
Airliner autopilots learn new auto-throttle modes, Control Wheel Steering, have two independent flight directors and up to three channels for auto land. They can optionally even have a directional servo for CAT 3 landing rollout guidance.
Learn more about the X-Plane autopilots here: https://developer.x-plane.com/article/preconfigured-autopilots-and-other-autopilot-changes-in-11-30/
The documentation for tuning the autopilot constants has been clarified and expanded with new sections about the new autopilot functions in 11.30: https://developer.x-plane.com/article/x-plane-autopilot-params/
Finally, have a look at the X-Plane airliner autopilot in action, performing an auto land in a gusting cross wind:
This beta brings in many new bug fixes and heavily requested new features! As with any beta, be aware that this could break your project SO MAKE BACKUPS! We don’t think there are any drastic changes to the data model, but, better safe than sorry.
Blend Glasswas in the same drop down menu as
Alpha Cutoff, and
Alpha Shadow. Now it is a checkbox allowing you to correctly specify a Blend Mode and apply Blend Glass to it. Existing materials with Blend Glass will see this new checkbox automatically checked. Blend Mode will be set to Alpha Blend or, if your plane is old enough to have been worked on during X-Plane 10, it will be set to whatever it was back then.
See the internal text block “Updater Log” for a list of what got updated, including this. You may see, for example:
INFO: Set material "Material_SHADOW_BLEND_GLASS"'s Blend Glass property to true and its Blend Mode to Shadow
Thanks to #361, just like the Datarefs.txt Search Window, we now have the same capabilities for searching Commands.txt (for manipulators). We are shipping with X-Plane’s latest Commands.txt file, but of course you can replace it with your own (as long as you keep the name the same). One day we hope to make it much more flexible.
Thanks to #358, some people who have access to X-Plane’s cutting edge particle code can use XPlane2Blender to specify particle emitters. Don’t worry, we’re all working as hard as we can to get these into the hands of others. Fortunately, XPlane2Blender users can hit the ground running the minute it drops!
mkbuild.py, the build script for the modern developer! It creates, it tests, it renames without messy mistake prone human intervention! To top that off, how about a testing script that doesn’t give false positives!
For airplane authors, the biggest question VR brings up is: what do I have to do to my aircraft to make this work? This is the first of three posts explaining not only how manipulation works with VR, but why we made our decisions and how we got here. Bear with me – this will end with specific recommendations for what to do with your aircraft.
Old-timers like me will remember that when the 3-d cockpit first came out, almost all of the “brains” of it were powered by clicking on the 2-d panel, which was “mapped” to the 3-d cockpit. X-Plane would find out where your mouse click intersected the 3-d cockpit, find the texture location on that triangle, and map that back to the 2-d panel.
This seemed pretty cool when it came out 15 years ago, but as authors started making more sophisticated 3-d cockpits, it became clear that we needed a way to specify how the mouse worked directly with the 3-d cockpit shape, because the mapping back to the 2-d wouldn’t allow the user to do basic things like dragging a throttle.
Thus in X-Plane 9 we added the first set of manipulators – tags on the 3-d mesh of a cockpit specifying what happens when the user clicks on it. The manipulator could specify a dataref to modify, a command to actuate, and some data about what kind of mouse click operation was happening.
The key words here are mouse click. The original manipulators were designed entirely in terms of a mouse on a 2-d screen; they were designed to be exactly as powerful as a 2-d panel system, which was of coarse also totally mouse-centric. The relationship between the generic instruments and the original manipulators is pretty tight.
The good part of the original manipulator system was that it was very flexible – mouse-centric handlers were a low level tool around which authors could do whatever they wanted.
The down-side of this design was that mouse-centric handlers were a low level tool around which authors could do whatever we want. We examined our own default fleet of a dozen or so aircraft and found that no two aircraft’s cockpits operated the same way, and almost all of them had at least some aspect that was hard to use – a poor manipulator choice for the job.
Knobs were, in particular, quite difficult – the original 2-d panel system used click-and-hold over a knob to actuate it, but authors working in 3-d had often used drag actions to do knobs, and the drag actions would respond differently depending on camera angle. We received approximately 8,452,124 bug reports that the knobs in the 747 were hard to use specifically because of this.
So during X-Plane 10, we added some new manipulators to X-Plane, and they had a very different philosophy: the manipulator described what was happening in the simulated aircraft, and X-Plane picked a mouse behavior to make that work. The new manipulators described knobs that turned and switches that either flipped left-right or up-down. These manipulators reacted to the scroll wheel automatically because X-Plane knows what the knob is and therefore what a reasonable scroll-wheel interaction should be. (By comparison, with the old-style manipulators, the author has to specify what a reasonable scroll-wheel action is.)
As it turns out, mechanism-centric manipulators are a lot better for VR than mouse-centric ones. Consider two cases:
As it turns out, we ran into this problem of not doing what to do with the mouse, and needing to know what the mechanism was before we even started looking at VR. The exact same problem (“I want to touch the 3-d cockpit as if it was a thing and have it respond in the expected way”) exists in VR and on X-Plane Mobile!
Because X-Plane mobile runs on a touch screen and you have your physical finger on a switch, there are a lot of cases where the switch has to track really well and work the right way. If the switch goes up and down, you want to flick your finger up to turn the switch on; if it goes left-right you want to flick left and right, and anything else is astonishing.
So X-Plane mobile set us on this path toward mechanism-based manipulators, and VR further drove us in that direction, since both have the same physical, non-mouse environment where a user directly interacts with the 3-d cockpit.
So as an author, what should you do when working on a 3-d cockpit? My answer is: use some of the manipulators, but not others, to model the way things work in 3-d.
These manipulators are the best way to create certain physical mechanisms – use them every time this case applies to your aircraft.
ATTR_manip_drag_axis. Use this for a physical mechanism that slides along a linear path, like the throttle handle of a Cessna.
ATTR_manip_drag_rotate. Use this for a physical mechanism that rotates around a fixed point, like the throttle handles of a 737, or a trim wheel. (Prefer this to the old technique of putting a drag axis along the edge of the throttle handles.)
ATTR_manip_noop. Use this to make a manipulator that blocks the mechanism behind it from being touched, e.g. the safety guard plate over a switch.
ATTR_manip_command. Use this for push buttons that actuate momentarily while a button is held down, like a button to motor a starter that you push in and hold down.
ATTR_manip_command_knob, ATTR_manip_command_switch_up_down, ATTR_manip_command_switch_left_right. Use these for knobs and switches with 3 or more positions that rotate or move. Pick the right manipulator for the mechanism!
ATTR_manip_axis_knob, ATTR_manip_axis_switch_up_down, ATTR_manip_axis_switch_left_right. These provide an alternative to the above manipulators when you must use a dataref. We recommend commands over datarefs any time you have a choice; the command system provides better interoperability between custom plugins, custom aircraft, and custom hardware.
ATTR_manip_command_switch_left_right2, ATTR_manip_command_switch_up_down2, ATTR_manip_command_knob2. Use these for knobs and switches with exactly two positions. You can use these to get a simple click-to-toggle with the mouse (quicker and easier for mouse users) while getting real 3-d movement in VR.
These manipulators are not perfect fits with physical motions and may require tweaking for VR, but they’re the best options we have now for certain problems. Try to use something from the always list instead if you can. Do not use these manipulators if the mechanism you are simulating matches something from the list above.
ATTR_manip_drag_xy. This is the only 2-axis drag we have, and is the best choice for eye-ball vents and the yoke. The yoke is special-cased in VR and should be based off of a 2-d xy manipulator. We are looking into more powerful multi-dimensional manipulation in VR, but this work won’t be complete for 10.20.
ATTR_manip_command_axis. This manipulator runs a command once based on moving a lever down or up. You should probably use a drag axis or command up-down switch, but there may be some odd mechanisms in aircraft where this manipulator is a good fit. It should not be your first-choice go-to manipulator.
ATTR_manip_push, ATTR_manip_radio, ATTR_manip_toggle. These manipulators can serve as alternatives for push-button style controls when you absolutely have to write to a dataref and not use a command. WARNING: Do not ever use these manipulators for things that move, e.g. don’t use these for banana switches, spinning knobs, or things like that.
These manipulators were for mouse-centric movement and should be replaced with knob or switch manipulators.
ATTR_manip_delta, ATTR_manip_wrap. These were designed to simulate knobs by click-and-hold – use the knob manipulators instead.
ATTR_manip_drag_axis_pix. This was designed to simulate a knob by click-and-drag – use the knob manipulators instead.
As you may have noticed from this list and the ever-growing size of X-Plane’s built-in command list, we love commands – they have become our go-to mechanism for our aircraft. Commands have a few advantages over data-refs:
In X-Plane 11 we’ve been moving to commands to get our planes ready for VR, the new manipulators, and FMOD sound all at once.
In the next post I’ll cover some of the issues specific to VR and the 3-d cockpit.
* Developers who write plugins that provide external interfaces to X-Plane: make sure you have a way to provide access to commands and not just datarefs! There are things you can do only with commands and not datarefs.
These smaller features are likely to be overshadowed by the release of the G1000 for default aircraft in 11.10, so I decided to dedicate a blog post to promote the articles I’ve written – you can find them among all the guides for aircraft developers: http://developer.x-plane.com/docs/aircraft/
Back in April, I flew a Mooney M20J with a KCS55A HSI in it, and realised that it was impossible to model in X-Plane correctly, so I got to work. See the manual for an explanation of this popular HSI/remote gyro system.
I’ve written a usage guide on the new datarefs and commands that I added, along with some more detailed explanation of all the different gyro systems X-Plane simulates, in this guide for aircraft developers. I also talked about the systems at length in a Youtube live stream earlier this year.
This is a feature that many add-on aircraft already simulate to some degree, but by means of more or less reliable plugin trickery. The X-Plane 11 default 737 and 747 are no exception. With X-Plane 11.10, a separate GPS steering mode for the autopilot becomes a standard feature.
The new datarefs and commands are explained in detail here.
Several people who build home-cockpit setups have asked about removing the bezels from the popup displays, so they can have only the screen of a GNS430/530, FMS or G1000 instrument to put on an external monitor, with a hardware bezel around it. While this can already be achieved through some clever hacking in the Miscellaneous.prf file, we now offer a more straightforward way to do this: The popup and pop-out windows now get their bezel graphics from the library system, so you can override the bezel graphics. How to override the bezel with nothing, if your bezel is made of hardware? Simply supply a 1×1 pixel blank .png as a bezel graphic, and X-Plane will know that you really want no bezel at all. In the case of a bezel-less 430, you’d put a 1×1 pixel png as the “cockpit/radios/GPS FMS/Garmin_430_2d.png” resource of your plane.
We are going to be releasing the XPlane2Blender 3.4 beta soon, and with it, a refresh of the UI and documentation. Thanks to a great e-mail about a lack of documentation, it was put as an important part of 3.4 release roadmap. It goes to show… we can’t fix it if we don’t know what’s wrong, even if its not a code problem. And we do want to fix it, I swear!
In addition, I want to remind everyone a core part of the Laminar Research philosophy, identity, and business plan is a thriving modding and third-party plugin ecosystem. Aside from build scripts and the like, Laminar Research employees use the same scenery development tools that are available to all. This is was a deliberate choice that elevates everyone to the same level – except when there is a gap of knowledge. This is never intentional, and never benefits anyone in the long run, especially third-party-devs. If your work is suffering because we forgot that not everyone knows what every little checkbox means, tell us! We’ll put it in the bug queue like everything else, and try to get back to you, personally, quickly.
Philipp made a change to the Cessna’s autopilot that makes it more realistic, but also slightly trickier to use.
As of 11.30, the Cessna’s autopilot uses HDG + GPSS for nav course selection. Philipp wrote a developer article explaining what all five of X-Plane’s nav course source modes do, but here are a few notes.
Among autopilots that aren’t totally hopeless (e.g. the Sperry, “none” for its course source) there are two major divisions:
This first category is less high tech and less useful to the pilot, and it’s the bucket the Cessna is in. If you want to fly a localizer, you have to set your AP heading bug to the localizer’s course, or the autopilot is going to lose its mind.
What this means is: if ATC gives you a heading to intercept the localizer, you cannot just engage heading mode, arm localizer mode, and fly the course to intercept – when you intercept the localizer, you won’t track it properly. You will have to adjust your heading bug onto the localizer front course once you start intercepting it.
The GPS is a special case: It works like a VOR/LOC when you are in NAV mode (affected by the heading bug) and like you’d expect when you are in GPSS mode (not affected by the HDG bug). So if you want to fly a GPS flight plan with twists and turns fully automated, you must press the NAV button twice in order to turn the autopilot to GPSS.
Something that can trip people up is that you cannot use GPSS and APR/GS at the same time – if you want to fly a WAAS approach with vertical guidance, you have to step down from NAV GPSS to NAV APR, which means you’re dependent on the pesky heading bug again. Confusing? Yes. Annoying? Certainly. Realistic? Definitely! This is exactly as annoying as the real thing.
The second category gets the localizer heading from either magic (GPS/LOC) or the OBS knob “OBS”) and always gets the VOR radial from the OBS course (which make sense). These setups let you fly a “dual mode” approach – engage HDG, arm LOC, and fly the intercept heading – when the localizer comes alive, the AP can switch modes and know which way to turn to intercept without you having to mess with the HDG dial.
You’ll find GPS/LOC-based systems in our Kingair (which has an EHSI) and Baron (which has a HSI).
That got your attention, eh? Sorry, this is not a tip on how to tune your X-Plane system; it’s a tip for aircraft authors to make sure their 3-d cockpits are running at maximum performance.
Prefill is when X-Plane blocks out the clouds that will be behind the airplane cockpit. The biggest cause of GPU slow-down is cloud rendering, so reducing the area that the clouds have to fill is really important.
In the 2-d cockpit, X-Plane pre-fills automatically. But in a 3-d cockpit, the airplane author has to specify which objects should be used to pre-fill.
One thought on alpha and HDR and aircraft:
If you need to create a final flat part of a panel out of multiple layers, some translucent, and you are using panel texture, it is better to composite the entire piece of panel in the panel texture than to layer polygons in your OBJ.
For example, consider the annunciator display on the dashboard that many airplanes have. There are two ways to build this panel:
Choose option 1! Tom had to convert the Baron’s annunciator panel from method 2 to method 1. A few reasons to prefer method 1:
You won’t use up that more panel texture, but you’ll make your life easier. This technique wasn’t totally possible before, but now with GLOBAL_cockpit_lit you can alwys have your panel handle real lighting.
I have updated the OBJ8 specification with the new X-Plane 10.10 commands. This blog post explains why we added some of these commands.
The pixel-space drag manipulator is a new axis manipulator whose drag length is measured in screen pixels instead of meters; its drag axes are always screen aligned, but it works both horizontally and vertically.
The goal of this manipulator is to make draggable knobs that:
The axis manipulator has the problem that it works in 3-d; depending on how you look at the manipulation target (both position and rotation) the sensitivity of the drag can change radically.
Recommendation: use the regular drag-axis manipulator for levers and other physically moving items. Use the pixel-space drag manipulator for drags where the underlying target does not move, like knobs. Use button-type clicks for anything that just toggles – it’s easier on the user.
Three new attributes (GLOBAL_no_shadow, ATTR_no_shadow, and ATTR_shadow) allow you to exclude part or all of your object from shadow casting. Shadows can make certain types of geometry, like grass billboards, look silly; excluding them from shadows fixes artifacts.
Note that ATTR_no_shadow is different from ATTR_shadow_blend..
Recommendation: fix shadowing bugs using ATTR_no_shadow for non-instanced objects, and GLOBAL_no_shadow for instanced objects. Use the Plane-Maker check-box for parts on aircraft.
This attribute lets you have your cake and eat it. In X-Plane 9, ATTR_cockpit gives you alpha blending, but ATTR_cockpit_region gives you correct 3-d lighting. You have to pick one or the other.
In X-Plane 10.10, GLOBAL_cockpit_lit gives you both. It makes ATTR_cockpit use 3-d lighting (while maintaining translucency) and it makes ATTR_cockpit_region respect alpha translucency (while maintaining cockpit lighting).
You can add this attribute to any airplane. This attribute should make it easier for authors to adopt correct 3-d lighting in their airplanes.
Recommendation: use GLOBAL_cockpit_lit on any airplane that uses ATTR_cockpit to change to 3-d lighting for your panel texture. Also see here for more guidance.