Do Not Work Around Our Bugs!

For most of its beta run, X-Plane 930 beta 14 didn't handle engine power limiting very well*. Here's the short version of the saga.

• Real planes sometimes have systems to limit total power output, because the power output of the engine (whether torque or internal temperature) can exceed safe operating limits at sea level).
  
• With X-Plane 9.00 you could set a critical altitude for an airplane - below this altitude, X-Plane would limit the power output of the jet. The idea is (roughly) to simulate these limiters by derating the engine's power output below this "critical altitude".
• This feature was really only meant for reciprocating engines - when Austin discovered in 9.20 that people were using this for turbines (understandable, given that there was no alternative) he simply disabled the feature for turbines. That wasn't so good.
• To resolve the situation a little bit more cleanly, X-Plane 9.30 has a setting per airplane called "FADEC - automatically keep engines from exceeding max allowable power or thrust" that, when checked, gives you version 9.00 style behavior.

Now this was mostly good except for one problem: the betas would default this setting to "off" when loading an old plane. Since version 9 always acted as if the "FADEC"** was on, this meant that old planes would need to be edited.

Finally with beta 14 we switched things: beta 14 and newer default old planes to have the FADEC checkbox on, so that planes match their old behavior - you can turn the check-box off if you don't want this behavior.

There is one final hitch: if you already went in and edited your airplanes for the earlier betas, you will find that they are now set wrong. You will have to reset the check-box. If you go back to the original, unedited, 920-compatible airplane you will find they "just work".

I mention all of this to make two points:

1. File formats for new features are subject to change during beta. In this case, the file format for the new FADEC check-box (introduced in 930) changed at beta 14. The OBJ syntax for dynamic lighting changed during beta too. Don't do "bulk" work (e.g. change a large number of planes in the same way ) on your fleet based on betas - you might have to redo that work again! Wait until the sim goes final. That's when the file formats are locked up.
2. Don't work around bugs in the sim. I have seen so many forum posts where there is a trivial bug in the sim (e.g. the sim is just screwed up in a simple way) and authors go in and update scenery to work around the bug. File a bug, then wait! If you work around the bug, we can't fix the bug, and if we don't fix the bug, then the bug just bites other users.

* Disclaimer: I don't do systems, I don't know anything about airplanes, so this whole discussion will be heavily simplified. The point of this post is not to get into a discussion of FADECS - in fact, don't even bother to post about FADECs, I'm not going to approve them. If you want to talk about FADECs and engine modeling, email Austin. The point of this post is one about file formats and compatibility.

** FADEC isn't a very good name for this feature - the feature generically limits power, without specifying a mechanism. My understanding is that some airplanes have mechanical limters, like a pressure valve on a turbo. Some planes have no limiters at all...ask a pilot "can you cook the engine by pushing the throttle too far" he will say "I'm not going to be the one to find out."

Optimization By Check-Boxes

In the next X-Plane 930 beta (it should post today I think) the rendering settings have two new check-boxes: one to enable the "dynamic" airplane shadow and one to enable per-pixel lighting.

In the last week a number of users emailed me performance numbers via the fps test, and from what I can tell, 99% of performance problems can be attributed to these two new features chewing up resources in a way that 922 did not. When the features are both disabled, from what I can tell, the sim should be as fast or faster than 922.

The new beta will also limits dynamic shadows to your aircraft - beta 13 will calculate a dynamic shadow for every aircraft, which is unacceptably slow when you have a lot of AI planes enabled.

I may still be able to improve the performance of the per-pixel-lighting shader, but fundamentally per-pixel lighting is going to be more expensive than per vertex. The average X-Plane scene might have 200,000 to 500,000 vertices. At absolute minimum resolution, no FSAA, you're going to have over 700,000 pixels even if there is no "over-draw" - you could easily have 10x that fill rate with only a modest increase in overdraw, full-screen anti-aliasing and window size. Simply put, per-pixel lighting is more work.

Please bear in mind: without per-pixel lighting X-Plane's pixel shader is extremely simple. If you have a "low-end" card this could give you the illusion of GPU power when there is really not much under the hood.

Examples of low-end cards: GeForce 7300, GeForce 8400, GeForce 9400, Radeon X300, Radeon X1300, Radeon HD2400. All of these cards are the younger brother of a fairly capable card, but with fewer pixel shader units/cores. If each unit is doing very little work, you don't need that much pixel-filling power...but when we go to a "real" shader, the difference between a GeForce 8400 and 8800 becomes very, very apparent. Simply put, even with optimization the GeForce 7300 (for example) will never run a huge monitor with per pixel lighting and high FSAA.

