When it comes to video cards, I’ve always been in the “don’t spend more than $200” school of thought. My logic is: video card technology moves so fast that paying a lot of money for the “first six months” of any new technology level is very expensive. Bless all of you who are early adopters – you’re helping keep nVidia and ATI humming, but it’s an expensive hobby to main an up-to-date machine.
This is one of my favorite tables (there is a similar one on Wikipedia for ATI). It shows performance of graphics cards and when they came out. Compare the GeForce 7950 GT2 and the GeForce 8800 GTS. If you want 24,000 MT/S of fill rate, you could buy a top-of-the-line two-cards-in-one-via-SLI 7950, but if you waited six months, a SINGLE intermediate-speed 8800 would give you the same thing while supporting DX10 shaders (e.g. geometry shaders, instancing, and all that awesome stuff). The 7950 GT2 apparently retailed at $600+, which was a real discount compared to actually chaining two separate 7950’s together (that’d get you up around $850). Look on newegg.com and you’ll see that GeForce 8800 prices aren’t that expensive (compared to an SLI combination). And the 7950 GT2’s come down a lot from what it used to cost.
For another datapoint, compare the Geforce 7600’s to the GeForce 6800’s. The 6800 was the monster card when it came out, putting nVidia back in the number one spot. But the next-generation’s intermediate range cards can do what was top-end before. (The 7600 can be had for a little over $100. Compare that to several hundred for the 6800 ultra about one year earlier.)
Simply put, you pay a huge premium to get a given performance level when it’s new and top-end. Wait one generation of cards (by buying last-year’s top end cards or this-year’s middle-range cards) and you save a lot.
It’s in this context that I don’t believe that SLI makes a lot of sense. In an environment where (IMO, and my opinion only) the top-end video cards are already expensive for what they do, SLI simply makes the situation worse, by allowing you to spend double what the already-high-end cards cost to get performance that will be available in one card in the next generation.
To do the math, does it make sense to spend double the price on your video card to extend its useful life by six months? Only if you intend to change cards every six months.
(nVidia makes an argument that SLI allows developers to preview the next-gen hardware, and this is true. My strategy is different: simply run X-Plane slowly and assume that the next-generation hardware will go faster.)
I don’t feel good about criticizing nVidia and ATI because overall I feel that their products provide an extraordinary value at a very good price, and the growth of performance in video cards has been astounding. Todays cards just hit it out of the park.
But to me SLI and CrossFire strikes me as a solution looking for a problem. They solve the problem of making the most expensive cards more expensive, but I don’t think they’re the best way to spend money on a flight simulation system. (Better might be to not buy at the “SLI/Crossfire” level of video cards, meaning spending $700+ on your video cards, but rather to go down a level and upgrade your motherboard/CPU more frequently.)
Some users email me asking for video card recommendations, in particular whether to buy an SLI/Crossfire configuration. The bottom line is, it depends on how much you value your money vs. your graphics card performance. If money is on object, and you want maximum speed, SLI configurations will provide the fastest performance (by some marginal amount). I believe that a good value lies below $200.
On the other side of the equation, I do recommend that everyone spend at least $100 if you’re going to buy a video card at all. Below $100 the price cuts come from remaindering really old inventory and removing parts from the card to save cost. For the savings of $25 you might lose half your card’s performance or half of its VRAM when you get down to the really cheap cards.
The other thing I tell users is the truth: no one at Laminar Research has an SLI system, so the reports we get on SLI come from users. Some users have told us they’ve gotten some benefit at very high FSAA levels. But at this point a single 8800 wll do the same thing. And SLI doesn’t address CPU speed at all. Consider this list of features – nothing on the CPU side will get even remotely faster with SLI.
And in full disclosure: my two Macs have a Radeon X1600 Mobility, a Radeon 9600, and a GeForce 5200 FX sits on the shelf for testing purposes. (This isn’t intentional bias toward ATI, it’s what Apple ships.)
A few days ago, Austin posted part of an, um, “animated” discussion between himself and an author regarding blade-theory vs. table-based flight models. (You can find it on the xplane-news yahoo group message archive.)
I’d like to ignore the whole “my flight model can beat up your flight model” thread and look at one of the side effects of physics vs. table based flight models.
In this previous post I commented on the nature of specifications in a flight simulator.
– Some data simulates real-world data. (“Reality-based”) The sim has open authority to interpret this data for maximum “quality” and the standard is “how close to reality are we”. The specification clearly sites reality as the authority on behavior.
– Some data is arbitrary and has a clearly defined interpretation. (“Specification based”.) The behavior of the computer program is unambiguous.
What I find interesting is that a blade theory flight model is a “reality-based” flight model; a table-based flight model is a “specification-based” flight model.
What this means is that, just like reality-based specifications in the scenery system, you can’t tune your flight model in X-Plane to achieve a desired end result without understanding the real-world meaning of the parameters you are changing, or you risk a compatibility problem with future versions of X-Plane.
Imagine that, for some reason, your plane seems to feel sluggish when turning. So you increase the area of the control surfaces and the problem goes away.
You can’t do that with X-Plane’s flight model! The area of the control surfaces mean something other than “a variable you can change to affect how the plane turns”. They have to match how the real-life airplane is built. If you increase the area, straying from reality, to “fix” a problem, what really happens is you create a new problem later when X-Plane goes to simulate your model.
Simply put, if you put intentional errors into your plane’s flight model to compensate for limitations to the sim, any improvement in the simulation accuracy of X-Plane is almost guaranteed to make your plane fly worse in the future.
So one of the important differences between a table vs. blade-theory flight model is how you talk about “bugs”. If your plane doesn’t fly the way it used to in a table-based flight model, that’s probably a bug (well, depending on how interpolation is done). In a blade-theory model it’s not a bug per se.
In a table-based flight model, how the real plane flies is moot – the table is king. In a blade-theory flight model, if the real plane flies differently and the input parameters of the plane are the same, it is a bug, or perhaps a design limitation.
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.
I just finished an example scenery package that shows how to place orthophotos using .polygon files. Check out the scenery website (look under tutorials) to download the package and also read the illustrations. (This is an experiment: this is more of an annotated scenery example tha a true step-by-step tutorial.)
The basic anatomy of an orthophoto-in-a-polygon is:
- A PNG file contains the orthophoto. (In the case of our example, ksbd_alpha.png.)
- A .pol file references the PNG file and defines the physical properties and layering information. (In the case of our example, ksbd.pol.)
- An overlay DSF references the .pol file. (In our case this is +34-118.dsf.)
- The DSF overlay contains exactly one usage of the .pol file, with a polygon parameter of 65535 (a flag to indicate that texture coordinates are in the DSF) and each vertex of the polygon contains texture ST coordinates.
This pattern is actually the same design pattern that is used everywhere in the X-Plane scenery system:
- PNG files are never used directly by DSFs, they are always referenced by some kind of “definition” file, like an OBJ, .pol, .ter. Sometimes the definition file has a lot of info (like an OBJ, which contains a 3-d model), and sometimes they just contain some basic attributes (like a .ter or .pol file, which contain info for the physics engine).
- The artwork definitions are always separate from the DSF, so that they can be reused easily in a lot of DSFs.
- The DSF says where the polygon goes and the .pol file says what it looks like, just like the DSF says where an object goes and the OBJ says what it looks like.
One decision I made early on in my work on the scenery system was to stop using “magic file names”. Prior to X-Plane 8, in a number of cases it was enough to add _LIT to the end of a texture file and a lighting mask would appear. In all modern file scenery format, there is a texture command (usually TEXTURE_LIT) to add this information.
Now this is probably more confusing to new users, and certainly a little bit confusing to anyone who was used to X-Plane 7. To some extent my goal is to have most scenery files be generated automatically – we’re still a long way away from that, so my decisions to prefer extensibility to ease-of-use in the low level formats cause problemes for now. (But try the new AC3D X-Plane plugin version 3.0 – with UI to edit all X-Plane properties, does it matter anymore whether OBJ8 files are easy to read? We now have a real UI for editing X-Plane specific properties.)
In the case of file formats my concern was extensibility. There are only so many “tricks” that we can possibly cram into a file name, and the more we try to make the file name do, the less simple it becomes. When textures can only be “lit”, tagging _LIT on the end is simple, and haivng to add TEXTURE_LIT can be annoying. But since then we’ve also added layering information and physics information. Imagine ksbd_LIT_AIRPORTS_-1_GRASS.png. Now we’re getting into the domain of confusing file names.
Take a look here at some of the things we’d like to someday do for textures…seasonal textures would really make the texture names crazy. (MSFS9 accomplishes this using four seasons, which keeps the names simple…but what if we want to customize the time range for seasons?)
And dataref-controlled textures? Well, you can’t encode a dataref in a file name – the / is reserved!
So all of these text files (.OBJ, .pol, .for, .ter, etc.) provide extensibility – they let us add new features to the way that DSF content is viewed without requiring cahnges to the DSF file format itself.
Since this blog post has gone off into a philosophical rant and the real info is in the tutorial, let me drift totally off subject by mentioning that while you’re looking at tutorials, take a look at Kriss’s tutorial on OBJ8 animation using the new AC3D plugin. If you’ve tried using the old system of animation (by typing cryptic goo into the AC3D object naes) you’ll find the new plugin will let you work a lot faster!
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!
Sergio and I were discussing the future of facades today. Facades are DSF polygons that are extruded into buildings by pushing up the polygon into a roof and texturing the roof and walls from a single texture using some simple formulas. The rules for facades are very simple – we originally thought them up for the purpose of creating buildings that precisely fit a city grid no matter what the block spacing.
The problem with facades is that the rules make very simple buildings – especially the roofs. So we want more powerful facades and the question becomes: how best to do this? There are two possibilities and I mention them here because they underscore what I think is the largest overarching design decision when creating a flight simulator scenery system.
1. We could make the facade builder in X-Plane smarter (write new rules).
2. We could write a stand-alone tool that converts the DSF polygons (plus a rule file) into OBJs that are then placed directly into the overlay.
This second strategy would turn the facade from a type of scenery element into a tool for making OBJs. We would be “pre-compiling” our facades.
Here are some of the considerations:
SPACE VS SPEED
Precompiling primitives is a space-vs-speed trade-off. For any given algorithm, it’s usually faster to pre-build the entities and load them from disk than to build them in the sim. But pre-building means more files on disk, meaning bigger downloads, more DVDs, etc. Building up buildings from facades inside X-Plane is actually a form of compression.
EASE OF DEVELOPMENT
This is one criteria where I think pre-compiling scenery is a clear win: it’s easier to build a stand-alone facade-to-OBJ converter than to implement it inside X-Plane. X-Plane is a relatively unfriendly place to build scenery algorithms because it’s busy being a flight sim.
STABILITY VS UPGRADABILITY
If we make OBJs out of facades using a tool, the objects will look the same even if we create a new version of the tool. This is good in that it means that custom scenery won’t change how it looks, but it is also a limitation because improvements to facade technology require rebuilding a lot of objects to take effect.
(Another aspect of this: if the objects made from the tool use a texture, that texture can’t have its shape changed even if we make new rules, because some objects will be on users machines that were built with the old rules.)
X-Plane mostly errs on the side of pre-building scenery, and this is the one area where we really take it on the chin for that decision: the inability to easily create a new composite look from changes to some parts of the scenery. (Airports that don’t cause grass to appear under them is an example of this.)
Perhaps some good questions for weighing these options are:
1. Would an author care whether the facade looks exactly the same in the future?
2. Are there enhancements coming along in this technological area that we would not want to miss out on for older scenery?
OTHER CONSIDERATIONS
Information loss: when we turn a facade into an object, the original polygon information is lost. Is it important that we ship the actual base polygons that make up buildings, or are the OBJs that represent them good enough?
Contextual Information: often we know more about a given situation when making scenery than when displaying it. Could we do better at building up a facade inside the sim (where we have context from other scenery packages), or when creating the sim (where we have a much larger dataset)?
For a while we’ve been getting the rare report from a user that our installer won’t download – usually it dies mid-download on a given file.
(Our servers transfer a complete 600 MB demo copy of X-Plane once every 8 minutes, all the time. So if we get a report of a problem from one isolated user, it’s almost always specific to the user. Systemic problems like a bad server generate a ton of email.)
One user stuck with us through some via-email debugging and we finally figured out one of the causes of failed downloads: popup blockers!
The X-Plane installer is built around simple off-the-shelf technology where possible. In particular, files are zipped and sent via http. This means we’re using openly available existing standards, and we get to leverage free code. (The biggest win is being able to use “plain old apache” for serving the installer.)
To the operating system and any firewalls involved, the X-Plane installer doesn’t look that different from a web browser. It goes to a web server and requests a big pile of files, a few at a time.
It turns out some popup blockers will detect patterns in URLs and automatically substitute the web content! So we go out asking for an object called com_120_60_1.obj.zip and the popup blocker decides that (perhaps because it’s a zip file and has 120_60 in it) the file shouldn’t be made available. It substitutes a 1-pixel black GIF file that the browser can show inconspicuously..
Of course, that one-pixel black file doesn’t look anything like a zip file – when our installer gets it, the installer has a fit.
This bug was a mystery before – what would cause our servers to send just one user a tiny GIF file, and only in one case. Now that we know that the software is designed to zap web advertising, it makes perfect sense.
I’ve been meaning to write this blog entry for about a year now. X-Plane 8 allows the airport surface area to be sloped. Here’s some of the back story and details.
Back when Austin and I were doing the design work for teh X-Plane 8 scenery system, we made a decision to allow sloped runways. The issue is that flattening the airport area requires the sim to edit the mesh on the fly, something we wanted to avoid.
(X-Plane’s scenery system is based on removing the editing of scenery from the sim itself…”X-Plane is not a GIS”. I did some slides on this once, I’ll try to post them soon.)
Instead we decided to simply drape the airports over the terrain, no matter how it was built. We figured that the sim’s engine could handle this (as it turned out, there were bugs that were fixed in the 8.20 patch) and in real life runways are often quite sloped!
Unfortunately when theory meets practice, things can get ugly…the biggest problem we saw was that in the original set of DSFs, the underlying terrain was very bumpy, and the smoothness requirements for a plane to take off are very high. (Flattening is also necessary to match the ground height with other sims for online flight.)
So we retrofitted the X-Plane engine with terrain flattening for airports. The flattening engine is meant as a last resort, to get absolute flatness and repair an already-flattened DSF. Its goal is not visual quality, but rather speed — that is, we can’t take 10 minutes analyzing the DSF each time we load one, or the sim will freeze pretty badly. (If this requirement that the flattener be fast ever goes away, we could do a much nicer job of flattening.)
The current flattening engine has two unfortunate properties designed to keep it fast:
– It flattens an area that is larger than the airport surface area (it rounds up) and
– It flattens vertices that are in the flattening area, not whole triangles.
The first limitation means that it may crush mountains around the airport, and is not appropriate for airports that are embedded in complex, hilly terrain.
The second limitation needs more examination. If a mesh triangle is partly inside the flattening area and partly outside, then the triangle is not flattened – one vertex is moved, and the others aren’t, which cause it to be sloped.
In these pictures, the blue lights represent the airport area perimeter, but the red lights show the full area that is flattened. I have artificially set the airport elevation much higher than surrounding terrain, to make the flattening obvious. Notice how some triangles become highly sloped!
When we make the global base scenery, we use the default airports from Robin’s database. So even if you do not want to submit your custom airport layout to Robin’s database, consider submitting some kind of layout to Robin. If an airport is present in the default scenery, then the area will be pre-flattened, which makes the sim’s flattening both work better and maybe even unnecessary.
Also, you can use the 130 code in a custom airport area to increase the airport boundaries, increasing the amount of flattening. But this is a mixed blessing – as you can see the mechanism is very imprecise. If you do use a 130 code in a layout and you submit the layout to Robin, please remove any 130 boundaries that have been set to a large area to flatten an airport.
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.
