X-Plane 10.04 is out for beta. A few notes:
To get 10.04, you must run the updater and check “get new betas as well as updates”. The updater will not get you a beta unless you specifically ask for it, and X-Plane won’t nag you to update if the patch is only in beta. (This is our preferred method of running betas, and all future betas will be like this.) There are some pretty major fixes to ATC and AI aircraft behavior, so it could be a beta worth getting.
We are starting to transition more of our various websites to WordPress; this is an on-going process. The eventual goal is to have all of our various web info into WordPress (on either the main site or the “developer”* site, which will grow out of this blog) and drop the wiki. MediaWiki makes everything possible when it comes to content management, but it makes nothing easy, and controlling spam has been a real problem. Eventually all of the knowledge-base articles that the sim can link to now will be browsable from those sites, but for now we’re still working on building up the infrastructure in our few free moments.
And speaking of developer resources: I am working on a release of scenery docs and updated tools; it’ll take a little bit to get everything together. I am getting hammered with requests; a complete release should get most people where they need to go, so I am trying not to jump in and write one-off emails answering questions; better to focus on permanent docs I think.
Finally, please don’t email to ask me “did you fix my bug yet.” If it’s not listed as fixed in the release notes, it’s not fixed. We’re trying to be accurate in the release notes so that you don’t have to ping us every single release, which burns your time and ours. Not all bugs will be fixed this beta; we have enough high priority ones that we’re going to get fixes out as quick as we can.
* The developer site will include aircraft, scenery, and ATC authoring info; the SDK website will remain separate, as LR doesn’t own the SDK IP. (It’s more like FSUIPC that way.)
X-Plane 10.03 is now final; here’s a little bit of what’s coming up:
- For a while we were “pushing” betas to all users via the auto-update system. We did this because we had critical crash fixes we wanted to get out quickly. Fortunately, that phase of the release is now over and 10.04 betas will only be available if you opt in and check the “beta” box in the updater.
- For 10.04 we are continuing to tune performance, fix bugs, improve the look of the sim, etc. In other words, it’s more stabilization and polish.
- Aerosoft has built a few custom and lego brick European airports for X-Plane 10; these will be available as part of the update for users who have scenery installed. This might be in 10.05 depending on how quickly I can get the installer/updater work done.
- Tom is working more with the airport lego brick library using WED 1.2; I fixed some WED bugs last week and will try to get some releases out soon.
I’ll post more on framerate in the next few days.
This is an authoring “gotcha” in X-Plane 10:
Do not use a degenerate UV map if you are using bump maps. If you use both techniques, your object will have black splotches in HDR mode.
Let me define what I mean:
A degenerate UV map is a UV map where the “U” and “V” axis (that is, the horizontal and vertical axes of your texture) are not moving in different directions across the face of a single triangle.
The most common case is when all three vertices of a triangle are mapped to a single point in the texture, giving you a “solid color” triangle (that is, the whole triangle picks up the color of the single point of the texture.
You can also have this problem if you use “1-dimensional” texturing – that is, all three texture points for a triangle are along a line in the UV map or two of the three points are colocated.
If you need to use bump maps for your OBJ and you need a “single color” spot, separate the UV map of each vertex of the triangle by a little bit (even just one pixel).
You’ll know you have this problem when you see some of your polygons show up as pure black when HDR lighting spills on them. Here the top of the APU/air conditioner on the jetway has a degenerate UV map. In HDR mode it shows as a black area despite the spill light. This kind of artifact will show through any geometry that should normally cover the affected area.
Why This Happens
(What follows is strictly for the computer graphics nerds – you don’t need to understand this to fix your OBJs).
For the computer graphics nerds: in order to apply a tangent space bump map, you need three basis vectors to create a 3-d space for the normal vectors; the tangent space bump map is then essentially a perturbation of the regular normal vector. (Or put another way, the tangent space coordinate space system defined by U, V, N is used to transform the tangent space bump map back into world space. For the degenerate case of no normal map, the normal map can be thought of as 0,0,1 and the transform is a no-op from what we would have had anyway.)
Some engines require that the U and V axes be specifically passed per vertex. X-Plane, however, reconstructs the U and V map from the UV map of the model. When the UV map of the model is degenerate (e.g. it doesn’t form distinct non-zero length basis vectors along the output triangle) the coordinate system of the tangent space normal map ends up degenerate and the output normals suffer from a divide-by-zero.
The divide-by-zero is burned into the G-Buffer and the artifacts are thus persistent.
One of the major components of the new ATC system in X-Plane v10 are the taxi layouts. We sometimes internally refer to this as the “taxi network” because what it’s REALLY comprised of is a network of taxi segments attached to other segments at taxi nodes. The concept is pretty simple, a node connects two or more segments together and it’s a place where a decision could be made by the ATC system in order to change directions. Every single land-based towered airport in the world has it’s own taxi network.
To give you an idea of what a network looks like, here’s one for Seattle (click to see it clearer)
White segments are runways, green-ish (my wife would say “seafoam”) segments are taxiways, red segments are taxiways inside of an active-zone* and the white dots are the nodes. For ground operations, this is what ATC knows about and it’s the ONLY thing ATC knows about. It doesn’t know about buildings or obstacles in the way, it only knows about the pavement. Anytime ATC wants you to get from one point to another, it has to give you a routing composed of a connected list of these segments. The only exceptions are the start and end segments. ATC is only allowed to go “off the grid” to get you onto or off of the network. So if you’re at a gate and you request a taxi to runway 34L, it first tries to figure out the fastest way to get you onto the network. It does this by calculating whether you’re closest to a node or a segment on the network, choosing the closest one and then giving you a straight line to that point. Now you’re on the network. The opposite happens for end points.
So that’s how you get in and out of the network, but what happens along the way? It’s not all that different than the GPS in your car. ATC analyzes essentially every possible routing from your start/end nodes and chooses the one with the lowest cost. Note that I said lowest cost, not shortest distance. Think about the best way to get to work in the morning. Do you take all back roads? Do you maximize highways? Do you avoid tolls? Your decisions are based on far more criteria than the mere distance. The ATC system is no different. Distance is just one of the contributing factors that goes into it’s cost calculations.
Some (but not all) of the other things in the costs are segment type, segment usage, segment angle and the aircraft’s mode of operation. These can be fairly complicated so I’ll summarize them quickly. Segment’s have different types. They can be one way or two way just like streets in a city. Obviously the cost of using a one way street depends entirely on the direction you want to go. If you want to go the legal direction, the cost is nothing out of the ordinary. If you want to go the wrong way, the cost is REALLY high. In other words…only do it if you have no other options! The final segment type is “runway”. ATC tends to avoid taxiing you on the runways because that’d be terrible for airport efficiency…especially if the runway is an active runway. Another contributor to cost is whether or not the segment is already marked to be used. In other words, if another aircraft is taxiing southbound on a particular segment and you want to taxi northbound, that’s a potential problem, so the cost is high. If you’re going in the same direction, it’s no big deal. Segment angle is important as well. ATC does it’s best not to issue routings that result in steep taxi angles. 747’s have trouble making 150 degree turns for instance. Lastly, there’s your mode of operation. Remember how I said ATC hates using runways for taxi purposes? There’s an exception. When you land, it’s often beneficial to continue taxiing on the runway since you’re already on it and you’re already going quite fast. All of these factors contribute to the cost weighting and the route chosen for you is the one with the lowest cost at the time.
So where do these networks come from? Where does the metadata come from? Well, there are thousands of airports in the world that need these taxi networks so that ATC can provide service. It was important to us that ATC would function at any airport out of the box so Ben wrote some insanely cool algorithm that runs “on-the-fly” when you load up an airport. The algorithm looks at the pavement, erodes it inward leaving the “average” center points of all of the edges. This works pretty well but it’s not without it’s problems. The first problem is that it has no clue what the pavement is to be used for. Is it an apron? Is it a taxiway? Is it an access road? Is it a shoulder on a runway? Pavement is generic in X-Plane so there’s no way to know. The result, as you can see in the screenshot above, is that sometimes you get routings on small access roads. Another problem is algorithmic “noise” that’s causes the taxi lines to be quite zig-zagged and wavy. This is why the AI planes often look drunk when they’re taxiing. Often, the segments are not “reduced” or “smoothed” as much as we’d like. You can see the entrances to each runway tend to have a “Y” shape to them because of the “fillet” on the taxiway. This is a byproduct of the erosion code. There is code in there to reduce it as much as possible and “snap” the edges to the runway but it has to be generic enough to work reasonably well at thousands of different airports. Most of the time it causes no problems but there are cases where the “Y” becomes extremely wide because the runway has a thick shoulder created with a strip of pavement. One final problem is the lack of metadata. The active-zones are stamped out around the runways proportional to their size so seldom do they line up with any painted hold-short lines. We have no clue what the taxiways are named. I know what you’re thinking “Why not use the painted taxi markings and signs to aid in the algorithm’s decision making”. That was actually one of the first things we tried and found the data to be too sporadic to be useful and it made the algorithm very slow and complicated.
So if the algorithm has so many problems, why are we using it? Two reasons. First, the alternative is that no airports would have ATC capabilities on the ground until a user made a custom layout by hand. Second, the algorithm was created to be a stop-gap solution, not a substitute for human data! The REAL taxi networks need to come from a human! Once they are made, they’ll be added to the apt.dat and distributed with the sim moving forward. This means that over time, human data will replace the algorithm’s data and taxiing will get better. The taxi network generation is one of the major features of WED v1.2 which will be released in the coming weeks. Authors can create a network for their airports relatively easily. In my first time using WED, it took me only 2-3 hours to create the network and I’m completely clumsy using any kind of CAD type software. Someone who knows what they’re doing could do an equally complex airport in about an hour I would guess.
The layout in the first screenshot above is an autogenerated one. That’s NOT what you’ll be using if you go to KSEA in the simulator and that’s because I made a custom layout. If the sim sees a custom layout, it always prefers to use that. Here’s what my custom layout looks like.
So you’ll notice the lines are straight! There are no taxi segments through buildings anymore, there are no taxi segments on the access roads, there are no “Y” branches at the runway entrances/exits. Also, not visible from this height, the segments are lined up perfectly with the taxi paint and the active-zones perfectly coincide with the hold-short markings as well. I’ve also named each segment properly so that ATC can tell you exactly how to get to your destination e.g. “Taxi via Alpha Charlie Two Foxtrot Delta”.
There really is no substitute for human data. It definitely results in a much more realistic and far less problematic experience.
*An active zone is a taxi segment that’s protected by ATC because it’s adjacent to or in some way affected by an active runway. This is how ATC knows what to protect with hold-shorts and it’s also how ATC knows when it’s time to talk to Ground vs. Tower.
Fill rate: when we talk about fill rate, generally what we’re talking about is your GPU’s ability to fill in individual pixels to make the final image you see while flying. (The actual components of GPU throughput get a lot more complex, but we’ll keep things simple for now.) Two key things to note about fill rate:
- It only comes from your GPU – not your CPU.
- The bigger the size of X-Plane’s window (or the higher the full screen monitor res), the more of it you use.
Therefore I can offer this very simple test as to whether you are fill-rate limited:
If you are running in windowed mode and making the window smaller improves frame-rate, you are fill-rate limited.
(There is actually one important exception to the above test: if you are running out of VRAM, making the window smaller uses less VRAM for the main window + off-screen buffers, which can help fps. So be sure to see whether cutting your texture res helps fps – if it does, you are out of VRAM.)
Fill rate gets used up by:
- A larger rendering window. This is the number one consumer of fill-rate. Double the size of the window in each dimension, you use 4x the fill-rate. That adds up quick!!
- Clouds tend to be fill-rate intensive.
- HDR mode is significantly more fill-rate intensive than non-HDR mode.
- The 3-d cockpit is more fill-rate intensive than 2-d and external views, particularly with HDR enabled.
- Shadows, to a limited extent.
X-Plane 10 contains a stat called “cpu load” in the framerate output data line; I will describe its full meaning and implication in another blog post, but generally low CPU load (e.g. < 0.7) means you are fill-rate limited. If your CPU use for one core is 100% (this means 25% in the task manager for Windows users on a 4-core i5, but 100% in top for Mac/Linux users no matter what the number of cores) then you are almost certainly not fill-rate limited.
Optimizing Fill Rate
X-Plane 10.03r1 will post in a little bit – this is our first attempt to finalize X-Plane 10.03. It is not the end of the bug fix and performance tuning work for X-Plane 10. But if we can get a stable 10.03 we can use it as a baseline and limit betas to those who check the “get betas” check-box in the installer.
X-Plane 10.03r1 contains fill-rate optimizations for the 2-d and forward-no-HUD views; we’ll have to see how much they help people, but they should help you a bit if you are fill rate limited, flying a plane with a 2-d cockpit, and are seeing low fps with clouds and/or HDR.
Once 10.03 is final, we’ll start 10.04 and I will attempt to make a similar set of optimizations for the 3-d cockpit. Note that the 2-d optimizations do not apply if you have a plane that uses the 3-d cockpit for the 2-d view. (Since all of the new X-Plane 10 default planes do this, we’ll need the 3-d optimizations in 10.04 to see the performance benefit with the 747, Baron, and other new default planes. The Cessna, Cirrus Jet, and Piaggio from X-Plane 9 should all benefit immediately.)
Your Mobile GPU Is Light But Not Fast
Here is a table I culled from Wikipedia: it is a table of GPU performance for the “top end” cards for ATI’s last 4 generations of hardware.
| CARD |
DATE |
GP |
GT |
BW |
GFLOP |
| 4870 |
Jun 08 |
12 |
30 |
115 |
1200 |
| 6970M |
Jan 11 |
21 |
32 |
115 |
1305 |
| 5870 |
Sep 09 |
27 |
68 |
153 |
2720 |
| 6970 |
Dec 10 |
28 |
84 |
176 |
2703 |
| 7970 |
Jan 12 |
29 |
118 |
264 |
3789 |
GP = gigapixels/second of fill, GT = gigatexels/second of texture, BW = GB/second of memory bus bandwidht, and GFLOPS = gigaflops/second of MADD. At least I hope – see the original table.
Now I have inserted one mobile GPU (the 6970M) into this chart. So the first thing you can see is: the 6970M provides in a laptop the power that was available in a desktop about two years earlier, more or less. That’s a big step back in time.
The reason is simple: mobile GPUs are typically cut down in their core configuration – there’s no way you can run a 150W full power GPU with those 3 fans in a laptop.
If you have an iMac, you have a mobile GPU. Even the older iMacs which didn’t have the “M” designation on their chip, those were mobile too. In fact, you’ve got a mobile GPU on a huge screen. (Super-size to the 27″ iMac to get the 4x fill rate boost and you pick up 1.7x the pixels; if you get the big iMac with the cheap GPU you have a mid-range mobile GPU on a 2560 x 1440 screen!)
Some Kind Of Summary
I’m not entirely sure what my main point here is…perhaps the executive summary is:
- We (LR) are working to optimize fill rate in X-Plane 10. Fill rate is not the only performance bottleneck we are working on, but it is a very important one. Some of this is in X-Plane 10.03r1, some will come in later updates.
- You can determine whether you are fill-rate limited by resizing your window.
- If you have a mobile GPU in a laptop or iMac you may have less fill rate than you would expect.
Happy New Year! I will try to get a few more posts out over the next few days; we spent a lot of December with our heads down trying to fix as many bugs as possible despite the chaos that the holidays always inflict on any company.
We had a slight fire-drill with beta 8 last night; it turns out it crashes on Windows, so we pulled back to beta 7. X-Plane 10.03 Beta 9 will come out today and fix the Windows crash and 1 or 2 other issues.
Right now we are “pushing” betas to everyone; this is not the norm and we will go back to the normal process (where users opt in to betas) once the 10.03 beta process completes. Since 10.03 has so many stability fixes, we want to make sure everyone gets them. We’ll lock 10.03 down before proceeding to additional performance tuning.
For December I had four things I was trying to work on: stability fixes, backward compatibility, performance enhancements, and third party support. I was only able to make progress on some fronts. At this point we have most of the hardware support issues stabilized and we’re close to closing up the crashes. (There is no short term fix for running the sim out of address space unfortunately.) We’ve done some performance tuning and a lot of analysis, but a lot of the work to act on the analysis is yet to happen.
The front where I made no progress is in third party support. So starting this week I am going to try to dedicate one day a week to some kind of third-party-only activity, whether it is getting out the docs on the new v10 authoring features, getting out scenery tools, etc. We have a lot of “almost ready things” and I don’t want to keep authors waiting.
Many of you have taken the time to tinker around with the new ATC system. Many of you have had a good experience, others have found yourselves frustrated for various reasons. My goal here is to try and explain what you can expect from the system moving forward and describe the causes of some of the troubles that you might be having.
First, as I’ve said before, what you see in the ATC system is just the tip of the iceberg. The features are going to expand moving forward. What you are looking at now is not the way the final system will work. If we waited months or even years before shipping X-Plane 10, I’d still be saying the same thing. The reason is that the ATC system has the potential to be very large and very comprehensive much like the scenery system. It will evolve over time. There will never be a lack of new things that would be cool to have, there will never be a lack of things that can be changed for added realism etc. We have to develop things in stages however and what you see is merely the first stage.
The first stage was designed with one goal in mind: to create a system that’s comprehensive enough to give AI aircraft a purpose. Having AI aircraft buzzing around creates a living airport environment. Coupled with Ben’s new roads and railways, the X-Plane world is no longer a static world, it’s one that’s alive! AI aircraft are very low maintenance. They don’t have many requests, they aren’t picky about their routings. They just want to depart from one airport and arrive safely at another airport and the current ATC does that just fine. We’ve also allowed YOU the user to interact with ATC at this point but humans are not as simple as the AI planes. Your goals are a lot more specific and detailed than the AI goals and the current ATC doesn’t handle that so well. That’s coming! That’s phase two however. Right now, your interaction with ATC allows you to “get into the system” so that you can have a turn to use the runway for takeoffs or landings.
For those of you unfamiliar with the real world ATC system, let me tell you what it’s NOT. It’s not a turn-by-turn Garmin navigation system. ATC’s job is never to be your navigator or co-pilot. Yes, they often do assist pilots but this is NOT their primary goal. Their primary goal is the separation of aircraft within their airspace. Often, when ATC is assigning you headings for vectors, it’s because it’s easier for them to put you exactly where they want you to be than it is to let you fly however you feel. They’re controlling your position for spacing, for sequencing and for efficiency. This typically only happens on approaches where numerous aircraft are all converging in tight spaces to use a single runway.
X-Plane is no different. If you file a flight plan with a blank route, you’re expected to go DIRECT to your destination. You will not be given instructions on how to do that. If you file a route, you’re expected to fly the route by yourself. You will not be told when to turn or how to get from fix to fix.
ATC is also not a weather service. If you want to know the weather, you have to tune to the various AWOS/ASOS/ATIS frequencies around the world. These were in v9 and they still exist today. Yes it’s true that real controllers will often give you weather information if you ask. We may add a little bit of that in the future but even in the real world, it’s not their job…they do it because they like to be helpful people.
The first stage of ATC right now will give you an IFR clearance after you file your plan. They will assign you a squawk code for radar tracking. They will issue you a routing to your assigned runway. They will ensure that you are only allowed to depart when it’s safe. They will stay with you until you’re near your arrival airport. They will provide vectors to your approach (visual/ILS) and then they will issue you a landing clearance and allow you to continue as long as the runway is safe to use. If the runway becomes unsafe, they will instruct you to go around for another attempt. When you land, they will issue an appropriate taxi route back to your gate. That is the extent of what is possible with the first stage. It’s not comprehensive but it’s a foundation to work off of.
What kinds of things might you expect in the next stage? (NOTE: these are not promises. The details of future features have not been finalized but i’m trying to offer an idea of roughly where we’re headed). VFR operations. Requesting higher/lower altitudes in flight. In-air conflict prevention and resolution. Changing destinations in flight. Requesting specific runways. Requesting specific approaches…etc. etc. Please do not make feature requests at this time. I’m just rattling off some ideas from memory.
I have one or two remaining stability issues to clear up before I can fix some of the current usability issues that seem to have come up. For now, here’s an explanation of some of the issues so that you may at least understand what’s going on under the hood. I will say, the current system is a lot like a fire alarm in that it only takes one simple problem like a dying battery to be REALLY annoying. But like a dying battery, a relatively simple fix can make the problem disappear.
- “I filed a FP but ATC isn’t talking to me” – That’s because you haven’t asked for anything. Tune your COM1 radio to the appropriate controller for an IFR clearance. At big airports, this is the Clearance Delivery controller. At smaller airports, this can be Ground or Tower.
- “How do i know what frequency to be on?” – You really only need to know the frequency for two people. The guy who’s going to give you your IFR clearance, and the ground controller. After that, you will be instructed by ATC which frequency you should be on for the remained of you flight. You can get the DEL/GND frequencies from a variety of places. First, in the sim you can go to the local map view, enable Airports and then click on the airport that you want the frequency of. Then look at the popup. You can also use real world charts or resources.
- “ATC is giving me a routing that’s through gates and buildings” – This is because the taxi layouts are auto-generated and have no idea where the buildings are. In the future, airport authors will create detailed taxi layouts that will completely alleviate this problem at their airports.
- “I taxi to the runway and nothing happens” – If you were talking to ground, he should have handed you off to tower. If he didn’t, then perhaps you didn’t pull up enough. Make sure to taxi to the very end of the yellow arrows…not necessarily the hold short lines pained on the ground. Again, when human authors make taxi layouts, these should align perfectly (as they do in KSEA) but for autogenerated layouts, they may not. Trust the arrows, not the paint.
- “I contact tower holding short of the runway but i don’t get a takeoff clearance” – This is because it’s not safe for you to takeoff. You have to be patient and wait. There could be someone taxiing on the other end of the runway, there may be an arrival that’s too close, or the last departure may still be in the way.
- “I’m constantly being told I’m off course” – This is because you are…
The problem however is probably not your fault. If you don’t file a route and you leave the routing blank, ATC assumes you’re going “direct”…the current bug is that direct is from the center of the departure airport to the center of your arrival airport. So what happens is that you takeoff, you fly runway heading, you get yourself adjusted, clean up the aircraft….by this time, you can be MILES from the center of the airport where the route line began. Now you decide to “proceed direct” your destination but you’re now paralleling the course that ATC expected you to fly. The real solution to this in the future is me fixing this in various ways but for now, try to fly a course track that emanates from the center of the airport or file a real routing. Real routings may sometimes have the same issues for the same reasons but will be probably be less severe.
- “I’m constantly hearing AI planes getting yelled at for their altitudes” – yeah this is because some of the AI planes are being asked to climb to FL360 or so and they seem to be climbing in an inefficient manner. They end up running out of airspeed at FL330 or so and then are not smart enough to step climb up the rest of the way so they just stay there on a border-line stall. Austin will need to tweak the AI planes in the future.
- “ATC’s not talking to me after I depart” – Why should he talk to you? You’re the pilot, your job is to fly the plane the way you filed. ATC is NOT a turn-by-turn GPS. You need to know how to get to where you’re going on your own and you are expected to do so. The ONLY time you can expect vectors currently is when you get within 30nm of your arrival airport. At that time, ATC will issue you vectors for your visual or ILS approach.
- “ATC forgot about me after issuing me some vectors” / “ATC is vectoring me away from the airport” – Perhaps ATC is not issuing the tightest vectors in the world if you’re in a small GA plane, but it’s not THAT far off. ATC (much like in the real world) typically issues vectors to final using a vectoring Tee (See below). Yes, you may be told to fly away from the airport. Yes he may give you headings that seem out of the way. He will not forget about you. Hang in there. Depending on your arrival angle, you may be given some shortcuts. In the future, I can add some tighter shortcuts as well but it’s actually not that far off. I think in it’s worst case, you can expect an 8nm intercept to final.
So here’s a vectoring tee like the one used by X-Plane’s ATC. The numbers represent the headings you could expect for this sample runway (09/27). Depending on whether you’re approaching from the north or the south, you’ll be given only half of this Tee. Let’s pretend that you were south of the airport…you’d be given a right turn heading 090, then a left turn heading 360, then a left turn heading 330, then finally a turn to 270. Depending on your aircraft type, you may be required to fly away from the airport by several miles. This is normal. ATC has not forgotten about you. You will be turned back toward the airport when the time is right.
So that’s a quick dump of my brain regarding ATC at the moment. There will be more posts in the future about future features and what you can expect. The purpose of this post was to just give you a glimpse of the status of things and alleviate some confusion all around since it’s a completely new paradigm for many people.
In my previous post I announced that we have the ability to recut DSF tiles in an update and that we have already started doing this. I pointed out that we’re not signing up to recut the whole planet because we don’t how we will manage distribution yet.
This sets us up to talk about OpenStreetMap (OSM). First the basics:
- The X-Plane 10 global scenery gets its vector data from OSM – that would be roads and water.
- X-Plane 10 does not get its raster data from OSM – we get land class and elevation data from a composite of sources , both integrated by Alpilotx using a mix of tools I wrote and some GDAL/GRASS voodoo. (I think he may have had to sacrifice a live goat. I try to not ask questions about what goes on with the raster data!)
- OSM is the only source of water body data in X-Plane 10.
The result is a lateral move for water body data quality and an ironic one: for the first time the US isn’t the area of the world with the best data sources. OSM coverage in Western Europe is often near complete. By comparison, the US is still quite sparse.* The result is that water bodies that were present in the US in version 9 are now missing in version 10.
(To make matters a bit worse, the OSM extract for the global scenery is from July. I had to take an extract and stop updating to stabilize the scenery development process. We’ll take new extracts in the future but what you see now is months older than the current OSM data, not weeks.)
Why didn’t we use multiple water data sources? There were two problems:
- We ran out of time. It’s really tricky to integrate multiple data sources that don’t line up spatially, and while we had some promising tech, it made the DSFs worse as often as it made them better.
- Because all other sources of water were not in OSM, we had the potential for road/water conflicts, which makes the integration very tricky. In the old days when we used terrible VMAP0 data for roads, we could just nuke the road if the water didn’t match. But OSM road data is quite accurate and we didn’t want to manually edit it.
So my thinking is that what we really need to do is make OSM as good as possible and then recut tiles. Improving OSM improves the global scenery in the long term, everyone can participate, it helps everyone using OSM, and once OSM has the correct water data, getting it into a DSF is just a matter of recutting the tile. If the water data is all in OSM, then we don’t have to worry about water/road conflicts. This is the true power of using OSM: for the first time we can all focus on the source data, because the source data is public and community owned.
I did some work a few months ago to prepare NHD (the US national hydrography dataset) for OSM use. I am hoping to find a little bit of time to continue with this effort – my goal was to make it easier for people to import high quality NHD water into OSM, but there were some unsolved workflow problems when I left off to focus 110% on getting v10 out the door.
What Other OSM Data?
One question that comes up over and over is: what other OSM data will you use? The short answer is that I don’t know, but I think individual building shapes is not on the short list. The problem is that I don’t think we can adopt our autogen at the quality level we like to such arbitrary shapes.
That doesn’t mean that other third party scenery can’t use the data now, or that we won’t use it someday. But it’s not next on my list.
One type of data that I do think we could make good use of is “point of interest” data – e.g. we there is a school tagged in the OSM data, we could drop in a school autogen art asset for a given location – this kind of “shaping” of the autogen could, I think, provide another level of richness and accuracy while leveraging the existing autogen and DSF generation technology.
OSM vs. Airport
One last note on OSM and recuts: in the past we have cut out roads near airports. Our older road data was often very inaccurate and would run right over a runway. The cutting process tried to minimize the insanity.
OSM data is often very good and there are many cases where the OSM data could be left alone for perfect perimeter roads. I do not yet know how we will modify the cutting code to ‘preserve’ such road data, but I would like to get this right in future renders.
One problem that makes this difficult: often the on-airport roadways are modeled in OSM, but without any tagging. The result (when road cutting is off) is a city street down the middle of the tarmac, often where the vehicle paths should be. So we need a way to know whether a given OSM road is okay or not.
* The US road grid was first seeded by integrating TIGER road data into OSM. This gives the illusion of total mapping when in fact some areas have never been hand edited. The TIGER water was not brought in during the initial import, hence areas with roads but no water.
With X-Plane 8 and 9 we had a perpetual problem: the airport layouts ship with X-Plane and are updated frequently by Robin; if an airport layout is changed significantly or a new runway is installed, the airport layout may conflict with the base terrain and autogen from the underlying DSF that was cut when the sim was first shipped.
This resulted in a huge amount of stress for users who were building airport layouts. When is the cutoff for new layouts? What if I don’t make it? It will be years before the DSF is fixed.
I think the solution for version 10 is actually quite simple: we will recut individual DSF tiles and “push” them in sim updates.
In fact, we are already doing this. Five tiles, including the tiles containing Paris and Denver, rolled off the production line broken and we didn’t detect the problem until after we burned the DVDs. The patch is already online, and if you are running with current betas and installed Denver and Paris from DVD, you should have the corrections.
I think we’ve reached a point in X-Plane’s development where we need to evolve the global scenery from a static product that never changes to an ongoing one that can be updated in pieces, on the fly.
The History
I have been involved in X-Plane since version 6; for as long as I’ve been around, the product has been updated frequently with frequent patching. Starting with X-Plane 8 we developed a proprietary installer that let us easily push patches to three operating systems, with users downloading only the changed bits of the sim.*
The problem with the update strategy was that the global scenery was always too big. And what we found was that if we perpetually recut the global scenery, it made everyone who had already bought the scenery crazy mad. The last thing you want to do is buy the sim and discover it would have been better if you waited.
The idea of the “update” strategy is that you can buy into a major version run as soon as you want or late, and if you jump in early you get all of the future updates for the version run for free over the net. So we would update the sim and leave the global scenery alone. Thus there was never an update to the version 9 global scenery.
The Brave New World
The problem with not updating the scenery is that it takes us years to fix bugs, share improvements with users, and integrate changes from users (e.g. better airport layouts). Using OpenStreetMap raises the stakes: anyone can improve raw vector data using OSM at any point. How long do we wait to ship the improvements to everyone?
So I think it’s time to start recutting tiles and shipping them in updates.
Now to be blunt: I have no idea how we are going to go about doing this. So far recut tiles come down in free updates to users who have them installed, but this is just a beginning; we don’t have scalability problems yet because we have recut only 5 tiles.
Airport Anomolies
In the long term I don’t know how many tiles we will recut, when we will recut them, or what percent of the Earth we might recut in a given version run. We are not promising to recut any particular area or set of tiles. Please read that sentence twice. Don’t come back to this post and say “but you promised me free global scenery.” I don’t know how much recutting we can do or what the terms will be. I just know that it is the direction we need to investigate and move in.
With that disclaimer in mind, I do think we will be able to recut tiles that have airport anomalies. For example, I have two bug reports on class B airports. KSFO has an incorrect coastline, and KORD has a collision between autogen and runways. In both cases, I don’t know what went wrong and will need to investigate. And in both cases, pushing the fixed tile in an update seems like a reasonable solution.
* As far as I know, no commercial solution would give us three operating systems, deltas from any past version, while making it quick to cut a patch. Since we use the installer for every beta, the initial development time was worth it to make patching quick for users and for us.
My preferred way to fix X-Plane problems is to fix the problem first, then post second. That way there is no question that what we ship is what we announce.
But there’s a bunch of issues floating around with X-Plane 10, some of which will either take a while to fully fix, or which will be fixed in steps, with some steps happening now and some happening over a much longer time frame as the sim evolves. So I’m going to write some of them up now and get the information out there. A lot of users have taken the time to send in good bug reports, so it’s not fair to then sit on the plan.
A lot of these plans are just that: plans. Plans change. I believe that one of LR’s strengths is that we can change the plan quickly – if we come up with a plan and it turns out to be dumb we don’t have to just go through with it, we can come up with something better.
With that in mind, I had the following conversation with Austin yesterday – over a rather poor cell phone connection:
Me: Heya! Do you want to talk about BAD ALEX?*
Austin: Wait, what? What did Alex do???
Me: Oh…no no. Bad ALLOCs! A-L-L-O-C-S. Running out of memory…
A number of you have seen this error. When X-Plane runs out of memory one of three things usually happens:
- Some low level part of the sim seg faults because the request for memory failed and wasn’t properly detected.
- The OpenGL driver blows up because it can’t function without memory.
- The sim tries to allocate memory and throws an “uncaught exception: std::bad_alloc” error.
So first, let’s make one thing clear: we are running out of virtual address space, not physical RAM or VRAM. X-Plane is a 32-bit process, and thus it can only access 2-4 GB of virtual memory (address space) regardless of what is in your computer. The specific limits:
- 32-bit Windows: 2 or 3 GB, depending on OS settings.
- 64-bit windows: 4 GB
- OS X: 3.5 GB
- Linux: 3 GB – I think.
This address space has to contain a few big things:
- A copy of every texture X-Plane is using. (Most OpenGL drivers will “back up” textures in virtual memory at least some of the time if not all of the time.)
- Every mesh that will be drawn for all scenery, planes, etc.
- The weather system (physical and drawn).
- The physical mesh that is collision checked.
- The sim itself.
- etc.
So if you increase the combination of screen size, texture res, turn on HDR (which allocates a bunch of textures to render to), crank up the autogen, the sum can exceed X-Plane’s virtual address space limit.
The Short Term: Surviving With 3 GB
In the short term there are a few things that you can do and a few things that we can do. If you are seeing crashes or bad_alloc errors:
- Turn down rendering settings. The major ones are: airport detail (set to default), forests (set to something moderate if you are using autogen too), and texture res (first run with compressed textures). Don’t use 4x SSAA when in HDR mode – use FXAA instead.
- If you are on 32-bit Windows, consider moving to 64-bit Windows, at least in the long term.
- If you are on 32-bit Windows with 2 GB per process, increase that limit to 3 GB as shown here.
Note that buying more RAM will not help! We are out of virtual address space, not physical RAM chips!!
In the short term we can:
- Improve the error reporting to make it more obvious what has happened.
- Attempt to detect a lack of memory earlier and give warnings.
- Tighten our memory belts – I need to go on another memory hunt. Unfortunately we went on a pretty serious one before we shipped so there may not be any quick wins.
- Detect 32-bit Windows that are running without the 3 GB warning and flag this for users clearly with help instructions. If you’re running with 2 GB on 32-bit Windows it’s hard to see this in the OS itself, but getting that extra GB makes a big difference!
The Long Term: 64 Bits
The long term solution is clear – we need to migrate X-Plane to 64 bits. This is not going to be particularly easy or fun.
- On Mac, we have to port all of our platform specific Window/UI setup code from Carbon/C++ to ObjectiveC/Cocoa because Apple doesn’t provide our APIs in a 64-bit variant. Thanks Steve.
- On Windows we have to change compilers, as the one we use now is old and doesn’t build x64 apps.
- Sandy and I will have to make a 64-bit variant of plugins.
- 32-bit plugins won’t run in a 64-bit app. As far as I know none of the three operating systems provides a way to bridge DLLs like this, so plugin authors will need to create 64-bit compiled versions of their plugins.
It’s not a trivial amount of work. But it is what we need to do. It’s crazy to have a video card with 3 GB of VRAM and an app with only 3 GB of address space – in that situation by definition an app could only fill VRAM with textures if it had no code (let alone data). For years the cards, CPUs, buses, everything has been getting faster, bigger, more, except for virtual address space limit, which we have finally smashed into face first.
There have been a bunch of posts in which I have said “we know we need to do 64 bit” but now we’re saying “it really needs to be on the next train that leaves the station.” We will probably start the porting work once we get the 10.0.x series of patches stabilized.
