The ATC Taxi routes are used by X-Plane ATC to provide navigation guidance around the airport. ATC does not use any information other than the taxi routes; it does not matter where concrete and asphalt actually are, only where the Taxi Routes are.
Taxi Route Authoring in WED
A taxi route is a collection of line segments. Each taxiway segment can be defined as:
One way
On a runway
Departure/arrival hot zones
ILS precision areas
Size restricted
In order for the taxi route to function correctly, a few things must always be true:
Taxi route segments cannot cross each other unless they are connected by a common node. WED automatically prevents this from happening by placing a node where two crossing taxi route segments overlap.
The ENTIRE grid of taxi routes must be connected – there should be a continuous path from any one route to any other route. (This means you CANNOT build an airport with disjoint movement areas, even if it exists in the real world!)
Every runway that is used in ANY flow needs to have a taxi route on it so aircraft can get from and to the runway.
Segments are color coded when viewed in the ATC Taxi + Flow tab, to provide an immediate sense of the properties assigned to each segment.
Basic Taxi Route Segments
The most basic taxi route segment that can be defined is for taxiway on the pavement surrounding an airport. Typically these are drawn over the line markings that guide aircraft around the airport. They are a collection of nodes and segments which are color coded yellow in the map pane.
These segments are typically named to match the real world route letters. You can leave the name blank for very small connectors and routes along the gate line. They can also be defined as one-way routes if planes always use it in only one direction.
To make a new taxi route, select the taxi routes tool and set the name and other properties in the tool bar, then click in the map pane to place the taxi route segments. The taxi route tool does not support bezier curves, so use short segments to approximate curves.
If you cross an existing taxi route segment while creating a new taxi route, WED will automatically insert a node at the intersection.
Runway Taxi Route Segments
A runway taxi route is defined by selecting the appropriate runway from the Runway drop down menu. The Name, Departures, Arrivals, and ILS Precision Area fields will be all be set automatically by WED. Runway segments are normally color coded blue in the WED map pane, but may also be purple – if portions of that runway are also hot zones for other runways (see below for information on hot zones).
For all runway taxi routes:
Taxi route nodes must be inside of the runway’s bounds. Only a small overflow zone past the ends of the runways is allowed.
Taxi routes must be parallel to and as close as possible to the runway’s centerline.
The runway must be sufficiently covered by the taxi route. This includes displaced thresholds, but excludes blast pads.
All runway taxi routes must be properly connected to the rest of the taxi route, as discussed in the Basics section
The property “Size” of runway segments has no function at all in X-plane.
Hot Zones
Hot zones are a location on an airport with a potential risk of collision or runway incursion, and where heightened attention by pilots and drivers is necessary. Usually a segment of the taxiway closest to the runway, or where runways overlap, hot zones are color coded red or purple (when crossing or on a runway) in the map pane.
All taxi route segments inside the hold short lines of the real airport should be marked as hot zones. The presence of the hot zone will cause the AI aircraft to correctly hold short at those hold short lines.
If the real world airport is missing a hold short line on one side of the runway (this is rare, but does sometimes happen) you still need to mark a hot zone approximately where the aircraft would have to stop in order to be out of the way of runway operations.
Runways need hot zones too. When two runways cross, each one needs to have a hot zone marked near the crossing point of the other runway. If there are real land-and-hold-short markings (LAHSO) lines on the runway, this is a good place to start the hot zone. The hot zones are used when a runway is inactive (and being used as a taxiway), and also to detect conflicts between a landed aircraft that is taxiing off the runway and crossing arrivals and departures.
ILS Precision Areas
An ILS critical zone is a designated area of an airport that all physical obstructions must remain clear of when one or more Instrument Landing Systems are in use, to protect against signal interference or attenuation that may lead to navigation errors, or accident. ILS critical zones are color coded orange in the WED map pane.
Taxi Route Sizes
Each taxi route segment has a size letter, which restricts the use of that segment by aircraft larger than the specified size. The sizes depend on only the aircraft’s wingspan in X-Plane and are identical to ICAO aircraft size classifications:
Size Wingspan Examples
A < 15m C172, B58
B < 24m King Air C90
C < 36m B737, A320, MD-80
D < 52m B767, A310, MD-10
E < 65m B777, B747, A340
F < 80m A380
Although this is useful to prevent oversized aircraft visibly hitting their wings on nearby scenery objects, care must be taken to not specify small sizes for no valid reason. The maximum size of aircraft that may taxi or be present at a given airport is limited by the largest size taxi route size specified in any of the ramp starts at that airport, plus runway size restrictions. If there is no path from any ramp start to the active runway wide enough to accommodate that aircraft, the ATC system may come to a full halt.
Taxi Route Obstructions
A similar “stuck forever” situation can occur if ramp start positions that can be used by AI (of type Tiedown or Gate) are on or close to taxi routes. ATC route planning will not check for such obstructions ahead of time, and if the shortest route to the runway happens to go along a route obstructed by a parked aircraft, AI traffic will stop indefinitely as it cannot re-route.
Validation
WED 1.5 (and greater) now has more validations to ensure airport ATC taxi routes are accurate and sensible.
If there are no ATC runway use rules specified, all runways are examined. Otherwise, only the runways mentioned in a runway use rule that also have at least one runway taxi route of the same name are checked during validation.
WED will display the boundaries where ATC taxi routes need hotzone after any failed validation in purple.
Final Tips
A good rule of thumb is to avoid “micromanaging” taxi routes. ATC and Ground Vehicle routes are intended to get traffic close enough to their destination that the built-in logic can taxi the vehicles to their final destination as needed. Specify only the preferred routes, as in general X-Plane can not tell non-plausible, obsolete or rarely used routes from the ones where you want aircraft to go.
Avoid connecting taxi routes directly to ramp starts so that the aircraft has room to maneuver between the taxi network and the ramp start for the best, most realistic results.
Use the fewest segments possible to specify only the desired & safe taxi routes. The taxi route is determined without checking for obstructions along the entire route–only the very next segment of the route is checked ahead of time, and the aircraft will not reroute if it becomes stuck.
Real world ATC is all about efficiency – runway space at major airports is limited, so ATC aims to use the existing runways, taxiways, and airspace in the most efficient manner to arrive and depart as many planes per hour as possible. The “flow” system in WED/X-Plane aim to model real world procedures that were designed for real world efficiency.
An airport ATC “flow” defines how the runways in an airport are used. Each flow tells ATC:
Which runways are used, and in which directions
Whether the runway is used for takeoffs, landings, or both
What kinds of planes use which runways.
Real world flows are often named after the direction of traffic, e.g. “east flow” and “west flow” but these names are never exposed to pilots. In the same manner, WED’s flows are named for reference and log output only and are never displayed to X-Plane users.
Flows are picked based on wind and weather conditions so aircraft can land and take off into the wind. They are also sometimes based on noise abatement – the route the aircraft flies may be restricted to not fly over residential areas at low altitude and high power.
Only one “flow” is used at an airport at a single time – each flow is designed so that all of the runways used in the flow can be used at the same time safely to have maximum efficiency at the airport. A very common misconception is that you need to add one flow per runway; this is not true! You should add one flow per set of conditions, and each flow should contain all runways that are active under those conditions. This implies that a flow is not picked per-aircraft at the time when that aircraft requests runway access; flows do not reference aircraft properties at all.
While X-Plane doesn’t move as many airplanes as KORD, we support the same kinds of rules for realistic routings and flow.
A detailed example: KBOS
Boston Logan has five runways that it uses for major operations: two parallel runways (4L/4R), two near-parallel runways (33L and 32) and one additional runway (9). The airport also has a noise restrictions: no aircraft ever land on runway 14 or depart on runway 32.
Based on this, KBOS has four possible main flows:
“Northeast” VFR flow:
Jets land on 4R
Jets depart 4L and 9
Heavy jets depart 4R
Props land and depart 4L
“Southwest” flow:
Jets land on 27
Jets depart 22R
Heavy jets depart 22L
Props land 22L and hold short of 27
“Northwest” flow
Jets depart 27
Heavy jets depart 33L
Props depart 27
Jets land 33L and 27
Props land 34
“Southeast” flow
Jets land 15R
Props land 15R and 15L (15L is tiny)
Jets depart 15R
Props depart 14
These flows are ordered from most efficient to least efficient for the airport. The southeast flow is a huge bottleneck because KBOS can’t land on runways 9 or 14; all planes have to land on one runway. It is also hard for ATC to land a prop behind a jet because of wake turbulence rules and the difference in speeds. By comparison the northeast flow provides the highest operations rate, with jets landing parallel to props (with each stream of aircraft packed tightly) and room for completely independent departures on runway 9.
Flows in WED & X-Plane
Selection Rules and Priority
The main rules for flow selection in X-Plane are:
Only one flow may be active at a time.
X-Plane will evaluate each of your flows in the order they appear in WED – the top flow in the hierarchy is evaluated first.
The first flow in which all of its rules pass is selected. No further rules are considered.
This means flows should be arranged in WED with care, and generally with the most selective flow first. Where multiple general flows exist, they should be arranged with the most efficient first. In our KBOS example, you would want to arrange the flows in WED in the order they’re listed above (ordered by high to low efficiency).
If no flows are usable – that is, if none match the current conditions – then the airport will be seen as temporarily closed. X-Plane treats airports closed by time rules alone as if they are normal, overnight closures.
It is advisable to always have a “low wind” flow as your first flow, such as 000-360 at 5 knots or less. In light and variable wind conditions, this will ensure that the flow remains stable (i.e. the airport does not continually want to change the active flow) if the wind direction changes rapidly. With continual small wind variations, a wind from 035 at 1 knot may rapidly change to 220 at 2 knots, then back to 040 at 1 knot. With a low-wind flow as the first one, which effectively ignores wind direction, other flows which do depend on wind direction will not be active until the wind is at least 5 knots (in this example) which should be enough to not be affected by small-scale variation.
Each airport has flows evaluated at the point when it is fully loaded into the simulator, typically when it’s within 100 miles or so. Environmental conditions at each airport are re-evaluated frequently to detect if a flow change is needed, but the system will also not change flows too frequently since this is disruptive to aircraft operations. Flow changes may also be delayed by aircraft taxying out, or those within a short time of landing.
Flow basics & rules
Each airport in WED should have one or more flows, ideally more than one. If no flow is provided, X-Plane will generate a basic set of flows aligned to the longest runway and, if necessary, at 90 degrees to it. Parallel and near-perpendicular runways are handled, as are separate low-vis flows for ILS-capable only runways if they exist. To make sure that your airport moves traffic the way you intend though, you should define and test your own flows.
To create a flow in WED, select the airport and use the “Airport→Create Airport Flow” menu.
Flows contain two kinds of data. To add these in WED, select the flow first.
Restrictions that control whether the flow can be used at any given time in the sim (time, vis & wind rules)
Runway Use rules tell which runways will be usable by arriving and departing aircraft, if the environmental rules are passed.
Runway Use Rules
Each flow has one or more “Runway Use” entry that describes a particular runway with use restrictions. These can be added in WED by selecting a flow and using the “Airport→Create Runway Use” menu.
Runway Use rules describe:
The end of the runway to start from
Departure frequency for aircraft departing from this runway using this rule (mobile X-Plane only)
Whether it is used for arrivals, departures, or both
The type of aircraft operations
Departure direction range
Initial assigned heading range
Flows also have a “pattern” runway for VFR traffic patterns. You must still include a runway use – just having the traffic pattern runway will not make that runway used. (The VFR pattern runway on the flow doesn’t tell us what kinds of planes use the runway, etc.)
The runway use rule for the pattern runway should include both arrivals and departures. But do not set a flow to allow arrivals (or departures) on both ends of a runway, or you risk head on collisions! For example, do NOT arrive on 4R AND arrive on 22L. In the majority of cases, if a runway allows arrivals and departures at the same time they will go the same direction and use the same runway.
It is okay to have a runway in a flow more than once – you might need this for complex rules.
From X-Plane 12.1.3, ATC will try to use all available runways in a given flow; before 12.1.3, only the first runway in any flow that meets the current aircraft’s requirements is used.
A single flow containing runways which intersect is normal and expected.
In this case we need to use the 4R runway use twice. For arrivals jets and heavies land 4R, but for departure, ONLY heavies use 4R. The logic behind this case is the heavies need the long runway 4R for departure, but the jets can depart runway 9 for more operations.
You can set this example up in WED two different ways with the same result.
Option 1:
Create a use rule and set traffic type to Jets & Heavy Jets
Set Operations to Arrivals only
Create another use rule
Set traffic type to Heavy Jets
Set operations to departures
Option 2:
Create a use rule
Set traffic type to Heavy Jets
Set operations to departures & arrivals
Create a new rule
Set traffic to Jets
Set operations to arrivals only
The departure frequency field is required but is not fully implemented in X-Plane. In X-Plane desktop version, the relevant frequency at any moment is determined based on nearby controllers’ airspace and this value is ignored.
Runway Uses also include the departure direction range. This is the rough direction from the airport that the aircraft will fly (e.g. if we depart KBOS for San Francisco, our direction is west). This is specified in the Legal on-course hdg min/max in WED. Given two runways that can both depart an aircraft, X-Plane will pick a runway based on departure direction when possible. This lets you specify things like “north departures use 27R, south departures use 27L”, to avoid aircraft crossing in-air. Take care to specify these ranges clockwise; a range of 315 to 045 would mean aircraft departing within 45 degrees of north would be preferred, while a range of 045 to 315 would prefer aircraft departing within 135 degrees of south.
Runway uses also contain an initial heading. These are the ATC Assigned hdg min/max fields in WED. This is the heading that ATC will assign the aircraft off of the runway – it can be a range so that ATC can “fan out” aircraft for faster departures. This is another case where two runway uses can be used, e.g. from our example KBOS northeast flow:
In other words, most props will depart runway 4L and head directly north. But props departing to the south or east will depart runway 9 and immediately turn south-east, getting out of the way of jets. Jets will take off runway 9 and go straight.
(The southeast runway 9 heading lets small airplanes going to Cape Cod go straight out toward their destination – the jets fly straight to get out over water and to not make noise over the city of Boston.)
Note that departure direction and initial direction do not have to match. E.g. at KBOS a jet whose departure direction is West might still get an initial direction of East – this means the plane initially flies the wrong way (usually for noise abatement) and is then turned around.
Time, wind and visibility rules
Flow rules come in three flavors:
Time rules define during what times of day the flow may be used. Time is given in HHMI format in Zulu time, not local time.
Wind rules define under what wind conditions the flow may be used.
Visibility rules define what visibility is required to use the flow; this is defined as part of the flow itself rather than a separately-defined rule.
You can have more than one wind and time rule for a flow; if you do, the flow will pass if any of the rules of that type pass. In other words, you can do this:
Flow “northeast”
Wind < 4 knots, 0-360
Wind < 15 knots, 270 – 090
Flow “southwest”
Wind < 15 knots, 090 – 270
In other words, if the wind is less than four knots or the wind is coming from the north, we use the northeast flow. This “or” behavior is useful because often airports will use the most efficient flow when the wind is very low.
Similarly, the time rules can have more than one time, e.g. for two peak periods.
For all weather-related rules (wind, visibility), you specify the ICAO code of a METAR reporting station. For major airports, this is the airport’s ICAO, but for small satellite airports, you can use the ICAO code of a larger nearby airport. This is for cases where a small GA airport’s runway use must be changed to affect the runway use of the neighboring large airport, or where several airports must adjust their runway uses all at once due to proximity.
Typically an airport with multiple runways will have higher priority “VFR” flows with higher visibility requirements and multiple runways in use, and then lower priority “IFR” flows with no visibility requirements. This lets X-Plane’s ATC use more runways in good conditions and just one runway in bad conditions. The same may apply for low/high wind situations.
Manually Checking Flows
The best way to debug your flows is to set a number of AI aircraft running and watch them, occasionally manually changing weather conditions to those which you think should activate different flows. You can of course check ‘manually’ by disabling AI (just to prevent flows being held unexpectedly), setting appropriate weather conditions, selecting an aircraft of a given type (i.e. prop, jet etc.), and requesting departure clearance from a gate start – not an on-runway start because these are handled slightly differently – or landing clearance from an in-air start.
You can also perform a quick check using ATIS if the airport provides this, since this will give you the active runways. From 12.1.3 onward, active runways are also shown on the map if you zoom in to the airport you wish to check.
To work out which flow should be used, start reading from the top of the list in WED and work down one line at a time. Select the flow, and check that any conditions there are satisfied (i.e. ceiling and visibility). Remember to check the weather the airport is actually reporting, because even with static weather set in the simulator, there are local variations in wind direction, speed and visibility. You might have set a 3kt wind to check a flow which has a wind restriction at 4kt, but if the random local wind variation only adds a single knot then your ‘low wind’ flow will not be used.
If the flow itself passes, check any time or wind restrictions. As long as one restriction from each type passes, the flow is accepted. Of course, if no restriction is given, the flow is also accepted. For example, if you have two wind restrictions and no time restrictions, then the flow will be used if either wind restriction passes.
It is permitted to have flows that define periods when the airport is closed. For example, smaller airports may only be usable during business hours.
At this point, if the flow has passed all the restrictions then this flow is the one that will be used. No other flow will even be considered. If the flow has not passed, read the next flow in the list, in order. If you reach the end of the list without any flow passing, the airport is also seen as closed.
Once you have identified which flow is in use, check each individual runway inside the flow in order from top to bottom. To be usable for a specific aircraft, that aircraft has to match the Traffic Type restriction. If no runway exists in this flow which satisfies that aircraft’s type and the type of operation (i.e. arrival or departure), then the aircraft will be unable to land or depart. No other flow will be considered.
Before X-Plane 12.1.3, the first runway that matches will be used; from 12.1.3 on, any runways that are usable for this aircraft type and purpose will be considered based on other conditions such as proximity and usage levels.
Example
These flows are from an airport which has six flows defined for two usable and parallel runways, 05/23 and 05R/23L . The first two flows are shown here:
The first flow, “Runway 23”, declares that when the wind is at 4kts or lower from any direction or less than 40 knots from somewhere between 150 and 320 degrees, runway 23 and only runway 23 should be used. The runway is restricted to only Jets and Turboprops, which means that the airport is inaccessible for props, helicopters, heavies and fighters.
Firstly, the flow is probably incorrect, because there is also a runway 23L which will never be used at all. In fact, two additional flows exist – one for 23 and one for 23L – neither of which will ever be used because they have identical wind restrictions to “Runway 23” and come after it in the list. This particular airport is popular with GA, so disallowing props is also incorrect – but a likely explanation follows.
The next flow, “Runway 23 Light”, will never be used because there is no circumstance where it satisfies restrictions that are not also satisfied by “Runway 23”; the only difference is the wind restriction, and it is more restrictive (20kts vs 40kts). “Runway 23 Light” allows the runway to only be used by props and helicopters so even if this flow were to be used, which is impossible, it would prevent jets and turboprops from landing if the wind speed was less than 20 knots. Remember that only one flow is ever in use at any time so if no runway in the currently active flow can service your aircraft, you’re out of luck!
In general, if you have considered naming your flows after runways and you have more than one runway, the flows are probably wrong.
What would be more appropriate would be to define four flows for this airport:
W Light, covering runways 23 (a long tarmac runway) and 23L (a shorter grass runway), with “Wind 4@0-359” and “Wind 20@150-320”, with jets and turboprops assigned to runway 23 and props and helicopters assigned to 23L. Heavies should probably remain excluded; fighters are a trickier question because even a WW1 biplane could be defined as a fighter.
W Normal, covering runway 23 only, with “Wind 40@150-320”, again with jets and turboprops assigned to runway 23. This would close the airport to helicopter and small GA aircraft when the wind was above 20 knots, but leave it open for more powerful aircraft.
E Light, a copy of “W Light” but using runways 05 and 05R and with a single wind restriction for “Wind 20@320-150”. It would be pointless to include “Wind 4@0-359” because it has already been satisfied by “W Light”.
E Normal, a copy of “W Normal” using only runway 05 and the wind direction reversed to cover “Wind 20@320-150”.
Debugging Flows and Flow Changes
When the weather changes, X-Plane will wait at least one minute before beginning to change flows. When it starts to change flows, the sim goes through three phases:
Departure drain. All new departures are held, but existing departures are allowed to depart using the old flow. All arrivals continue to arrive using the old flow.
Arrival drain. Once the number of non-held departures falls to zero, all arrivals not on final are re-routed to the new flow. Existing arrivals are allowed to land on the old flow.
Complete change-over. Once the existing legacy arrivals have landed, the new flow is fully in effect and the ground hold is lifted.
Note that if the weather changes back to the old flow in phase 1, the old flow is resumed; if the weather changes back in phase 2, we continue to the new flow.
The logic behind step 1 is: we have to let all taxiing departures depart on the old runway because there might not be enough room for aircraft to turn around on the pavement. While this is happening we don’t re-route arrivals to avoid a head-on collision. The logic behind step 2 is: as long as pending arrivals are arriving in the old runway, we can’t release the gate hold because the departing aircraft might block the arrivals’ route to the gate.
By default the ATC system logs some information about flow changes to Log_ATC.txt, but you can turn on advanced and detailed logging by setting the art control atc/debug/rwy_flow to 1. Detailed logging starts after the art control is set. Log_ATC.txt can be viewed in real-time using the “developer console” menu item in the Special menu.
You can also view more details about runway selection by setting the art control atc/debug/rwy_selection to 1.
Starting with X-Plane 10.50 and WED 1.5, ramp starts can be customized with a lot of data to help specify their use. Ramps starts should be designed based on their use in the real world and should never have aircraft scenery objects placed on them as this would interfere with the “Draw Parked Aircraft” and “AI Aircraft” functions in X-plane 10.50 and newer.
Ramp start definitions are also used when deciding what parking locations are suitable for the user aircraft.
Ramp start type
The majority of ramp starts should be either Gate or Tie-down spots. Static aircraft will show up only at these ramp types.
Misc and hangar type ramp starts should only be used for human player starts. X-Plane will ignore Misc type and will not spawn static aircraft there. When Hangar is set, X-Plane assumes the aircraft is in a building (and therefore not visible) and won’t spend resources placing aircraft there. AI aircraft will use Hangar locations as a last resort if no tie down or gate spots are open, but will not use Misc.
Set only one type from the drop down here.
Equipment Type
This field determines what type of aircraft should use this parking spot. Set at least one type from the drop down here, but multiple types are supported on the same spot. The differentiation between “Heavy Jets” and “Jets” is based on their unladen mass and follows the ICAO standard. As a very rough guide, all aircraft size E or larger are usually classified as “Heavy” and those of size D and below as “Jets” although there are a few size D heavy aircraft. It is recommended to always include both “Heavy Jets” and “Jets” as equipment types for all ramp starts of size D and larger to avoid creating unintended restrictions.
Size
This field determines what size (wingspan) aircraft can be assigned to that spot, both for static and AI/user aircraft. For static aircraft, X-Plane will place aircraft that are marked in X-Plane’s scenery library as the specified size & one lower (i.e., size C will be used by size C & B aircraft).
The classification of these sizes follows ICAO Aircraft Size Standards and is as follows:
Letter
Wingspan
Example
A
<15m
C-172, Baron 58
B
15-24m
King Air C90
C
24-36m
B737, A320, MD80
D
36-52m
B767, A310, MD10
E
52-65m
B777, B747, A340
F
65-80m
A380
Ramp Operation Type
To further limit what type of aircraft can be shown as parked aircraft at that ramp, set an operation type. When set to “none,” no parked aircraft will be placed, but AI aircraft of a suitable size can still use this ramp start. Pick only one type from the drop down here.
Airlines
Case insensitive in WED, three letter ICAO codes as per the Airline Codes Wiki Page separated by spaces. This field also affects both static and user/AI aircraft.
For static aircraft, if you have included more than one airline code in this spot, X-Plane will randomly pick one before the available liveries in the library are checked. If the airline code X-Plane selected is not found in the user’s library, a random result will be placed instead. So limit your definitions to airlines code most people actually have static aircraft installed for, otherwise most people will only see completely random liveries at those starts. X-Plane by default includes liveries for only a small number of major airlines, but these will always work. See the category lib/airport/aircraft/airliners/ for available liveries on ramp starts marked as Operation Type=’Airline’. Or the equivalent categories corresponding to the other operation types, if selected.
For moving aircraft, parking spots which are marked as suitable for the aircraft’s airline will be selected first when assigning parking.
Designing sceneries with Ramp Starts
All ramp starts of types “Tiedown” or “Gate” must be placed to allow aircraft taxing along ATC taxi routes to safely pass any aircraft parked there. To check for interference, switch to the “Taxi+Flow” view mode in WED and verify the yellow aircraft shapes are completely clear of the ATC taxi routes depicted in any color, with preferably 10-20 feet of clearance to spare.
User and AI Parking Allocation
When the ATC system needs to allocate a parking spot for the user or an AI aircraft, both when they are created and when they are about to land, it tries to narrow the choice to the best-matching set before choosing one from that reduced set semi-randomly. The information described above is all used in producing the initial reduced set.
All non-Misc parking spots are searched. Any that are blocked by an aircraft are first excluded, where the user’s aircraft, AI aircraft and static aircraft are all considered. A spot may be blocked by an aircraft parked nearby even if it is not itself allocated.
If nothing is available the search is repeated, dropping restrictions in a defined order, until at least one spot is seen as usable. This order is:
Airline
Operation Type
Equipment Type
Size Class (i.e. allow an aircraft which is too large for this parking spot)
Start Type (i.e. allow the inclusion of Hangar, but not Misc)
If the system is trying to allocate a spot for an aircraft which needs parking and more than one spot is usable at the end of each search, those which match the aircraft’s size class most closely are retained
When any criteria have been ignored, only those spots which form the least-bad match from the resulting set are included. In other words, if some spots match three criteria and some match four, only those which match four criteria will be considered.
Debugging Ramp Starts
If AI don’t seem to be using your airport or ramp starts, there are a couple art controls that you can turn on to help debug the situation. (Note you will need to set the art control then make sure the airport reloads by leaving entirely and coming back.):
atc/debug/log_spawn=1 (Prints log info on AI aircraft arrival & departure logic. Use developer console to see this in-sim)
airp/debug_ramp_starts=1 (Leaves on screen a bunch of visual debug markers telling you about the ramp starts, so if a static airplane is missing or wrong you can SEE the data.)
From X-Plane 12.1.3 on, you can check compatibility with particular aircraft using the new “Usable” toggle in the flight configuration page. Select the aircraft you wish to test and then enter the advanced location selection. If you zoom in a little the airport will show only those spots which are usable for this aircraft type. Bear in mind that this page will also show ‘misc’ starts, which will allow the user to start there but nobody, including the user, to be assigned parking there.
When testing, remember to check multiple aircraft types. Common problems include:
GA parking spots which are not suitable for jets. Use the Cirrus Vision SF50, a class A small jet, to check this.
Large spots (classes D, E and F) which are not marked as usable for Heavy aircraft.
Airports where every spot has the same airline restriction. This happens with some in the US where people have marked every parking location as being usable only by SWA, for example. This effectively means that all SWA aircraft can park anywhere, and that for all other aircraft the airline restriction will have to be ignored, meaning that they can also park anywhere.
This RFC is for a scheme that allows overlay scenery elements (points, polygons/poly-lines and road networks) in a DSF to be associated with an airport ID; if the airport is specified by a higherpriority scenery pack than the one that the DSF resides within, then those DSF elements are not loaded. This mirrors the behavior of apt.dat elements (where all apt.dat elements for an airport whose ID is replaced by a higher priority scenery pack are not loaded).
Implementation Details
This scheme is built on top of a number of layered extensions to the DSF file format.
Comment Types
The DSF file format has (since its inception over a decade ago) contained comment blocks. A comment is a blob of variable-sized arbitrary binary data in the DSF command stream. The comment’s size is known to a DSF parser even if the comment’s contents are opaque, allowing for extension to DSFs with forward compatibility.
Until now, X-Plane did not use comments. This scheme introduces comments with a 16-bit comment type starting the comment block, followed by data specific to the comment type. Comment types can be used in any comment command (8, 16, or 32-bit) as long as the comment’s payload is at least 2 bytes long.
Filter Index Comments
Comment type 1 is defined as a change of the filter index. The filter index is a 32-bit signed integer indicating what filter is used to process certain DSF commands; a filter of -1 means “no filter is applied”. No filter is treated as the default state; as filter index comments go by, it effectively changes the filter applied to the next command.
Filters are applied to road network, polygon/poly-line and point commands, but not to patches and base mesh.
Filtering Scheme
X-Plane defines filters to include or not include overlay elements by airport ID code using new properties: the property sim/filter/aptid defines a new filter; the value of the property is the airport ID to match. The filter is defined as including overlay elements if the airport whose ID matches the value is defined by this scenery pack, and as excluding overlay elements if the airport whose ID matches the value is defined by another scenery pack.
X-Plane also uses the filter properties to filter exclusion zone properties; any of the sim/exclude_XXX properties that are after a sim/filter/aptid property in the DSF property table will be included only if the filter is defined as including overlay elements. Exclusion zones defined before any of the filter/aptid filters are always included.
First version to read X-Plane DSF files and use the new library system and packaging.
OBJ7 cockpit texture commands added for 3-d cockpit objects with working panels.
X-Plane 8.01 (11/10/04)
This is a demo download of X-Plane 8.00.
Checkbox added to disable DSF loading, so users can use ENV or DSF scenery without moving files.
X-Plane 8.03 (12/30/04)
This is the first major bug-fix update to the original X-Plane. Besides a number of enhancements to the scenery system to improve the look of the new scenery, it also fixes a number of big performance-killing bugs. Note: this build was originally called X-Plane 8.02 but was accidentally released without a beta label. It has been renamed to 8.03 to prevent confusion about what build is most recent.
On two texture unit machines, X-Plane will load only the base layer of composite terrain types when there is a border texture. Previously borders would not be visible because X-Plane would run out of texture units, so this change effectively prefers borders to composite textures.
Object Version 2 support restored to the sim. This is a legacy format and not recommended for new development, but is supported by 802 for scenery migration.
Libraries may reference multiple objects or facades for one virtual path, providing for variation on an object to be provided by an add-on library.
Facades can have night lighting textures via the TEXTURE_LIT command.
Facades can have real textured roofs instead of a solid color.
Composite textures may be used in any terrain, not just terrain that was composite in the default artwork.
BUMPY and WET commands added to the terrain type file format to allow for customized terrain surfaces.
X-Plane 8.04 – 8.06 (2/2/05)
This is an additonal bug-fix release that also integrates a number of systems changes.
Load order preference has changed: in 8.04 ENV files in the custom scenery folder are preferred to DSFs in the default scenery folder.
X-Plane 8.10-8.11 (3/19/05)
This feature release mostly focuses on systems features but also has a few scenery features to support global scenery.
The sim/require_object property is recognized to force objects in a DSF to be shown at low rendering details.
Terrain files can control clamping vs. wrapping and other properties.
X-Plane 8.15 (6/19/05)
This feature release also focuses on systems, but does have a few fixes to ENV handling.
ENVs draw taxiway lines.
Bug Fix: ENV water-land physics properties now match V7.
Bug Fix: Tall objects with hard surfaces now track correctly.
Bug Fix: No more occasional “NaN” errors with ENVs.
X-Plane 8.20 (11/15/05)
This feature release provides a bunch of new scenery features and the new OBJ8-based object engine.
New .ter file commands for more control of projection, wrapping and composite borders.
New .net command to keep the number of texture repetitions even – useful for bridges.
New .net command for more carefully controlling polygon offset – also useful for bridges.
New .bch file format for beach textures around waterboddies.
New OBJ8 file format with animation, per vertex normals, blending control.
Bug fixes to the OBJ8 engine: poylgon offset and materials now work correctly.
This is mainly a performance-tuning relase, but with a few new scenery features–overlays are the important one.
Sim support for Overlay DSFs.
Datarefs allow a plugin to tell which object is being drawn.
Asynchronous 3-d clutter instantiation.
Bug fixes for culling and speed improvements.
X-Plane 8.40 (4/13/06)
The main purpose of this release was to get X-Plane working on the Intel Macintoshes.
Library system regionalization added.
Object-location datarefs allow for animating multiple instances of one object.
X-Plane 8.50 (7/18/06)
This release features the new apt.dat system as well as other OBJ extensions.
New apt.dat 850 file format support.
New DSF polygon types for draped polygons, painted lines and strings of lights.
OBJ8 supports control over blending, hard surfaces and draw order.
New show/hide OBJ8 animation commands.
OBJ8 supports a new light system.
.net road files support cars and hard pavement.
Facades support hard surfaces and blending control.
Default ships and other default scenery re-implemented as library objects.
Library regions may be defined with PNG files.
X-Plane 8.60 (11/28/06)
A few new features for custom scenery packages, and some bug fixes.
.pol overlay polygons can have texture coordinates, for overlay orthophotos.
.pol files can have clamped textures using new commands.
.For files can prevent trees from being placed over water.
New EXPORT_BACKUP library command lets DSFs use objects from other packages optionally.
Better memory management for overlays in long flights.
Bug fix: Facade walls are now randomized.
X-Plane 8.64 (11/1/07)
Various low-level bug fixes for the scenery system.
Better alignment of OBJs.
X-Plane 9.00 (11/24/07)
New major version, which supports all v8 scenery features plus new ones. The rendering engine no longer pauses on scenery load, uses shaders more heavily, and has increased forest capacity.
OBJ file format supports key frames.
New OBJ command to use part of the panel texture for VRAM savings.
Road .net files extended to support trains.
Road networks are legal in DSF overlays.
New .ter commands to hide terrain repetition using pixel shaders.
Improvements to .pol placement in overlays
Improved forest exclusion zones
It is possible to fly under hard surfaces.
X-Plane 9.20 (10/4/08)
Feature Release with internationalization support, new aircraft and systems code.
OBJ supports manipulators.
Texture Paging Implemented for .ter and .pol files.
Texture engine heavily threaded.
X-Plane 9.30 (Beta 1 2/4/09)
New OBJ features.
OBJ supports variable LIT texture, no draw, solid walls.
OBJ hard surfaces can be animated.
Draped orthophotos with bezier curves now work.
DSFs can contain multiple LOD patches.
X-Plane 9.40 (12/4/09)
New OBJ features, better multi-thread support
Most 3-d Scenery Processes run on up to 8 or more cores
Normal/Specular maps
Parameterized Lights
X-Plane 9.50 (4/15/09)
Performance improvements for large orthophoto sceneries.
Parameterized light list extended to cover all aspects of airplanes.
Perhaps the most important structural difference between the X-Plane and MSFS scenery systems is that MSFS integrates and processes scenery data while the sim runs, while X-Plane scenery is pre-processed. Some examples:
With MSFS, you can specify a water polygon as part of scenery – this data will be merged with land-class data when scenery is loaded. In X-Plane, you specify a water polygon when you build a mesh file; that data has already been merged by the time your .dsf file is ready for distribution.
With MSFS, land-class, orthophoto, and DEM data are combined when the sim runs to create the final mesh. With X-Plane, this data is combined when you create your finished DSF scenery file.
With MSFS, objects are placed on terrain while you fly (auto-gen); with X-Plane, objects are placed on terrain when the DSF file is built (pre-gen).
The X-Plane approach has strengths and weaknesses and a few big implications for scenery developers:
Overall, scenery add-ons must be more monolithic for X-Plane than for MSFS – see integrated mesh vs. layers below. There may be categories of MSFS scenery that cannot be created as ship-alone products on X-Plane. For example, you cannot create scenery that only improves land class data without also providing a mesh in X-Plane.
In some cases, processing time for scenery data is a non-issue for X-Plane. For example, you can input very complex coastlines to X-Plane’s scenery tool; that expensive polygon processing is done during scenery creation and a finished mesh is created.
X-Plane’s terrain meshes are pre-defined in a DSF file – they are not created by X-Plane from raster elevation data. For this reason, any water-tight mesh can be used in X-Plane. We say that X-Plane uses an irregular mesh because the Laminar-provided mesh-creation tools create irregular meshes and the default scenery that ships with X-Plane uses irregular meshes, but it might be more correct to say that we use a mesh of any form.
X-Plane uses an irregular mesh because it can provide superior accuracy for a given vertex count, relative to a regular grid. With an irregular mesh:
Mesh triangles edges can be placed along any polygonal border. This means that polygonal water bodies and orthophotos efficiently shape the mesh.
Mesh triangles can fit the contours of terrain.
We can reduce mesh triangles where they aren’t adding value (e.g. flat locations).
X-Plane has support for detail-removing LOD in version 8 and later (that is, you can provide alternate meshes in a scenery single DSF file and X-Plane will pick between them based on view distance). The scenery tools, as of this writing, have relatively limited support for mesh LOD.
Texture Use
Mesh textures in X-Plane are used directly as part of the mesh – the mesh is more like a big model in that regard. (Compare to MSFS, where the final terrain texture for an area may be built up and pre-mixed from multiple layers.) This means that the performance of a mesh scenery may be improved by careful texture planning. A small number of large textures will outperform a large number of small textures, by reducing batch count to the graphics card.
X-Plane can “page” textures, that is, load lower and higher resolution versions as the user flies. This feature is only available for .pol and .ter textures, that is, base mesh imagery and overlay imagery – it is not available for 3-d models. Paging is done on multiple cores, so flight can be very smooth even with a lot of imagery on a multi-core machine.
For best texture performance, use .dds files – this saves time calculating mipmaps, provides higher compression quality (pre-compressing using a slow offline algorithm reduces artifacts) and improves paging speed.
Integrated Mesh Tiles Vs. Layers
An X-Plane base mesh covers a 1×1 degree “square” of the world (they’re actually not square when viewed in 3-d). The entire mesh for this degree must come from one file, and that mesh must be “integrated” – that is, it contains all land-use, orthophoto, and elevation data, as well as polygonal features like water.
For this reason, you cannot combine an orthophoto add-on and a mesh add-on for the same area in X-Plane; for base meshes you must combine any land-use/orthophoto customizations with mesh improvements.
It is possible to make “overlay” scenery, and overlays can “drape” orthophotos over the mesh. However, the performance of “draped” orthophotos is significantly lower than base mesh orthophotos; for a large area a base mesh is a must for good framerate. Draped orthophotos are targeted at localized modeling, e.g. to customize the surface area of an airport.
Pre-Generation Vs. Auto-Generation
X-Plane does not have auto-gen as it exists in MSFS. With X-Plane scenery, all model, road and vegetation placements (sometimes collectively called ‘clutter’) have their locations specifically defined in a scenery file. Scenery files might have hundreds of thousands of model placements.
Clutter in X-Plane is defined by an abstract placement and an art asset. That is, while you must specifically provide lat/lon coordinates for all houses in your scenery files, you can refer to a single separate model for the house – you do not have to copy the house’s geometry into the scenery file.
It is possible to replace, augment, or customize the actual models used in this process. All art assets go through a library system, which lets third parties utilize X-Plane built-in art assets by reference, or let third parties augment X-Plane’s built-in art assets.
Land-Class vs. Terrain
X-Plane’s scenery system does not distinguish between land-class and orthophotos as a way of covering the mesh. Instead, any given part of the mesh is covered with a “terrain” (defined by a .ter file); the terrain definition will specify the texture res for repeating textures, physical properties, etc.
X-Plane can support both land-class and orthophoto-style texturing. For land-class textures, the terrain file specifies a texture size and orientation and that they should wrap around to form repeating tiles. For orthophoto-style texures, you can specify the coordinate placement of the texture on the terrain in your scenery file.
See Also
Anatomy of the X-Plane Scenery System provides a road map to the various components of the X-Plane scenery system; this can help you locate the useful parts of the scenery system.
Textures play a huge role in determining X-Plane frame rate. The harsh decision to use only one or two textures per airplane and only one texture per object was based on the enormous performance benefits to restricting objects and planes to one texture each.
(Think of each texture X-Plane uses as a crayon you use to color your scenery. But the box of crayons is in the other room, so each time you have to change crayons, it takes a long time. The one-texture-per object rule guarantees that X-Plane won’t be “changing crayons” all the time.)
Pack Textures
Video card memory is at a premium in X-Plane; this is obvious, but don’t waste space in your textures. If you can resize your image to be smaller in Photoshop without losing (much) quality, consider making the texture smaller. If you look at some of the textures Sergio Santagada has done for X-Plane, you will see that every pixel is utilized, and every image is reduced until each detail is one pixel. This helps maximize video card memory.
Use Fewer Large Textures
Use fewer large textures rather than lots of small ones. For example, use one large texture for many objects, allocating the texture space as needed. This both improves frame rate and gives you the flexibility to use non-power-of-2 rectangles within the one larger texture.
Use Textures for Nearby Objects
If you have so many textures that you will need multiple large bitmap files, combine objects that are nearby in your scenery onto one texture. This way if only some of your objects are visible, they will be more likely to all come from the same texture.
Use Alpha Only When Needed
If your texture does not have any transparent parts, make sure to save it without an alpha channel as a PNG file. X-Plane will enable alpha processing if the alpha channel is detected, even if the entire texture is opaque.
Make sure pixels that are supposed to be transparent are 100% transparent. It is faster on older video cards to render pixels that are totally transparent than to render pixels that are, say, 90% transparent. Also, translucent pixels may cause Z-buffer problems.
Terrain
The rule to use fewer larger textures applies doubly to terrain. In the old scenery system, it was best to use a 1024×1024 bitmap and apply the texture over multiple quads. Similar optimizations will help newer versions of X-Plane.
Objects
The overall rules for textures apply to objects as well, especially regarding sharing of textures. Here are some additional things that will help object performance.
Optimal Size for Objects
Probably the biggest factor in object performance is the number of objects vs. the number of polygons in the objects. Here you face a trade-off. There is a certain overhead for drawing an object at all, so making 1000 objects, each with one quad, will be a lot slower than making 1 object with 1000 quads. On the other hand, X-Plane chooses to draw or not draw an object based on whether any of the object is visible. So if your object is very very large, the whole object will be drawn even if only a tiny portion of it is on screen.
Please remember, these are only guidelines – use these guidelines when you have
flexibility as to how you build your objects, but do not bend over backward to hit these numbers. They are meant only to give you a sense of X-Plane’s ideal performance range.
The ideal object dimensions are no larger than 1000 meters on a side – 500 meters on a side is good. Larger than 1000 meters and you will be drawing the object even when it is almost entirely not on screen. 500 meters is the granularity of X-Plane’s rough culling pass.
Ideally an object should have as many polygons as possible – there is no upper limit to the number of polygons; better to have all of your polygons in one object than split between multiple objects. But it can be a problem to have an object with too few polygons. Objects with less than 24 vertices are not efficient in X-Plane. Do not add polygons just to get above this minimum, but if you have objects with a very small number of polygons, consider merging a few objects together.
If an object models one entity, do not break it up for the sake of frame rate; it is very difficult to place multiple objects near each other and get precise alignment. For example, if you have a suspension bridge, use one object rather than three. (If you use three objects, getting the sections to line up will be impossible.
If you have a number of objects near each other that always use the same texture and are not repeated, consider merging them into one bigger object, to get closer to the optimal size. For example, a series of trees or taxiway lines in an airport could be merged into larger chunks to hit optimal object size.
By the same logic as above, consider breaking up collections of objects if they are too big (e.g. too large on screen.)
If you are going to employ level of detail (explained in detail below), make sure you use separate objects, as level of detail decisions are done per object.
One other warning: If an object is heavily repeated, you may not want to merge it because this effectively means more memory usage. X-Plane’s object memory usage is primarily a function of the number of commands in the total set of OBJ files you use. The individual placements of an object are very cheap, but the OBJs themselves can be expensive. If you have 1000 house OBJs, each different, each used once, this is a lot more memory than 1000 placements of a single house object. So you may not want to make a single object with 100 houses if you were using one house object over and over…you will effectively be increasing memory usage.
For New Objects
Definitely take a look at the OBJ Overview document; it contains a ton of OBJ8 specific advice. One note in particular: if you view the bottom of your OBJ8 file (skip all of the IDX entries) to the commands section, the number of TRI commands is a good indication of how well optimized your object is. If you have a ton of commands after the IDX section, your object is probably not optimized.
Object Command Ordering
X-Plane does some minimal reordering of the commands in your object, but for the most part the commands in your object are executed in order. You will get best performance if:
all of the commands of the same type are together when possible. (E.g. all of the TRI commands are back to back.
all of the polygon commands (triangles, quads, etc.) are together. Keep the lines together. Keep the light commands together.
This may be impractical for authors and is mentioned primarily for programmers who develop software that creates OBJ files.
Note: the motivation for not optimizing polygons in OBJ files is partially to keep load times down (by having this done at scenery creation time) and partially to give authors total control over render order within an object. This allows an author to create an object with translucency without Z-buffer problems.
Level of Detail
Level of detail control is one of your most powerful tools to optimize object performance. The level of detail OBJ command lets you specify more than one version of your object for different distances, and also puts a hard limit on how far away your object will be drawn. LOD improves frame rate by reducing the amount of work X-Plane has to do in rendering objects.
If your object does not contain LOD commands, X-Plane will pick a maximum distance for your object based on its dimensions. X-Plane’s guess is just a guess and will either be too low (causing your object to disappear) or too high (causing your object to be drawn needlessly), so consider putting LOD commands on all objects, even if they only have one version.
Multiple representations of your object take time to create, so do an estimate of which objects are worth creating multiple versions of. Some examples:
A skyscraper that is placed in the scenery once that contains 50 polygons. 50 polygons x 1 object is not a lot of polygons – creating a second version of the skyscraper is probably not worth it.
The statue of liberty, as the centerpiece of a scenery package, modeled with 30,000 polygons. In this case, the one object does cost a lot, and may be visible from a long way away due to its large size. This is a case where a second LOD (with, say, 1000 or less polygons) could be worth it.
A house used everywhere with 10 polygons. This is a dubious case – even though the house is used a lot, at best you will only save a few polygons, and the reduced LOD object will be below X-Plane’s efficient sizes. Experimentation will show whether this is a win, but it wouldn’t be the first object to optimize.
A jetway, used 100 times on an airport, with 350 polygons. This is a huge win. This one object causes 35,000 polygons to be drawn, and all 100 objects are probably visible on final approach. Creating a reduced LOD version to be used 500 meters away with only 50 polygons will cut almost 30,000 polygons off of X-Plane’s load without much noticeable degradation.
Even with single representations, good LOD choices are important for frame rate. Taxiway signs, for example, should have low LOD levels because many of them are visible when overflying an airport, but they are very small and disappear from view rapidly.
Avoid hard quads
The hard quad command is more expensive than the regular quad command. Avoid using it unless the polygon absolutely has to be hard.
Facades
Unlike objects, each individual placement of a facade takes up additional memory. In other words, using 2 facade definitions once each takes only a tiny bit more memory than using one facade definition twice. Polygon memory for objects is saved once for the .OBJ file. Polygon memory for facades has to be created once for each instance of the facade because each facade is slightly different in shape. X-Plane has no mechanism for recognizing and pooling same-sized facades.
Avoid excess stretching
The biggest danger to performance from facades is to extrude a facade into a footprint that is much larger than the facade’s ideal size, or to add more floors than the facade’s ideal height.
When X-Plane “extrudes” a facade to make a building in your scenery, it looks at your panel and floor split points and takes as many or as few panels and floors as is needed to meet the height and wall length requirements specified by the DSF file. X-Plane combines adjacent panels, and only adds more polygons to cut out parts of the texture or to duplicate parts of the facade.
In the above picture, a facade is shown in its original form with cutlines and then in three instantiations. The quads X-Plane creates are shown by separating the facade into its component quads. In the first case, the facade is smaller than its ideal size, so four quads are produced. In the second case, the facade is the exact size of the texture, so only one quad is produced. In the third case, the quad has been stretched. Two quad are needed vertically, but many facades are needed horizontally because the facade is so much wider than the texture. This facade is horizontally overextended.
Avoid overextending facades either horizontally or vertically; at most a facade
instantiation should be no larger than twice its ideal size either horizontally or vertically. Make sure your facade definitions match the way they are used in the DSF. For example, if you have a facade that is used 100 times and is overextended to form 10 polygons horizontally and 10 polygons vertically, you will have 40000 polygons where you should have had 1600 polygons.
Named lights are lighting billboards that are designed and implemented by Laminar Research and built into X-Plane. You can add a named light to your aircraft or scenery by using the LIGHT_NAMED command in an object.
The behavior of named lights cannot be customized – each named light comes with preset behavior, such as blinking or changing colors.
Named lights are affected by animation – that is, a named light is hidden if inside an ATTR_hide command, and the directionality of a named light is affected by both the orientation of the object/aircraft and any rotation/translation animations that the named light is inside.
Lights.txt
You can locate the master list of named lights in the file Resources/bitmaps/world/lites/lights.txt. Do not edit this text file! This file will be updated by the X-Plane updater and should be considered part of the sim, not for third party modification. If you need a new named light, send feature requests to LR. The file can be useful for checking for the existence of a particular named light in an older version of X-Plane.
Revision History:
01/26/18 Updated with Joining Taxiways to Runways
06/25/08 Updated With Taxiline Guidelines
10/25/07 Initial Draft
Correct Formation of T Junctions
A “T” junction is any connection between lines in an airport layout where one line ends in the middle of another line. T junctions would include a T-shaped meeting of taxiway lines (shown in these examples), but the junctions formed by the edges of taxiway pavement are also T junctions and need to be formed using the same technique.
The key points are:
Two lines in a WED layout (of any type) should always meet at their endpoints.
One line should not end in the middle of another line.
This means that you must split a line at the point another line intersects it.
You should not simply attempt to visually line up your layout. Consider this T junction:
It looks correct but upon zooming it becomes clear that the taxiway line ends “near” the next line but is not actually on it. With no vertex to join to, this join can never be clean.
Junctions like this can suffer from all sorts of problems in X-Plane:
The alignment error may look significantly worse in the sim–the only way to guarantee a good connection is to have two vertices with the exact same location.
If one of the lines is a bezier curve, the approximation of the bezier in X-Plane may be different from WED, causing a disconnect.
If these lines were taxiway edges, the “sliver” of a gap could cause bumps when a plane rolls over it or ugly rendering errors in the pavement.
The correct way to build a T junction is a two-step process.
Split one of the lines so there is a vertex at the location where the two nodes will meet. :
Then drag the connecting line to that vertex. In WED you can use the “snap to vertex” option to get precise positioning of the two vertices on top of each other. :
This T junction will look correct at any zoom, and will render correctly in X-Plane.
Remember: close visual alignment in WED is not good enough! You must create an extra vertex and snap the vertices together to create precisely aligned layouts.
Correct Bezier T Junctions
When a T junction is made up of a bezier curve, another issue comes into play: besides needing the end vertices to be snapped together, the bezier curve handles must not be “over-curved”. Consider this layout:
It looks okay in WED, but note that the lower control handle of the bezier curve is on the left side of the straight taxiway line (and yet the bezier curve itself is on the right side. This is a mistake in the layout! Here’s what it looks like close up:
The problem is that the bezier curve control handle (by being on the left side of the taxiway line) pulls the bezier to left a little bit too much. The result is that the bezier crosses over the centerline before joining with it. This error looks small in WED, but in X-Plane, where the taxiway lines aren’t as smooth, the error is significantly more noticeable.
In order to fix this problem, the lower bezier control handle must be on the same side of the joining line as the curve itself–in this case on the right side.
This creates a bezier curve that looks good no matter how closely it is zoomed.
The key here is to err on the side of caution: position the bezier control point on the right side of the connecting line; do not trust the preview of the curve to show if there is a problem.
Do Not Add Extra Vertices to Make Smooth Curves
You must add vertices to make T junctions correct. However, you should use the smallest number of vertices possible to correctly describe your layout. For example: this is a bad taxiway line.
The taxiway line is bad because it uses a huge number of vertices – way more than necessary. The line should be built like this:
Use a small number of bezier curves to shape your lines. Do not add extra vertices in an attempt to make the line look smoother in X-Plane.
X-Plane uses an “error” heuristic to draw taxiway lines–basically it will add vertices to minimize the “squareness” of lines. The problem with adding vertices is that you have to add a very large number of vertices to force X-Plane to render at a higher quality. If you add a few vertices, you increase file size, download time, load time, and RAM use, and X-Plane simply adds fewer of its own points (since fewer are needed to reach the same amount of roundness). Only by adding an insane number of vertices can you markedly improve visual quality; this comes at the expense of RAM use for your layout.
Leave smoothness of lines up to X-Plane; this setting will be wired to the user interface. Some users will need lower rendering quality to use your airport on slower computers. If you add too many vertices, you simply assure that these users cannot fly to your airport at all.
Joining Taxiways to Runways
Taxiways should be drawn to the runway edge, not just to the runway shoulder edge:
Connecting the taxiway to the runway in this manner will result in correctly recessed runway edge lights and a better looking connection between the pavements. The taxiways are automatically drawn above the shoulders and below the runways. If you stop the taxiway at the shoulder edge, it often leaves a gap between the runway pavement and the taxiway.
Comments Off on Correctly Forming Taxiways and Junctions
In X-Plane 9, you can create a draped polygon by specifying a polygonal outline in a DSF and a .pol text file with the properties for the polygon. The .pol file references a texture, and optionally applies a physical surface to the polygon. If a physical surface is applied, it acts “over” the base terrain. In this way, the image of a concrete pad (on top of base mesh grass) can act like concrete, with correct physics wherever the plane drives.
There is one limitation with this system: if the author places a large orthophoto (showing heterogeneous terrain) into the scenery, the orthophoto (whether via a .pol or .ter file) can have only one physical property. Thus an airport orthophoto must be “all grass” or “all concrete”.
There is a work-around for this problem, but it is very expensive: an author can place multiple polygons using the same orthophoto texture and shape each polygon to the distinct regions. So the author would put one polygon in place for the whole orthophoto, then a second polygon for only the concrete. Two .pol files reference separate surfaces but one texture.
While X-Plane will efficiently load the texture only once, the resulting polygon mesh is particularly inefficient, because:
X-Plane will dutifully clip the top polygon visually, even though there is no need to do so and
The concrete areas must be drawn twice (once for the bottom and once for the top). To avoid over-draw, the bottom polygon must be clipped as well, which makes even more triangles.
The Proposed Fix
The proposed fix is a new .pol attribute, something like “NO_DRAW”. When present, the polygon would only apply physical properties to the mesh, but not apply any paint. Under this scenario the author would:
Set the physical property of the orthophoto to the “lowest priority” surface, typically grass or dirt.
Use no-draw, concrete-surface polygons to “annotate” the hard physical areas on top of the orthophoto.
X-Plane would perform no clipping on the bottom orthophoto, for maximum mesh efficiency, and would have no overdraw since the texture is only drawn once.
