My family visited DC this weekend and we went out to Udvar-Hazy, the extension of the Smithsonian aerospace museum out near Dulles international airport. My dad took this picture.
That is one of the two radar antennas (and the telescoping arm) used to scan the earth as part of the Shuttle Radar Topography Mission (SRTM). The SRTM is basically the first really good quality most-of-the-earth elevation dataset, and it is the main (but not only) source of elevation data for the X-Plane global scenery.
The telescoping mast shown in the picture (horizontal) extends one of the two radar antennas away from the shuttle when in orbit; had they not been able to retract the antenna they would have had to detach it and leave it in space. Fortunately the mechanism worked properly, so they were able to bring the antenna back for posterity.
Microsoft extended Windows XP sales yet again, more or less. But rather than rant about how the Vista user experience makes me want to tear my fingernails off or how brain-damaged it is to try to put DRM into drivers, let me instead focus on Windows as an example of the cost of contracts.
I have
ranted in the past about how the boundary between X-Plane and a third party, or the plugin system and third parties, or even two third parties, is a contract. Consider:
- The named light list forms a contract between X-Plane and objects, e.g. X-Plane guarantees that there will be a named light called “airplane_landing” and that it is a good choice for landing lights. (This implies that X-Plane won’t change what it looks like to be inappropriate for landing lights, and that third parties won’t use it for inappropriate uses, like airport apron lights.)
- XPLMGetDataf forms a contract between the plugin SDK and plugins, guaranteeing that there will be a function in the XPLM called “XPLMGetDataf” that takes a dataref and returns its value. (This implies that Sandy and I won’t rename it or change its arguments or remove it all together, and that plugins won’t pass non-datarefs in as arguments.)
- Even a paint kit forms a contract – the airplane maker is essentially saying “the tail will be mapped to the upper left of the texture, and I won’t remap my UV” and the livery maker is saying “I will put an image in the upper left corner that looks like a tail.”
By comparison, the clouds are not a contract – there is no way third parties can customize the look of the clouds, so we can change the algorithm by which we create them pretty much at will. We could switch to a volumetric approach for all clouds or even go back to 2-d without worrying about third party interaction.
Okay – that’s a lot of words about contracts…what does that have to do with Vista? Well…
The Cost of Changing the Contract
Two major aspects of why Vista has been a worse experience for users than Windows XP come directly to the need for Microsoft to change contracts.
- For years, applications have run on Windows with admin rights. This is not good – it means that any process can do serious damage to the system if hijacked – and on Windows processes get hijacked on a fairly regular basis!
- For years, audio and video drivers have run pretty much unprotected. This was good from a performance perspective, but also caused a lot of BSODs. On Windows, drivers are third party components and are quite possibly not checked by Microsoft (especially video drivers) so letting them run without protections is risky.
In both cases, the problem is that the old contract is both (1) poorly designed* and (2) being used by a lot of third parties. What choice did Microsoft have? Continue to let apps run in admin mode and hijack the whole machine any time the user picked up a virus? Or change apps to run in user mode and hope that the applications didn’t depend on this guarantee?
(At this point,
Raymond might go ballistic and point out that the Windows API doesn’t really promise admin rights and apps should not have been doing all of these naughty behaviors in the first place. I don’t know what the Win32 API declares…the difference between what a platform declares and what it does is important enough to warrant another post. Certainly with X-Plane we have to worry a lot about third parties depending on behavior that was unintentional but turned out to be useful.)
Vista has been a difficult transition because it changed a bunch of rules (that needed to be changed). In the long term, I am sure that both of these decisions are for the better — eventually applications won’t be counting on administrator rights, so we won’t have to fume about UAC (or shut it off), and a hijacked web browser won’t be nearly as dangerous.
On the video driver front, the Vista experience is pretty reasonable now – there has been a lot of improvement since Vista first came out. I expect applications and UAC to take a lot longer – video drivers get revised quite frequently; applications seem to linger around forever.
I’m Not Signing That
If we end up with a situation like this in X-Plane (the contract is used heavily by third parties and not well designed) we only have two options, and they’re both bad:
- Break the contract. Third party content stops working, users are angry, authors are angry.
- Stick with the contract and mitigate as best we can. Usually this means writing more code (slows down new features), using a less optimal implementation (lowers frame rate), etc.
This is why my first reaction to any file format extension is: “is this going to be a PITA in a year”? The benefit might be visible now, but the cost could plague us indefinitely.
What You Want, Not Where You Want It
If you would like to request a feature, tell me what you want, not where you want it implemented. I bring this up because many of the feature requests I get are very specific and describe an implementation, not a goal. (To draw an analogy, it’s as if I call a general contractor and say “dig a big hole right here” without telling him “it is for a swimming pool”.)
The reason “what not how” is so important is because many of the “how” implementations that people send me involve creating new contracts with third parties. I am going to try to design the feature with the minimum contractual obligations – that is, to do just what is intended and hopefully not much more.
But if I can’t tell what you are trying to do, I can only say “I won’t code this implementation – the cost of long term support due to contractual obligations outweighs the usefulness.” It might be that there is another way to implement the feature that would not put a long term burden on the scenery system or airplane SDK and still provide all of the benefits.
* Poorly designed? Or perhaps well designed for a previous problem – if the problem changes, the design might not be appropriate. Or perhaps not even designed at all – sometimes contracts evolve without a lot of central planning. All of these things have happened in X-Plane. In the case of Windows, I suspect it’s the previous-problem case — that is, what made sense for much smaller computers where the scope of what could be done was quite limited no longer makes sense for big modern computers that are capable of a more expensive and robust solution…just my speculation.
Thanks to those who replied to my previous post…and my decision is: to wiki. It’s relatively easy to make the Wiki look as good (and I use the term good loosely) as the non-Wiki scenery website. By comparison, it would be very complex to make the scenery web-site interactive and faster to update. (And update ease is very important – one of the reasons why there is so little documentation on the scenery website is that it is so hard to document.)
So…as a beginning, I have reskinned the wiki. (If you want the old look, create an account and pick the old skin, called “monobook” in your preferences.) If you don’t like the new look, you can send me a new style sheet or even an existing MediaWiki 1.9-compatible skin…I can install it and can select it in your preferences.
I have also installed some extensions that should help add additional flexibility (for example, the Wiki can now have image-based links). Over the next few days I will try to clean up the front page a bit to provide a clearer navigation structure.
One thing we will need on the Wiki is…
WikiGnomes – that is, users who help to organize and polish the content for readability.
In the long term, I would like to migrate scenery.x-plane.com to the Wiki. But for now that is lower priority than creating new documentation.
Posted in News
by
Ben Supnik |
If you run X-Plane 9.21 (or 9.22) on a Macintosh with an old ATI or nVidia graphics card (with no pixel shaders), you somehow squeeze 25 fps out of X-Plane*, and you can try a test build, please email me.
Those cards include:
- Radeon 7000-9200, inclusive.
- GeForce 2, 3, or 4 series.
I have a change in the panel code that I need to performance test against older hardware!
* Basically you would have to really crank the settings down – but I think under some really baseline settings these machines might be able to run X-Plane 9 without fogging.
Posted in News
by
Ben Supnik |
You might not believe this (due to the general lack of scenery system documentation) but I do spend some brain power thinking about X-Plane documentation for third parties!
Consider two approaches to documentation:
My question is: which of these approaches is more “readable” or “clear” to you as a third party? Each one (the formal website vs. the Wiki) has pros and cons, but I can’t judge “usability” of the documentation myself. Is it easier to find things on the website? On the Wiki? Comments welcome!
(I need to decide where to put future documentation, hence the question “which works better for those who read the documentation.)
Besides X-Plane for iPhone (which I now call “X-Plane general aviation” to avoid confusion) there are now two new apps: X-Plane Airliner and X-Plane Helicopter. The helicopter version uses part of the Grand Canyon and the airliner version uses part of Southern California.
All three apps (the general aviation version has a free update) have a fix in the DSF lower that should help avoid crashes.
Basically while X-Plane used to run under memory limits for the phone, it would temporarily go quite a bit over memory the limit during the DSF load, as the DSF loader would use some temporary memory. The new code very carefully purges temporary memory as it runs, and thus never exceeds its final memory footprint. Before 9.04 there was always a risk that your phone was in a tight memory situation to begin with, such that X-Plane going “over budget” would cause the OS to kill it off. (Rebooting the phone apparently purges memory or something.)
So…this is a long-winded way of saying: if you update X-Plane iPhone to 9.04 and still have the app quit at launch (or right after launch), please send us a crash report!
It looks to me like we could afford a few landing light halos on most (but not all) hardware. This gets a bit tricky in terms of how we make this available to authors…
- We have to allow access without breaking old planes.
- There will be two distinct cases due to very different hardware.
So…I have posted an RFC on the X-Plane Wiki. Please post your thoughts on the discussion page!
One option (not really discussed in the RFC) is to do nothing at all. Basically I hit upon this during some routine refactoring of the shaders. The whole issue can be deferred indefinitely.
Why wait? Well, I don’t believe that an incremental increase in the number of landing light halos is the future. Our end goal must be some kind of truly global illumination, hopefully without a fixed lighting budget. It may not make sense to add a bunch of complexity to the aircraft SDK only to have all of those limit become unnecessary cruft a short time later.
(I think I can hear the airport designers typing “why do the airplane designers get four lights and we get none? Give us a light or two!” My answer is: because of the fixed budget problem. We can allocate a fixed budget of lights to the user’s aircraft because it is first in line – we know we either have the lights or we don’t. As soon as we start putting global lights in the scenery, we have to deal with the case where we run out of global lights. For scenery I definitely want to wait on a scheme that isn’t insanely resource limited!)
Programmers: yes – Dx10 hardware can do a hell of a lot more than 4 global lights. Heck – it can do a hell of a lot period! For example, it can do deferred rendering, or light pre-rendering. A true global lighting solution might not have anything to do with “let’s add more global lights a few at a time.”
Every time I work on a new X-Plane feature, I do a combination of:
- Reorganizing and cleaning up old code.
- Adding new features.
- Tuning performance for this new environment.
My experience has been that the investment in cleaning up old code is more than paid for by faster, easier development of new code – it’s easier to code in a “clean” work area.
As part of my work on 930 I am refactoring and optimizing how we set up pixel shaders. I’m not sure if there will be any framerate benefits in the short term, but in the long term there is definitely an advantage to being able to set up the most optimal shader configuration for any situation.
(Since most of what we draw – OBJs, airplanes, DSFs) can be created by users, we never really know what we’ll be drawing…the set of art content X-Plane can handle is almost unlimited. So it is up to shader optimization code to “find” the optimal setup for a particular stew of OBJ attributes, textures, etc.)
The short term fall-out during beta is unfortunately a certain amount of pain. It’s likely that these changes will introduce graphic quirks with certain combinations of planes. These are fixable! The important thing is: if you hit a graphics bug with a particular plane or scenery pack in 930 (whenever we get to beta – we are not in beta yet!) and that bug is not in 921 – report it! It may be that the optimizer is being too aggressive with a particular combination of settings and turning off some critical feature.
I will run the new shader optimizer code through just about every scenery pack and airplane I can find, but invariably there is some magic trick in a third party plane on the .org that I won’t have.
One thought for creating fast content: alpha is expensive! Or rather, let me rephrase that to: if you are not using the alpha channel of your texture, you should not have an alpha channel in your texture.
(For PNG this means stripping the alpha channel off, rather than having a solid 100% opaque alpha channel. For DDS this means using DXT1 with no transparent pixels.)
The new shader optimizer detects the case where alpha is not being used and sets up a more optimal code path. (The old shader optimizer did that too, but only some of the time – in the new code, we will always take this optimization.)
Having alpha blending enabled can inhibit “early-Z” optimizations on modern GPUs, and also require a more expensive blending operation in the framebuffer.* So if your model doesn’t use alpha, strip the channel.
* Some newer graphics cards recognize 100% opaque alpha and provide fast write to the framebuffer. But even if early-Z-type optimizations become alpha friendly, there will still be optimizations we can make in the sim if we hit the no-alpha case.
I want to revisit the question of whether (and how) the livery system should be extended. In particular, it is my opinion that the livery system should not be extended to allow:
- Replacement of OBJs used for modeling the airplane or cockpit.
- Alternate or modified ACFs*.
- Generally, the livery system shouldn’t be used for changing the plane’s behavior – it’s just paint!
I have commented previously in three parts that the livery system is meant to make easy the integration of third party paint without (a) violating copyright, (b) requiring byzantine installation instructions or (c) requiring the painter and original author to coordinate. I have received requests from a number of very talented airplane authors, asking for the livery system to cover a whole range of new features, most of them involving configuration. I will try to explain in this post how I think should should be handled.
First, to be clear: an aircraft file is the .acf file that contains the X-Plane specific data needed to simulate the plane; the aircraft package is the folder containing that .acf file. A livery is a painting scheme for the 3-d model of the airplane, and a configuration is an instance of a plane with certain features, e.g. with or without G1000, with P&W; vs. Rolls Royce engines, etc.
Configurations of an aircraft should be created by putting more than one aircraft file
(.acf) in a single aircraft package. Because the graphic and sound resources needed for the aircraft are accessed relative to the .acf file, you can build a family of aircraft with some common aspects and some unique aspects to each plane.
Files used by an aircraft fall into three broad categories:
- Files found by a fixed formula using the .acf name, e.g. be20_paint.png. Let’s call these “file-specific”.
- Files found by a fixed formula without using the .acf name, e.g. the contents of the aircraft plugins folder. Let’s call these “package specific”.
- Files that are explicitly named in the .acf file, like airfoils and OBJs. Let’s call these “flexible” (since this naming scheme could be used in any way).
Here’s how the important files in an aircraft break down:
- The aircraft paint scheme is file specific.
- The aircraft panel background is package specific (but you can effectively have each file use a different panel background by setting the panel type differently for each plane).
- Sounds are actually either, which effectively makes them flexible. Non-generic instruments are package-specific.
- Objects, generic instruments and airfoils are flexible.
In other words, if you can live with duplicating your aircraft paint files (and I suspect that in most cases either the plane is built by objects, or the modifications in each configuration warrant paint changes anyway), then every other feature can be set to package or file specific, allowing you to build a group of aircraft around a single real-world plane.
Now if there are aspects of a multi-configuration aircraft package that don’t work right now, we can look at possible changes to the sim to make this work. But it appears to me that just about everything necessary to make multiple configurations is already available in the sim now.
As a final note, the question here (livery vs. multi-file aircraft pack for configurations) is one of file formats, and thus of data organization and contracts between authors and programmers. It is not a question of user interface. The user interface can be reshaped to make multi-aircraft packages look like liveries, or liveries look like multi-aircraft packages. But I suspect that most of the interest in extended liveries is on the file-format side.
* The one exception for liveries is the tail number — given the strange state where the tail number, as painted into the livery, is also written into the ACF, it wouldn’t be bad to be able to override this property. Some people are already doing this using plugins.
Some coding problems are stubborn – I find myself looking back at a week of working realizing that all I really did was prove that a bunch of theoretical improvements don’t work in practice.
Improving OBJ throughput is one of those problems. On a high-end machine, even drastic changes to the OBJ engine make only the slightest difference in throughput – 2 or 3% at best. Every improvement counts, but a 3% improvement doesn’t change the game for how we draw scenery.
There is at least one route I haven’t had time to go down yet: object instancing. The theory is that by making many objects appear with only one object drawn, we get a multiplier, e.g. a 2x or 4x or larger amplification of the number of objects we can have.
In practice it won’t be that simple:
- To get such an amplification we have to recognize groups of the exact same object. Grouped objects will have to be culled together. So we might get a hit in performance as we draw more objects that are off-screen, just to use instancing.
- It may be that the grouping requirement is so severe that it is not practical to find and group objects arbitrarily (instead we would have to group objects that are built together, like clusters of runway lights). That might limit the scope of where we can instance.
- The objects have to look more or less the same, so some categories of very complex objects won’t be subject to instancing. (E.g. objects with animation where each object might look different.)
- I have already coded some experiments with geometry shaders, and the results are just dreadful – geometry shaders simply don’t output a huge number of vertices efficiently, so they don’t help us increase our total vertex throughput. The experience has left me with a “prove it” attitude toward GL extensions that are supposed to make things faster.
When will we know whether instancing can help? I don’t know — I suspect that I won’t be able to find time for code experiments for a bit, due to other work, particularly on scenery creation and tools.
