To get the weather-radar data from x-plane, turn on the CONTROL PAD output in the net output screen, and expect this data to be sent by UDP:
if(puff15)
{
static xint lon_deg=-1;
static xint lat_deg=-1;
static xint lat_min=-1;
if(++lat_min>=61)
{
lat_min=-1;
if(++lon_deg>2)
{
lon_deg=-2;
if(++lat_deg>1)
{
lat_deg=-1;
}
}
}
struct wxr_line_struct // we send a scanline of 61 vertices of weather, spaced 1 minute x 1 minute of lon/lat! cool!
{ // 61 to get both edges of the degree, since this is vertex-centered not cell-centered
xint lon_deg_wes; // vertex-centered not cell-centered is needed to plot radar without it looking blocky
xint lat_deg_sou;
xint lat_min_sou;
xbyt storm_07[61];
};
wxr_line_struct wxr_line;
wxr_line.lon_deg_wes=flt[p0].dat_lon+lon_deg;
wxr_line.lat_deg_sou=flt[p0].dat_lat+lat_deg;
wxr_line.lat_min_sou= lat_min;
for(xint lon_min=0;lon_min<61;lon_min++) { xflt cloud_rat=0.0; xflt storm_rat=0.0; wxr_region_threaded_access->get_num_puffs(ct_radar_precip ,"X-IOS-gen",
(xflt)wxr_line.lon_deg_wes+(xflt)lon_min/60.0 ,
(xflt)wxr_line.lat_deg_sou+(xflt)lat_min/60.0 ,
0.0 ,0,NULL,&cloud_rat,&storm_rat);
wxr_line.storm_07[lon_min]=intlim(storm_rat*9,0,9); // we have 9 clear plus levels of precip in X-IOS
}
inet.inet_send("xRAD",(xchr*)&wxr_line,sizeof(wxr_line),en);
}
This article describes how to optimize the performance of scenery and airplanes that use OBJs. OBJs are often the most expensive part of an airplane or scenery pack, so careful construction of OBJs can help.
Identifying Performance Limitations
There are three typical scenarios for object performance tuning:
- You have a small number of objects with a lot of detail in each one. Typically you will be constrained on “detail” – that is, the total VRAM used by all objects, total number of vertices, and sometimes attributes. A typical scenario might be an airplane, where there are only 20 objects, but each one uses a huge texture, a huge normal map, and has a ton of vertices.
- You have a moderate number of objects, each with a moderate amount of geometry. But do to the repetition, the total vertex count is very high. This is a case where the “leverage” of repeating an object causes problems. A typical case might be a jetway that has a lot of detail and is placed into an airport scenery package 200 times.
- You have a huge number of objects; pure object count is the limiting factor, even though the objects themselves are quite trivial. This can happen when objects are used to build cities, e.g. you have 10,000 building objects in a small area.
Before you can optimize your airplane or scenery, you must identify which scenario you are in. The best way to do this is to reduce the ‘cost’ of your scenery/airplane and watch performance change.
- Reduce the size of textures in photoshop.
- Temporarily remove parts of a model to reduce vertex count.
- Remove some objects from the scenery pack.
When you find a crude technique that improves framerate, you know where your costs are.
Optimizing Detail
If you have a few objects and are still having performance problems, there are a few things to look out for:
First, be aware of overall vertex count. X-Plane can handle fairly large models, but at some point you will run out of vertex budget. Use LOD to simplify meshes when viewed from far away. Two notes on LOD use for vertex count:
- Don’t use LOD to save a small number of vertices. For example, LOD to reduce from 100 to 50 vertices is not a win for detail-bound models. But if your airplane is 500,000 vertices when viewed up close, LOD might be a real win.
- You get maximum performance when an object is not drawn at all because the maximum LOD distance is set low. Separate details that can be eliminated entirely into their own objects, then set their LOD very low to avoid them. The very act of drawing an OBJ is expensive, even if it contains one OBJ, so you save setup costs in this case.
The total amount of texture used by a model or scenery can start to crowd out VRAM. Here LOD is important too. If an object is not drawn at all because we are farther away than its highest LOD, then its texture won’t have to sit in VRAM. But this only works if the texture is not used by any objects.
- Organize your textures so that all details are in one texture, then use LOD to try to eliminate details when viewed far away.
Example: if you are building an airport, put all of your trucks, cones, and other small objects into one texture. Keep the terminals separate. The terminals will be visible from 10 miles away, but if all of the details have low LOD, the detail texture may not be used at all when on final approach, cutting down VRAM use.
Be aware that the cockpit object’s texture is never compressed or reduced in size, so use this texture sparingly; use it only for details that must be crisp to make the plane flyable. If the user is running at a low texture setting, there is a reason for it!
Optimizing Leveraged Geometry
When you have a moderate number of high-cost objects, the total geometry can start to add up. For example, 200 jetways with 10,000 vertices each will add two million vertices to the scene. It’s likely that all of the jetways are visible when the user flies over the airport; two million vertices is a lot, particularly when the rest of the world must be drawn too.
When working on an object that will be placed many times and has a lot of detail, use LOD carefully to avoid high vertex count. For example, it’s fine to have a high detail jetway with 10,000 vertices as long as we have another LOD with only 1000 vertices and a reasonable transition distance. At any one time, most jetways won’t be nearby and will take only 1000 vertices (for 200,000 vertices total) with maybe one jetway using 10,000 vertices. That’s almost a 10x savings in vertex count.
But be aware: there is a cost to having lots of LODs, so generally you should only use two or three LODs.
Optimizing Total Object Count
When placing a large number of objects, the object count becomes the most important factor. Most users will have machines that can draw between 3000 and 8000 objects, per frame, depending on rendering settings, hardware, and drivers. When building cities, it’s pretty easy to exceed these numbers.
The most effective way to cut object count is to make the farthest LOD of your objects be not too far away. When an object is beyond its maximum LOD distance, it is not drawn at all, reducing object count. X-Plane is very very fast at eliminating objects that are beyond their LOD distance. For example, X-Plane can easily draw an OBJ for every taxiway light (over 10,000 objects at KORD) because the LOD distance is only 500m on each light . Thus of those 10,000 objects, almost all of them are eliminated rapidly.
When object count gets large, small mistakes in the OBJs themselves start to add up. A single attribute in an OBJ can add one batch and make the OBJ twice as slow on the CPU to draw. For an airplane cockpit this is no problem, but if the OBJ is repeated 5000 times then we’ve added 5000 batches. When building an object that will be placed many times:
- Do not use attributes if you can possibly avoid it.
- Keep LOD low when possible.
- If possible, use only triangles; avoid lines and animation.
OBJ File Format Performance
This section contains some notes regarding the creation of fast OBJ files. This is only of interest if you are working on an export script that creates the OBJ file itself – that is, it deals with how to best organize an OBJ file for maximum speed.
Ordering
Let’s start with the ‘cost’ of everything. Basically, the rough list is (most expensive changes come first: these are the things you do NOT want to interleave):
- Changing primitive type (tris vs lines vs lights vs smoke – always put lights last!).
- Changing to and from the cockpit texture (try to avoid doing this more than once!!)
- Changing “shader” (this includes: poly OS, ATTR_light_level — Material changes)
- Animation
- “Cheap” attributes (ATTR_hard/ATTR_hard_deck, ATTR_draw_disable). Basically these control which ‘physical’ mesh a tri is part of are the cheapest attributes and lowest priority to optimize.
In other words, you never want to do anything to make your OBJ bigger to optimize out ATTR_hard, because the sim is good at ATTR_hard, but it is very slow at changing to the cockpit texture, so avoid doing that more than once. Within these buckets, there really isn’t much difference – that is, poly_os and blend mode both change shaders, so they have nearly the same cost.
You can avoid ‘small’ batches of two sided by duplicating the geometry and reversing the normal – if an entire OBJ is two sided, ATTR_two_sided _might_ be best, but if a model has only a few two-sided geometry, duplicate the mesh; it can be worth it to create up to 100+ extra triangles to avoid a shader change attribute.
The cost of anim transforms is of course partly in the animation, but part is in the stoppage of drawing. So given a HUGE pile of animation commands, it’s good to have them all in one group. That’s why the XPlane2Blender exporter performs well even though it duplicates the animations (to avoid attribute state) – the result is typically a set of animations, and they’re cheaper in groups.
One other note: if you put the word DEBUG on its own line at the end of your OBJ, X-Plane will output the internal command structure, which is what X-Plane will actually run. It will be different from what you output – some commands are optimized out, and some OBJ commands become multiple X-Plane commands. Generally, shorter output in that log is better, and fewer shader changes are really important. Note that the list contains aesthetic ideas too – e.g. poly_os is before non-poly_os because otherwise the poly_os geometry will look bad!
In the end, the fast path is an OBJ with _no_ internal shader changes; this case is fast no matter what the sort order (since there are no shader changes to sort) but if a user includes shader changes, there is going to be a speed hit.
Almost all lighting billboards come from OBJs, via named lights or custom lights.
They are usually subject to level of detail (LOD). However, there are some exceptions.
Philosophy:
- Authors know better than X-Plane when an OBJ should disappear – it’s a subjective thing. X-Plane always honors ATTR_LOD for triangles.
- X-Plane knows better than authors when a light should disappear – since X-Plane knows how those abstract light params are rendered. X-Plane may ignore LOD. Usually this involves light being drawn for a longer distance, in cases where there is no perf hit in the rendering enigne. This is almost always desirable for authors.
Guidelines:
- Replicate your lights through all LODs with the SAME exact values.
- You can drop a light in far LOD but don’t add one.
Notes on implementation:
- X-Plane may draw your light for longer than you want – calc will be based on light’s actual appearance.
- X-Plane won’t double-draw extended-LOD lights when repeated in two LODs. Not a problem!
- Don’t add lights in far LOD – X-Plane may not be able to accurately do this effect if it is tampering with LOD!
- If your last LOD is light only, X-Plane can handle this VERY efficiently. So often there is penalty for huge final LOD for a named light that is geo only.
X-Plane 940 allows you to customize the look of the prop disc using a series of datarefs. The idea is to allow a plugin installed in an airplane to provide the rules for prop disc rendering, while letting X-Plane deal with the details of z-buffer thrash and other prop-disc-related artifacts.
Authors who want detailed 3-d props (when not spinning) should continue to build these with a 3-d modeler and turn off the “draw plane part”.
A sample plugin that controls the prop disc datarefs can be found here: //www.xsquawkbox.net/xpsdk/mediawiki/Custom_Prop_Disc
You can download a sample airplane with a custom prop disc driven by a plugin here: File:Example prop disc.zip.
Concepts
A prop is either a disc or not. In disc mode the physical prop is not drawn – instead one or two proxy textures are drawn to simulate the effect of the prop spinning rapidly.
When the prop is not a disc, X-Plane will draw an airfoil for each blade, unless the plane part is disabled for drawing in Plane-Maker.
The prop disc is made up of two parts: the front disc and the side billboard. (The side billboard is not used unless a plugin activates it.) The front disc is a quad normal to the longitudinal axis; the side billboard is a quad normal to the lateral axis. Both spin around the longitudinal axis.
The prop disc texture is used by dividing it into equally sized cells horizontally and vertically and then selecting a cell. Up to two horizontally adjacent cells can be blended; vertical cells cannot. (Vertical cells are intended to provide multiple textures for a main and tail rotor, for example.)
The cell grid does not have to be the same for the prop front and side billboard. For example, a typical layout might divide the texture into 4 cells for prop front discs (using the first 3) and then 16 cells for the prop side billboards, using the last 4.
Each engine has a prop override – when this is 0, X-Plane fills in all other values, managing cell selection, angles and the choice of whether the prop is a disc to match prior behavior. When a plugin sets this override (per engine) all datarefs (including prop angle, which is what makes the prop spin) are under plugin control.
All datarefs are per-engine arrays, for individual control of each engine.
Datarefs
sim/flightmodel2/engines/prop_disc/override
Set this to control the rest of these datarefs.
sim/flightmodel2/engines/prop_is_disc
This dataref can be set to 1 to use billboards and discs or 0 for a physical prop. You can read this dataref even if you are not overriding the prop.
sim/flightmodel2/engines/prop_rotation_angle_deg
sim/flightmodel2/engines/prop_disc/side_angle
These are the rotation angles of the front disc and side billboard – set by X-Plane unless you override.
Important: you should limit the prop angles to the range of 0-360 degrees while you compute them. While the sim will function with the values out of range, the result of letting the values get very huge is a loss of numeric precision that will cause artifacts during long flights.
Datarefs For Cell Selection
These datarefs control “cell selection” for teh textures:
Front disc:
sim/flightmodel2/engines/prop_disc/disc_s
sim/flightmodel2/engines/prop_disc/disc_t
sim/flightmodel2/engines/prop_disc/disc_s_dim
sim/flightmodel2/engines/prop_disc/disc_t_dim
Side billboard:
sim/flightmodel2/engines/prop_disc/side_s
sim/flightmodel2/engines/prop_disc/side_t
sim/flightmodel2/engines/prop_disc/side_s_dim
sim/flightmodel2/engines/prop_disc/side_t_dim
The s_tim and _t_dim define the number of horizontal axis (s) and vertical axis (t) cells for the prop disc and the side billboard. Make sure they are not zero! The _s and _t datarefs pick which cell; the lower left cell is numbered 0,0.
For the disc_s and side_s datarefs you can pass in fractional numbers to create a blend between two cells…for example, the value 2.25 is a blend of 75% cell number 2 and 25% cell number 3.
Translucency Control
You can control the translucency of each prop disc. For the front disc:
sim/flightmodel2/engines/prop_disc/disc_alpha_front
sim/flightmodel2/engines/prop_disc/disc_alpha_side
sim/flightmodel2/engines/prop_disc/disc_alpha_inside
X-Plane will interpolate between the front translucency and side translucency based on the view angle of the camera. So for example if disc_alpha_front is 1.0 and disc_alpha_side is 0.0, the disc will fade out as the camera rotates from front to side.
disc_alpha_inside is a scaler. For example if it was 0.75 then the disc would be 75% as opaque inside the cockpit as it is outside.
These datarefs provide the same service for the side billboard.
sim/flightmodel2/engines/prop_disc/side_alpha_front
sim/flightmodel2/engines/prop_disc/side_alpha_side
sim/flightmodel2/engines/prop_disc/side_alpha_inside
Controlling the Side Billboard
sim/flightmodel2/engines/prop_disc/side_width
This defines the width of the side billboard in meters.
sim/flightmodel2/engines/prop_disc/side_is_billboard
If you set this dataref to 1, the side billboard will be aligned to the camera (billboarded) automatically by X-Plane. If you set it to 0 it will be rotated around the longitudinal axis of the engine based on the side_angle dataref.
sim/flightmodel2/engines/prop_disc/side_number_of_blades
This defines the number of billboards to draw for the side billboard.
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.
Draw Order Within an OBJ
Draw order within an X-Plane object is deterministic – X-Plane always draws objects in the order of their command structure. Therefore you can control draw order using your 3-d modeling tool.
- The ac3d exporter will export models in the order shown in the hierarchy view.
- The Blender exporter will sort your model, but will keep groups separated, and will put mesh triangles marked “alpha” last.
- LR’s modified blender exporter for v10 (to be staged with v10 – contact LR if you want to merge the changes into another distro) sorts triangles back to front and front to back to help make translucent surfaces work.
X-Plane 10 Only: the order of additive LODs is not guaranteed; X-Plane may draw the LODs in any order.
Layer Groups and Draw Order Between OBJs
All art assets in X-Plane belong to a layer group. Layer groups are always drawn in order, but within a layer group the draw order is unpredictable. This means:
- You can force one object to always be drawn before another by putting it in a lower layer group (using ATTR_layer_group).
- You cannot dynamically change the draw order at runtime – you must pick which object is drawn first.
- You cannot change the draw order based on camera angle.
Note that using layer groups disables X-Plane’s ability to optimize object draw order for performance (because it forces a particular, possibly non-optimal draw order); use layer groups only where you must use them for correct visual output.
User Controls for Lighting Effects
external spill vs. emissive
instrument lighting rheostats
panel lighting rheostats
HUD rheostat
Instrument Lighting Properties
These lighting techniques apply to both 2-d panels and 3-d cockpits that use 2-d panels as textures.
Instrument Overlay Lighting Modes
Generic instruments overlays have one of three lighting modes – the lighting mode controls how LIT layers are used and how the instrument reacts to brightness changes. In considering the mode, each instrument has:
- A power source.
- A rheostat controlling instrument brightness.
- Some amount of light falling on the instrument, the sum of ambient, flood, and spot lights.
Built-in instruments typically have either the glass or mechanical mode, but a few are composed of parts that have both properties.
Mechanical Lighting
Mechanical lighting is the simplest mode: the overlays brightness comes from the sum of ambient, flood and spot lighting hitting the instrument overlay. This mode of lighting is appropriate for instrument overlays that simulate mechanical parts, parts that require something to cast light to be seen.
If electric power fails, the instrument is still drawn; the power failure is noticeable because the spot and floods will go dark, reducing the amount of light that falls on the overlay.
For backward compatibility, mechanical lighting will use the _LIT texture when it is dark and the electrical system is on. However, we recommend that you use back-lit lighting for mechanical lit instruments in X-Plane versions 920 and newer. (See below.)
You can cause mechanical lit instruments to disappear using generic instrument filters; this might be appropriate for a mechanical flag, for example.
Glass Lighting
With glass lighting, the instrument brightness rheostat determines the brightness of the instrument. The light cast on the instrument has no effect. This is appropriate for EFIS elements and other “glass” displays. If power fails, the instrument is not drawn at all.
For backward compatibility, mechanical lighting will use the _LIT texture when it is dark and the electrical system is on. However, we recommend that you use not use this feature with glass lighting in X-Plane versions after 920. (See below.)
Back-Lit/Additive Lighting
Back-Lit lighting is a new lighting mode: the daytime texture is drawn based on the sum of ambient, spot and flood lighting; the LIT layer is then added on top of the day time texture (when power is available) at a brightness based on the instrument rheostat.
The result is an instrument that is self-lighting, but still visible due to ambient light if power fails.
Lighting Modes for Non-Generic Instruments
- You can set the lighting rheostat property on any instrument, even an old one.
- The parts of that instrument that respond to the “instrument brightness” rheostat will now follow any of the 16 lighting values.
This lets you use the moving map and pre-made EFIS elements with multiple lighting rheostats.
In X-Plane 930 and newer, you can set the legacy lighting mode to “mechanical” or “additive” (which corresponds to mechanical or back-lit for generics). Legacy instruments are “glass” or not based on their type, and in fact some parts may be glass while others are not.
Lighting for 2-D Panels Only
Theoretical Model
Under the new 2-d panel lighting model, there are four sources of light:
- Ambient light comes from outside the plane – its level is a rough approximation of sun and moon effects (but in the 2-d panel it is not directional.)
- The flood light fills the entire panel with a single color, similar to what was available in 902. The flood level is controlled by the panel brightness rheostat (flood light rheostat).
- Up to 3 spot lights fill some areas of the panel with a specific color. The spot lights are defined by an RGB color in PlaneMaker and a mask (indicating where they have influence) in a PNG file. Three new rheostats control the spot light brightness individually.
- Instrument overlays can also have “emissive” lighting – that is, they can light themselves up regardless of these other effects. Instrument brightness can come from one of sixteen rheostats; default instruments use rheostats 0 and 1 (for pilot and copilot). Old datarefs and instruments keep rheostats 0 and 1 in sync for compatibility with 902 and beyond.
Panel Background Spot Light and Shadow Masks
Four things are necessary to use the new panel spot-light feature:
- Include at least one spot light overlay. These overlays have the same name as the panel, with the extensions -2.png, -3.png and -4.png. Their format is a gray-scale PNG (no alpha) of the same size as the main panel. These correspond to each of the three spot-lights.
- Change the -1 shadow layer from RGB+alpha to gray-scale, no alpha. In its converted form, white means more shadow, black means no shadow.
- Set the RGB colors for the three spot lights in the PlaneMaker view screen (lights sub-tab).
- Optional: include rheostats to control the spot light levels.
The change in shadow format is very important: without the spot light system, the shadow uses transparency to overlay a color image. With the shadow format, the shadow is a simple gray-scale mask, with higher values meaning more shadow.
Spot lights affect burned-in instruments on a per-pixel basis; that is, the the spot light masks combine with the background image to produce a lighting effect.
Spot lights affect overlays on a per-instrument basis; that is, the overlays will take on a lighting level from the average of the spot light around the instrument, but one side of an overlay can’t have a different spot-light affect from the other side. The precise way spot lighting is used depends on the lighting mode (see below).
Lighting Tips
Creating Glow Effects With Default Instruments
In X-Plane 930 and newer you can use “additive” lighting with the default instruments – set the lighting mode to “additive” in Plane-Maker and add _LIT-1, _LIT-2 textures etc. to the overlays.
This effect is typically used to make LEDs and back-lit numbers have a warm “glow” at night.
There are two problems with this technique. First, additive lighting can only be used on the overlays of an instrument, e.g. the -1, -2, -3 and -4 layers. So there is no way to make the background glow. For example, if an instrument has its numbers and markings in the background, those can’t be made to glow.
The work-around is to make a new instrument, typically a generic rotary with 1 image cell and no click mode, with additive lighting mode and the image of the glow. The glow goes in the -1 layer.
This glow instrument must be lower in the panel “stack” than the instrument you want to glow. The glow will appear on top of the background (since all backgrounds are drawn before any overlays) but under the moving parts of the regular instrument (which is higher in the sack).
For an example of this, see the default C172 in X-Plane 930 or newer. Since the steam gauges have their markings in the background, the author uses a single large generic to add all the glow effects to the six-pack instruments.
The second problem is that default instruments automatically categorize their layers into lit vs. mechanical lighting…the “additive” option only affects those “mechanical” layers. For example, in the radio stack, the LEDs are automatically categorized as “lit”, so additive lighting is not available for them.
Usually this is not a problem – if the layer is lit, you wouldn’t need glow because the lit texture would already contain this.
Per-Pixel vs. Per-Vertex Limitations
The 2-d “lighting” masks (-2, -3, and -4 layers on the panel background) add light to the panel and instrument background and any burned in elements on a per-pixel basis.
However, due to performance limitations, these effects only affect overlays on a per-vertex basis. That is, the entire overlay is lit uniformly by the -2,-3, or -4 mask based on one sampling point. (The same is true for the -1 shadow layer.)
There is no one good work-around for this…typically you will have to use a combination of careful shaping of the background lighting effects and possible use of lighting overlays to reduce artifacts.
Theory
A color profile describes what the meaning of various RGB color triples mean, that is, how red is red?
It is important that the color profile you author your textures with is the same as the one X-Plane uses to show them.
The recommended color profile is sRGB, a standard color profile. You work in sRGB color space, save your files with this marked on the PNG file, and then X-Plane can adjust the color if the user’s display doesn’t match sRGB.
Steps For Correct Color
To maintain correct color, you must do three things:
- Author with correct color
- Save your work in a way that will not confuse X-Plane
- Set up X-Plane to correctly recreate that work
Setting up the Authoring Environment
In order to create a texture that looks right, you need to author in an environment where ‘red’ is really ‘red’. To do this, you need to:
- Set your monitor to an sRGB color profile.
- Set your painting program to both work and save using the sRGB color space.
Making Sure Textures Are Saved Properly
Your saved PNG files must contain either a gamma chunk that indicates a gamma of 0.45445 or an sRGB chunk or both. How you do this will depend on your painting tools, but one of these chunks must be present for X-Plane to “know” that your texture is authored in sRGB.
If you are working with DDS, use XGrinder and DDSTool – X-Plane’s handling of color correction with DDS textures is [quirky]; using XGrinder/DDSTool ensures that the DDS file is encoded with the same rules X-Plane will use to decode it.
Setting Up Correct Viewing in X-Plane
Finally, to see how the texture looks in sim, keep your monitor calibrated to sRGB and set X-Plane’s gamma setting to 2.2. This will tell X-Plane that it does not need to modify your textures, which are already in sRGB, just like your monitor.
Mac Users: if you are using a version of OS X before 10.6, your monitor’s gamma will probably be set to 1.8. In this case, you can set X-Plane’s gamma to 1.8, but setting the color profile’s gamma to 2.2 might be a more accurate way to work.
This article describes how to locate a user’s X-Plane 9, 10, or 11 installation – it is targeted at third party add-on vendors who want to make the installation process easier for users.
Important: a user may have more than one copy of X-Plane installed on their computer. While we expect normal users to have only one copy of X-Plane, there is no requirement that there be a single installation.
X-Plane creates a text file in the user’s preferences that lists all known locations of X-Plane. The file is a simple text file with each line being a full path to an X-Plane installation location.
Not every file path points to a valid installation location. If the user has moved X-Plane, then some of the paths may be old and stale. An installer must examine each of the install locations and determine whether the location is in fact a copy of X-Plane. X-Plane’s updater simply validates that the directory exists, but you could also verify the presence of the Resources folder inside the root folder. You cannot assume that any given executable will be in place, as the executable names vary by operating system.
The installation list file is named
- x-plane_install_11.txt for X-Plane 11
- x-plane_install_10.txt for X-Plane 10
- x-plane_install.txt for X-Plane 9.
The location of this file varies by operating system:
- OS X – the file will be in the user’s preferences folder, i.e. ~/Library/Preferences/.
- Windows – the file will be in the user’s local app data folder, i.e. C:\Users\nnnn\AppData\Local\. Use CSIDL_LOCAL_APPDATA to find the location.
- Linux – the file will be in the user’s home folder in a .x-plane/ sub folder, i.e. ~/.x-plane/.
X-Plane 10.25 introduces a new mechanism for authors to optimize framerate in very large custom aircraft, using custom datarefs to “kill” the objects attached to the aircraft. This article explains how the mechanism works and how to use it.
This facility can only be used by aircraft that use a plugin (or plugin script) to create custom datarefs. This facility is only useful if the objects attached to the airplane cause significant framerate loss.
Setting an Object-Kill Dataref
An object-kill dataref is a dataref associated with an attached object that, when it has a non-zero value, causes X-Plane to skip drawing of that object entirely. The dataref is provided by a plugin associated with the aircraft.
In the example to the left, the gear have custom datarefs that hide them – the plugin could set these datarefs to 1 when the gear are up or when the camera is inside the 3-d cockpit. There is also a single custom dataref removing both seats and the cabin interior – this dataref would be set to 1 when the camera is facing forward or when the camera is far from the aircraft.
The object-kill dataref is optional; if the slot is left blank (it is left blank by default) the object is always drawn. An object-kill dataref is not available for the cockpit object, which is always drawn.
Performance of object-kill and ANIM_hide
It is already possible to hide objects using animation, e.g. ANIM_hide. So what is the difference between “hiding” part of an object and “killing it” (removing it completely) with a custom dataref?
An object consumes CPU and GPU in several ways:
- Drawing the object takes CPU time, spent running the object’s internal “commands”, reading datarefs for animations, and configuring the graphics card (time spent on the CPU in the video driver).
- Drawing objects takes GPU time to draw the vertices of the objects. This cost is usually minor; you need to draw several million vertices for the GPU to notice.
- Drawing objects takes GPU time to fill in the pixels of the object. This can be significant, particularly for large screen resolutions, lots of translucency, HDR, and FSAA.
- Drawing an object requires accessing the vertices and texture of the object in VRAM; this increases the total amount of VRAM needed to draw the scene. (See here and here for more info.) This VRAM is needed even if only part of the texture or geometry is actually drawn.
When you use ANIM_hide to hide an object, you save the cost of drawing vertices and filling pixels on the GPU. However, you do not save the cost of the CPU time, or the reduction in working set, because X-Plane runs the entire set of CPU computations for the object regardless of what will be drawn. (X-Plane does this because it must be prepared to draw part of the object even if another part is hidden. ANIM_hide was never intended as a performance optimization.)
When you hide an entire object attached to an aircraft using an object-kill dataref, the object is not processed at all; not only is GPU time saved, but CPU time is saved. Since the object’s data in VRAM is not accessed at all, the pressure on VRAM goes down.
Guidelines for Using Object-Kill
- Use object-kill when the object that can be removed is complex, e.g. an object with a lot of animations, ATTR_light_level directives, etc.
- Use object-kill when you can remove every object that references a large texture set. (For example, if your aircraft has a wing texture with a 2048×2048 normal map, it’s a win to remove every object that uses the wing texture.)
- Use object-kill to remove objects that are rarely visible. For example, if your object comes with a ground power unit, staircase truck, cones, and animated ground crew, it can be a win to object-kill the objects since they will mostly be gone.
- Splitting your aircraft into lots of small objects for the purpose of using object-kill is often not a win. There is a fixed CPU cost per object, so if objects are mostly visible, having more of them is a loss.
- Object-kill datarefs need to run quickly; remove objects based on simple static conditions like “kill gear when the gear is fully retracted”, or “kill the GPU when the plane is moving.” It is not worth it to try to do complex 3-d calculations to determine that an object should be killed. X-Plane already applies visibility culling to your objects.
