Algo-Gen

I may be fighting a pointless and unwinnable linguistic battle, but I have to try. People very often refer to the default city buildings in X-Plane as "auto-gen" but by any reasonable definition of "auto-gen" they are not really auto-gen at all.

Now these are all made up computer terms, so we can't really check the dictionary. But "autogen" scenery (short for automatically generated) usually refers to scenery that is created by a flight simulator itself, usually while you fly, and usually by placing 3-d detail in places that match the base terrain. This exists in FSX, and existed in X-Plane up to version 7.63.

X-Plane 8 doesn't have autogen!!!!!!! X-Plane 8 has scenery that is generated by computer programs, but X-Plane is not the computer program that is doing it. When you see a ton of buildings piled up in New York City, that is not becaues X-Plane looked at the New York city base terrain and said "hrm - some buildings would be nice."

What actually happens is we analyze New York City when we create the global scenery (before we ever burn the DVD masters) and the DSF generator places all of those buildings in New York City. X-Plane simply gets a huge list of buildings from the DSF and draws them.

I am going to try to coin the term "algogen" (algorithmically generated) to describe these buildings that (like autogen) come from a computer generating semi-random buildings from input data, but unlike autogen, algogen is a process that runs once before the scenery is made.

So how is algogen and autogen different?

• You can't change the pattern of algogen building placement by editing files in the sim. The algorithm has already been run! You can replace the buildings using an overlay (that excludes the base) or by using a library of models to substitute models.
• We are trading data size for computation. The DSF is bigger because it lists the location of every building in New York, even if they were just algogen buildings, but the job of placing those buildings is less difficult because X-Plane does not have to check each building against each road. That has been done in advance.
• Changing the scenery via an overlay doesn't change the algogen! Add an airport via an add-on and you have to exclude the buildings. (But if you send that airport to Robin, the next global render will include it and the algogen will skip the airport automatically.)

Note one of the interesting results of algo-gen: X-Plane can't tell the difference between an alg-gen building and a hand-placed one! They're all just objects in a DSF. The fact that algo-gen buildings disappear with lower settings is because the sim/require_object property in the DSF header tells the sim which objects are important, and our generator always signals the buildings based on obstacle data as important. But algogen as a process is not visible to X-Plane!

And that's why I'm spending so many words on trying to distinguish between "algogen" and "autogen" - because the processes are fundamentally different, they're very different for scenery authors to work with. As a result, authors coming from X-Plane 7 or FSX will be very surprised if they try to understand X-Plane in terms of autogen....they won't be able to find the autogen config files, and the autogen buildings won't react to other scenery changes, because they're not actually autogen at all!