To Copy Or To Reference

In designing interfaces for building planes, writing plugins, etc. one of the main design questions that keeps coming up is: to copy or to reference? Should authors simply refer to an art asset, piece of data, or code in order to utilize it, or should the author copy a snapshot into the custom add-on. There isn't one right answer. Here are the main considerations.

Performance and Efficiency

One of the obvious considerations is efficiency: in some cases we might be able to provide better performance when an art asset is referred from a common source.

For example, in some cases X-Plane will consolidate VRAM use based on actual files, so a library object is loaded once no matter how many packages use it, but is loaded many times if a package copies it.

(In other cases X-Plane will actually merge multiple copies of a resource - referencing is only a win in some cases.)

An indirect consideration: if an art asset is provided by Laminar Research and is used by reference, then a new update can provide a new, better optimized art asset - see below.

Dependencies and Contracts

When someone uses an art asset, algorithm, etc. by reference, it creates an implicit contract by the provider of the asset by reference to not change the properties of the asset. By comparison, when the asset is copied, the contract is only to support the format that the asset is encoded in.

This is the main reason why I am often against providing new assets by reference, whether it is a new dataref, texture, etc. Often I will simply send a user a snippet of code, rather than making X-Plane's version available via a dataref. The idea is that copying does not create a new interface (and thus a new "contract") between X-Plane and the add-on.

Copyright and Legal Issues

For historical reasons, the US legal system describes the privileges of intellectual property owners by regulating the act of copying. (To say that this is a bit quaint in the digital age doesn't even scratch the surface, but that's a rant for another post.) The result of this particular regulation of copying (but not of referencing) is that the decision to provide an asset by copy vs. reference has legal implications. If the author does not want to go through licensing, referencing may be the only option.

The Constraints of Hardware

In a previous post (in which I tried to argue that threading is a "how" and not a "what" when it comes to feature requests) a user made this comment:

That is, that I feel you are a bit too concerned about the fact that XP has to be possible to run on a 2001 year machine. This really halts the development although you could add options to turn this and that off.

I'd like to side-step around the details of cost-benefit analysis (e.g. do the sales from low-end systems pay for the development of a renderer with lower system requirements) but take a second to focus on three general issues:

• Is there a cost to developing a scalable renderer?
• How does the trend of hardware development affect hardware?
• How do marketing forces affect both of the above?

Scalability

Is there a cost to writing a renderer that can run on a wide range of hardware? Absolutely. Obviously we have to write more code to do that.

But there is an additional cost: there are some rendering engine design decisions that have to be made system-wide. It's not practical to provide different scenery files for different hardware (since we are limited by distribution on DVD). In some cases we have to pick a non-ideal data layout (for the highest end hardware) to support everyone.

But: before you raise up arms against your fellow X-Plane user who is holding you down with his GeForce 2 MX and P-III 800 mhz machine, bear in mind that the problem of picking a data format is a bit unavoidable. Even if we targeted the highest-end machines and told everyone else to jump in a lake, those decisions would appear to target rather quaint machines only a year into the version run. At some point we have to pick a line in the sand.

There is some light at the end of the tunnel when it comes to scalability: as computers become (on average) bigger and faster, we can start to defer at least a little bit of the work of scenery generation to while the sim is running. When we first designed the new sceney system (for X-Plane 8) most users did not have dual-core machines, so the doing work on the scenery was very expensive. We preprocessed as much as possible. This isn't as necessary any more.

So are high-end users limited by having one renderer that fits all sizes? Perhaps a little bit, but any design choice is only going to fit one hardware profile perfectly, and hardware is a moving target; today's shiny new toy is tomorrow's junk.

Hardware Growth

Every two years (to be very loose about things) the number of transistors we can pack on a chip doubles. This "transistor dividend" can be turned into more cores for a CPU, or more shading units (which are now really just cores) for a GPU.

And this gets to the heart of why I don't think we can say "forge the low-end" any time soon. Imagine that we support 6 years of hardware with X-Plane, and the best hardware is 8 times as powerful as the low-end hardware. Fast-forward two years - we drop two-years of hardware and two-years of new ATI and NV graphics cards come out. What is the result?

Well, the newest hardware is still 8x as powerful as the old hardware, but the difference in the polygon budget between the two has now doubled! In other words, the gap in absolute performance is doubling every two years, driving the two ends of our hardware spectrum farther apart. (Absolute performance is what Sergio and I have to worry about when we design a new feature. How many triangles can we use is an absolute measurement.)

