In the distant past I blogged about the “crayon rule“, that is, thet importance of not changing textures a lot during rendering, and how authors can help X-Plane avoid changing textures.
Before X-Plane 8.50 the sim would change textures every time the pavement changed types in an apt.dat file. So if you have an airport layout that alternates concrete and asphalt pavement (the order in the apt.dat file is the drawing order!) then X-Plane would just switch and switch.
X-Plane 8.50 tries to be smarter about this and detect when it can get away with changing your layout order to reduce texture changes, improving framerate.
Here’s my warning: X-Plane is not very smart about this! We try to eliminate unneeded changes but our code isn’t that elaborate and it won’t optimize as well as you can.
The sure-fire way to improve framerate is to group your layouts by pavement type. This will give you the best framerate. If you have to overlap pavement and control the draw order, I recommend using as few groups of pavement types as possible.
I’m back from a week’s vacation in the mountains – having access to no digital devices is so refreshing!
We’re still working on optimizing the planet code; until this is done we won’t have the best possible framerates in 850. So even with beta 7 I think there will still be some improvements we haven’t gotten to yet.
When it comes to discussing graphics cards, VRAM always comes up. How much do you need? Is more really better? And why does X-Plane say it is using 300 MB of VRAM at current settings when you only have 64 MB of VRAM on your graphics card? How is this possible?
Well, the short answer is that X-Plane’s measure of VRAM is actually mislabeled. But there’s more to it than that. (See the bottom for tips for managing VRAM and framerate.)
X-Plane creates two kinds of graphics data for your graphics card: geometry data (the shape of mountains and valleys, buildings, runways and airplanes) and texture data (the raw images that are “painted” onto that geometry, such as grass, water, and airplane liveries).
The amount of texture data X-Plane loads is a function of your texture resolution settings – lower resolution means less texture data. Turning on texure compression also lowers this amount, and adding custom scenery may raise it.
The amount of geometry data X-Plane loads is a function of the number of cars and objects, add-on scenery, and which base meshes you use (new DSFs have more than old ENVs). Turning down the 3-d detail can reduce the amount of geometry data X-Plane has to load.
There are three two places that geometry and texture data can be stored: system memory (the RAM in your computer, on the motherboard) and video memory (VRAM, the memory on your graphics card). VRAM is usually faster than system memory, especially when the graphics card uses it, but there is usually less of it. For example, my Mac has 2048 MB of RAM but only 256 MB of VRAM.
We need one more concept to understand how VRAM and frame-rate relate to each other: the “working set”. X-Plane loads a lot of textures when it starts up. But when it draws a frame, it may not need them all. For example, we may load the grass runways texture, but we may not need it if there are no grass runways nearby. The “working set” is all of the geometry and texture data that X-Plane needs to draw the current frame. And since you cannot look at the whole world at once, the working set is usually a lot less than the total data loaded. (For example, as soon as you stop looking at that aircraft carrier because you’re flying away from it, the geometry and texture data for the aircraft data are no longer in the working set.)
So putting it all together we can realize that:
- In the rendering settings dialog box X-Plane is reporting the total texture data.
- The rendering settings number is possibly low because it doesn’t account for geometry data.
- The rendering settings number is possibly high because not all loaded data is in the working set.
- X-Plane has two sources of memory to work from (VRAM and system RAM), so even if the memory reported by X-Plane was right and bigger than VRAM, system memory would allow us to still run.
So in summary the display in the rendering settings dialog box is not very informative – you cannot look at that number and your card’s VRAM and use that data alone to predict frame-rate troubles.
So…how much VRAM do you need? Well, X-Plane uses VRAM and system RAM. Anything that is stored in system RAM has to be transfered over your graphics bus (this is your AGP slot or PCIe slot, faster is better, meaning AGP 8x is better than AGP 4x).
This is about to get geeky…skip down a few paragraphs for the practical part.
Basically you need enough VRAM and bus bandwidth (capacity to shovel data from system memory to your graphics card) to handle the entire working set (the stuff X-Plane needs) once per frame.
If I haven’t already lost everyone, you could say:
max framerate = bus bandwidth / (working set – VRAM )
So faster bus = faster framerate, and more VRAM = faster framerate. (Math sticklers might ask – if VRAM = working set, is framerate infinite? No…but this equation tells us that if the entire working set fits in VRAM and thus you are not limited by the card fetching data. Other limits on the card will limit your framerate. But this doesn’t happen so often as X-Plane’s working set on a high-end card with nice settings can be hundreds of MB.)
So you either need more VRAM or a faster bus. In practice, both are good! If you’re looking at a new computer, do not settle for anything less than a PCIe16x slot – that’s the fastest bus you can get now…less will limit the usefulness of your computer when you try to upgrade.
Generally when you’ve got more data than VRAM your framerate will be slow – but if you have extra unused VRAM, your framerate will not increase. So what I recommend is: turn down texture resolution (and restart) and check framerate. Once you do this and the framerate does not improve, go back up one notch. This is the highest texture resolution you can run without losing framerate. If you want to go higher, go for it…but you’ll pay for it in framerate a bit. Also, turn off FSAA for this test, as it can slow down framerates and make the role of VRAM hard to detect.
(A historical note: in the old days graphics busses were a lot slower than they are now. Remember that everything the card needs that doesn’t fit in VRAM has to go over the graphics bus. So…on the old cards if you ran out of VRAM, the sim’s framerate really tanked – it could fall down to 2 or 3 fps. But modern machines have much faster graphics busses, so as you run out of VRAM, the framerate get slower but is not totally unusable, becaues the graphics bus can keep up.)
Tips for best framerate:
- Always use texture compression.
- Turn down tex res until framerate doesn’t increase, then go up one notch.
- Be sure to buy a card with PCIe 16X!
- If the VRAM listed in the rendering settings is larger then your card’s VRAM – don’t panic!
Austin and Randy and the gang are out at Oshkosh right now – with Austin out of town there won’t be a new beta for at least five days. In the meantime I’ve had some time to look at X-Plane 850’s performance and tune the code a bit. (The next beta should be faster than beta 4.) I’ll cover performance in a few blog posts because there are a lot of issues.
For today I’ll stick to my usual rant: the difference between frame rate and sim efficiency. Simply put:
frame rate = (sim effiency * hardware power) / (visibility * scenery complexity)
Basically the sim gets faster with a bigger computer or more efficient code, and it gets slower as visibility goes up or you load more art into it. (By art I mean more complex 3-d models, bigger textures, more complex DSF meshes, more roads, or any other content that looks better but makes the sim do more work.)
Sim efficiency is only one of several factors in the equation, but, as a programmer, it is the one I care about most. For every release of X-Plane, I try to measure and confirm that the sim can process scenery at least as efficiently as it used to. If our efficiency goes down, your framerate goes down with nothing in return.
So in looking at the puzzle of low framerate in X-Plane 850, there are two questions we have to answer:
- Is the sim less efficient than 840? (The answer, BTW, is yes, 850 beta 4 is less efficient, and I am working to fix that now!)
- Does the set of artwork we’ve included in X-Plane 850 weigh down the sim more than the artwork in 840 when the same rendering settings are used? (The answer is: apparently not or at least not by any significant amount, but more research is needed.)
The point I’d like to make here is: nothing is free. We want to be as efficient or better than 840 (and when we’re not, we work to fix it!) We want to make sure that if you don’t use the new features, the old features don’t cost any more than they used to. But we do not
try to keep the framerate the same if you turn on new things that you didn’t have before!
We cannot give you something from nothing. If the sim ran at 30 fps with no cars before, it’s probably not going to run at 30 fps with cars – cars take time to draw. Some examples of what’s new in 850:
- 3-d structures on all of the runway lights (this can be shut off by disabling textured lights).
- Cars on the roads (controlled in rendering settings).
- Birds flying around (controlled in rendering settings).
We’ve also redone the models for the ships and hot-air balloons. The new ones are more complex than the old ones and probably slow the sim down a little. Why didn’t we provide a fallback to use the old fast artwork? Well, at some point if we try to provide everyone with every rendering setting we’re asked for, the rendering settings dialog box will look like the cockpit of a 747-100. So in some cases we try to set something up that is reasonably fast and useful but not too complex, so ordinary users can understand the settings. In a later post I’ll cover some of the tuning tricks you can use to maximize performance.
Coming up next: the relationship between VRAM usage and framerate.
X-Plane 850 is now beta – see item 7 of Klingon Software Development. A few random thoughts:
We aim to make each new patch of X-Plane “performance positive”, meaning for the same settings as the previous version, the new version will run faster. X-Plane 850 is definitely not performance positive right now, but this is mainly because it is an early beta. Expect lower framerates until we have time to do some tuning work and analysis.
X-Plane 850 supports a new apt.dat revision with curved taxiways, lines, etc. However you will not see this in the betas. The reason: the sim supports the data, but we have not yet shipped any new layouts using these features. Until custom scenery authors and layout creators adopt the new features you won’t see them in the sim, even though the capability is there. Because we have not yet released editing tools for these new features, it’ll be a bit before people can take advantage of them. (You can make curved taxiways now by reading Robin’s spec and then using a text editor, but this is a very slow and painful way to make a layout. This is how I have to make taxiways to test the code right now.)
Finally perhaps most important: Austin and I do not have time to follow all of the various on-line forums and communities, so if you post a bug to a forum but don’t file a bug report with us, the bug probably won’t get fixed! Please use our bug report web page to file bugs with the new beta.
(The bug report web page is for bug reports only. In particular, if you bought X-Plane and are having trouble with it, please email info at x-plane dot com to receive tech support. Filing bugs will probably not get you timely tech support, but emailing our tech support people will.)
I’ve been asked by a few object authors to put a show/hide command in the OBJ8 format for more advanced animation. It turns out this is trickier than you might think. For example, consider this set of OBJ8 commands (based on a hypothetical ANIM_hide command):
ATTR_flat
TRIS 0 30
ANIM_begin
ANIM_hide sim/flightmodel/whatever
ANIM_smooth
TRIS 30 30
ANIM_end
TRIS 60 30
What’s tricky here is: the use of state changes inside the “hidden” part of the object. Should the triangles after the animation be smooth, flat, or change depending on the animation?
Internally X-Plane has an object optimizer; when objects are loaded we analyze it and attempt to reduce the number of total commands, so that object drawing is as fast as possible. I strongly recommend you optimize your objects heavily – if we optimize, we might make the object faster, but if you optimize you will make it faster. Our optimizer is aimed at speeding up internal commands that are generated by X-Plane as it translates the object from OBJ7 or OBJ8 to our internal memory structure.
The problem with using show/hide to optionally skip commands is that the optimizer can no longer remove state changes. Because we don’t know whether we’re flat or smooth (after a hide command) we can’t know whether the next flat or smooth attribute is needed or unnecessary. So if show/hide is truly conditional (meaning it can skip commands) then it actually can cause things to be slower because it prevents X-Plane from removing unnecessary state change.
(The case of smooth/flat might seem trivial and contrived; it is. But there are additional “hidden” attributes that are generated by X-Plane as it translates the OBJ into our in-memory internal format. So state change can come from places you might not expect. Thus it’s important that the optimizer do its best to remove state change that can’t be addressed in the OBJ itself.)
The alternative (and one that is more likely to get implemented) is show/hide as state. Under this model, the full object is completely evaluated, but the ANIM_hide command basically causes triangles to not appear. This is similar to the workaround that people are doing now: using ANIM_translate to move the unwanted geometry a very long way away (and hoping it is out of sight).
Show/hide as state makes a trade: all commands are executed always, so we run no faster by hiding, but since the execution of the object never changes its flow, it can be more heavily optimized.
I am currently leading toward the latter approach for this reason: currently objects are slow because the CPU must do the work of state change (ATTRibutes, etc.). But graphics cards are becoming more sophisticated; in the future it may be possible to run an object with state change as a single command for the graphics card, with no CPU intervention, making things faster. But the graphics card does not yet have the ability to handle conditional logic, so show/hide as conditional logic could stop us from fully utilizing the graphics card in the future.
(Some OpenGL geeks may be thinking now “but the latest graphics cards do have conditional logic”. This is true, but currently it is only usable in shaders; the cards do not yet have the ability to skip whole commands conditionally. I believe they will be able to handle static state change before they can handle conditional state change.)
A quick note on the AC3D plugin based on a conversation wtih Tom….
The AC3D X-Plane OBJ export plugin is not an optimizing plugin – it is meant for “finishing”.
The idea is that the plugin can edit an OBJ and preserve almost any strange sequence of attributes you come up with. If you’ve carefully ordered your polygons and used ATTR_no_blend and a bunch of other tricks to use translucency and other tricks, the plugin will not scramble your work, but will preserve it. This lets you put the finishing touches on your OBJ, hence a “finishing” plugin.
The other side of this is that in preserving your object, the plugin does not attempt to make any optimizations that would reorder your object. So if you “ask” the plugin to make an inefficient object by using lots of state changes, it will do so and your framerate will suffer.
Basicaslly there is a direct correspondence between the model in AC3D and the exporter OBJ file. So to use AC3D efficiently you must understand both what makes an OBJ fast (not using ATTRibutes among other things) and how you do these things in AC3D (not using flat shading at all, for example).
The best of both worlds would be of course to have a menu option to optimize a model, which would let you optionally change polygon order for speed. This is something I would like to do but I’m not sure when I’ll have time to code it.
First the basics: you can use the ATTR_LOD command in an object to specify what distance range an object is seen from. This has two implications:
- You can have your object look different (and usually less complex) from farther away.
- Probably more important is – your object is not drawn from arbitrarily far away. All drawing is bounded!
This second aspect is actually the more important one…because at any given time most of the objects in the sim are too far away to draw due to LOD! But this begs the question: what happens if you don’t specify ATTR_LOD at all? Is your object drawn from hundreds of miles away?
The answer is: if you don’t specify ATTR_LOD X-Plane calculates an LOD for your entire object that starts at 0 meters and goes to a distance where we think no one would care if your object disappeared. The calculation is based on the bounding sphere of your object.
Our built-in algorithm usually works pretty well, but there are some cases where it gets fooled. One important case is: when you merge two small objects into one big object, the LOD distance goes up, because the total area that your object covers goes up!
What this means is: if you have a dozen small taxiway signs from XTaxiMaker, they’ll all disappear relatively quickly as you go away from the airport, protecting framerate (by keeping the number of drawn objects down). If you merge those into one big object, the performance of the sim changes in two ways:
- Framerate when the objects are drawn goes up – we now draw one object instead of five. The number of objects drawn is very important to framerate.
- The objects will be drawn more frequently, so overall framerates maybe lower.
The moral of the story is this: if you merge objects for performance, be sure to insert an ATTR_LOD statement that is apporpriate to the actual distance at which point the objects are invisible, not the total “radius” of the object! Taxi way signs are not needed after 1500 meters, even if they cover the whole airport. Similarly some packages have taxiway markings in an OBJ. These objects usually cover big areas but the lines themselves are so thin that they aren’t needed when far away.
(Also beware: LOD is calculated frmo the middle of the object, so if the object is huge, take that into account.)
As a final note, ATTR_LOD is “free”. X-Plane will calculate and check LOD distances on every object no matter what. If you don’t use ATTR_LOD, one is generated for you. So there is no harm in adding ATTR_LOD to your object. Your framerate will only go down if you pick an LOD that is larger than the sim would have picked for you.
I was investigating Anacortes, WA with version 7, 8 US and 8 global scenery this morning and had a (probably obvious thought): if your framerate is inadequate with the new global scenery, use the old scenery!
What’s important to understand is: the amount of work to be done is defined by the scenery, but the capacity of the sim to do that work is defined by your hardware and the version of the sim! In particular, 835 is definitely faster than 820, which was faster than 800, which is faster than X-Plane 7. So you can use X-Plane 835 with old scenery and get a much higher framerate.
In the Anacortes area I’m seeing framerates in the 60s with global scenery, 90s with the US DSFs, and 120s with V7 scenery. In a direct comparison with all settings controlled, X-Plane 7.63 runs this airport at 52 fps, while X-Plane 8.35 runs the same scenery at 110 fps.
There are two things going on here: in newer versions of the sim we can use newer, more efficient techniques to talk to the card. These techniques are invented by the graphics card vendors to allow applications to take advantage of the ever-growing power of graphics cards. So a new X-Plane has an advantage over an old one in the way it utilizes modern hardware – hence the framerate improvements.
We are also “spending” that performance dividend to provide more realism. Here you can compare the look and framerate of the v7 ENV (top) vs the v8 DSF (bottom). We are utilizing higher performance to make scenery more realistic, but if you’d rather have the framerate just load up the old scenery. It still works, and it’s very fast.
Here’s a short list of some of the features of OBJ8 you should never use:
Don’t use ATTR_no_depth. This attribute should probably never have been invented and will be removed someday. There is no situation I can think of in the sim where this attribute is a good idea. (If you do need it, please let me know – tell me why!) Use ATTR_poly_os to put your object on top of a runway or the ground.
Don’t use ATTR_ambient_rgb or ATTR_specular_rgb. These attributes are no-ops and have never worked.
Don’t use ATTR_diffuse to change the color of your object. Use a small solid-colored patch of your texture – it’s much faster. The only reason for ATTR_diffuse is in conjunction with ATTR_emission. I will explain this special usage in another post.
Don’t use ATTR_shade_flat. You can represent any shading, smooth or flat, with ATTR_shade_smooth. In AC3D this means clicking the ‘smooth’ button and using the crease-angle to create the appropriate look for your object.
Don’t use ATTR_poly_os with huge offsets. Even if you stack several layers of offset polygons on top of each other, you do not need to make each offset larger and larger; the offset only needs to be large enough to put the polygon over the base terrain. An offset of 1 or 2 is almost always adequate.
A few other warnings: Don’t rely on your objects being drawn in a certain order in the sim – this will change! Don’t put lights in the middle of your objects – when textured they will only look right at the end of the object.