Algogen is a classic pattern of "precompute" vs. "compute-while-fly". Generally precomputing gives authors more flexibility (in our case, we have an obj engine that can handle a lot of objects, so authors can make their own objects of the same density as algo-gen with the objects placed anywhere) at the expense of making it more complex to edit the existing scenery (edit the mesh and the algogen doesn't change).

When we started the v8 scenery, two things pushed me toward precomputation:

• In the past, changes in X-Plane's rendering engine had broken third party add-ons. So a precomputation strategy (by getting the scenery code out of the sim) means that the sim is doing less "interpretation" and thus the interpretation of scenery is less likely to change.
• We wanted to focus on performance, which means getting computation out of the sim whenever we could.

Now that last point isn't quite as important as it used to be...when we were doing the design (during mid X-Plane 7), dual core for everyone wasn't on the radar, so the penalty for complex computation while flying is lower (and thus we have more expensive in-flight computation, like forests and completely draped bezier curve-based polygonal pavement).

But I think precomputation is still useful. Even with dual core, the algorithm that places X-Plane's algo-gen bulidings can take one to two minutes for a 1x1 DSF tile on a very fast computer. That's still a load time that's out of the question for us; even on the second core, the DSF wouldn't be "ready" in time for you to fly it. So one use of precomputation is to run algorithms that are more expensive than you can have in real-time. (That algorithm to pack objects inside an irregularly shaped polygon made by roads and land features is not fast.)

More importantly, precomputing does give us a nice advantage in the use of storage data. We ship about 50-60 GB of final scenery, but the source data is well over 100 GB. When we run the algogen algorithm, we have access to the full set of source data: coastlines, elevation, and land use before any simplification is done and any data is thrown out. So we have the potential not only to do a more complex analysis, but to do the analysis on a larger data set.

The down-side of precomputing is that if integration of all data is saved until sim time, there is the potential for third parties to contribute separate data to the sim via add-ons and still have the integration of those data sets work well. This doesn't always work out - see complaints in online magazine reviews about combining orthophotos and new road grids in FS2K4...they don't integrate because neither of those types of resources can be integrated to match the other in real time. But autogen still does a much better job than algogen at this; algogen basically has to be recut when other data changes. (And that is our intention - if you change the road grid, exclude and replace the objects too!)

Performance Wrap-up (for now)

The story on X-Plane performance is never over, but the chapter that is 9.00 pretty much is. I think we'll be RC in the next build (if all goes well). Certainly a lot of the things that are still performance "problems" will require changes larger than we can do in a late beta.

I say problems in quotes because a lot of what's been reported lately is in the form of: a huge screen res + a lot of shaders + a lot of FSAA = slow fps. That's not really a bug, that's an engine limitation. Now I want to make the engine as fast as possible, and a lot of this pixel shader stuff is new to 9.0, so if our track record for tuning stays the way it was for v8, we'll probably get some efficiency improvements later.

But unfortunately there's an underlying limitation: the new water and fog both cause the rendering engine to consume significantly more hardware resources than it would otherwise. Turn them on and you get prettier pictures at a price.

Just to post a a few general things I've found:

• X-Plane 9 will tell you where your GPU really stands. GPUs that were very adequate for X-Plane 8 (like the GeForce 6600 GT) will turn out to have nothing left in reserve for v9, while GPUs that were bored in v8 (the GeForce 8800 GTX for example) will show what it really has.
• Generally the cost of going from no shaders to shaders with water reflections of "none" and no volumetric fog should be very low if your screen res and FSAA don't add up to something crazy (like 16x FSAA at 2048x2048).
• If you do have serious performance hits, try --no_fbos in the command-line; some drivers seem to have trouble with them.
• The P180's virtual cockpit is a lot more expensive than the other ones, because it has a huge panel that is used in 3-d. We'll hopefully rebuild the cockpit at some point.
• Turning water reflections to "complete" is very expensive. Watch the water and use the lowest setting that looks good. You don't need complete reflections if there are a lot of waves!
• Shaders, FSAA, and screen size are all pulling from the same set of resources - be careful about cranking up all three.
• Check your v-sync - a lot of users whose vsync clamped them at 60 fps in v8 will be clamped at 20 in v9.
• Do your testing with texture res set low, then crank texture res later; pixel shaders also require the allocation of VRAM that can't be purged (for things like reflection images) so running out of VRAM can show up in some weird ways performance-wise.
• The new Intel iMacs have serious performance problems with shaders on. This is due to driver limitations; given the much better performance under BootCamp, I expect the Mac performance to get better when the drivers are updated. For now I'd keep shaders off.

For now, please hold off on sending me performance reports. I just don't have time to address them. In the future I will try to solicit very specific performance data points that we need to check. Perhaps in the future we can also set up a database of fps-test results to have a more comprehensive idea of how the hardware does its job.

I expect future features to appear in v9 that further eat hardware; those features will have an off switch. You may have to pick and choose what graphics you enable; there is no free lunch here. I also expect new graphics cards to emerge that make the GeForce 8800 GTX seem quaint!

ATI: 2. Ben: 0.

What a difference new drivers make. ATI's latest OpenGL drivers (Catalyst 8.1) seem to work quite well with X-Plane. On two fronts:

• Linux. Turns out all you need to do to make X-Plane happy on Linux with ATI hardware is update the drivers. I'm running with the Cat 8.1 drivers on my MacBook Pro and things look good. Use Catalyst 7.11 drivers or newer! No more MALLOC_CHECK_=1 or --no_threaded_ogl. With the next beta, you won't have to use --force_run anymre.
• Windows. We were getting reports of corrupt screens on startup, and with the Catalyst 8.1 drivers these reports became very frequent. Turns out our threaded OpenGL code was doing something naughty*. Beta 19 fixes this.

The only known issue I can think of is: if you see corrupt water reflections, run with --no_fbos.

* Well, the way you set up threaded OpenGL on Windows and Linux is not very well documented, so I say naughty in that we made the drivers unhappy. I have yet to find a document that states clearly whether what we were doing is correct or not. We had to guess.

2 Blog or Not 2 Blog

I figure there are three things that making blogging suited for software:

1. A small interested group of users can subscribe to a blog without giving out an email address.
2. The information in the blog can be found using a general search tool like Google.
3. It's easy for a busy programmer to post.

I think this last point is not to be ignored - I post a lot here because it's easy enough to whip up a blog post that I can write one while the sim is booting.

The down-side of this is that blogs are not self-organizing. The blog is chronological, and somewhere within a heap of 200+ posts are detailed information on scenery topics not documented on scenery.x-plane.com.

That's not good. So I'll be trying to make a concerted effort to write real permanent documentation for some of the new scenery system topics that I cover. Documentation on DDS is in the works.

Part of the problem is that my interface for updating the X-Plane scenery website isn't that robust. One of the nice things about the plugin system being a Wiki is that it's easy to organize and easy to edit. (And one of my frustrations with "support forums" is that they don't self-organize...they mix questions and answers based on history and not a search key that a user might use, like "what's wrong with my card." We'll be supplementing the Linux forum with a Wiki soon.)

Airplanes - How it Fits Together

Here's a summary of the new airplane features in 9.0 (and some coming). Hopefully this will give you an idea of what new capabilities are available for modeling planes in X-Plane 9. This list will sound like a broken record - virtually all of these features are optional; you don't have to recut your finished airplanes to use them in version 9.

2-d vs. 3-d Panel

You may have noticed the new "3-d panel" option in PlaneMaker 9. This allows you to build a separate panel for the purpose of providing the texture to ATTR_cockpit (or ATTR_cockpit_region). You can then:

• Provide alternate instrument artwork in a cockpit_3d folder. (This lets you have perspective artwork for the 2-d cockpit and orthogonal artwork for the 3-d cockpit.)
• Pack your instruments together tightly to save space. (There is a real cost to large panels, so using a 1024x1024 panel for the cockpit object is a lot better.)

The 3-d panel is strictly optional, fully replaces the 2-d panel only for cockpit objects, and is activated by providing a custom panel background in a cockpit_3d folder. (See the "Example Plane-Widescreen+objects" plane in beta 19.)

ATTR_cockpit_region

Cockpit regions are an alternative to using the entire 2-d panel to texture your objects. They provide a few advantages:

• Performance. By requiring a power of 2 and allowing you to use a sub-area of the panel, cockpit regions avoid a lot of wasted computing that ATTR_cockpit can cause.
• Next-gen lighting. Unlike ATTR_cockpit, real 3-d lighting is applied to the panel when you use this attribute. This means that you will get a gradual decrease in light on your geometry (correct based on the angle of the sun) that matches the rest of the object.

Please note that you can mix and match which way you get your cockpit texture and whether you use the 2-d or 3-d panel feature (above) independently. However, you can only use ATTR_cockit or ATTR_cockpit_region in your airplane, not boht. ATTR_cockpit is still supported.

Generic Instruments

Generic instruments let you build instruments that follow some basic shapes (needles, tapes, etc.) that can be tied to any dataref. This both lets you customize particular instruments very precisely or create an instrument driven by a plugin dataref. These instruments are optional in version 9 - the old "premade" instruments are still supported.

New Datarefs

X-Plane 9 provides new datarefs targeted at airplane authors. The datarefs are better organized and have clearer names. But the old datarefs still exist, so legacy planes do not have to be updated.

Generally the entire cockpit should use only sim/cockpit2/ datarefs, and the plane exterior should use only sim/flightmodel2/ datarefs.

One special feature of these two sections: if your plane is used as an AI plane, these datarefs will animate the plane with the AI plane's control deflections, not the user's control deflections. So using these datarefs fixes the "AI animation" problem.

Plugins in Aircraft Folder

Version 9 airplanes may have a plugins folder (inside the ACF package) with fat plugins inside them. If you develop a plugin for your airplane, consider packaging it this way -- this will allow your users to install the airplane with a single unzip for all platforms and no extra "drag-this-file-here".

Plugins in the airplane folder is optional - you don't have to provide a plugin, and plugins that are installed in the main Resources/plugins folder will still work. Still, I encourage you to use this feature because it makes the install process a lot simpler. The X-Plane SDK website will have documentation on fat plugins.

Liveries Folder

X-Plane 9 features a new "liveries" folder. Liveries (replacement exterior paint for airplanes and their attached objects) can be placed in packages in the liveries folder to greatly simplify the process of repainting an aircraft. See the "Example Plane-Widescreen+Objects" for an example.

While the liveries feature is optional, I strongly encourage anyone doing repaints to adopt it. Liveries can be switched by the user in the sim without any file manipulation; there is thus no risk of accidentally deleting or breaking an aircraft.

Large 2-d Panels

In X-Plane 9, a panel can be up to 2048x2048 in size. You pick the dimensions. The panel will scroll horizontally if necessary.

Note that if you use the new 3-d panel feature, the 2-d and 3-d panel do not have to be the same size. I would recommend a large 2-d panel (to fill large monitors) and a smaller 1024x1024 3-d panel (for performance).

Hiding Parts

X-Plane 9 will allow you to hide aircraft parts. Many v8 planes use OBJs to model the plane geometry, and use a transparent ACF texture to hide the ACF. Setting the parts to "not drawn" saves the CPU time that X-Plane would spend drawing the airplane, and is thus more efficient.

Keyframes

X-Plane 9 supports key-framed animation; this is useful for the scenery system, but for airplanes it allows for much more complex and realistic animation. OBJs that don't have key frames still work.

Manipulators

This is a feature coming in the future: the ability to control how the user clicks and interacts with the cockpit object in detail. In X-Plane 9.0 we only support clicking on cockpit-textured geometry; manipulators will make features like draggable handles a lot more workable.

Global Illumination

X-Plane 9 does not yet offer a lot of control of the in-cockpit lighting environment; we'll be working on this in future versions. These features will be opt-in...that is, you'll have to change your model to get the new features, and old planes will work the way they always used to. It is likely that you'll have to use "modern" airplane-building techniques to use these new features (meaning OBJs, named or custom lights, lego brick instruments ,etc.).

Off Topic: Kid in a Candy Store

I try not to divert this blog from X-Plane related stuff, but I just can't resist. Go to the itunes music store and search for:

amichai margolis

Ami has been a friend of mine for years; Orah V'Simchah is the first CD he's recorded of his own music (I played bass on it). A few time a year he pulls a band together and we play a few gigs. Anyway, enjoy the tracks!

Reflections in the Wrong Place

We get a lot of bug reports showing strange reflections in the water. Some of these we can fix easily, and some will be more difficult, if not impossible. There are two fundamental constraints on the water-reflection code:

• A reflective surface (read: water) must be approximately flat to be correct. This is just how the algorithm works. (If you want to see why a non-flat surface fails, try to draw a camera position opposite the reflection plane and trace rays through this "reflection camera". Draw reflected objects that are close and far from the water and then observe the parallax error you get if the reflection plane curves.)
• We need one "water camera" for each flat reflection plane. You can't just statically offset when we have multiple elevations. (When drawing your diagrams, note how an elevation change causes a change in reflected angle, not just an offset.)

So the water will always have two problems: the earth is round (so nothing is really flat), and we can have lakes of multiple elevations (and we can't afford to render a water reflection per lake).

X-Plane tries to get around the non-flat water problem by picking little bits of the water that are flat (and seem useful) and using them to define reflections. This algorithm will always have problems, but at least it can be tuned.

Now there are also some things that we can fix with the water:

1. The math in beta 18 is simply wrong, something that will be fixed in beta 19.
2. The ocean is built from polygons that are too large; this introduces approximation errors when we try to pick "a little bit" of water to use to figure out our reflection plane.

There is one more problem that I see, especially in airports like PAKT: if there are two water surfaces of different heights that are nearby, X-Plane uses a slanted water plane that tries to include both. This works very badly - the resulting slanted plane doesn't look even remotely plausible. I'm not sure how soon we can tune this problem.

Why You Can't Have a Setting

I get a lot of requests for settings...the email is typically something like:

• Some feature in X-Plane is defaulted to X.
  
• I like it better when it's like Y.
• Can I have a setting to change the feature between X and Y.

Raymond Chen has a great posting that I think is very topical: "In order to demonstrate our superior intellect, we will now ask you a question you cannot answer."

This brings up one of the main reasons why we shy away from more settings: the more complex we make X-Plane's configuration, the less likely it is that the average user will be able to set the sim up correctly. Settings requests usually come from our most advanced users, but we also have users who have never used a computer before. Really! I've been on the tech support calls - they are very nice, but way overextended on the computer side of things. Should we allow them to pick whether scenery geometry is store in AGP memory vs. VRAM?

From our perspective, having a setting that a user doesn't understand is worse than neutral, it's actually harmful. Every one of those settings is something that can go wrong with the sim. I removed the ability to set the level of detail bias to positive (in other words, extend the visibility distance of scenery beyond its original design) after about 500 complaints of "low framerate" from users who had maxed this setting out (causing a 4x increase in 3-d processing load) without knowing (1) what the setting was, (2) what it was good for or (3) what the down-side was.

Could we present all the info to make intelligent decisions on the rendering pages? Honestly, probably not beyond a certain point...we would devolve our sim into a lecture on working sets, bottlenecks, and the OpenGL pipeline long before the user got flying. (Wait, that's my blog! Doh!!!) At some point the sim just has to do its best to do the right thing, or something similar to it. Just as Raymond points out that the default answer to any dialog box is "cancel", the default answer to any rendering setting is "all the way up."

When I tell a user who wants a setting that he or she can't have a setting because some other user will abuse it, the answer is almost always: well why don't you have two settings screens, a simple and advanced mode?

Besides the irony (of trying to solve the problem of too many settings with another settings), Raymond also points out that no location to hide an advanced setting is ever quite good enough. This is something we have struggled with, choosing command-line options more for to pragmatic reasons than because it's a great solution.

This doesn't mean you can't ask for command-line options...I am just trying to point out some of the thinking on the other side of the coin.

When Can You Not Use DDS?

There are a few cases where you cannot use DDS files in X-Plane:

1. Airplane 2-d panels (any layer - base, lit, -1 shadow layer, 2-d or 3-d).
2. Airplane instrument images.
   
3. Bitmap-based region specification referenced in a library.txt file.
4. Any gray-scale/alpha-only texture (e.g. mask files in the scenery system).
   

Beta 17 is treating cases 1 & 2 as an error; beta 18 will simply stop looking for DDS files in those cases.

Please note that airplane panels and instruments are not compressed right now, so there would be no performance benefit to using DDS in these cases. (If anything, PNG has smaller file size when compression is not used.) If we ever allow compressed panel textures, we'll probably allow DDS panels at the same time.

Case 3 is just a particular version of case 4 - that is, the region bitmap is black and white (1 channel) so DDS provides no benefit. Use a gray-scale no-alpha PNG!

Simple Optimizations for Airplanes and Objs

Just a few basic things:

For airplanes where you don't want to show the PlaneMaker part (because you've rebuilt the plane visually using OBJs):

• In X-Plane 9, set the parts to be invisible - this is faster than drawing them with a transparent texture.
• In X-Plane 8, if the texture is transparent, please downsize it! A 1024x1024 texture that's fully transparent is just a waste of VRAM!

For any version, any object, avoid using ATTR_diffuse_rgb when possible. You can get the same effect by tinting your texture and save unnecessary state thrash.

Panels Will Be Opt-In

First, the most salient point: in X-Plane 9.00 beta 16, 2-d panels and 3-d cockpits should both look the way they did in version 8. That is, your v8 plane should look good in v9 without modification. This is due to both:

• A bunch of bug fixes regarding burn-in and night lit layers.
• "3-d" lighting is not applied to the cockpit texture.

On this last point, my hope had originally been that I could apply 3-d lighting to the cockpit and simply make existing content look better. It has become painfully clear to me that this is not possible -- existing planes are very carefully tuned to look good despite what I can only describe as "inconsistent" lighting rules in v8. Applying more consistent general 3-d lighting wrecks this tuning.

So new features regarding 3-d cockpits will be opt-in - that is, you will have to change your model to start using them. Existing content will work the way it used to.

I will explain what new features are available in 9.0 and what will come in 9.1 in a separate post real soon.

Water: What's Coming Now

Beta 16 should be out relatively soon and includes what are probably the last of the water improvements for X-Plane 9.0. (All future water improvements will be in free patches or future releases.) Here's what made it into this particular version:

• Water wave patterns now follow the wave settings in the weather-water screen.
• "Fetch" data from the DSFs (information about whether water is subject to ocean waves or not) is used to modulate wave patterns - go to KSAN and set the wave height fairly high. Notice how the waves die out to ripples in some of the bays.

When I last blogged about water, I hadn't realized that we already have "fetch" data in the DSFs (and have since 820). Bear in mind that the fetch data in the current DSFs is not very good - I am sure you'll find plenty of strange cases where there are ocean waves inland, or calm areas in the ocean. The algorithm just isn't that good. New fetch data only comes with new global scenery.

The physics engine is not synchronized with the visual waves, although they both use the same wave height from the weather screen. The physics engine isn't using fetch yet. I may be ale to address this in a future beta, but I'm not sure.

What I have had to punt on (for now - remember, a ton of new features come to X-Plane in the form of free patches!) is the issue of reflectivity, sparkle, and water color from various view angles. As I explained in my previous post, the way the wave pattern is filtered with view-distance causes the water to look unrealistically calm from far away. Now that we can haev taller waves this is less of an issue (set very high waves to avoid the reflective look as much as possible) but it's still there.

I have some possible technology ideas on how to address this problem, but we don't have enough time left in this build to go all the way with them.

One final note on water: Windows users witih Radeon HD hardware can work around the corrupt reflective water issue by running the sim with --no_fbos.

X-Plane Water - Now and the Future

Randy forwarded me a very detailed email message from the features list about water. First a few notes:

1. I don't read the features list - I'm only blogging this because Randy forwarded it my way.
2. Procedural water (that is, procedural waves with the sky as a reflection) is a default shader option because when we first looked at it, it seemed to be "low cost". Some hardware really chokes on this option. But one trend that's clear: I have not seen any hardware that can do volumetric fog but has trouble with water. When it comes to expensive computations, vol-fog is the the heavy effect. If your card can run with vol-fog even remotely well, you're not going to get any kind of fps boost by turning off water. So the question of whether procedural water can be optional is one of whether the water looks good (which I will discuss below), not one of performance.
   
3. I've received plenty of emails about how we can "cheat" on the reflections to make them faster. To be honest, these ideas aren't very useful...you really need to know how the rendering engine works on a low level to find good ways to cheat on reflection quality.

(It's not enough to make the reflection texture less good looking, you have to do so in a way that makes it take less time to render! We've basically already taken all the optimizations we can - that's what that water reflection detail popup does. Keep it on a lower setting.)

So with that in mind I'd like to bring up three issues with the reflective water and give you some idea of the roadmap. I should say that when I list features as coming in the 9.xx or 10.xx time frame what I really mean is: some depend on new global scenery and some do not. It's possible that we may do a ton of water work in 9.1 or we may not do any more for five years. I can't really make a good prediction on future features after 9.0, except that they'll be, um, really cool. :-)

Water Weather Settings (9.00)

X-Plane currently provides a global wave height setting. X-Plane 9 beta 15 ignores this setting and simply creates calm water. This is simply a link-up between the physics and the shader that I had not gotten to until now. I believe that beta 16 will address this; the water wave height will match what you dial in. This still is only a baby step, but there will at least be a workaround for the mos common complaint (the ocean looks like glass) in that you can set the wave height to 10 meters.

Water Properties (9.xx, 10.xx)

Now Peter brings up an important point: the properties of how the water look vary with their location. First I must point out an architectural issue: you can't do a great job of computing "fetch" (open runs where wind builds up waves) in the sim because the area adjacent to the current water may not be loaded. That is, if X-plane doesn't have the pacific ocean loaded, how can it know that the waves hammering San Francisco can be pretty big? So I have always viewed fetch as something to pre-compute into a DSF mesh.

(This does bring up an architectural issue...how can we have properties on open ocean with no DSF mesh? The answer might end up being that we do have to provide water-only DSFs for bays and inlets that are large enough to cover a whole tile.)

Now it turns out that (secretly) the DSFs have contained a very crude version of fetch since 8.20. In version 8 we didn't really have the shading power to visualize it (I did have some experimental code once) and in version 9 it is not yet hooked up. The fetch calculation isn't very good, but it does exist. In the long term, we've talked within the company about including bathymetric data (water depth) and even water properties like clarity and the color of the goo in the water. Improving the water metadata would be a next-global-scenery feature, and we don't recut global scenery very often.

(The DSF format is flexible...you can encode just about as much extra data into the mesh for water as you want - it's not a format change.)

So I think you may see some improvement in the water as we utilize existing fetch data in the mesh, and some improvement as we encode more meta-data into the mesh. Note that to do any of this we need to change the sim a bit...right now it assumes a constant wave height - this would no longer be true. I think these kinds of improvements will start during the 9.x run but not be in 9.0.

Filtering Errors (9.xx)

This is the most technical issue with the water, relating to how the graphics hardware works. The problem is that the way the far-view of the water is computed is too reflective due to down-sampling.

In real life, if I am in front of a body of water with 6 inch waves, I will see two things:

1. Near me, I will see the waves themselves. Part of the waves will be dark, because their surface normal faces me, so the Fresnel equation says I see down into the water, where I see the bottom (or if it's deep enough, darkness). Part of the waves will be at an angle to me and act reflective, picking up colors from the sky and maybe surrounding terrrain. So my waves are going to be a mix of the sky color and some kind of dark color, with the color contrast allowing me to see the shape of the wave.
2. Farther out, the waves will be smaller than my eyes can distinguish and I'll start to see a more consistent water color, which is a mix of all of the various sky color inputs and darkness. The particular mix might depend on the chop and shape of the waves and angle to the sky. The important thing is: there is scattering of the reflection at a level smaller than my visual acuity, so I see sky color, but I don't see a sky reflection, and that color is darkened by the Fresnel equation.

Now in X-Plane the problem is this: the water waves are built up procedurally from a noise texture. As we get farther away, that wave texture is reduced in quality. Unfortunately, the graphics hardware averages together the wave shape, not the resulting color from the wave shape.

So instead of getting sky + deep = darker blue for the water, I get peek + trough = flat water! In other words, at a far distance the waves are canceling each other out before color lookup, giving us a perfect mirror in the far-ground.

This is fundamentally an implementation problem - I bring it up only because it's a counter-intuitive one. In the immediate future, the "glass lake" problem will become less because filtering only kicks in like this when the waves become less than one pixel - with the option for taller waves coming, the waves should be visible farther out. In the longer term we'll probably put in new shading code to address filtering problems.

Reflection Positioning Bugs (9.0, 9.xx)

As of beta 15 I thought I had fixed most of the reflection positioning bugs (that's what happens when something reflects in the wrong place in the water) - the geometry for this is made complicated by the Earth being round. I don't expect to nip all of these bugs in 9.0 but I do hope to get most of them, and I will keep working on this as bug reports come in.

Wave Shape (9.xx)

Finally, our wave shapes are quite primitive - it's just shaped procedural noise designed to look tolerably like water. We have a framework into which we can insert more complex wave equations (at the cost of some framerate). I don't know what the future will bring in this area. The v9 water sets out a new foundation onto which we can do more complex water. But we have to crawl before we can walk.

A New Broken Record

For years now I've been harping about ways to keep the number of batches down in your scenery. A batch is a single submission of triangles to the graphics card for drawing. Batches get rendered fast even if they contain a ton of triangles, but changing modes between batches is not very fast, so a few large batches is hugely better for performance than a large number of tiny batches.

To play that broken record one more time, there are two ways that you (a scenery designer) can cut down the number of batches):

• Use a small number of larger textures instead of a large number of small textures, preferably sharing textures between similar scenery elements that are placed nearby. X-Plane will do its best to merge the content that uses those textures into single batches. We call this the "crayon rule."
• Use less attributes in your objects. Attributes usually require a new batch (after the graphics card mode has been changed due to the attribute). So if you've got 1000 attributes in your object, you've got a problem.

Well, with X-Plane 9 I have a new broken record: avoid overdraw!

Overdraw is the process of drawing pixels on top of other pixels on screen. It happens any time we use blending to do translucency, and any time we use polygon offset to build the image in layers.

Overdraw is bad because with X-Plane 9's pixel shaders, most users are slowed down by the graphics card's ability to fill in pixels (pixel fill rate), with those complex shaders being run for every pixel. If you are at a screen-res of 1200x1024 looking at the ground with no objects, that might be 1.2 million pixels to fill. But if there is an overlay polygon covering the ground, we have 2.4 million pixels to fill! That's a huge framerate hit.

Right now there's not much you can do about overdraw. Once MeshTool comes out I will post some guidelines on how you can limit overdraw.

We took a step in the v9 global scenery to limit overdraw: in X-Plane 8 the global scenery tried to hide repetition of flat textures by drawing them over each other with offsets. In X-Plane 9 this is done in a pixel shader (e.g. the texture is analyzed and swizzled in the shader and then drann once), cutting down the number of times we must draw.

If you turn pixel shaders on and off in a flat area like Kansas you might see this if you compare the screenshots - the farm textures are more repetitive without shaders. This gives faster fps to everyone (with or without shaders) by eliminating overdraw.

Scenery and the New Plugin SDK

Sandy and I are working on a major revision to the plugin SDK (all the old stuff will work, we're just adding new things) that should be available in X-Plane 9 soon. The new "2.0" SDK APIs include some new functionality for working on scenery.

• Plugins can find the height of the ground at a given location, which is necessary to draw in the 3-d world in a realistic way (e.g. vehicles that drive on the ground in a sloped airport environment).
• Plugins can load and draw OBJ files using X-Plane's built-in facilities. I've posted OBJ drawing code in the past, but this makes things even easier.
• Plugins can lookup virtual paths in the library to find artwork from scenery packages.

This makes a number of scenery-system concepts available to plugins.

I've been resisting OBJ-drawing support in the SDK for a while, but a few things changed my mind:

• We've moved as much drawing in X-Plane to OBJs as possible and it's been a big win. A lot of the dynamic elements are OBJs, they're used in scenery and cockpits and airplanes. Using OBJ files means our artists (who are not programmers) can customize just about every aspect of the sim. So by providing a file format with a rich tool chain to plugins, hopefully we are helping third parties streamline content development.
• With pixel shaders, X-Plane's 3-d drawing environment has become complex and hard for third parties to safely augment. By encoding drawing at a higher level via pre-built OBJs (which can be animated via plugin-driven datarefs) we can insulate plugins from drawing-environment changes.

I Broke Volumetric Fog

I'll try to get it fixed soon....it's a bit frustrating, because it's the second time in the last week that I made a change to X-Plane to try to improve performance, tested it on my hardware, then discovered in-field that it helps some machines but screws up a lot of others.

The fog was a screw-up though...it's broken on the 9600XT and I have one of those.

(I'm not entirely sure what the minimum graphics card for volumetric fog will turn out to be...right now we let you use it no matter how slow it makes the computer, but generally it's been sort of a performance problem...it's just a very expensive algorithm that needs some kind of restructuring.)

Formats that are not changing

If you have content that worked in 864 but does not work in 9, please file a bug! Please do not assume we intentionally changed the file formats to break compatibility...I would rather get the bug report so we can fix X-Plane than have you change your work.

For every author who changes his or her work in response to a bug (an accidental breaking of compatibility), we'll have dozens of users who find their add-ons not working but not knowing how to fix it themselves.

With that in mind, beta 16 will have two fixes:

• Some panels were showing the default instrument backgrounds over custom panels. This will also be fixed in the next beta.
  
• Lit customized overlay parts were not showing. This will be fixed in the next beta.

So if you see those bugs, please check your plane against the next beta when it comes out. If you find other problems, please file a bug!

Panel texture in weird places

X-Plane 8 didn't care much whether you used ATTR_cockpit in scenery objects or other strange places. It would simply show the cockpit panel texture, and if it hadn't been updated, you might see an old one, and if it had never been used, maybe you'd see the random (but colorful) contents of memory. Similarly if you could get close enough to another airplane to look in the window, you'd see your own panel, since there is only one panel texture (for the user's airplane) in the entire scenery system.

This is a bigger problem in X-Plane 9.

• Because the panel texture can be expensive for big panels, we are a lot more aggressive about not setting up the panel texture if we can avoid it. This means that sometimes the texture doesn't exist at all. This is why in beta 14 you get an error if you do a formation flight having only been in "w" (forward 2-d) view...the panel texture doesn't yet exist, but the exterior view of the Cessna tow plane uses it.
• With panel regions there can be up to four panel textures, so you can see the potential for anarchy.
• Panel textures aren't even the same size any more, causing the wrong-panel-in-AI-plane problem to look even weirder than before.

So in beta 15, the panel texture is replaced with a dummy white texture for:

• Any cockpit object for an AI plane.
• Any scenery objects that are illegally using the panel texture.

This prevents crashes and other nasty stuff. If you want to make the panel be visible in your AI plane, consider using LOD to make a non-panel-texture "fake" cockpit image (at a very small res) at farther LODs. My guess is that in normal usage of the sim you'd really have to do something dangerous to get close enough to see the hack.

We did discuss live panels for all planes (for all of about 3 seconds), but the live panel texture in 3-d is so expensive that it'd be prohibitive to most users for even one AI airplane, let alone 20!

It's Time to Try Nine

If you create plugins, airplanes, or scenery for X-Plane and haven't tried your add-ons with X-Plane, please do so soon!! It's much easier for us to fix backward-compatibility problems while we're still in beta. Beta 14 introduced some bugs (that should be fixed in beta 15 real soon) but I think we're reaching the point where you can do compatibility testing.

We're working on a public Linux beta - see here.

Beware the Forceware

Brett and a few other users pointed out to me that the nVidida ForceWare 169.21 release appears to hose video for X-Plane. If you have an nVidia card, don't update, or you may want to back up a version.

This kind of thing has happened in the past - hopefully a revision will come out fairly soon. (But I do not have contact with the nvidia driver team for Windows on this...)

Also some users are seeing corrupt startup screens with ATI hardware - apparently some configs don't react well to us turning vsync off. Not quite sure what we'll do about that yet, but hopefully a fix will be in the next few betas.

Is Bigger Always Better?

We've been preaching "one big texture, not lots of little textures" for a while now, and generally speaking, packing a lot of art into one big texture makes life eaiser for X-Plane, because it can draw more triangles at once before it has to tell the card to change what it's doing. Inside the company we call this the "crayon rule".

Now the total set of geometry and textures that X-Plane needs to use for one frame is the "working set" - you can think of it as the crayons that you keep out of the box because you need them all the time. And as I said before, if the working set becomes too big, your framerate dies.

Now with large panels we're seeing a new phenomenon, one of the first cases where the crayon rule might not be true. The reason is due to working set.

When you make an airplane with a large panel in version 9, you can either use ATTR_cockpit, which lets you use the entire panel as a texture, or you can use ATTR_cockpit_region, which will let you use several parts of the panel. Each ATTR_cockpit_region is a texture change, so that's more crayons. And yet ATTR_cockpit_region is usually faster.

The reason is two-fold:

1. You can often use cockpit regions that don't cover the entire cockpit texture. Large panels are rounded up to 2048 if the are larger than 1024 in any dimension, so the "wasted space" in a 1600x1600 panel is actually quite huge. If you can get away with some smaller regions, your total panel texture area is smaller because there isn't wasted space due to this rounding, and you can also skip things like Windows. Prepping the panel texure takes time, and it's done once for lit and once for non-it elements, so it adds up!
2. It turns out there are two categories of textures that contribute to the working set: static texures and dynamic ones, and their impact on VRAM is very different. Dynamic textures are much more expensive. The panel texture is dynamic and it's uncompressed, so it really costs a fortune. (32 MB of VRAM for 1600x1600. That's not a lot for a static texture but for a dynamic one that'll kill you.)

Here's the details on dynamic vs static textures: the OpenGL driver keeps a backup copy of a texture in main memory, so that if it has to purge VRAM (to make room for more stuff) it still has the texture. As it "swaps" textures, the process is to simply send textures as needed from main memory to VRAM. No big deal.

But with a dynamic texture, the texture has been modified in VRAM! So the copy in system memory is old and stale. The graphics card thus must send the texure back to main memory, consuming twice as much bus bandwidth as normal. (To free 16 MB of VRAM and refill it takes 32 MB of transfer, 16 MB to copy the old texture back to system RAM and another 16 to send the new textures to VRAM.) On non-PCIe cards, this back-transfer might be at 1/8th the speed of the transfer to the card, so this is even worse on AGP cards.

Thus the driver does its best to not throw out dynamic textures. And this is why the panel texture is so expensive. That P180 will cause X-Plane to make two 16-MB dynamic texures, and those textures will cause 32 MB of VRAM to basically be off the table. That's less space for the other textures to swap in and out of. This kind of "permanent allocation" makes the VRAM budget tighter for all other drawing operations.

Given the right combination of large panels, large res, pixel shader effects (which make more dynamic textures), clouds, and FSAA, you can easily get even a 256 MB card to a state where the free space into which static textures are shuffled becomes horribly small, and the framerate just dies.

So the moral of the story is: yes, it can be worth 4 crayons (using panel regions) to avoid the huge cost of dynamic textures from large panels.

As to static textures (regular DDS files) that are 2048x2048 - the jury is still out but my guess is they don't represent a huge performance problem. As one user pointed out to me, they're only 2 MB when compressed (maybe more with alpha) so they're not insanely huge, and they can be swapped out.