I was at least as surprised as you will be to discover that…
..when you pop back to your starting location using replay mode, the airport appears (belatedly – see the previous blog entry) almost five times faster if you turn off texture compression!
What the hell?!?! 🙂 It’s almost as if some idiot programmed X-Plane to load scenery five times slower if texture compression is on. Oh wait…that was me.
The problem is: how to balance the importance of keeping the framerate up with the importance of loading airports before you get there? All background work involves stuff we might do in the background (if you enable the rendering setting), maybe on a second core/CPU if you have one, and also some talking to the graphics card. We can only talk to the graphics card between drawing frames* and doing so stops rendering.
It turns out that in X_Plane 8.30 when we developed background loading, I put in the “go 5x slower” option because compressed textures visibly halts the sim as the graphics card stops rendering and compresses each texture. Without this 5x slowdown in background work, flight becomes stuttered and bumpy. The problem is that the 5x slowdown means we’re going through airports at a much slower rate than we should be.
I am working on airport tuning now…there will still be a delay before you see airports if you use instant-replay to move around fast enough (this delay is about the length of time the sim would have spent halted during scenery load but now no longer does) but the responsiveness should be a lot better.
(Here is a discussion of dual-core for Flight Simulator X…tdragger explains the issues well, and I think they apply to any graphics-intensive real-time or near-real-time simulation, so it doesn’t surprise me that both X-Plane and FSX offload similar types of work to extra cores.)
*Newer OpenGL drivers get around this limitation to various extents; we will eventually support this in X-Plane.
Sometimes with X-Plane 850 you may reach your destination airport only to discover that…it’s not there! What’s going on???
Well, in X-Plane 850 3-d scenery is created while you fly. This includes roads, trees, buildings, and most importantly airports. So…if the flight simulator cannot build 3-d scenery as fast as you fly, you may get to the airport and discover and it’s missing. After a while, it will appear. The easiest way to see this is: go to replay mode, so you can easily move a huge distance just by dragging the replay slider. This will “thrash” the 3-d scenery build-up and a bunch of airports will be missing.
There is one exception to the “build-as-you-fly” rule: whenever you do anything that changes the scenery situation from a dialog box, X-Plane says to itself, “well, the user is already not flying, because a dialog box is open…why don’t I take the time now and create all the 3-d scenery nearby”. So when you place an aircraft at an airport, change certain rendering settings, etc. then the sim builds the airport up front and it will always be there.
I do not yet have a fix to the problem of missing airports. For now I recommend that you consider turning down your 3-d scenery; often a lot of roads or objects can cause the sim to get behind in its 3-d work. I am working on making the code more efficient.
Apple has released new iMacs. Previously the iMac was the best X-Plane experience for the dollar among Macintosh hardware offerings. It still is, mostly.
But…the cheapest smallest iMac, at an affordable $999 does not have the kick-ass ATI Radeon X1600 graphics card. Instead it has the, well, ass GMA950 integrated graphics.
If you are looking to buy an iMac and are even going to think about playing X-Plane, buy the more expensive box and get the ATI card. You can’t upgrade iMacs, at least not in any way that I’ve ever heard of, and the GMA950 is never going to perform well.
More importantly, as X-Plane progresses we will take more and more advantage of hardware shaders, and the GMA950 is missing a major set of shaders. So even though the iMac itself is blazingly fast, the video card will simply be unable to show a lot new features.
EDIT FROM 2/19/07: this article mentions some bugs with light visibility from X-Plane 850 betas. These bugs were fixed, and the mechanism of detachment is entirely internal to X-Plane. So please bear in mind when reading this that while this describes the internal engine of X-Plane, you as an author don’t need to DO anything special for lights.
One user reported that the taxiway lights are visible a very long way away from the airport. This is true, but it is probably not a cause for concern. By comparison, the airport beacon has a way of disappearing – hopefully less so in beta 11. Here’s what’s going on:
(When I say “light” in this blog post, I mean the little ball of color that is supposed to simulate the look of a light bulb. “Fixture” refers to the 3-d object modeling the real-world device that holds that bulb in place. The actual rays of light cast are not simulated – that’s why the approach lights don’t illuminate part of the plane no matter where you fly. Current graphics hardware just doesn’t give us that ability yet.)
In X-Plane 850 all “lights” are made via OBJ8 objects. The OBJ8 object may contain both 3-d geomemtry that forms the fixture, and one or more “lights”, created via either the LIGHT_NAMED or LIGHT_CUSTOM command. Objects may also have multiple versions based on LOD. If you don’t use ATTR_LOD, a single LOD range is assigned by X-Plane based on how big your object is. (Bigger objects will need to be visible farther away.)
Now here’s where it gets weird. Some of the lights in an object are “detached” by X-Plane from the OBJ and stored separately in the scenery. We do this for performance – the detached lights can be fed to the graphics card via a different mechanism that is much faster than regular OBJ drawing. One of the effects of light detachment is that the detached lights are no longer limited by the LOD of the object. They instead are drawn to much further distances. The fixtures of the objects, however, are never detached…thus some of the airport light OBJs in X-Plane are only visible to 500 meters. We can get away with such a low distance because the light bulb itself is detached and will remain visible.
So which lights are detached? Well, it depends on a number of factors – lights are only detached if they are not subject to animation and they are simple enough to be drawn in bulk. Which lights are these? It’s hard to predict.
So the airport beacon and taxiway light work differently; the taxiway lights are very simple and are detached – hence they are visible a long way away. The airport beacon lights are animated (the light bulbs rotate with the fixture), and are never detached. Thus the airport beacon is subject to LOD constraints and taxiway lights are not.
If you set the world level of detail setting to “low” or “very low” it simply reduces the LOD ranges of all objects. Thus on “very low” the airport beacon may be seen to disappear before the (detached) taxiway lights. For beta 11 I have tried to set the airport beacon LOD large to be enough that even on such low settings the beacon will be visible farther away.
There is one more piece to the puzzle: all lights become dimmer with distance. So in theory our hope is that the lights will become fully dim due to distance before we stop drawing them with LOD, producing a gradual fade-out rather than a sudden disappearance. But if we don’t tune all of these parameters right, lights can randomly appear to disappear in the distance instantaniously.
If there’s a moral of the story, I’m not sure what it is, except perhaps: this new light system is very new, and I am sure our artists will tune it a bit over the next few versions of X-Plane, helping to hide these implementation artifacts.
I just moved into a new house…comcast shows up on Monday (in theory) so until then I won’t be posting much or answering email, but a quick note on 850:
The new extensions to the apt.dat format for 850 are not considered final until we go “RC” (releae candidate). So…
…if you are experienting with 850, please expect to have to update your work during beta. If you don’t want to change your work please wait until we are RC!
…if you are trying other people’s 850 experiments, they may not work if they haven’t been updated to the latest X-Plane.
The beta period is definitely experimental. Once we go RC, we’ll freeze the format so that third parties can make scenery.
Continuing the thread of hardware and how the market doesn’t always provide the machines we want…let’s look at Windows.
We’ve hit a point that people have been saying would come for years: computers aren’t getting faster – they’re getting cheaper. Technically computers are getting faster, but there are now ultra-low-end Windows machines that aren’t much better than what you could get a few years ago. But they are so cheap!
Consider a quick visit to Dell’s website. Their cheapest low-end machine is less than $300 with monitor! Insane! It’s not much of a machine to a flight-simmer, but it is a 2.5 ghz machine with 256 MB of RAM and an 80 GB hard drive. Put a cheap RAM chip in and that’s basically what I got as my flight sim machine a few years ago.
The problem is – to get the price down, the machine’s had the parts totally stripped out of it. The graphics are going to be an embedded chipset, probably Intel’s, and they’re not going to be usable for games. Want a PCIe 16x slot? (Accept no less for a flight simulation machine these days?) I couldn’t find a Dell with one of these for less than $650!
Perhaps this makes sense – consider what my MacBook Pro is doing right now and how much of its CPU capacity is used:
– Email: 15%
– Word processing with real-time spell-check: 6%
– Surfing the web: 10-40%
Of course if I go launch X-Plane…
So if I was really talented and could do all three of these things at once, my computer would still be overqualified! For the average person, the sub-$300 computer is just great. It does what they need and is becoming very affordable.
Where things get tricky is when one of those users wants to try X-Plane for the first time. In order to get the price down to $300 Dell has had to cut to the bone on all components. So what we’re seeing from users who have new machines is the have’s and the have-not’s.
The haves have new motherboards with fast memory controllers, large caches, dual core chips, and 16x graphics slots – the card in that slot is usually a monster. (Even last generation’s mid-range cards like the 6600GT were very powerful by X-Plane’s requirements.) The have-not’s have a machine with integrated graphics and no slot to replace them with, very little cache and slower memory controllers.
There isn’t really a point to this blog entry…the market is just meeting people’s needs. A summary of my observation is: where a rising tide of technology lifted all computers a few years ago, that push is now lowering price instead. As a result, many users have machines that are not way overpowered for their day-to-day work and are thus underpowered when they discover flight simulation.
As I catch up on Steve Jobs’ keynote for WWDC 2006 (where they announced the new quad Intel Mac Pros) it occurs to me that there’s a missing slot in Apple’s product line that makes things tricky for X-Plane users.
At this point I wouldn’t say that Apple is expensive (they’re not cheap, but the internal components aren’t cheap either). The problem is finding what you want.
The MacBook and Mac Mini are reasonably affordable, reasonably fast (now that they’re Intel-based) and do most things that users want. But both have Intel graphics chips, which make them hopelessly underpowered in the graphics department for X-Plane.
The MacBook Pro and Mac Pro come with great graphics chips and are great high-end products, but clocking in at over $2,000 they’re outside the ballpark of what most people will pay for a home computer.
The iMac is probably the best bet for a home flight-sim user. At $1300 it’s not too expensive, but it comes with a great graphics chip, is a fast overall computer, and flies the sim real well. The flat screen looks good and it’s a nice clean machine to have on your desktop.
What Apple hasn’t made (and I suspect never will) is an $800-$1000 desktop with fast graphics and no monitor (a mini pro if you will) and a graphics card in a slot (so it can be upgraded). Such a box would be the best choice for a Mac for flight simulation, but since it doesn’t exist the iMac’s the next best thing.
To end with a minor rant: the new Mac Pro comes with the nVidia GeForce 7300 GT as one of the options. This isn’t a bad card – today’s cards are now so fast that even the “low end” ones are fast. (Compare to the 5200FX, which was unusably slow from day one.) But a low-end nVidia card in a $2500 Mac? The previous-generation 6600 GT outperforms it in fill rate and memory bandwidth. This isn’t the first time Apple’s shipped a big machine with an option for an inappropriately slow graphics card. (I suppose I’m seeing the world from the perspective of a gamer.)
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.
X-Plane 850 allows you to model taxiways by cutting holes in pavement, as well as by building up pavement around a hole. In other words, you can make a letter-‘O’-like shape by making a circle and then cutting out the center, or by making two semicircles that touch.
Which is better? Here are a few guidelines:
- Making an area out of smaller pieces is slower in that you must introduce individual lines only to “cut” the area into smaller parts. So generally subdividing your pavement is harmless as long as the cuts can be a few simple straight lines. Using bezier curves or lots of straight segments just to partition an area into smaller parts can slow down frame-rate. So if you’re going to partition, keep it simple.
- If you keep your partitioning smple, there’s no harm and it does let you control the “grain” of the taxiways textures.
- It takes X-Plane longer to build layouts that have more complex polygons. So subdivision can make airport build-up faster. So for example, modeling an entire class B airport with a single polygon is probably too complex – consider breaking up the polygon a bit.
- It’s better to have two adjacent polygon taxiways with more complex boundaries than one polygon on top of the other. X-Plane has to further subdivide polygons based on the topography of the local terrain, and that subdivision happens for every layer of pavement that’s overlapped.
- One exception: two edges of polygons that touch and are bezier curves may not line up properly, due to rounding errors. So if you want to have one curved surface over another, you may have to use overlaps.
I got a bug report that Tom Kyler’s “Grand Forks” scenery wouldn’t load with X-Plane 850. It turns out the apt.dat file has a syntax error that X-Plane 840 silently ignored but X-Plane 850 reports as an error message.
I’ve wired up the apt.dat loader to use the new, more forgiving error reporting system. Most of the sim still doesn’t use this system, but when the sim does, the result is a single dialog box (per scenery package, no matter how many errors) that looks like the image on the left.
X-Plane then logs detailed information about the problem to the log.txt file like this:
***Error with scenery file “Custom Scenery/grandforks/Earth nav data:apt.dat” (/code/design++/HLutils/OOPS_cpp/airp.cpp: 493.)
An apt.dat enumeration is out of range: Invalid beacon code. Expected a code less than 6 but got 343128. Airport is KGFK. File is Custom Scenery/grandforks/Earth nav data:apt.dat.
This way authors can get as much information as we have about the corrupt file while users are not bombarded with technical details. When possible X-Plane will continue to load, but the sim may abort if the file is too badly corrupted.
