The three gyro systems X-Plane always had
X-Plane always simulated three different methods for getting attitude and heading information in the cockpit, and a total of six separate gyros to use and drive panel instruments:
- vacuum gyro – this one is driven by air being sucked through it, and the vacuum necessary to pull the air into it is generated by an engine-driven vacuum pump. This is the system most often found in simpler general aviation aircraft like a C172. X-Plane simulates a vacuum pump driven off the accessory section of the engine, thus the gyro will spin up when the engine spins up.
- electric gyro – this gyro replaces the failure-prone vacuum pump, hose, and filter system with a simple electric motor inside the instrument, which spins up the gyro. You find those in non-glass Cirruses, Diamonds, and other more modern general aviation aircraft. X-Plane drives this motor off a DC electric bus, or, if checked in Plane Maker, off the AC inverter.
- AHARS – the fully electronic attitude and heading reference system replaces the gyros with sagnac laser-gyros or cheaper MEMS gyroscopic sensors (comparable to the ones in your smartphone) to generate attitude and heading information without any moving parts. This system is obviously electrically powered.
Where’s North, anyway?
It is worth noting that none of the gyro systems have any idea where magnetic north actually is. All they can do is keep their orientation within space, so they need to be aligned to magnetic north by using an external reference, such as a magnetic compass or the compass dial painted onto the pavement in the runup area of an airport. Cessna pilots are familiar with the little knob on the bottom left of their directional gyro – it’s what they push and twist in order to set the gyro to the magnetic heading.
Fluxgates
Another way to align the directional gyro to magnetic north is by using a sensor that can detect the direction of the earth’s magnetic field. This sensor is called a fluxgate, or sometimes magnetometer, and is usually mounted in the left wing of an aircraft, far away from the engine, other avionics, or any equipment that might generate magnetic disturbances. The fluxgate transmits a signal to the remote gyro unit.
Slaved gyros and remote HSIs
For most HSIs, a remote gyro unit is mounted in the back of the plane. It’s an electric gyro that keeps its orientation once spun up and aligned. The fluxgate signal tells the remote gyro unit where magnetic north is. Thus, the electric gyro can be slaved to the fluxgate, indicating magnetic north without the need for the pilot to align it! It is worth noting that the fluxgate is subject to some, but not all of the errors the magnetic whisky compass is. In particular, while it does not have an acceleration error, it does have a dip error in turns! Thus, the electric gyro is used to get a very reliable course information during a turn, where the fluxgate reading is inaccurate, while in horizontal flight the slaving mechanism takes care of eliminating gyro precession. In other words: the gyro is used to compensate short-term errors of the fluxgate, and the fluxgate is used to compensate long-term errors of the gyro.
Free your gyro
Most remote HSIs have a way to free the gyro from the slaving to the fluxgate sensor, and treat it instead like a regular directional gyro. This mode is called “free” mode, and is activated by flipping the remote gyro switch from “slaved” to “free”. Besides a magnetometer failure, a use case for that is when flying with regards to true north reference, instead of magnetic north, which is done for example in northern Canada. In this case, the gyro is freed, and then the slew buttons or rocker switch (which work just like the slewing knob on the old C172’s directional gyro) are used to align the gyro to true north.
How can I use that in X-Plane 11.10?
In the dataref list of X-Plane 11.10, you can find all these values under the sim/cockpit/gyros/ category. Now that you know what AHARS, elec and vac mean, you just need to remember that psi is the heading, theta the pitch and phi the roll. When you make a 3d instrument for an HSI or DG, be aware of the correct system and dataref to use. The sim/cockpit/gyros/dg_drift_vac(2)_deg data refs allow you to see how far the vacuum gyro has drifted from the magnetic north, and the commands sim/instruments/(copilot_)DG_sync_[down/up] allow you adjust the setting of the vacuum gyro (the push-and-twist). For electric (remote) gyros, the new dataref sim/cockpit/gyros/gyr_free_slaved[] allows you to turn on (1) or off (0) slaving the electric gyros to the fluxgate. In free gyro mode, the new commands sim/instruments/[copilot_]free_gyro_[down/up] allow you to model the slave buttons or the CW/CCW switch on a slaving compensator panel. The respective drift datarefs sim/cockpit/gyros/dg_drift_ele(2)_deg allow you to model the slaving meter gauge. Finally, the new datarefs sim/cockpit/gyros/gyr_flag[] indicate whether the GYRO or HDG warning flag should be shown on the HSI or DG instrument. The new flag dataref not only reacts to low vacuum pressure or failed electric gyros, but it also momentarily shows while a free gyro adjustment is in progress, just like you’d see it on a Bendix/King KCS55A HSI.
Additional Fixes in X-Plane 11.10
Besides the new features mentioned above, X-Plane 11.10 fixes a few problems with how the existing gyro systems interacted with failure modes and electrical systems:
- A separate failure mode now exists that allows you to fail the electric gyros of a plane (if so equipped)
- Electric gyro systems now depend on electric power, even when they are not driven off the inverter. They will show up in Plane Maker as a consumer of electric energy.
- The gyro in the turn coordinator or turn and bank indicator now depends on electric power. It will show up in Plane Maker as a consumer of electric energy.
- AHARS systems now depend on electrical power and react to their failure setting.
- Finally, there’s a command for automatic quick-align of the directional gyro: sim/instruments/(copilot_)DG_sync_mag does just that. Former FSX pilots will feel at home when they assign that command to the “D” key on their keyboard.
Autopilot NAV modes: source selector and engagement
X-Plane’s autopilot always has and always had one channel for a tracker/coupler function, that works on both low-sensitivity sources like VORs and high-sensitivity like LOCalizers. With the HSI source selector, either a VOR/LOC receiver or a GPS/FMS can be selected to feed lateral deviation (what is indicated by a CDI) to the autopilot, whilst the desired track is fed to the autopilot by a number of different sources that can be configured. Thus, there’s only one NAV mode to take care of tracking the GPS flight plan, or intercepting and tracking a VOR radial or localizer.
Depending on the source, the nav mode can be armed before it actually engages, which is done for example in dual-mode intercepting. Dual-mode intercepting allows the autopilot to follow a heading, until a selected VOR radial or localizer course is intercepted, at which point the tracker/coupler takes over from the heading mode. In order to engage, the NAV mode needs either a both falling and less-than-full deflection on an angular offset (VOR, LOC), or an absolute XTK (GPS/FMS). Thus, NAV mode is never engaged directly, but armed (using a command, dataref or 2d panel button).
The new separate Autopilot NAV mode: GPSS
X-Plane 11.10 now supports a separate autopilot nav mode that works only with GPS steering cues: GPSS. GPSS tracks the GPS or FMS flightplan, with all the benefits you are used to from GPSS: turn anticipation and automatic tracking of arc segments, holdings and procedure turns. However, it works on a separate channel that is hardwired to the GPS/FMS in the plane including for front course (DTK) information.
This mode cannot be armed. If a valid GPS steering cue is available (a waypoint is active) it engages immediately. Otherwise, it just refuses to engage.
What is important is that the GPSS mode is treated like a heading mode when it comes to dual-mode intercepts. Thus, it allows you to arm localizer interception, while tracking a GPS flightplan that for example takes you through an RNAV transition onto the ILS approach. In this case, GPSS is active, the HSI selector can be turned to a VOR/LOC receiver, and then NAV or APPR mode can be armed. The autopilot will follow the GPS flightplan until it intercepts the localizer, at which point tracking will switch from GPSS to NAV (VOR or LOC).
Various X-Plane add-on aircraft have achieved similar functionality through various kinds of plugin trickery in the past. This new mode is now available without plugins.
Datarefs and commands
The new command sim/autopilot/gpss toggles the GPSS mode on or off. Note that the mode will refuse to engage when no waypoint is active in the GPS/FMS. The sim/cockpit/autopilot/autopilot_state flag field now has the flag 2^19=524288 to indicate whether the mode is active, similarly, writing that value toggles the mode. sim/cockpit2/autopilot/heading_mode will read 13 if GPSS is active. Finally, sim/cockpit2/autopilot/gpss_status will return 0 for off and 2 for engaged for the new mode.
Modeling Updates
Adopt sRGB Color Space for All Textures
X-Plane no longer supports non-sRGB color space images or gammas. This goes for DDS and PNG images. You must create sRGB color space artwork for X-Plane 11. If you have DDS files in 1.8 gamma, re-grind them with the latest X-Grinder. If your PNG files are not saved in the sRGB color space, please convert their color space.
Motivation: non-sRGB color spaces with non-sRGB gamma were supported historically in X-Plane to support authoring on very old versions of Mac OS X. However, since 2009 OS X has supported sRGB as its default gamma, making this unnecessary.
Furthermore, determining gamma from DDS and PNG files has proven to be very difficult; X-Plane’s gamma tag in DDS is non-standard, causing interoperability problems with many standard DDS tools; color space tagging in PNG is unreliable, including PNGs saved by photoshop.
By removing gamma conversion and simply assuming sRGB, we make it more likely that modern content is interpreted with its correct intent; this eliminates all bugs where incorrectly tagged modern sRGB content is treated as a non-standard gamma and processed incorrectly by X-Plane.
Color Correct Translucent Glass Textures
You may need to retune the color and alpha of your translucent glass. In almost all cases the right thing to do is to:
– Make the RGB of the window darker – the real window does not add light to the scene, it absorbs some small amount of it. It is not crazy for a tinted window to have a black RGB, with the alpha being more transparent to ‘lighten’ it. Think of a cross fade between a truly clear piece of glass and a black piece of paper.
– Make the alpha of the window more opaque – the linear blending looks like it lets more light through, so once your window is dark enough you may find you need heavier tinting.
See the “X-Plane 11 Material Model” article for a detailed explanation of how the new lighting and material model works.
Plane Maker Updates
Categorizing Reflective Surfaces
All reflective surfaces must be marked inside or outside to reflect the correct part of the world. This includes glass for the first time in v11.
You should update the lighting mode of all attached objects in Plane-Maker. Objects marked “glass” in X-Plane 10 will have been auto-updated to “glass exterior” in X-Plane 11; if the glass object is inside the airplane, change it to “glass interior.”
GPS
The old v9 GNS430 GPS is gone for good. If you open a plane using it in Plane Maker 11, it is force-upgraded to the new 430 we’ve had since X-Plane 10.30.
For integrating with your panel, you can use the rad_GPS_430_screen or rad_GPS_530_screen instrument depending on your size requirements, or you can drop in the complete G430 or G530 with bezels and buttons and resize as needed. Then refer to the commands.txt and search for the string “g430” to find all commands for the buttons on the GPS bezel. Note that these commands for bezel buttons will work regardless whether you are using the 430 or 530 size instrument. Note also that the commands with “n1” in the name go to the designated “pilot” or “NAV1” unit, and the commands with “n2” in the name go to the designated “copilot” or “NAV2” unit.
FMS
The old v9 FMS instrument is also gone for good. If you open a plane using it in Plane Maker 11, you will receive error messages or the panel accordingly. To use the new FMS, drop in the 2d FMS instrument or rad_CDU739 screen instrument for the screen of the new FMS. Refer to the commands.txt and search for the string “FMS” to find all keys and buttons to wire up to your bezel. Note that commands with “FMS2” in the description will go to the designated “copilot” side unit.
Fuel Flow
Now, the specific fuel consumption values you enter in Plane-Maker at various altitudes for fractional power settings are defined to be the power output fraction compared to max available power or thrust AT THAT ALTITUDE.
So, if you have an 850 hp turboprop engine, even if it is flat-rated so that it has a thermodynamic output well above 850 hp, and can carry 850 hp to well above sea level,
if you are at, say, 28,000 feet and the engine can only GIVE you 600 hp, the SFC for full power will be used when the engine is putting out 600 hp.
This is because 600 hp is, indeed, full throttle at that altitude!
If you reduce power to 300 hp of output at that altitude, then the half-power SFC will be used, because the engine is at half power for that altitude!
So, simply put, look at the power or thrust that the engine is actually putting out, divide that by the max power that it COULD put out, and THAT is the power fraction that is meant for the various SFCs.
NOTE: If the engine is flat-rated to some power setting, then you do, indeed, need to use that flat-rated power as the maximum in the division above.
So if you have a flat-rated engine allowed to only output 850 hp, even though it is thermodynamically good for 1,200 hp, if you are spinning out 850 hp, then that is indeed the max allowable power, and the full-power sfc will indeed be used. So simply divide the current power by the max achievable (and allowable) power at a given altitude, and that is the power fraction for the SFC.
Engine Idle & Engine-Driven Generators
PT-6 engine idle logic is different in X-Plane 11. X-Plane will try to get close with idle ratios, but fine tuning is needed in Plane Maker to get the same numbers as in X-Plane 10. In version 10, the high idle was automatically boosted inside of X-Plane, but now it is not: You have to boost that high idle manually by entering a higher value for high idle in Plane-Maker. You will need to revisit ALL idle ratios for all of your aircraft.
The turbine idle is now floating point like everything in a real PT-6. Move the red knob to move smoothly from low to idle, or hold it partway if you want to keep the engine temps where you want, as you would in reality. For turbines, you will want to enter a higher high idle than low idle now… X-Plane does not do this for you any more, since you can now tune those fuel flows at idle as you like for yourself!
For example, for a king air you probably want 55% ng for lo idle, 70% for hi idle, which works out to about:
HI idle: 1.70
LO idle: 1.00
In other words, our lo idle is just enough to run the engine, at the lowest Ng recommended, and we bump that up by 70% at high idle to spin the generators and air conditioning compressors.
Each real PT-6 is set up differently based on the settings of the engine driven generators!
Jet Engines
The jet engine flight model has been modified. Low/high jet engine bypass is gone and we only go off the bypass ratio you enter. Check your aircraft’s thrust curve values in Plane-Maker in the ENGINE window, DESCRIPTION tab, right side of the screen, where we have “thrust power curves with N1”, which you can enter.Then go to the engines window, and then the Jet Curves tab on the right. Set the reference Mach number on the lower left for the inlet on your plane to get the thrust peak right around the top speed for your airplane.
Gear Doors
Gear doors options are gone in Plane Maker 11. Add the gear additional frontal area as needed to get the same effect without the hassle
Want VISIBLE gear doors? Then make an OBJ to do them properly for sure!
Transition speed for steering
Transition speed for steering option was intentionally removed from Plane Maker 11. Real airplanes that have two levels of steering don’t have a transition speed at all – they have two controls:
- the tiller turns the wheels a LOT and is used for low speed tight turns around the apron and parking.
- the rudder pedals turns the wheels a little (and the rudder, of course) and can be used on takeoff and landing.
The behavior to transition from wide (tiller) to narrow (rudder) steering based on speed is a hack to allow users with a SINGLE “heading” axis to be able to drive on the ground without tiller hardware, by changing whether the twist axis acts as rudder or tiller based on speed. This transition is no longer part of the aircraft because it’s a hack to allow the user’s particular joystick hardware to work – it’s not aircraft specific at all, it’s USB-hardware specific.
Panel system
_LIT panel backgrounds are no longer supported. This feature dates back to X-Plane 6 and was deprecated in X-Plane 8. Replacement techniques:
- In 2d: Use the -2, -3, and -4 overlay layers of a 2-d to create 2-d “spill” lights, and use per-instrument lighting for instruments.
- In 3d: Use 3-d lights from Plane-Maker or OBJs to light the panel with spill, and instrument lights (and ATTR_light_level) for instruments.
All panels used for 3-d cockpits are rendered as two separate textures, always; a single unlit texture is no longer supported. Panels rendered in two textures has been supported since X-Plane 9. If you use ATTR_cockpit_region or GLOBAL_cockpit_lit, your add-on needs no changes.
If your add-on is using ATTR_cockpit without GLOBAL_cockpit_lit, you will find the lighting on your panel has changed. You will need to:
- Use real 3-d lights to light the panel externally (e.g. post lights, etc.)
- If you have plugin code that renders to the panel, use sim/graphics/view/panel_render_type to draw only albedo to the day panel and only lit graphics to the lit panel. If your panel is all glass, you can use this dataref to skip drawing.
Plugins that were drawing to a single-texture panel and ignored panel_render_type may see a serious performance problem until they are updated.
2-D overlay panel lighting layers (full panel backgrounds in the 2-d folder with the suffix -2, -3, -4) are no longer supported in 3-d cockpits. You can continue to use these lighting layers to create dynamic 2-d light effects for 2-d panels, but they have no affect on the 3-d cockpit.
3-d cockpits should always use real 3-d lights, either from Plane-Maker or OBJ-based spill lights to achieve spill lighting effects.
APU
In X-Plane 11, the existence of the APU must be specifically marked in Plane Maker’s systems window. Previously we would make a guess based on whether or not the default instrument was used, but X-Plane 11 will not guess.
Updating aircraft for the new UI
X-Plane 11 makes extensive use of the metadata filled out in Plane Maker’s author window. Make sure to update these fields following the instructions here.
The new UI also uses icons that can be generated from within X-Plane or by hand following these instructions.
Supporting Auto-Start
X-Plane 11 supports commands that allow a user to start and shut down the engines automatically. Besides simplifying operation of complex aircraft, these commands are used by X-Plane’s AI to fly complex aircraft.
Supporting Convenience Features
Some common features of third party aircraft are now built into X-Plane. This just means that X-Plane provides standard, canonical datarefs and commands. By using the standard commands and datarefs, you allow users to share keyboard shortcuts and menu items with all aircraft.
Aircraft Doors
X-Plane 11 provides simulation of up to ten animated aircraft doors – if your aircraft needs more than ten doors, please contact us.
Commands to open and close the doors
sim/flight_controls/door_open_1
sim/flight_controls/door_open_2
sim/flight_controls/door_open_10
sim/flight_controls/door_close_1
sim/flight_controls/door_open_2
sim/flight_controls/door_open_10
Datarefs:
sim/cockpit2/switches/door_open[10] – int, writeable, opens/closes the door
sim/flightmodel2/misc/door_open_ratio[10] – float, read-only, shows its current, animated position.
Yoke show-hide
X-Plane 11 allows the user to hide the yoke in the 3-d cockpit to more easily see the panel.
sim/operation/toggle_yoke – command to toggle yoke visibility
sim/graphics/view/hide_yoke (int, writeable) – indicates yoke visibility, can be edited.
Navdata
The Navdata files Airports.txt, Navaids.txt, Waypoints.txt and ATS.txt as well as the Proc/ICAO.txt files no longer ship with X-Plane. If your aircraft requires those files, please make sure to notify Navigraph/Aerosoft so they can make a package for you. The default data for X-Plane will no longer contain those files.
You can find information about the default data that ships with X-Plane 11 here: //developer.x-plane.com/?article=navdata-in-x-plane-11
Weapons
The weapons SDK is the one area where we have moved temporarily backward from X-Plane 10. X-Plane 11 features a new unified weapons system that takes technology from both X-Plane 10 desktop (for physics) and X-Plane 10 mobile (for multiplayer simulation). Unfortunately, we haven’t had time to create an appropriate dataref interface to these weapons.
Getting the interface to weapons finished is on our short list for after 11.0 ships; expect that the list of datarefs may be different for 11.xx than it was for X-Plane 10. The new system has new capabilities that make the old “fixed index of weapons” model not a great fit.
Unfortunately, this means that if your add-on depends on plugin-controlled weapons, you’re stuck in a holding pattern until we can post a new interface that we can maintain.
Sound
FMOD documentation is still pending. There are a lot of details to get right in making an FMOD-enhanced aircraft; please do not ship an FMOD-enhanced aircraft before the docs come out – there’s a very high chance of doing something wrong if you’re just trying to guess how the system works.
What you can do now is learn how to use FMOD! Download the FMOD studio editor (it’s a free download) and start working with its sound design tools.
Service Vehicles
Pushback trucks and ground service vehicles are new in X-Plane 11. Now, for ground traffic to swirl all about your airplane and service it, you will want to set up the docking ports on your airplane!
For any old V10 airplane or other airplane not yet set up to handle ground traffic, fire up Plane-Maker and go to the STANDARD menu, then VIEWPOINT window.
In there, go over to the last tab on the right, labelled “Location” or more recently “Docking Ports”. There, enter the lat, long, and vertical arm of the docking ports for the various types of service trucks! (Ports should be based on what the plane actually has.) Make the window super-wide to see the airplane on the right side of the screen with the docking ports drawn as little spheres to help you position the docking ports quickly.
Once you have entered a docking port location for, say, a fuel truck, then whenever you ask for service or set “AI Flies Your Plane”, the fuel trucks will go to that location to give service.
Beginning in X-Plane 10.40, Plane Maker added support for a variety of extra “metadata” information in ACF files. X-Plane 10 did not make use of this metadata, but X-Plane 11 uses it extensively. For your aircraft to take advantage of the new filtering & search support in the Flight Configuration screen’s aircraft grid, you’ll want to make sure you include this information.
To add aircraft metadata, open your aircraft in Plane Maker, then go to Standard > Author. There, you can set the following fields used by the X-Plane 11 user interface:
- Name for X-Plane UI: The name as displayed in the aircraft grid, and the aircraft’s Customize screen. This should be short and sweet—prefer “F-22 Raptor” or even just “F-22” to “Lockheed Martin F-22 Raptor.”
- Design Studio: The group producing your aircraft. You want the design studio to stay consistent for all the aircraft your group produces. This is in contrast to the “aircraft author” field, which credits the actual people involved in the plane. So, for instance, your studio might be “Amazing Sim Planes,” while your “author” field might be something like “Jane Doe, flight model; John Doe, 3-D modeling; Jack Jones, texturing.”
- Manufacturer: The real-world manufacturer of the aircraft you are modeling. (E.g., Boeing, Cessna, etc.—not related to the team creating the X-Plane model.)
- Classification (checkboxes): An aircraft may fall into zero, one, or many categories (airliner, general aviation, experimental, etc.). Your aircraft will appear in the UI section corresponding to each category it belongs to.
All the fields above are also available in the text search field. So, for instance, if your aircraft has the following fields:
- Name: F-22
- Manufacturer: Lockheed Martin
- Studio: Amazing Sim Planes
- Classification: Military
…your aircraft would show up in all of the following searches, based on matches or partial matches for words in those fields:
- “22”
- “F-22”
- “martin”
- “amazing”
- “sim planes”
- “military”
The new X-Plane 11 UI includes aircraft icons arranged in a grid on the Flight Configuration screen. The new icon style is a simple picture of the aircraft, seen from a particular angle, over a transparent background. By keeping your icons consistent with the X-Plane 11 default icons, your aircraft will both look professional and be identifiable at a glance.
Generate Icons
You have two options for creating X-Plane 11 icons for your aircraft:
- X-Plane can automatically generate an icon for each livery of your aircraft. This is the preferred method. To do so, start a flight in your aircraft, then, in the menu bar, click Developer > Regenerate icons for current aircraft (shift + R by default).
- Note that we control for some variables in generating these images by moving the aircraft to PMDY and changing the window size.
- Alternatively, you can use your own 3-D modeling tool to generate the icons, following the specifications below.
X-Plane 11 aircraft icons are stored as follows within your aircraft folder:
- [Your aircraft directory]
- [your ACF name].acf
- [your ACF name]_icon11.png
- [your ACF name]_icon11_thumb.png
liveries
- [your livery name]
- [your ACF name]_icon11.png
- [your ACF name]_icon11_thumb.png
- [another livery name]
- [your ACF name]_icon11.png
- [your ACF name]_icon11_thumb.png
Note that there are actually two images on disk for each livery: the normal “_icon11.png” and the “_thumb” version. The former is an 800×450 image used when you click “Customize” for an aircraft; the latter is a 174×107 image used in the aircraft grid view. (The smaller size gives you both a better image quality and improved performance when scrolling through the grid.)
You probably accessed this page because you ran into an error message in either Plane-Maker or X-Plane, telling you your panel is not compatible with X-Plane 11. The correct fix depends on the kind of instruments you are using in your panel:
Old instrument compatibility
The following instruments are considered “legacy”. They continue to work in v10 aircraft loaded in X-Plane 11, but they can no longer be added to new aircraft in Plane Maker 11:
- GPS_BC
- GPS_GA
- GPA_HM
- FMS
- FMS_small
Note that you cannot save a panel using these instruments in Plane Maker 11. If you want to edit a panel that has those instruments in it, you need to use Plane Maker 10.
If your panel uses those, be advised that these instruments work in X-Plane 11, but will be discontinued in X-Plane 12.
New instruments
The following instruments are available for use in Plane Maker 11 and X-Plane 11:
- GNS430
- GNS430_screen
- GNS530_screen
- CDU739_screen
All of these instruments use the new navigation infrastructure of X-Plane 11 with full terminal procedure support.
Mixed old/new panels
The “copilot” checkbox of the instrument in Plane Maker’s panel editor determines whether the instrument is considered to be on the NAV1/pilot or NAV2/copilot side.
Panels using both instruments from the “legacy” and “new” category are possible, provided all instruments from the same group are on the same side. That means, you can have a new GPS on the pilot side, and an old FMS on the copilot side.
If you keep getting an error message about an incompatible instrument, check all your navigation instruments in the panel and note whether the copilot checkbox is checked. Make sure legacy vs new instruments are correctly separated by side.
X-Plane 11’s Physically Based Rendering (PBR) uses a new material model for solid textured objects and meshes.
Physical Simulation
The X-Plane lighting and material model divide the light interaction with materials into two categories:
- Specular reflection – this is light that bounces directly off the surface of a material. Speuclar reflection is responsible for mirror-like reflections, glossy appearances on materials and any white “sun spot”.
- Diffuse reflection – this is light that makes it past the surface of the material and is partly absorbed. Diffuse reflection is significantly less directional and may be strongly tinted. Diffuse reflection gives materials a “matte” look.
X-Plane 11 conserves energy between diffuse and specular reflection – having a stronger specular reflection reduces the amount of diffuse reflection automatically; in this way highly glossy and reflective materials don’t appear to be overly bright compared to matte materials.
Comparison to X-Plane 10: in X-Plane 10, specularity could be added without reducing diffuse reflectance; this meant that most reflective materials were brighter than non-reflective ones. An artist could choose to manually darken the albedo of a texture to compensate.
The microsurface of a material is considered to be rough or glossy (or some measure in between); roughness and glossiness are measures of how smooth the surface is, not how reflective it is. A surface can be highly reflective and highly rough at the same time.
Roughness serves to spread out specular reflections; a mirror image in a rough surface appears blurry, as each ray of incoming light bounces in several directions.
X-Plane 11 conserves energy as roughness is adjusted; the same amount of energy is reflected in a rough or glossy surface. The difference is that a glossy surface has a highly focused reflection; a light source’s specular reflection will go in one direction on a glossy surface, resulting in a specular highlight that is very bright but small.
By comparison, a rough surface diffuses the specular energy in all directions; the specular reflection is visible over a wide range of angles but is not very strong.
Comparison to X-Plane 10: in X-Plane 10, all surfaces are glossy and only the overall specular reflectance could be changed. Therefore it was impossible in X-Plane 10 to model a surface like asphalt, which is simultaneously very reflective and very rough. An artist could attempt to simulate this by creating a high frequency noise pattern of highly reflective and non-reflective pixels to manually “break up” the reflection, but when zoomed out this effect is incorrect.
Surfaces become more reflective when viewed at glancing angles; this is called the Fresnel effect. X-Plane 11’s rendering engine simulates this automatically. The specular reflectance of a material that is specified by the artist is its minimum reflectance, when the material is viewed directly (e.g. the camera is orthogonal to the surface).
X-Plane 11 automatically decreases diffuse light as the effective reflectivity increases. This avoids materials appearing too bright at glancing angles.
(This is probably a bug – the incoming light is not more glancing based on view angle! The actual effect of fresnel is more complicated because it is affected by the integral of all incoming light.)
Comparison to X-Plane 10: X-Plane 10 does not provide camera-angle-based variable reflectivity; as a result, materials often have to be made too reflective at all angles to make glancing angles look adequately reflective.
Material Properties
The major properties of a material are controlled by two channels of the normal map of a model:
- Roughness is stored in the alpha channel of the object, with 1.0 (maximum opacity) being the most glossy surface, and 0.0 (the most transparent) being the roughest surface.
- Base reflectance (how much light is reflected off of the surface at an orthogonal angle) is optionally stored in the blue channel; no blue means no base reflectance and maximum blue means a completely reflective material at all viewing angles.
This scheme is opt-in; objects use the NORMAL_METALNESS directive to indicate that the blue channel is suitable for base reflectance. (Since legacy models typically have strong blue values from tangent space normal maps, the blue channel must be ignored in legacy models.)
If metalness is not used, a base reflectance of 0.04 is assigned to the entire material; this is a good approximation for most dielectrics (plastic, wood, concrete, etc.) and also a reasonable backward-compatible value for X-Plane 10 content. The roughness channel is intentionally encoded to have the highest gloss value in X-Plane 11 match the most reflective material in X-Plane 10. (Since X-Plane 10 specular reflections were all highly glossy, this means that at least plastics and matte materials “just work” in X-Plane 11.)
X-Plane 11’s treatment of the albedo color (day texture) changes as base reflectance increases:
- The albedo is used to tint specular reflections. While this is not strictly physically correct, it provides an affordable way to create tinted metallic reflections.
- Because base reflection is increasing, the diffuse color becomes darker due to energy conservation.
Glass Effects vs Decals
The alpha channel of the albedo (day texture) is used to create translucent rendering, e.g. the mesh being drawn is blended with the mesh behind it to create a mixture of both colors. There are two physical interpretations of this alpha effect:
- The top mesh is “translucent”, e.g. like tinted glass; the color taken from behind the mesh represents light transferred through the top mesh (translucency).
- The top mesh does not always exist in the alpha-clear parts of the texture, e.g. like the holes in a fence. The top texture acts like a ‘decal’ over what is behind it. In this situation, partial alpha represents a blend of both materials as if there is a pattern of holes in the top mesh so small that both the presence and absence of the material happen in a single pixel. (Think of zooming out with a chain-link fence – the result is translucency.)
In practice, authors use one effect (alpha blending) for both physical cases (translucency and decals). The meaning of alpha matters for physical correctness.
When alpha means ‘decal’, clear alpha removes all lighting effects from the mesh. This is the correct simulation of the mesh not existing.
When alpha means ‘glass’, clear alpha removes the diffuse but not specular component of lighting effects from the mesh. This is the correct simulation of light passing through the boundary layer from ‘stuff behind the mesh’, rather than being absorbed.
X-Plane 11’s default interpretation is the ‘decal’ interpretation, which:
- Matches X-Plane 10.
- Is HDR/deferred rendering compatible.
- Preserves decal behavior on surfaces like runway pavement.
Authors have the option in X-Plane 11 to use glass alpha as long as:
- The object is attached to an aircraft and
- The aircraft’s lighting mode is marked as “glass”.
In this situation, authors can put the BLEND_GLASS directive into an object header; this will cause alpha to make the diffuse channel translucent while keeping specular effects, for reflections on clear glass.
Terminology
X-Plane has two viewing modes for panels: a forward 2-d view that shows the 2-d panel and a 3-d view that shows the 3-d cockpit (which corresponds to the virtual cockpit in MSFS). Unlike MSFS, X-Plane does not provide multiple 2-d panel views – the 2-d side views may not contain working 2-d panels. X-Plane does not provide native support for popup panels, but it is possible to create them using a plugin or other tricks.
X-Plane’s panel consists of a background image (where alpha creates the transparent windshield) and a gray-scale or RGB overlay image that applies shadowing and some 2-d spot lighting to the panel. While MSFS has “gauges” X-Plane has “instruments” – the individual unit of placement.
Instrument Differences
The MSFS panel is created using an XML file; gauges can also be coded in C++ and can be in the form of *.dll or MSFS specific *.gau format.
X-Plane panels reside inside the ACF file in binary format (but can be exported as text from Plane-Maker); most panel editing is done using Plane-Maker’s near-WYSIWYG user interface.
X-Plane provides hundreds of types of instruments built in:
- Pre-made instruments model existing real world instruments; X-Plane ships with a complete set of real world instruments for VFR and IFR flight. Limited customization is possible by replacing bitmaps, and tuning a few parameters.
- Generic instruments provide basic “mechanism”, e.g. a needle that rotates, a button that toggles, etc. The generic instruments have a large number of customized parameters and visualize data from a “dataref” – that is, a sim variable from X-Plane itself or a plugin.
Therefore the closest thing to building gauges using the XML file is to build a panel out of multiple generic instruments. Typically a modern panel might be built primarily from generic instruments, but use the pre-built instruments for the moving map and a few other cases.
Custom Gauge DLL Vs. Plugin
While MSFS allows a custom gauge to be built via a DLL (where the gauge provides a bitmap of its 2-d image), X-Plane has a slightly more generic mechanism:
- An airplane can contain one or more plugins.
- Each plugin has full access to the X-Plane plugin SDK API – this includes building menus, custom UI and windows, creating and modifying sim variables, and drawing using OpenGL.
- Often the generic instruments can be customized by feeding a dataref from your plugin into the generic instrument – that is, the generic instrument rotates the needle (and X-Plane does the drawing) but the animation is keyed to output from your plugin.
- A plugin can also draw directly onto the panel – this happens on a panel-wide basis, not on a per-instrument basis. (This is how a complex custom nav display might be built.)
X-Plane does not provide a general mechanism to let an author “place” a custom plugin-drawn instrument into a panel using Plane-Maker; typically custom instrumentation is specific to a single plane. Where users have tried to build add-on instruments via plugins, they have had to create ad-hoc mechanisms to place those instruments.
The Virtual/3-d Cockpit
X-Plane’s 3-d cockpit environment is actually a rendering of the entire airplane in 3-d; all of the 3-d modeling work you do for airplane will be visible in the 3-d cockpit, allowing for the user to exit the VC and do a walk-around of the airplane. (See “Camera Restriction” below.)
Therefore the virtual cockpit is is simply modeled in 3-d using OBJ files, which contain meshes. Standard animation is used for instruments like steam-gauge airspeed indicators; this is similar to MSFS where a 3-d animation can be driven off of an animation source. Like MSFS, using “real animated 3-d” is often the fastest path for mechanical instruments.
X-Plane does have one “special” object (the “cockpit object”) that is intended particularly for VC work; it allows a 2-d panel to be UV mapped onto some 3-d surfaces, similar to using a material to indicate a 2-d panel mapping in MSFS. This work-flow is largely the same – you would create a snapshot of the “unwrapped” set of 2-d gauges (Plane-Maker can make this snapshot) and then UV map using it. The precise way to indicate “panel texture” depends on the 3-d editor you use.
Like MSFS, X-Plane provides a separate 2-d panel for the purpose of providing a material/texture for the 3-d virtual cockpit; therefore you can tightly pack this texture even if you want to ship a 2-d panel as well. In X-Plane, 2-d panels scroll and are often 2048 x 2048; it is important for performance to tightly pack the panel that is used in the 3-d cockpit.
Mouse-click interaction in the 3-d cockpit in X-Plane is annotated directly on the 3-d mesh; you mark a sub-section of the mesh with a “manipulator” describing what you want to have happen and the gesture. Typical manipulations include drags in 2-d or in arbitrary 3-d space, clicks, etc. Manipulations typically change an X-Plane dataref or run an X-Plane command (similar to an MSFS sim event) to affect the flight model.
Besides direct 3-d manipulation, you can mark any part of the 3-d mesh that has a panel texture mapped to it as “panel clickable” – this causes 3-d clicks to be passed through to the underlying 2-d panel, where the click operates as expected.
Things X-Plane Doesn’t Have Yet
Arbitrary Transforms
X-Plane can show and hide instruments but it cannot arbitrarily rotate or move them; there may be some XML transformations that are not yet possible in X-Plane. In many cases, a pre-built instrument will exist, and you can simply retexture it.
Things MSFS Doesn’t Have
Gradual Lighting Control
For any 3-d model in X-Plane, you can tie the level of the emissive (_LIT) texture using ATTR_lit_level, which arbitrarily scales the texture using a dataref. This has application for more realistic baked lighting, but can also be used to create gradual light faders in the 3-d cockpit or even to create instruments. (For example, the gear light LEDs can be made to appear by tying their lighting level to the gear status.)
Camera Restriction
You can restrict the movement of the camera in the 3-d cockpit by tagging a mesh as solid to the camera; this will stop your user from walking through the walls of the VC.
Use a hidden, simplified, manifold mesh to restrict the camera; the camera restriction will react better and use less CPU power with the simplified mesh.
You can use animations in your camera-restricting mesh. For example, if you animate the doors of your fuselage in the camera-restricting mesh, a user can exit the airplane only when the door is open.
See the default Cessna 172 in X-Plane for an example of this.
What are Non-Monotone Key Frames
Non-Monotone key frames are key frames where the key frame table is not in order. Here are some examples:
N1 ANGLE
0 50
50 270
100 230
This key frame table makes the angle of the needle increase as N1 goes up, but then the needle will reverse and go back down a bit. In this case, “angle” is non-monotone.
In this table for a a rotary;
enum image
0 0
1 2
2 1
4 3
3 4
Both the input and output are non-monotone.
When Would I Want Non-Monotone Key Frames?
Generally you’ll want non-monotone key frames under two cases:
- If an instrument has to move forward and backward in response to data (e.g. the N1 needle example above).
- If you need to remap the enumerated values for a rotary (e..g the rotary example).
When Are Non-Monotone Key Frames Allowed?
- The value (but not dataref) key frame column can be non-monotone as long as the instrument reads but does not write the dataref. So non-monotone output can be used for a needle as long as it is not draggable, for example.
- Rotaries may have non-monotone key frames for both input and output, as long as values are matched _exactly_ without interpolation.
Previewing Non-Monotone Key Frames in Plane-Maker
Plane-maker recognizes that if you have out-of-order non-monotone key framing tables then you are probably intending to use a dataref that EXACTLY hits the key frame, like an int dataref that passes in enums. (You would use this to re-order the mapping between enums and rotary positions.)
In this case Plane-Maker will snap-round the simulated dataref to exact key frames so that you can see a sane preview of the dataref.
If you have done this but the dataref in x-plane is NOT rounded to key frames, you will then see wrong interpolation in x-plane, since we can’t cleanly interpolate non-monotone functions!!
Goals
- Creating liveries/repaints needs to remain simple. Repainting a plane is one of the simplest ways to make X-Plane content – this simplicity should not be lost.
- It should be possible to create a livery without copying airplane content. This is desirable for three reasons: (1) efficiency of implemetation, (2) enabling repaints while retaining content copyright and (3) allowing the author to update the core plane without repainters having to re-copy modified art assets.
Bug Fixing
- If an aircraft package contains multiple aircraft files, liveries will be available to all of them. If the aircraft files represent different configurations (E.g. P&W vs. RR engines) a livery might be appropriate for one aircraft file but incomplete for another. Requested: some way to “limit” a livery to certain aircraft files in a package.
- The tail number is part of the ACF file, but may change due to paint changes of an aircraft. Requested: a way to specify the tail number per livery.
Configuration Management
Airline authors would like to give repainters a choice of “cosmetic” (meaning they do not affect the FM) options for the airplane – this would include things like antenna placement and window location, but would not include things like engine selection or winglets. These cosmetic options would be created by the primary airplane author – the livery repainter would simply select the appropriate parts for the livery in question. (For example, a painter creating a British Airways livery would select Rolls Royce engines to match the real world planes.)
Livery Configuration Files
Proposed: a text file in the livery would provide a storage location for additional per-livery data. This file would be a simple keyed record file (like all X-Plane text files). The file wold have a package specific name like livery.txt, not an aircraft specific name, like ba20_livery.txt.
(This is because the livery might be shared across multiple configurations – file-specific liveries are discussed below. However, consider a Cessna 172, offered in two configurations – with or without G1000. This 2-d panel change would not affect repaints, thus the desire for package-wide liveries.)
Livery configuration files could be written by painters, or (more likely), if a plane author provides a “repainting kit” with starter images, annotated UV maps, etc. then a livery configuration file would be provided in the painting kit that would be customized by the painter.
Configuration File Options
File Matching
If present, a key would specify what ACF files the livery matches for. If no keys are present, the livery can be use for any file. Example:
REQUIRES_FILE b747-400.acf
Tail Number
If present, overrides the tail number for the ACF.
TAIL_NUMBER N4772Q
Object Mapping
The object mapping would allow the livery to remap what objects are attached to the plane, by specifying a file name substitution scheme. The intent is that the airplane author would attach the “default” objects for a configuration in Plane-Maker, but provide alternate objects that could be mapped.
Example:
# This selects to use the "direct_tv.obj" antennas OBJ instead of the regular
# antennas.obj. A painter who wants to have the appearance of direct TV on the
# plane might include this mapping.
MAP_OBJECT antennas.obj antennas_direct_tv.obj
OPEN ISSUE: this could go in one of two ways:
- The above scheme, which lets the painter remap objects directly or
- A scheme in which the primary airplane author enumerates legal combinations and the painter picks from among them. In this second option, the livery might only contain
CONFIG_CHOICE antennas direct_tv
Where the meaning of the option and its legal configs were defined in the ACF package itself.
- Advantages: slightly simpler liveries – livery authors don’t need to know where objects live and what is meant to go with what.
- Disadvantages: whole system becomes more complex, including complexity in the main package.
Ben says: I was originally in favor of choice 2, but Peter has me leaning toward choice 1 for overall simplicity.
Authoring Information
Perhaps the livery should contain authoring information, e.g.
LIVERY_AUTHOR John Wharfing
LIVERY_COPYRIGHT Copyright 2008, All Rights Reserved.
