One thought on alpha and HDR and aircraft:
If you need to create a final flat part of a panel out of multiple layers, some translucent, and you are using panel texture, it is better to composite the entire piece of panel in the panel texture than to layer polygons in your OBJ.
For example, consider the annunciator display on the dashboard that many airplanes have. There are two ways to build this panel:
- Model the entire thing in the panel texture. The background can be part of the panel background, and each annunciator is a generic instrument.
- Each annunciator sits on a transparent background, and the background of the annunciator panel is a separate piece of non-panel texture, on a second mesh, directly behind the first.
Choose option 1! Tom had to convert the Baron’s annunciator panel from method 2 to method 1. A few reasons to prefer method 1:
- The sim does not allow for truly emissive translucent lighting in an OBJ, so the results look better if composited in the panel texture.
- You can get shadowing artifacts between the polygon layers.
- Spill lighting on the dashboard will not look quite right if there is alpha.
You won’t use up that more panel texture, but you’ll make your life easier. This technique wasn’t totally possible before, but now with GLOBAL_cockpit_lit you can alwys have your panel handle real lighting.
I have updated the OBJ8 specification with the new X-Plane 10.10 commands. This blog post explains why we added some of these commands.
Pixel-Space Drag Manipulator
The pixel-space drag manipulator is a new axis manipulator whose drag length is measured in screen pixels instead of meters; its drag axes are always screen aligned, but it works both horizontally and vertically.
The goal of this manipulator is to make draggable knobs that:
- Have a good response speed for both slow and fast drags via a non-linear curve and
- Have the same drag sensitivity no matter what camera angle.
The axis manipulator has the problem that it works in 3-d; depending on how you look at the manipulation target (both position and rotation) the sensitivity of the drag can change radically.
Recommendation: use the regular drag-axis manipulator for levers and other physically moving items. Use the pixel-space drag manipulator for drags where the underlying target does not move, like knobs. Use button-type clicks for anything that just toggles – it’s easier on the user.
No Shadows
Three new attributes (GLOBAL_no_shadow, ATTR_no_shadow, and ATTR_shadow) allow you to exclude part or all of your object from shadow casting. Shadows can make certain types of geometry, like grass billboards, look silly; excluding them from shadows fixes artifacts.
Note that ATTR_no_shadow is different from ATTR_shadow_blend..
- ATTR_no_shadow: the geometry simply does not cast a shadow! This is meant to exclude objects like vegetation.
- ATTR_shadow_blend: the geometry does cast a shadow, but only if the alpha is greater than a certain ratio. This is meant to make windows with tint cast shadows correctly.
Recommendation: fix shadowing bugs using ATTR_no_shadow for non-instanced objects, and GLOBAL_no_shadow for instanced objects. Use the Plane-Maker check-box for parts on aircraft.
GLOBAL_cockpit_lit
This attribute lets you have your cake and eat it. In X-Plane 9, ATTR_cockpit gives you alpha blending, but ATTR_cockpit_region gives you correct 3-d lighting. You have to pick one or the other.
In X-Plane 10.10, GLOBAL_cockpit_lit gives you both. It makes ATTR_cockpit use 3-d lighting (while maintaining translucency) and it makes ATTR_cockpit_region respect alpha translucency (while maintaining cockpit lighting).
You can add this attribute to any airplane. This attribute should make it easier for authors to adopt correct 3-d lighting in their airplanes.
Recommendation: use GLOBAL_cockpit_lit on any airplane that uses ATTR_cockpit to change to 3-d lighting for your panel texture. Also see here for more guidance.
Here are three obscure Plane-Maker/X-Plane features that can save you time if you developer complex aircraft.
Plane-Maker Will Copy Your Instruments
You may know that in Plane-Maker, you make your own copies of X-Plane’s PNG files to customize the look of the instruments. But did you know that Plane-Maker will copy the images for you?
Select an instrument and type Control-P (which is the default for the command binding “pln/panel/copy_instrument_png”). Plane-Maker will copy all PNGs for that instrument into your aircraft’s cockpit or cockpit_3d folder. This can save you the time spent wading through X-Plane’s cockpit folder to find the right PNG files.
X-Plane Can Make a Panel Image for UV-Mapping
When you are making a 3-d cockpit, you use the 3-d panel as a texture. But how do you know how to UV-map this texture in your cockpit? Often the panel background (panel.png) is blank.
X-Plane can make a snapshot of your panel for you, in the exact size you need to UV map. Use Control-Alt-Shift-Space (Command-Option-Shift-Space for Mac nerds) to run the “sim/operation/make_panel_previews” command in X-Plane. It will make a PNG file in your aircraft called Panel_preview.png – it’s just like Panel.png but with the instruments drawn in – perfect for UV mapping.
Plane-Maker Will Tell You What’s Wrong
That sad face icon in top bar of the Plane-Maker panel editor enables “warning” mode. In warning mode, every instrument that has a potential problem gets a red outline. Select one instrument with a red outline and in the upper left corner of the panel you’ll see a description of what’s wrong.
This picture on the left is from Plane-Maker editing a 3-d panel. (That’s why it is just a “packed” set of instruments with no background; this panel is used as a texture for a 3-d cockpit – each instrument is UV-mapped into the right location.)
The air-speed indicator has been flagged as having a problem, and the text shows it. In this case, the lit texture has an alpha channel, which causes the lit texture to draw incorrectly. Fix the texture and the warning will go away.
I strongly recommend checking all Plane-Maker “red boxes” on your plane – most of the warnings will tell you about problems that would otherwise be very hard to detect.
This is a feature I looked at putting into X-Plane 9, but it turned out that it affects so many different parts of the sim (and has to be done all-or-nothing) that it got kicked to v10. Consider these two pictures of the default B777 (the lighting was not adjusted, only the time of day):
The night image looks pretty, but what’s wrong with the day image? The answer is: the small panel post lights in the night image are still casting a fair amount of light in the day image. And the result looks silly. But why?
The answer is: in real life your pupils would contract in the sun, letting in less light. The sun is really rather bright, so the daytime panel would still look normal, but the apparent power of those posts lights would be a lot less, because your eyes are less sensitive. In other words, the relative strength of the sun and post lights is wrong in the second image.
Computer monitors don’t have a huge dynamic range for how much brightness they can put out. So we can’t hope to display the absolute brightness of the scene correctly. Instead we need to make everything brighter at night (to simulate your night vision) and dimmer during the day, like this:
In this set of images, the night image is matched precisely to the previous one, but as the sun comes out, the apparent brightness of all lit textures has been scaled down to simulate the effect of your eye becoming less sensitive due to the flood of sunlight.
What’s good about the compensated image is that the weird artifacts from the post lights are gone; the relative strength of the post lights is really low in relative terms.
What happened to the EFIS and moving map? The answer is that they too are not as apparently bright relative to the sun as they would be at night.
There is one hitch here: plenty of real airplanes have light sensors for various avionics; the avionics will automatically turn up their brightness during the day. So it is possible (I am no expert on the 777) that in the real plane, as the sun rises, you might not have to adjust your instrument brightness; the sensor would do it for you. The pictures above illustrate what you would see if no automatic adjustment is made.
Auto-adjustment presents a challenge: currently two wrongs make a right. We don’t auto-adjust the brightness of instruments, but we don’t simulate the apparent visual brightness relative to the sun, and the result are instruments that look adequately bright at all times of day without user adjustment.
I think in the productized version of this feature, authors will have two options for anything lit:
- Tie the lit instrument/texture to an auto-adjusting rheostat (e.g. brightness 1 + auto adjustment) or
- Tie the lit instrument to the “raw” rheostat (e.g. brightness 1).
The tricky part will be finding the right mapping for legacy airplanes into the new system.
I sometimes get questions from authors considering how much to rely on a 2-d panel mapped to 3-d via the panel texture vs. a true 3-d panel. I can’t comment on what will look best, but I can comment on the relative performance characteristics of both techniques, and the answer might surprise you: in some cases you’ll get better performance by modeling directly in 3-d.
The 2-D Way
When you use the panel texture to make an object, X-Plane goes through a lot of steps to create the final result:
- Your panel has to be rendered in 2-d. We atlas your panel textures, but we don’t necessarily order them optimally – we don’t know the optimal order. Each generic instrument is at least one batch, perhaps even two. Those batches have very low vertex count, and the vertices are stored non-optimally on the CPU. There may be a fair number of texture changes between instruments.
- If you use ATTR_cockpit_region, we then go back and do the same thing…again! Why? Well, we need your panel’s raw color (“albedo” to graphics nerds) and the emissive light given off by anything self-lit separately, so that we can do correct 3-d lighting.
- Both of these are rendered to an off-screen texture that the video driver will feeel obligated to preserve at all costs, putting pressure on VRAM.
- Only when all that is done do we begin drawing your object, with the usual batches to change to panel texture and change back, perform animations, etc.
If this seems expensive, that’s because it is. Periodically users send me airplanes to look at their performance, and lately I’ve been seeing a lot more problems with 2-d panels (that fuel 3-d cockpits) being the performance bottleneck, not the 3-d modeling itself.
The 3-d Way
What if we want to go 3-d? Well, we’re going to “eat” a lot more of what your 3-d pit already has:
- You’ll need a lot more animations to move all of those parts.
- You’ll need new batches with ATTR_lit_level to dial up and down various lighting levels.
But you do get some advantages:
- Geometry in objects is processed about as optimally as we possibly can. All of that work we’ve done on the rendering engine to make OBJs fast is available in your cockpit. So you can increase 3-d detail ‘for free’.
- Your lit geometry can be drawn in a single pass (we don’t need to prepare two separate lit textures). So for example a needle would take three batches via the panel-texture route (a batch to rotate the needle for albedo, a second batch to draw the rotated night needle, and a third batch to draw the resulting texture in 3-d) but only one if you use the OBJ directly.
- Since you organize your textures for OBJs, you can guarantee that all of the cockpit stuff is together, saving texture thrash.
- You can use normal maps to add per pixel detail to your cockpit; panel textured geometry cannot be normal mapped.
A Balancing Act
Given the high cost of panel texture relative to native OBJ drawing, you’d think going native OBJ would be a no-brainer, right? Well, not quite.
A needle is an easy case: you can model a needle using a rotation animation, so your implementation in an OBJ and our generic instrument are quite similar. Same with the throttle lever generic instrument.
But what about a “glass pie indicator”? What about a moving map? What about a rotary?
There are some generic instruments that have “movement” for which there is no equivalent OBJ technique. With these generics, the generic instrument/panel code may be able to render the generic quite a bit more directly than your OBJ can simulate the same effect.
This is my suggestion on a cut-off: if you can directly model a generic instrument with an OBJ (needles, throttles, and other “simple moving things”), consider 3-d. If you would have to use a lot of extra texture space, copies of your mesh, or a lot of show-hides, use the panel texture.
Your goal should not be to eliminate the use of panel texture. But if you can cut panel texture down to a single 1024 x 1024 region from a larger area, you’ll probably see a performance win or a reduction in your airplane’s system requirements.
Performance Test First
Final thought: before you invest months in a complex cockpit design, mock up the “work-load” X-Plane must do and performance test it! For an OBJ, simply make one moving instrument and duplicate the mesh to get the number of expected animations. For the panel, drag out a bunch of instruments, make custom textures and just paint junk into them with photoshop. The goal is to make X-Plane do the same amount of work as it will in the final version. Then fly your test panel on target computers and observe performance.
There were a few threads regarding lighting rheostats in X-Plane 9. Here’s a short version of the issue and why we’re not changing X-Plane 9’s behavior.
X-Plane 9’s policy toward lighting rheostats is a little bit arbitrary. The sim will pre-position every lighting rheostat in the cockpit to 75% intensity on sim startup, and from that point on, we never touch them. We do not reset them when you load a new plane or reset your flight.
The result of this is that when you load a new airplane, it “inherits” the rheostat positions of the last airplane loaded. This can cause a problem if the newly loaded plane doesn’t have controls to adjust the lights (e.g. it has no instruments on the 2-d panel or manipulators on the 3-d panel, and there is no keyboard shortcut defined). A plane can be “stuck dark”.
It would be nice if X-Plane would pre-initialize the lighting rheostats on startup, but X-Plane deos not have enough information to do this. For example, on plane load, the instrument brightness should be set fairly high (so a glass cockpit can be read during the day) but the flood lights should be fairly low (to prevent loss of night vision). But X-Plane has no idea which rheostats control instruments and which control floods. So if we wanted to correctly initialize the cockpit, we wouldn’t have enough information.
To make it more complicated, some airplane authors have taken it upon themselves to initialize the cockpit via plugin code. If X-Plane were to start changing the rheostats at startup, it might undo some of what these plugins have done.
Given the difficulty of maintaining compatibility and the lack of a “correct” set of values, we decided not to change the behavior in 9.50 or 9.55.
If there’s any take-away point for airplane authors, I think it is this: provide controls for the lighting rheostats that you use in your airplane. Otherwise the user can’t turn the lights on if they are off for any reason. You can control the lighting rheostats with a generic instrument, manipulator, or the built-in instruments.
Ugly Glow
There is a separate issue that sometimes comes up: X-Plane panels can look bad when the flood lights are turned all the way up during the day. A panel can look very red and washed out, for example.
This problem comes from a mismatch of real-world lighting levels. In the real world, the sun is approximately four gajillion times more powerful than the little dome lights in an airplane. So when the sun is out, the dome light isn’t visible even if it’s turned all the way up. The dome light only looks bright when your eyes have adjusted to a no-sun condition.
What X-Plane should do (and may do in the future) is scale all cockpit lights relative to the overall daytime brightness, which would effectively dim the effect of flood lights during the day. Simply turning down flood lights when a flight is started during the day is not a full solution, as the user can simply turn them right back up again and end up with an unrealistic scene.
Suffice it to say, I think we will address these things in a v10 time frame, not a v9 time frame; in the short term it’s better to have airplanes continue to function as the author intended.
In order to understand the difference between hiding geometry and disabling drawing, you need to understand that an OBJ triangle can serve many purposes. Broadly, those purposes are:
- Drawing (the most basic use).
- Collision detection, of which we have three flavors: collision of the plane with the object (“hard surfaces”, or “physics”), collision of the mouse with the panel (manipulators, or clickable triangles) and collisions of the camera with the airplane (“solid camera”, which constrains the camera).
Any given triangle can be drawn and/or used to check for any of these collisions*; attributes change what the triangle is used for.
By default, all triangles are drawn; ATTR_draw_disable marks future triangles as not being drawn. This allows you to make a triangle that is used only for collisions. Examples might include a “hot spot” in front of a region on the panel (the hot spot might be easier to click than a small switch) and an invisible simple mesh to constrain the camera.
By comparison, ANIM_hide effectively removes some triangles from your model (temporarily) for all uses – drawing and collision detection of any kind. If a door is hidden, it’s not only not drawn, but it’s not going to stop the camera moving through it either.
Some key points to these distinctions:
- Categorizing what a triangle is used for (drawing, various flavors of collisions) is static – that is, it is always the same for the object and never changes with datarefs or animation. This is intentional for performance reasons!
- Animation to hide triangles affects the triangle in every way consistently – drawing and collisions.
Generally, you will get better performance improvements by removing categories from a triangle than by hiding it. (That is, it is better to not have manipulators on your cockpit, so it isn’t mouse-click collision-checked, than to hide it.) But the purpose of ATTR_draw_disable and ANIM_hide are different enough that which you use will be determined by the effect you are trying to create.
Finally, note that hiding an object completely (that is, the object does no drawing) does not provide the maximum performance benefit of not having an object at all. ANIM_hide was created to allow authors to create clever effects, not as a performance enhancer!
* This is not quite accurate: airplane-object collision checks are only available in scenery objects, and camera/airplane or mouse/panel collision checks are only available in the cockpit object.
Tom has a new video on youtube of his just finished Falco. The video shows what screen-shots cannot: that the mouse interactions on the plane are really well crafted.
If you’re just discovering X-Plane (or just discovering that X-Plane’s 3-d cockpits can be very interactive), here’s X-Plane’s “raw” capabilities for manipulation:
- The simplest manipulations are based on mapping the mouse from the 3-d cockpit back to the 2-d panel. This can only be done when the 3-d cockpit is textured using a piece of 2-d panel. This is the oldest way to make a clickable cockpit in X-Plane, dating back to the original X-Plane 3-d cockpits. The advantage of this method is that it’s very easy to set up; the disadvantage is that the mouse click gestures tend to be “flat” in their operation.
- As Tom’s plane demonstrates, you can manipulate just about any dataref or command via a drag along a specific axis. Axes are subject to animation, so there’s a lot of potential for “grabbing” things with this interface.
- X-Plane also supports direct “click” manipulation – this can be handy for buttons where you don’t want to require the user to move the mouse around. There are several types of click manipulation.
Click and drag manipulations can be tied into the plugin system – your plugin sees a manipulation as a change to a plugin-created dataref. This makes it possible to create almost any imaginable mouse effect. If you don’t want to write a plugin, you can still write up the manipulators to any of X-Plane’s datarefs (there are thousands) or commands (we’re getting up toward the 1000 mark on these too).
To create manipulators on your cockpit, you can use the latest plugin for AC3D. A manipulator is a property on a mesh within your object – each mesh can have its own manipulation with its own properties.
X-Plane does not have an IK solver. Rather, movement of “stuff” in your cockpit is indirect.
- Your manipulator changes a dataref as the user drags along an axis.
- The dataref change shows as an animation on your mesh.
Fortunately, ac3d has a “Guess” button for the axis manipulators. If you set a mesh to be manipulated by dragging along an axis, the guess button will examine your animations and suggest an axis that will create the most “natural” looking animation for the manipulation. For example, if you have a throttle handle that rotates, the guess button will provide a drag axis perpendicular to the throttle (to push the levers); if you have a throttle lever that pushes, the guess button will make a drag axis that runs along the lever.
There is no need to use the 3-d panel if you only want 3-d cockpit.
That might be the most counter-intuitive statement in the entire universe. Let’s break it down and see what’s going on. Originally we had the 2-D panel. The 2-D panel was where you put your instruments for interior views. When 3-d cockpit support was added, the 2-D panel was used to create the panel texture – that is, the instruments texture for the 3-D cockpit.
Thiat worked for a while, but as handles became more complex, screens became larger, and as 3-D cockpits became a more complex, authors started to run into the system’s limitations. If the author wanted to create a huge panel, then the panel texture for the 3-D cockpit was huge. Furthermore, texture space for the instruments in the 3-D cockpit was wasted because the 2-D panel had to have windows on it.
With X-Plane and 9 we added the 3-D panel to fix these problems. The 3-D panel is a second panel whose sole purpose is to provide instruments as a texture for the 3-D cockpit. When you have a 2-D panel and a 3-D panel, the 2-D panel is used to draw the panel in 2-D viewing modes and 3-D panel is used only to create the panel texture for the 3-D cockpit. With this setup the 2-D panel can be huge, and the 3-D panel can be small and compact with no windows.
The 3-D panel solves a second problem as well. Often the overhead panel is drawn in perspective on the 2-D panel this perspective view is useless for texturing a true 3-D cockpit. With a 2-D panel and a 3-D panel, the author can draw the overhead in perspective for the 2-D panel, and orthographically for the 3-D panel.
Now here’s where things get complicated: if an airplane has no 3-D panel the 2-D panel is used for both the 2-D view and the 3-D cockpit. But some airplanes have only a 3-D cockpit. In this case, there is no reason to use the 3-D panel at all. You can simply use the 2-D panel for texturing the 3-D cockpit and not worry about the user seeing it; in a 3-D only plane the user will only see the panel as a texture for the 3-D cockpit.
This setup is confusing in name: how can you have a 2-D panel used for a 3-D cockpits? But it is an allowed configuration. In fact, it was the only configuration allowed in X-Plane 8.
In summary: a 3-D cockpit can use the 2-D panel or 3-D panel as its panel texture. If an airplane has no 2-D panel, then the 2-D panel can be used for the 3-D cockpits without problems. In this situation and there is no need for a 3-D panel.
(It might be better to think of the 2-D panel and three panels simply add his two panels so that you can have two different versions of the panel. The names to the panel and 3-D panel are really just labels.)
X-Plane doesn’t natively and directly support popup panels, but that doesn’t mean you can’t pop them up. Generic instruments have a dataref-driven set of show-hide fields. (The “filters”.)
Now what you might not have realized is: groups have filters too! So you can hide an entire group with one filter, and you can put premade instruments in the group.
So…even though the FMS is a premade instrument with no filter fields, by grouping it you can show and hide it.
Important: the backgrounds of instruments are not shown or hidden. So if you want to do this, customize the FMS to have a transparent background, and use a generic rotary to put a real background behind it. The rotary goes in the group, and thus it can show and hide.
One more tip: clicking in 2-d goes through one instrument to another, for historical reasons. So if you pop up an instrument, you might want to hide the instruments it popped up over so clicks don’t affect them.
