I just finished answering a user’s questions about whether to upgrade from a Pentium D to a Core 2 Duo and now I am back looking at a framerate problem on a 1.4 ghz G4 with a Radeon 9200.
Let’s just consider that for a second!
One set of X-Plane users has the latest generation hardware and expects X-Plane to look as good as it can. Getting 270 fps on this hardware (yes, we have seen fps this high with the default settings) is not useful – these users want more graphics on their big machines. If we don’t give them this, X-Plane is not a competitive product.
Another set of users still has previous generation hardware. If I may single out a particular group – Mac users with the G4 processor – that previous generation wasn’t ever very impressive even when it was new. Basically Apple was stuck because the G5 was the best chip they had but couldn’t be built with low enough power to put in the places they wanted to put it. Apple also wasn’t putting terribly nice graphics cards in their machines at the time. (This was fixed when they stuck a 9700 mobility in the PowerBook.) So we have a whole group of PowerBook and Mac Mini users suffering from low framerate on older machines that were never that good as flight sim machines to begin with. (And G4 users I do understand your pain – until about a month ago my laptop was an 800 mhz G4 with a GeForce 4 MX.)
It is in this context that I say: if your framerate is low, be sure to turn the new stuff off! I did some extensive benchmarking of X-Plane 850 vs 840 and can tell you four things that very much affect framerate:
- Cars on the roads! Cars really kill framerate. 840 has no cars, so it wasn’t doing any of that work. Turn them off!
- Birds! 840 had no birds, and they represent more drawing. Birds really divide machines into the haves and have-not’s…big machines don’t even notice the cost, but if you are having framerate issues, turn them off.
- Textured lights with 3-d frames. This is one of the bigger hits. I will comment on this more below, but if you’re fighting for framerate, turn this off.
- Water reflections and shadows. This isn’t the perfect setting, because it requires turning off cloud shadows as well as water reflections, so try it last; water reflections are actually not that expensive but you may get a few fps back.
In my benchmarking my dual 1.8 ghz G5 with Radeon 9600 XT (this machine is significantlty slower than a new DuoCore MacBook Pro by the way, so this machine represents a lower performance point than ANY new hardware that anyone should buy for X-Plane) I found that with these 4 settings off (and the equivalent textured lights and water reflections off in 840) X-Plane 8.50 was consistently faster than 8.40. Turning on water reflections and textured lights (but not the 3-d cars and birds) makes 8.50 slower than 8.40 but only slightly.
A final note on textured lights with 3-d frames: there are two catagories of graphics cards:
- Graphics cards with pixel shaders. On these cards, if you turn off 3-d textured lights, we will still draw them with textures, because the card handles it, so you’re not losing any framerate for the nicer looking lights.
- Graphics cards without pixel shaders. On these cards, textured lights are done with the CPU, just like in 840. They’re slow, so they are turned off.
My point is this: the checkbox gives you the best look when on, and the best look while prioritizing for speed when off. So if your framerate is low, turn off the 3-d textured lights; we will give you any quality that we can give you for free and nothing more.
In summary: you can’t have a full bottle of wine and a drunken wife. If you want the new eye candy that was not present in the previous version of the sim (3-d birds, 3-d cars, water reflections and 3-d lights) you will have to pay for them with fps. We can give you the choice of fps or more eye candy, but not both.
A final thought: is it possible that 850 has a performance bug? Maybe! I am analyzing this now. I will post detailed instructions in my next blog entry on how to report these things. Filing a bug saying “the framerate sucks” doesn’t provide useful information; posting to a forum saying “the framerate sucks” doesn’t provide useful information either. But there are some tests you can do that will provide us with the info we need. Our biggest limitation is: we don’t have one of each kind of graphics card. So the 850 beta testers who have gotten us detailed performance numbers have been very helpful!
I just realized that the planet-wide rendering was running at 65 fps on my G5 with clear skies but less than 20 fps with a single cirrus layer! Ooops! With X-Plane 850 we use the same OpenGL code to draw terrain whether it’s close-up (DSF) or far away (the planet render). This seemed like a good idea because it helped the two mesh. Well, it turns out cloud shadows are way too slow when applied over a huge area.
So…I simply killed them. This will be in the next beta. If you look hard you’ll be able to see a slight color change (well, worse than before) where the cloud shadows disappear at the DSF->planet transtion, but the fps are worth it. The G5 went from less than 20 fps looking at the planet to 65 fps, and the MacBook Pro went from 36 fps to 100 fps.
This was never an issue in 840, where the planet had the simplest OpenGL code you can imagine and looked like, well, just compare the planet in 840 vs 850!
Anyway, this explains why I thought I’d fixed the planet code and users cried bloody murder: my standard framerate test has no weather, because that’s Austin’s code. (Hence I shut it off to check the performance of only my code.) But sure enough it was the weather that affected the “cost” of the planet render.
There is a moral here for programmers: always test performance under real-world conditions! Often a system can have interdependencies that don’t appear in “lab” conditions. (Another example: you can’t test the speed of airpor build-up without scenery because one of the slowest parts is “draping” the airports over the scenery. When there is no scenery the ocean terrain triangles are very large and so the draping happens much faster than it can with real ground.)
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.