If we say "okay forget it, only 3 years of supported hardware" that gets us out of jail for a little while, but eventually even the difference between the newest and slightly off-the-run hardware will be very large.

A gap in hardware capability is inevitable and it will only get worse!

Market Divergence

You may have noticed that the above paragraph makes a really gross assumption: that the lowest end hardware we support is the very best card on the market from a certain number of years ago. Of course this isn't true at all. The lowest end hardware we support was probably pretty lame even when it was first made. The GeForce FX 5200 was never, even for a microsecond, a good graphics card. (It was, however, quite cheap even when first released.)

So the gap we really have is between the oldest low-end and newest high-end hardware, which is really quite wide. Consider that in May 2007 the GeForce 8800 Ultra was capable of 576 GFLOPs. Two months later (July 2007) the GeForce 8300 GS was released, packing a whopping 22 GFLOPs. In other words, in one video card generation the gap between the best and worst new card NVidia was putting out was 26x! (I realize GFLOPs isn't a great metric for graphics card performance - really no one metric is adequate, but this example is to illustrate a point.)

Let's go back in time a few years. In February 2002, NVidia released the GeForce 4 Ti (high-end) and MX (low-end. The slowest MX could fill 1000 MT/s, while the fastest Ti could fill 2400 MT/s. That's a difference in fil rate of "only" 2.4x.

What's going on here? Commodification! Simply put, graphics cards have reached the point where a lot of people just don't care. Very few users need the full power of a GeForce 8800, so a lot of lower-end machines are sold with low-end technology - more than adequate for checking email and watching web videos. This creates a market for low-end parts and creates a wider "gap" for X-Plane. Dedicated returning X-Plane users might do the research and buy the fastest video card, but plenty of new users already have the computer, and it might have something unfortunately (like a Radeon X300 or Intel GMA950) already on the motherboard.

As X-Plane's hardware needs diverge from the needs of mainstream computer users, we can expect some but not all of our users to have the latest and greatest. We can also expect plenty of new users to have underpowered machines.

Let me go out on a limb (I am not a technologist or even a hardware guy, so this opinion isn't worth the bits it is printed on) and suggest this: we're going to see a commodification fall-off in the number of cores everyone has too. Everyone is going to have two cores because it is cheap to put a second core on the main CPU if it lets you get rid of a whole array of special-purpose hardware. Give me multi-core and maybe I can get away with software-driven rendering (who needs hardware acceleration), software-driven sound (goodbye DSP chips), maybe I can even find cheaper ways to build my I/O. But 16 cores? The average user doesn't need 16 cores to check email and run Windows 7.

So as transistors continue to shrink and it becomes possible to pack 8 or 16 cores on a die, I expect some people to have this and others not to. We'll end up in the same situation as the graphics chips.

Summing It Up

To sum it up, sure there may be some drag on X-Plane in supporting a wider range of hardware. But it's an inevitable requirement, because hardware shifts in capability even during a single version run, and as hardware becomes faster, the gap between -end and cheap systems gets wider.

Glass vs. Glass (Translucent)

In Plane-Maker you will see that there are two "glass" lighting modes for instruments - one called "glass" and the other called "glass (translucent)".

What's the difference?  The difference is how they respond to their lighting rheostat being turned down.

• Glass becomes dim by mixing the RGB colors of the overlays toward black.
• Glass (tranlsucent) becomes dim by mixing the alpha channel of the overlays toward transparent.

Which one do you want?  It depends on what you are doing.  The rules I suggest are:

• Use "glass" if you are using the layer as a "mask" to block elements behind it.
• Use "glass (translucent) if you are using the layer as an "overlay" to draw on top of other elements.

A Few More Manipulators

I'm not sure if these will make it into X-Plane 9.30 (we're trying to close down features, but it doesn't do much good to hold off features that help people make airplanes) but...while I was in Italy I created a few more manipulator types.

The set of manipulators let you change the value of a dataref directly with a mouse-click - the various flavors control how the dataref is changed.

These manipulators are the natural corollary to the command manipulator, which runs a command on a click.

Why have both? Commands are good, but they don't cover 100% of sim functionality (just like datarefs don't cover 100% of sim functionality).  By having both, it will be possible to control switches and buttons that are best accessed by a dataref change.

For the basics on commands vs. datarefs, see here.

The generic instruments already write to both commands (via the trigger instrument) and datarefs (via the rotary instrument) - these new manipulators provide the same functionality for 3-d cockpits.

Multi-Threading Is a Weird Feature Request

Over and over, whether it is a feature request list for X-Plane or another simulator, I see the same thing: "multi-core support" or "multi-threading" as a feature request.

Now before I continue, I must remind everyone: X-Plane is already multi-threaded and will take advantage of multi-core hardware. How much we use those cores depends on the type of scenery loaded.

The problem is that multi-threading (as a way to use multi-core hardware) is a solution technique, not a problem statement.  What is threading going to be used for?  If I simply program the other 7 cores of your computer to calculate PI to 223,924 digits have I met the feature request?  This probably isn't what anyone wants.

Implicit in the request for multi-core is (I speculate) a request for better frame-rate.  (I did see one user who wanted multi-core to be used for a more accurate flight model.  This strikes me as a poor trade-off for hardware based on my understanding of the flightmodel - we would use a lot of hardware for only a marginal accuracy improvement - but I commend the user for stating the problem and not just a possible solution.) But is multi-threading the best way to get framerate?

If I had two patches to X-Plane, one that doubled fps by using two cores and one that doubled fps by using more efficient code, which would be better?  To me the obvious answer is: the code that is more efficient.  It will run on any hardware (not just multi-core) and if you have multi-core hardware, we still have that second core free for some other functionality.

So to me the feature request should be something like: "higher framerate - and yes I have multi-core hardware".  Or perhaps "more visual detail at the same framerate - and yes I have multi-core hardware".

All feature requests need to be in terms of problem statements, not possible solutions.  This lets us find the set of problems that can be solved together in a coherent manner, and it lets us pick a solution that meets our engineering goals.

Masks for Glass Instruments

X-Plane's panel system does not have true "masking" based on a bitmap.  You can clip an instrument to its rectangular region, but most masks are made by overlaying another layer or instrument on top of the moving parts.  Examples include the circular mask for the moving map and the outside of the artificial horizon dial.

If you are using ATTR_cockpit then what you see in the OBJ is just like what you see in the 2-d panel, and the masking problem is simple: pick a mask that matches your background.  In particular, if the back of the panel is black, your mask must be black; if the back of your panel has a gradient, the mask must contain a copy of a slice of the gradient.

But there are two cases where this rule does not work the way you might expect.

Masks for 2-d Spotlights

The 2-d spotlight textures (panel-2, panel-3, etc.) have a strange property: they light the background of the panel (the "burned in layer") per-pixel but the overlays are lit per vertex. This is a cheat to keep the frame-rate high.

Normally this is not a problem - the moving parts are small and look different enough from the background that the lighting mismatch is not visible.  But if you have a mask in the 2-d panel and spot lights, it will not match!

Unfortunately there is not much you can do about this.  The only thing you can do is to keep the spotlight color uniform over the entire mask region.

Masks for Cockpit Regions

When you use ATTR_cockpit_region, the lighting model for your 3-d cockpit changes: instead of drawing the panel (as you saw it in 2-d), X-Plane calculates the albedo (day-time) and emissive ("_LIT") components of the panel separately and then combines them with real 3-d lighting.

The good news is that the spot light problem is no longer a problem.  Since the spot lights are 3-d and are applied to these final "panel textures", a mask that matches the background will blend perfectly.

But in order to mask, you need to know which part of the panel texture you are masking (albedo or emissive!).  If you are masking the albedo texture (e.g. a mechanical artificial horizon), create a mask that looks just like the panel background.

But for a glass instrument, the moving parts go into the emissive layer.  Your mask must be pure black!  Where did I get that from?  The emissive layer adds light to the object.  Black is an absence of adding light.  So pure black 'erases' any light-only elements (which include all glass EFIS instruments, etc.).

One nice thing about this strategy: you can build a custom glass instrument (with a black mask) and put it over any background. This means you can reuse your art assets no matter how they are positioned on the panel.

I'm Back

After almost three weeks in Europe, I am now back home!

First, I would like to thank the entire team that put together the French X-Plane Congress - it was a wonderful event - you guys did an amazing job!  It was great to see so many X-Plane people in one place (including the elusive Marginal!). The French X-Plane community is a strong group and it shows.

I would also like to thank Cris for setting up an informal Italian X-Plane get-together (complete with the Zurich delegation :-) for our last night.  We didn't get much sleep, but it was great to see so many people again before we flew back home.

At this point my in-box looks like someone dropped a bomb on it...it'll take a while to dig everything out.  The first priority of business is X-Plane 930 - we'll do a series of betas over the next week or two that will hopefully put the release to bed. Once 930 is done, I can probably beta WED 1.1 and get back to work on scenery.