I can’t say enough good things about Jonathan Harris (Marginal) — his work on X-Plane has been fantastic, he is one of the most advanced third party scenery authors I know of, and when he sends us a bug report, it is usually so perfectly patched up that I’m looking at the bad line of code in minutes! (One of these days I’ll post one of his bug reports — he always isolates the bug in a simple package that makes it very clear, with no extra “stuff”.)
He emailed me a while ago with some questions about layer groups, and I saved them to rewrite into a blog entry. A little bit of background:
X-Plane 850 and 860 introduce the concept of “layer groups”, which provide a way to control the draw order of scenery to some extent. Objects naturally fall into a layer group based on their type (e.g. objects go into the “object” layer group by default, and runways always go into the runway layer group). However, some scenery elements let you customize their layer-group placement in two ways:
- By changing which layer group the element goes to entirely, or
- By providing a “bias number”, which indicates that within the catagory of scenery elements, this one must be drawn early or late.
Layer groups let you do a number of useful things:
- Make sure that polygons and objects are drawn under runways or over taxiways when needed.
- Make sure that runway markings with polygon offset are drawn before 3-d objects.
Simply changing the order of objects in the DSF is not a reliable way to control draw order! Layer groups are. You can read about layer groups in the OBJ8 spec.
With that in mind, some Q and A. (I will elaborate on my answers from what I originally sent Jonathan.)
J: I assume that objects and polygons within a single layer can be drawn in any order – ie there’s no defined drawing order between different scenery types.
B: You assume correctly! Within a layer group, X-plane is free to reorder to improve fps. So you cannot rely on the draw order of any two scenery elements without assuring that they are in different layer groups, either by using different group names, or different relative offsets.
J: But is there are defined drawing order between objects/polygons and apt.dat-generated scenery?
B: Yes because airport scenery goes into specific layer groups! (In fact, all scenery has a “default” layer it goes into, and they usually vary by type of scenery element.)
J: eg if I have an object or polygon with ATTR_layer_group runways 0 will it be guaranteed to be drawn after the runway?
B: You’re close. The runways go into the runways group so
ATTR_layer_group runways -1
will always be before runways and
ATTR_layer_group runways 1
will always be after.
ATTR_layer_group runways 0
is the default layer group for runways, so your object or polygon would be in the layer group with all of the other runways, and X-Plane would be free to change the order amongst your object and runways in any way that would optimize framerate.
J: If not, is there any other way to insert objects and/or polygons between the taxiways and the runways?
B: The numeric offset is provided for this. The “spacing” of the layer group numbers is such that you can have up to 5 groups before and after each “named” group. So anything from runways -5 to runways +5 is fair game. (In other words, you can separately control up to 5 different “layers” of elements with a well-defined order for any layer group name.)
If your X-Plane is framerate low, or you want to increase your rendering quality, you might think “time for a new graphcis card But is it?
Some rendering settings actually tax the CPU more than the GPU (graphics card). Here’s a simple rule of thumb: if you increase the setting (and restart X-Plane) and your frame-rate does not go down, a new graphics card isn’t going to make it go up!
For example, if you have one of those new-fangled GeForce 8800s, you may have noticed that when you turn on FSAA the framerate doesn’t dip at all. That’s because the 8800 is insanely overpowered for X-Plane (at normal monitor resolutions) and has plenty of extra capacity that will be sitting idle on an older PC. When you turn up FSAA, you are simply wasting less of the card’s excess capacity. It goes without saying that if there were a card faster than the 8800, it wouldn’t improve your fps any more than the 8800, it would simply be even more bored.
Here’s a rough guide to which features tax the CPU vs GPU:
CPU-Intensive
- World Level of Detail
- Number of Objects
- Draw Cars On Roads
- Draw Birds (not that expensive for modern machines)
- Draw Hi Detail World
- World Field Of View (wider view means more CPU work!)
GPU-Intensive
- Texture Resolution (requires more VRAM)
- Screen Resolution
- Full Screen Anti-Aliasing (FSAA)
- Anisotropic Filtering (most cards can do at least 4x)
- Draw Hi-Res Planet Textures From Orbit
- Cloud Shadows and Reflections (not that expensive)
- Draw Hi Detailed World
A few specific framerate-optimization warnings:
- FSAA is equivalent to a higher screen resolution – that is, running at 2048×2048 and no FSA is similar to running at 1024×1024 and 4x FSAA. Both of these tax the video card with virtually no CPU increase. This is probably the only setting that can be helped only with a video-card upgrade.
- Texture resolution: do not worry if the total size of all textures loaded is larger than the VRAM of your card. To find out if more VRAM would help, measure frame-rate with your normal settings, with texture resolution down a notch, and with anisotropic filtering down a notch. If turning texture resolution down increases fps more than turning down anisotropic filtering, more VRAM may help. Machines with faster graphics busses (like PCIe x16) will be less sensitive to VRAM.
- Most Important: do not ever turn “World Detail Distance” beyond the default setting – you will simply destroy your fps and chew up your CPU for no benefit. I strongly recommend trying “low” for this setting – if you like a lot of objects, this setting can make a big difference in performance.
- The number of objects is virtually always a factor of how fast your CPU is, not your GPU — that is, most GPUs can draw about a gajillion objects if the CPU could only get through them fast enough. If you are unhappy with the number of objects you can draw, do not expect a new graphics card to help – it probably won’t.
- Cars on roads hurt fps on machines that don’t have the fastest CPU.
- Draw Hi detail World is doubly dangerous – it uses both the CPU and GPU. Quite literally this is where we stash “luxurious” options. Everything this checkbox does chews up framerate. (If these options didn’t, we’d leave them on all the time!) So you should not use this option if you aren’t happy with fps, if you don’t have a fast CPU, or if your graphics card isn’t that modern. (HINT: if your nVidia card has “FX” in the title, don’t use this!)
Start with the default settings and experiment – turn a setting up one notch, then restart, then turn it down and try another. Different machines will be faster for some things and slower for others.
EDIT: one user correctly determined (by observing CPU utilization relative to settings) that puff-style 3-d clouds bottleneck the GPU, not the CPU! This was not what I expected – when Austin originally wrote that code, our measurement indicating that sorting the puffs from far to near taxed the CPU a lot, making this CPU-intesive. At the time the old Rage 128s would also get bogged down by filling in translucent puffs as you flew right into the thick of the cloud.
Times have changed and neither the sorting nor the alpha-drawing is even remotely expensive on a modern machine. So I was surprised to see the CPU not being used. After some investigation, it turns out that while the CPU and GPU have gotten a lot faster over time, the communciations channel between them has not. The result is that they both do their jobs really quickly, and as a result clog up the communications channel…the CPU simply can’t talk to the GPU fast enough to get the clouds out.
This is a great find by this user, as this is something that didn’t matter on old machines, but can be optimized in the future for new ones.
If you have a dual core Intel Mac, OS X 10.4.9, X-Plane 8.60 and an Intel Graphics chip, try running the sim with this command-line option:
–use_threaded_ogl
You can read about how to use X-Plane with command-line options here.
This series of posts will discuss how the LOD system works for objects. Understanding LOD is very important for tuning the performance of custom scenery that uses either very complex objects, or a very large number of objects.
Authors View vs. X-Plane’s View
A “level of detail” for an object is a complete representation of the model with complexity changed to fit a viewing distance. In other words, LODs are copies of your objects, some of which have been simplified so they will draw faster when far away.
Each LOD for an object contains a viewing range, indicating for which range it is appropriate to use this LOD.
An X-Plane object can have LOD information, via the ATTR_LOD attribute. If it does, it may have one or more “LODs” – that is, separate representations of the same object.
If an X-Plane object has no ATTR_LOD command, X-Plane turns the entire object into one LOD by automatically calculating the viewing range based on the size of the object. (I’ll discuss this in more detail in later posts.)
This last point is important because it means that, to X-Plane, every object has at least one LOD. If an LOD is not provided by the author, one is created!
Picking an LOD
When X-Plane draws an object, it measures roughly how far away it is and picks the LOD within the object to draw. This can save some frame-rate but isn’t a cure-all.
– The cost of animation and attributes is based on the LOD drawn. So if you have an object with a lot of animation that is not visible a long way away, using a second, simpler LOD with no animation will help framerate because X-Plane won’t evaluate the animation when the complex LOD is not drawn.
– The cost of moving the texture to the graphics card is incurred no matter what LOD is picked, so you don’t save on “working set” (that is, the effective amount of VRAM X-Plane needs) with LOD. If your object has a huge texture, you pay that cost any time it is drawn.
– The cost of the number of triangles in the model is partly saved by using a simpler LOD, but it is partly global to the entire object. The problem is that all of the geometry coordinate data for objects is kept together in one giant glob. So when the tiny simple version of your model is being drawn, X-Plane may be shoveling the complex version to the card anyway.
This last point is important: making more LODs may actually increase the total amount of geometry data and make performance worse. Therefore while it may help a lot to have a second LOD that is much simpler, having 10 LODs, each slightly simpler than the last will probably hurt performance. Be sure to try your objects on a computer that doesn’t have a lot of free VRAM to see the effect of more LOD!
Don’t Draw That Object
While you can save some frame-rate by having X-Plane draw a simpler LOD, the true power of the LOD system happens when an object is so far away that none of the LODs apply. For example, if my object has 3 LODs from range 0-1000 meters, 1000-3000 meters, and 3000-6000 meters, then once the object is over 6 km away, X-Plane simply doesn’t draw it at all!
Not drawing an object is great for framerate. Not only do we save the time on the animations and attributes, but X-Plane never has to process the texture or geometry data, and that’s where the real framerate win comes from. Therefore the most important question for object LODs is “what is the maximum LOD” – that is, what is the farthest distance before X-Plane can stop drawing your object. X-Plane is pretty efficient at recognizing cases where objects, or even whole classes of objects, are simply too far away to draw.
(Consider the runway lights with the new “high detail world” setting…X-Plane places an object for every single runway/taxiway light, of which there are almost 10,000 at Chicago O’hare. But since the maximum LOD for these tiny objects is only 500m, X-Plane then eliminates the vast majority of the objects very early on and doesn’t bother to draw them, keeping framerate up.)
To draw a stupid analogy: the shorter the grocery list, the quicker your shopping. But if your grocery list has NO items and is totally EMPTY, you don’t even have to drive to the store, which really saves you time.
In the next part I will discuss world level of detail and maximum LOD didstances.
With the new version of DSF2Text and X-Plane 8.60 it is possible to overlay orthophotos on top of DSFs. I’ll get into this in more detail in a future blog post…the purpose of this post is to be a wet blanket.
Using polygons to overlay orthophotos on the base mesh might seem perfect. It’s easy to do and you can clip polygons to any shape. Perfect, right?
WRONG!!!!
There are a few major problems with overlay polygons that make them well suited to some cases but not a general purpose cure-all for orthophoto-based scenery. Here’s the fine print:
- Orthophoto polygons draw over the base mesh. In particular the base mesh is still drawn underneath the orthophoto. This means that wherever you use them, X-Plane is drawing twice! This is bad for performance…it will cut the speed of mesh drawing in half. Ouch! (This is not an issue when working on very small areas like airports, but it is an issue when working on very large areas.)
- Polygons are not built up until you fly near them. Polygons are part of the 3-d “clutter” part of the scenery not the base mesh, so we defer building them until we get near them to save memory. (This is the same as airports – look at an airport in textured map mode when far away from it — no taxiways!) But this means that if the orthophoto is huge (and thus visible far away) its absense will be quite obvious.
- Polygons burn CPU time when they are built up. For very small polygons this isn’t that noticable, but the larger the polygon, the more work X-Plane does “draping” it over the base terrain. So on single-CPU systems with large polygon orthophotos, the framerate may be adversely impacted.
Basically overlay polygons are great for texturing small areas like airports or special landmarks within a city, but are not appropriate for making wide-scale orthophoto base meshes. For that you really need to replace the base mesh DSF!
With X-Plane 860, we now mark the X-Plane executable as being capable of using 3 GB of virtual memory on Windows. This means that if your copy of Windows can support large address spaces and you have a powerful enough PC, you can now use more add-ons. (Mac and Linux have always gone to 3 GB by default.)
You can read more about setting Windows up to handle large address spaces here. Please don’t try this if you don’t know what you’re doing, and please don’t contact our tech support if you destroy your copy of Windows — we can’t support the whole OS.
Please note that this change does not improve the hardware capabilities of your computer – it only enables X-Plane and Windows to take full advantage of what you have. You will not see a performance boost because of this.
I found the reason for frame-rate loss for Logitech sticks…everything in this entry is Mac specific.
X-Plane has (for a long time) done a rather poor job of parsing the HID descriptors that
the driver provides for USB joysticks on OS X. However it turns out that in the case of Logitech, after we found the 4 axes the joystick usually has (pitch, roll, yaw and throttle) we then went on to misparse a bunch of strange stuff at the end of the stick as more axes. It turns out that reading those axes causing some kind of huge framerate loss. I don’t fully understand this, but given the HID spec I’ve seen I’m not hugely surprised.
Why is this x86-Mac specific? I don’t know! Why is this so much worse in 860? Well, in 860 we raised the number of axes from 6 to 8. With more axis slots, we tried to read more incorrect parts of the logitech stick, for more fps loss.
The solution is one that’s been a long time coming: I’ve rewritten a bit of our Mac HID-parsing code to do a better job of figuring out what’s a joystick element and what’s not.
The bad news is: for the next few betas there may be some broken joysticks. If you have a joystick and it stops working in the next beta, please file a bug and include as much specific info about your joystick as you can.
The good news is: I think we will get almost all of the fps back on x86 Macs – Logitech users will not need to get new sticks.
A side effect is that we should no longer have “dead” slots – that is, buttons and axes that didn’t do anything. This should allow you to use more of your X-52 if you have one.
For X-Plane 860 beta 6 I think we may change the way the airport lights setting works. Since
(despite my previous rantings) there is a lot of discussion of performance based on settings (e.g. “I used to get 40 fps with this menu pick, now I need this other menu pick”) as opposed to based on what the sim is actually doing, allow me to go off in some detail about what’s going on under the hood.
During X-Plane 850 and 860, I tried to fix a number of long-standing “quality” issues, where the sim had small artifacts. There is a fps penalty to fixing these artifacts that I thought was small, but the message is clear:
- Some users are flying X-Plane on lower-end systems and can’t spare a single fp.
- A lot of users really don’t care about the quality issues and would gladly trade back the visual “improvement” (which doesn’t seem like an improvement after living with the issue for 4 years) for those few fps that mean the difference between clear skies and fog.
So…with that in mind, let me explain runway lights for 3 versions of X-Plane.
X-Plane 840 and earlier
In X-Plane 840, lights could be textured or untextured. This was controlled by a simple checkbox “draw textured lights”. A few lights (on the airplane, for example) were always textured because we thought they were few in number and important visually. The rest was decided by the checkbox.
No airport light ever had a 3-d “structure” (e.g. you couldn’t see the light housing and support rod).
No light was ever drawn using hardware acceleration, even if the graphic card had pixel shaders; we simply didn’t have the code. Therefore textured lights ate up a lot of CPU power and thus ate up a lot of framerate. But life was simple!
X-Plane 850
With X-Plane 850 things got a lot weirder.
- We rewrote the lighting engine to optionally use pixel shaders if present. This improves performance of textured lights a lot. In fact, on a given machine with pixel shaders, textured lights with hardware acceleration are faster than non-textured lights without hardware acceleration. (For hardware accelerated lights, the texturing doesn’t cost anything compared to hardware accelerated untextured lights.) It’s important to note this performance fact!
- Sergio created a bunch of 3-d object lighting fixtures for the runway environment. They have a low LOD, but up close you can see the actual lighting structure.
So what to do about that setting? Well, basically with the check box on we did the nicest looking thing, and with the check box off, we did the fastest thing. (The check box’s label doesn’t do a good job of representing this.) We thus have four possibilites:
- Checkbox off, no pixel shaders: we draw untextured lights using software, no objects.
- Checkbox off, with pixel shaders: we draw textured lights using hardware, no objects.
- Checkbox on, no pixel shaders: we draw textured lights using software, with objects.
- Checkbox on, with pixel shaders: we draw textured ilghts using hardware, with objects.
This is plenty confusing if you ask yourself “what is this checkbox going to do” – it depends on your hardware. But the rule is quite simple if you consider the intent: we either give you the fastest (off) or nicest (on) rendering we can.
X-Plane 860
With the next X-Plane 860, we’re going to use this checkbox to control multiple aspects of the sim, but always with two choices: either prioritizing visual quality, or prioritizing framerate.
So this option will not only pick the fastest (or nicest) light code and turn the objects on and off, but it will also, for example, turn on or off per-pixel fog (something that looks nice but is slower than the old per-vertex fog).
I’m not sure everyone will like this, but I think it will meet some important needs:
- It will make it obvious how to set the checkbox. Either you want speed, or quality.
- It keeps the config interface simple for new users.
- It gives us a way to tie in a number of small optimizations that add up when taken in concert.
It seems to me that we’re seeing the haves and have-nots. If you’ve got a Core 2 CPU and a 7000-serise GPU, things like per-pixel fog are chump change. If you’ve got a G4 with a Radeon 9200, you need any speed you can get. So hopefully this change will make the UI clearer and help us meet everyone’s needs.
I think the framerate test may be the best piece of code I’ve ever written for X-Plane. It speeds up my own work checking X-Plane’s performance (and removes the risk of careless error), allows us to easily collect user-based stats, and has changed the dialog on performance in the beta from he-said/she-said (the result of having no precise quantitative measurements) to a fact-based dialog box where we can discover problems more quickly.
Today in a noble sacrifice (using this card is nothing less than torture) I put a GF-FX5200
back in my G5 to look at bugs and performance. (The terrain night lighting and landing lights should be back in all nVidia hardware with shaders in the next beta.) Some things I’ve learned:
Turning off GLSL shaders boosts fps from 46 to 55 fps with my Radeon 9600XT but goes from 22 to 45 fps with the FX5200. From that we can learn:
- The penalty for GLSL shaders is really really high on the FX5200.
- The shader implementation for the FX5200 just doesn’t run at the same speeds we see in R300-based cards…it’s not in the ballpark.
Looking at a profile of the sim, with the FX5200 running shaders, about 50% of the time is spent waiting for the graphics card to chug.
Other things I’ve found:
- GLSL shaders are slower on terrain, but still worth it for runway lights – having those be hardware accelerated is definitely a positive.
- Per-pixel fog doesn’t affect fps on the 9600XT but is a measurable penalty on the FX5200.
- The landing light also hits the FX5200 about 20% – again it’s negligible on the 9600XT.
The moral of the story may be: we need a way to not use shaders for terrain on the FX5200. Between the little things that shaders give us (that we can’t use) that cost too much and the overall lack of performance, GLSL terrain and the FX5200 may not be a good idea.
If you have an FX5200 and OS X 10.3, there may not be any benefit to updating to 10.4 – you’ll have the option of using GLSL shaders but you may not want to.
If you have a G5 and an FX5200 and the option to put a new card in, you may want to consider it – you’ll almost certainly get a fps boost (especially if you use something like an X850).
One user posted this comment in response to my rant on framerate…
“What I wonder in X-Plane and FS2k4 as well is, why there is no better automatic regulation which automatically set object density, object quality and so on based on the current frame rate….”
This is a good idea that has been suggested before. However when I tried it, it worked very poorly for two reasons:
- Because we reduce visibility as well when fps fall, if we also tie object density/distance to framerate, then we have two separate variables responding to framerate. The result was oscillations. Think of framerate and visibility as a (hopefully) dampened oscillator. With two variables, getting the oscilation out is a lot harder.
- the relationship between object density as the sim controls it and framerate is not a static one, because object density (relative to other scenery complexity) varies a huge amount with locale. In the mountains, backing down objects won’t save your framerate. In the city it will. So coding the “spring factor” for that oscillator is very difficult.
That doesn’t mean we won’t try this again in the future – that’s just what happened when I tried my first naive attempt.
Other comments reflected users either hoping for more fps from existing hardware (there’s a lot of that on X-Plane.org) or saying that X-Plane runs well on their modern shiny computer.
Here’s some stats for you:
- Radeon 9200: 1000 MT/sec 6.4 GBi/sec
- GeForce 5200 FX (64-bit version): 1000 MT/sec 2.7 GBi/sec
- Radeon X1950XTX: 10,400 MT/sec and 64 GBi/sec
- GeForce 7900 GTX: 15,600 MT/sec and 51.2 GBi/sec
(These numbers come from Wikipedia – I make no promises.) The first number MT/sec is mega-texels per second and represents how many millions of pixels* the card can fill in. GBi/sec is gigabits per second of data transfer from VRAM to the GPU. Neither of these are perfect predictors of card speed (but they do limit your ability to run with a lot of FSAA) but they do illustrate something:
The difference between the speed of the smallest and biggest graphics cards is over 15x for fill rate and over 25x on memory bandwidth! That’s the equivalent of people trying to run with a 3 ghz and a 120 mhz CPU! Anyone running with a 120 mhz Pentium out there? Definitely not – our minimum CPU requirements are ten times that.
In other words, the high rate of technology improvement in graphics cards has left us with a ridiculously large gap in card performance. (In fact the real gap is a lot worse – the 9200 and 5200FX are not even close to the slowest cards we support, and I haven’t even mentioned the new GeForce 8 series, or pairings of two cards via SLI or Crossfire.)
* Pixel or texel? Technically a texel is a pixel on a texture, at least by some definitions, but perhaps more important is that these numbers indicate fill rate at 1x full-screen anti-aliasing…you would expect them to fill screen pixels at roughly 1/16th the speed at 16x FSAA. This is actually good – it means that FSAA can help “absorb” some of the difference in graphics power, making X-Plane more scalable.
