Thursday, November 29, 2007

How Framerate Dies - Glitching

Back in the good old days (that would be X-Plane 6), X-Plane's framerate would suffer in two ways as you cranked up the rendering options:
  1. For most features (more visibility, more autogen) as the CPU and GPU became more heavily loaded, the framerate would gradually decrease.
  2. If you ran out of VRAM (that is, the working set of textures needed per frame was more than your card's VRAM) framerate would really die fast - think 2 fps.
The reason for this second behavior was that computers couldn't shuffle textures between main memory and VRAM fast enough to render a frame in a 30th of a second.

As computers have gotten faster, this second behavior has gone away - modern cards, with fast PCIe 16x busses, can transfer textures from system memory to VRAM pretty fast - fast enough to have the working set be (slightly) larger than VRAM and still fly. So as texture memory increases, framerate decreases more gradually.

However, a new behavior has emerged: "glitching". You may have noticed that when you've got your computer set to the ragged edge of the rendering settings, as you turn the camera, the framerate will stutter for a few frames, then return to a relatively high rate (40-50 fps).

What's happening is: the working set of textures and geometry needed by X-Plane just barely fit in VRAM. But when you turn your head, a different set of textures and geometry are needed. While the card sorts out what is needed and what isn't, it spends some time needlessly shuffling textures, and eventually reaches stability, with only what's needed in VRAM, and framerate stays high.

Glitching has emerged as a mode of performance degredation because over time we've cut down the amount of "stuff" (textures and geometry) x-plane needs to draw a frame to only what's really absolutely needed. This means there is less intersection between the working set in one view and another, and it also means you can get closer to the edge of your hardware.

So my view on glitching is basically "too bad". If the working set weren't as carefully trimmed, you wouldn't have glitches, but the framerate would be entirely low, not entirely high. The only solution is to turn down settings that increase the working set (object density, world LOD, tex res, forests...) until the computer can run without glitches.

An even stranger variant of this: users sometimes report framerate getting "stuck" at 19 fps and then coming back when they change apps. The problem is that the driver doesn't know exactly what the best order of textures to keep in VRAM vs. shuffle the view changes, sometimes the driver ends up with a non-optimal decision about what stays in VRAM and what goes, causing framerate to drop. Changing which app is in the foreground fixes this by temporarily pushing a lot of items out of VRAM, at which point the driver makes a different decision by luck.

Again, the solution is simple: turn down rendering settings to get the working set smaller than VRAM.

Basically, if the working set is smaller than your amount of VRAM, you should have even framerates, proportional to rendering load.

If the working set is greater than VRAM, the driver may find an optimal way to shuffle things and only decrease fps a little, or it may find a non-optimal way to shuffle and you'll get terrible fps, and that shuffle can change on the fly, causing framerate to fluctuate all over the place.

Two Truths of Hardware

I would have to say my track-record at predicting hardware developments in the sim world has been pretty poor. But these two factors seem like they won't change for a bit:
  1. The amount of working data a system can crank through in one frame keeps increasing while the total amount of virtual address space stays the same (3 GB).
  2. The gap between the fastest and slowest systems from a finite time period keeps widening.
To elaborate on this first point, as video cards get faster (both GPU and internal bus/RAM speeds), system RAM and buses get faster (graphics slot changes are rare, but with enough VRAM this is relatively moot) the amount of texture and geometry data that X-Plane can tell the card to draw in a 30th of a second keeps going up. So users are running with more trees, roads, 3-d, etc. than in the past.

But all of this stuff lives in memory, and even if a user has 8 GB, X-Plane can't load more than 3. Imagine what will happen when a graphics card can draw 3 GB of data in one frame? X-Plane will have to use all of its available memory for things you see right now or it will waste graphics power. This would mean purging from memory anything that isn't on screen!

On the second point, video card power doubles every, um, six to twelve months (perhaps more like 18, now that the card makers are hitting the same fabrication and power limits that the CPU makers have already hit, but this is all seat of my pants). So even if we only supported the last three generations of cards (we support at least seven!!) that gap in performance doubles!

This means that every year it requires a more flexible rendering engine to make a sim with decent frame-rates for old computers and up-to-date graphics on new ones.

Obects and Liveries

In X-Plane 9 betas 2, you can use the livery system to provide alternate textures for misc objects attached to your plane, but not the cockpit objects. Beta 3 will address this, allowing cockpit objects to reference the livery system too. We'll get some examples posted for how this all works soon.

Austin and I were discussing this last night - here's a few thoughts on the difference between the misc. objects and the cockpit object:
  • Because you can have multiple misc. objects, you can effectively use more than one texture for your airplane. These days plane designers want a lot more than one texture.
  • We're working on optimizations for attached objects - basically by breaking your plane carefully into a few objects, you may be able to optimize frame-rate. A lot of this code is not in the sim yet, but will go into a later beta.
  • Using multiple objects with different LODs is a much more efficient way to improve fps than simply having multiple LODs of the entire plane.
For example, make an interior object with a low LOD (0-500 meters) and an interior texture. Attach it. Then make an exterior object with an exterior texture and a longer LOD (0-50000 meters). When you back away from the plane, X-Plane can entirely skip the interior object, which means that neither the geometry nor texture have to be moved to VRAM. That's a big performance win.

The cockpit object is also different:
  • The cockpit object induces the sim to make a texture out of the 2-d panel. (And it is the only object where the panel texture is legal.)
  • Mouse-click analysis is only done on the cockpit object. If you load up the cockpit object with all of the animation for your landing gear, X-Plane has to wade through all of that animation to update the mouse cursor in the 3-d cockpit.
  • The cockpit object can be swapped for an alternate object in the exterior view (we'll provide more control of this for misc objects soon).
So my general advice is: use the cockpit object only for the real panel itself!

However, we have provided livery support. You can't livery the 2-d panel, and the livery system is not meant to reskin cockpits, but there are probably some planes out there that used the cockpit objet to model exterior plane features (from before we had misc objects). The livery system in beta 4 will let you reskin these planes without changing how your obects work.

A wide range of performance

One trend I'm seeing in the forums is a wide range of reports on X-Plane 9 framerate. I see both "X-Plane 9 runs faster than 8" and "it's so slow I can't fly at all."

In my experience this kind of situation is often due to hardware-specific performance issues...that is, X-Plane is doing something that is fast on one kind of GPU but slow on another. Once we figure out what the problematic operation is, we can replace it with something that's fast for everyone.

If you've got all of the eye candy turned off, everything on minimal, and are still getting 20 fps, that's not X-Plane 9 being a pig, that's something wrong with X-Plane 9 on your particular system. Please...try beta 3 when it comes out, then if it's still slow, report a detailed performance bug and we'll investigate.

Tuesday, November 27, 2007

Beta 3 - Don't Panic

X-Plane 9 is currently in beta 2. Long-time X-Plane users know that a lot of bugs get fixed between early and late betas, and they also know that a good number of bugs get added between the early betas.*

If all goes well, X-Plane 9 beta 3 will be out in a few days. My advice is: don't panic. X-Plane beta 2 crashes for a number of users, so our top priority is to fix the crash and get the fix out ASAP. If your bug doesn't get fixed in beta 3, it's probably because we're still working on it but didn't want to delay getting the crash fix to users.

Similarly, beta 3 will include some performance improvements, but more are coming. Beta 3 doesn't represent the end of our performance tuning, it represents the first beta that we can do serious analysis with. We only have a fraction of all of the supported video cards within the company, so if your computer is having performance problems, well, we'll figure out what's going on in beta 3 and then fix it.

* Our approach to bug fixing is: if a piece of code is buggy because it's subsystem has a design problem, we go in and fix the design problem, even if we're in beta. Other companies might say "no fixing design problems (which changes more code) during beta." But the way I look at it, badly designed code is just going to cause problems all the time until it's fixed, and it has to be fixed some day, so why wait.

(Why would there be badly designed code in X-Plane, or any computer program? Computer programs change over time, and the functionality they perform changes and grows. As this happens, the designs of the past no longer make sense for future requirements. In my experience most design problems come from code "outgrowing" its framework.

So our approach is to upgrade the framework as soon as it shows signs of growing pains, rather than jamming as many features into the existing framework as possible until it becomes so overcrowded that we can't get anything done.)

Monday, November 26, 2007

Multi-Core and X-Plane 8 and 9

To answer some speculation and questions I've seen on the forums regarding X-Plane and multiple cores:
  • X-Plane 8 and 9 will use up to four cores to "shift" the scenery coordinate system when scenery needs loading. This shift causes a pause in both X-Plane 8 and 9, but it is a relatively short pause.
  • X-Plane 8 and 9 will use a second core to build 3-d geometry out of road, forest, facade, and airport definition data while you fly, as you move through the loaded scenery area. This is particularly important to smooth flight when there is a lot of 3-d enabled.
  • X-Plane 8 and 9 will use a second core to do some of the work of loading textures from disk while you fly. (Right after a scenery shift happens, over time new textures are loaded in.) Some of that texture load is still done on the main thread. Texture compression is done on the main thread, which can cause stuttering. (I expect to address this in the future, but authors can use DDS textures now in v9 to simply not do the compression at all and make everything faster.)
  • X-Plane 9 will load new DSFs into memory on a second core. Loading new DSFs takes the vast majority of scenery load time, thus flight with X-Plane 9 and a dual-core machine is a lot smoother than it was in v8. This is a big win for the dual-core machine and is new to v9.
All of our new work on the sim keeps multi-core in mind. We know that more and more users will have multiple cores and that we're leaving performance on the table if we can't distribute rendering load across two cores.

So the important points here I think are:
  • X-Plane 9 significantly uses a second core.
  • Use of the second core has grown significantly over time, and will increase in the future.
  • I like to use bullet points way too much in my blogs and emails.

Friday, November 23, 2007

X-Plane 9 Performance - Let's Wait a Little

When someone posts bad performance with X-Plane 900b2 vs. 864, the urge for me to respond is overwhelming. I spend a lot of time very carefully comparing old and new versions in controlled situations to make sure we haven't let any part of the engine get slower.

For now I will try to hold off - there are a few basic things we can do with beta 3 that will change not only the performance of the sim, but also how the rendering settings are organized.

For now a few immediate thoughts:
  • If you are looking at a new graphics card, don't plan your hardware purchases on the beta. Wait for a final build to evaluate.
  • There is no free lunch - settings that don't exist in v9 (volumetric fog, reflective water, forests) are going to cause lower fps than 864. (You could set the forest setting to "insane" in v864 with no penalty, as long as you had no forest add-ons installed.)
And finally, something I find myself saying over and over and over: there is no relationship between the fastest computer on the market today and the highest settings in X-Plane. We do not guarantee that the fastest computers can run x-plane "maxed out".

The highest rendering settings represent the most detailed output our engine can make, and the most data we have (based on what fits on the DVDs). We provide this very high rendering setting because:
  1. A user might want a lot of detail in one area and not others. You can run on "insane" roads if you leave the other settings dialed down, or reflective water can be on if you don't have a lot of objects or world LOD. So even if having ALL settings on maximum kills virtually any computer made today, having some settings on maximum can be useful.
  2. If you buy X-Plane 9 now you are entitled to every patch (and then you may use it long after the version run is over). So you might be using X-Plane 9 for 2, 3, or 4 years. Settings that are impossible to reach on today's hardware may be very usable on future computers.
So we do not penalize users who want some settings very high, or future users, by preventing you from setting the settings in any way you wish.

Please understand that the settings are not calibrated the same as X-Plane 8. If you set the rendering screen to look "as close" to x-plane 8 as possible, you are almost definitely not getting the same amount of detail (and the same load on hardware) as you were in 864. They are not comparable. Trust what you see out the window while flying, not what's on the rendering settings screen.

Wednesday, November 21, 2007

X-Plane 9 Is Here

There will be a lot more to post about this soon...a few immediate comments:

We have an order in with one of our server providers to get a lot more bandwidth for demo/update downloading...the servers are going to be pretty slammed, but we're doing our best to keep downloads fast. I believe the beta should be about 600 - 700 MB over the net.

X-Plane beta 1 is on the DVD. X-Plane beta 2 is on the net. In other words, we've already done our first patch since the DVDs went master. This patch improves performance and fixes QuickTime movie recording on Windows. (BTW QT movie recording is completely overhauled for version 9.) So once you get DVDs, make sure to run the web updater to get beta 2. With a DVD install this is a tiny download, since the updater only fetches changed files.

The DVD set is "X-Plane 9 beta 1", but the scenery and terrain/earth orbit textures are final. So you can buy DVDs now and simply use the web updater to get the "final" X-Plane 9.00 (plus of course all of the free upgrades and patches for the life of version 9).

This is the first major version release where we've had our updater. In the past we've had to either post a new version without a beta, or put a beta on DVD. With X-Plane 9, the large files that aren't available for web updating are finished, and the rest of the beta can be upgraded over the net. I hope this allows people to participate in the beta program and still enjoy the sim with full scenery.

Sunday, November 18, 2007

ANIM_hide is not a framerate optimization

I'm sure I blogged this before, but the blog's gotten old enough that I can't find my old posts. This came up in an internal company discussion, so let me say it again:

ANIM_hide is not a framerate optimization. 99% of the time it doesn't make your object draw faster.

ANIM_hide is provided to let authors make certain animated effects (like swapping out a prop disc for blades based on prop RPM). These are animated effects and cost fps, because they use the CPU and interrupt the graphics cards from just blasting out triangles at warp speed. An example:

You might have a very complex object attached to a plane that doesn't need to be drawn at all, like a landing gear assembly. This object could have its own texture, a ton of animations, and high triangle count. Using a giant ANIM_hide around it to prevent drawing when the gear is retracted does you no good. Here's why it doesn't help.
  • Before an object can be drawn, X-Plane prepares the geometry and texture to be used by the card. These are atomic operations (we have to prepare the whole texture and all of the geometry no matter what we will actually use) and they are expensive.*
  • X-Plane then must evaluate the animation command on the CPU to decide if the object must be drawn. If the object drawing is simple and the object is drawn, this CPU work is just wasted, so this technique wouldn't even make sense unless the object is hidden a lot of the time.
  • If the object is hidden, X-Plane will still run through every command in the object, simply skipping drawing. So if the object is heavily animated, we still pay a lot of CPU for the "hidden" object.
You will actually save some performance with ATTR_hide in one situation: if the geometry that is not drawn with ATTR_hide covers a huge amount of the screen (e.g you are really close to the object) then not drawing the pixels saves frame-rate. This would be extremely unlikely - you'd have to hide an entire cockpit from the inside to see any kind of benefit with this.

Why doesn't ANIM_hide actually skip work? Well, it may someday, but for now it's a question of how we optimize objects. When we load objects, we evaluate their command sequence and attempt to consolidate and remove unnecessary CPU work. We remove unnecessary state change, combine drawing commands when possible, etc. This works because we know at object-load time exactly how the object will be drawn. But consider this bit of OBJ "code":

TRIS 0 30
TRIS 30 60
TRIS 90 120

If ANIM_hide really skipped work, is the ATTR_smooth routine necessary? Can the last two TRIS commands be combined into one big TRIS command? If ANIM_hide removes an attribute, we don't know until we actually draw the object what attributes will be run. But if we say ANIM_hide doesn't affect state change (which requires us to actually do the state change) we can then realize that none of the state change in this object are actually necessary, saving 3 attributes, and allowing us to combine a triangle batch.

So for now our policy is one of simplicity:
  • ANIM_hide is for artistic purposes, but not optimization purposes. It simply stops drawing, it doesn't eliminate work.
  • The optimizer then goes to work on your object.
  • I think we will someday provide a new mechanism for the "landing gear case", one that's specifically designed to quickly eliminate parts of a plane that are expensive and don't need to be drawn.
* X-Plane does try to optimize out this cost in some cases. For the purpose of drawing, an object can get "culled" (not drawn at all) by being too far away for LOD or fully off-screen, or it can get "drawn" (meaning we do look inside the commands). Culling is very very fast, and drawing is usually quite slow. The optimization of avoiding using geometry and textures always work in the culling case, but usually do not work in the drawing case. So having a smart LOD on the landing gear is a huge win.

Friday, November 16, 2007

New SDK coming...

Read the info here:

Please note that if you are a scenery author and not a programmer, this will not directly affect you at all. (But see the section on compatibility - old plugins will still work!)

Version 9 will also feature a lot of new datarefs - this should make things a lot easier for authors doing animation.

The new API will allow programmers to access the terrain mesh. This means that add-ons that want to add dynamic graphics content by drawing (e.g. drawing in baggage trucks) will be able to place that content "on the ground" no matter what the surface of the airport area. I think this will allow for some interesting new add-ons.

Thursday, November 15, 2007

Add-on Forests...

It looks like Andras and Albert just released new forests...their work looks really good and makes me go "is that really X-Plane"? Definitely a must-have add-on!

I would also suggest that anyone who wants to know why X is wrong with the global scenery read some of Andras' posts on the X-Plane tech list...a few weeks ago he described in a lot of detail the kinds of problems that both he and I face when working with global datasets - his comments are right on the money!

I think we'll have more announcements regarding forests relatively soon. Things have been quiet because behind the scenes we're in a big push.

Saturday, November 10, 2007

The problem with KLGA

With X-Plane 820 global scenery, you can fly with "sloped runways" (this option drapes the runways like a piece of cloth over the terrain no matter how strange the terrain is) at most locations, but not La Guardia, where there is a huge hump in the runway.

It turns out the problem with KLGA is that there are vertices in the mesh that are adjacent to both water and the airport. The field height is a few meters above sea level, so we cannot decide what height those vertices should be? (Zero for the water, or a few meters for the airport?) In the 820 global scenery, the water wins, pullling down any part of the airport that is coastal.

For the version 9 re-render of the global scenery I am trying to fix this by creating a buffer zone of a few meters around coastal parts of the airport. This assures that we will have at least TWO vertices at the corners of the airport. The inner one can then be at field level and the outer one at sea level. The triangles in between these two "rings" form a sloped transition area (more sloped if the airport is far above water level), allowing the inner area to remain flat.

We'll have to see how much this helps coastal airports - in hindsight I'm surprised that a lot more airports weren't as unmanageable as KLGA.

(As a side note, it appears that the SRTM raw elevation data is at its least reliable in airports - there's something about them, perhaps the metal or concrete or heat that causes a ton of drop-outs and false reflections. So we have to pre-process the airport areas pretty heavily to use them at all - and sometimes this pre-processing doesn't even work)

Friday, November 02, 2007

Taxiway Shapes

For this blog entry I will try to show how to put together taxiway segments to avoid WED problems.

Here we have a 3-way junction, that is, one taxiway ending with another. First, what not to do:

First we have an overlapped solution. This is not good because overlap is wasteful of graphics card power. We also have the problem that the edge markings will overlap. So in the second and third picture, we "cut away" the horizontal taxiway markings by adding vertices. (In picture two we have overlap, in picture 3 we try to end the taxiway right at the intersection.)

The problem with technique two is: we still have overlap (and imprecise markings). The problem with picure three is that we can't guarantee that the vertices of the vertical taxiway are exactly "on top of" the horizontal taxiway edge. So you may get something in X-Plane that looks more like this:

(Gap exagerated for clarity.) This is a "slivering" problem. The solution is one that is both efficient and nice looking:

In this situation, I have inserted two vertices in the edge of the horizontal taxiway and then used "snap to vertex" to assure that the corners of the vertical taxiway are exactly the same as the "cut points" in the horizontal one. This gives me a connection that will look clean in x-plane with no cracks or slivering and no overlap. My lines also end at just the right places.

(Hint: once you do this, to move all of the overlapped vertices at once, select them all with the marquee tool and drag.)

Another issue I see sometimes with WED layouts is how to draw the "fillets", or curved taxiways that touch runways. Because the lines are not as smooth in x-plane as WED, often users are surprised when the approximations of the bezier curves cause an overlap and theere is no pavement.

Note that we're stuck - we can't use the technique described above because we can't insert vertices into the runway. So we have to overlap. Less overlap is better - the overlap here is exaggerated to make things clear.

In this curve, we have a control handle only on the bottom vertex. It will overlap as soon as the control handle reaches the other side of the top line. By pulling the control handle down, we restore the curve.

Here we have two control handles - now it is a question of whether the top control handle crosses the top of the taxiway.

Here is one solution - at the expense of more overlap we can simply give ourselves some breathing room with our bezier curve. However, my preference would be to try to keep the control handles below the taxiway top by a wide margin.