If you have an Android device, check your market for the new update. The update allows users to purchase aircraft and scenery add-ons if they wish. This is an “a la carte” style system. We hope you’ll find it more cost effective as a user to buy the aircraft/scenery that you want instead of having to buy an entirely new product for $9.99 just to get at a couple of planes that you like.
I think I’ve talked about this on forums, but the actual blog post I meant to write (months ago) has been sitting in my ‘drafts’ folder and it’s so obsolete that I’m just going to start again. So…
As you may have heard, X-Plane 10 is going to use OpenStreetMap (OSM) as our data source for vector road data and some fraction of our vector water-body data. X-Plane 9 uses TIGER and VMAP0, so switching to OSM will be a huge improvement.
If you haven’t looked at OSM, the very short version is that it’s a cross between Google Maps and Wikipedia: it’s a global map of vector data that anyone can edit. And unlike Google Maps, anyone can get the actual vector data and use it for any purpose. This makes OSM useful for creating global scenery.
Here is a comparison of downtown Paris in VMAP0 and OSM.
(That’s the 48N 2E tile, which contains Paris. The top images are a whole-tile and metro image from VMAP0, and the bottom are the same areas in OSM.)
There are two big wins with OSM:
I can’t emphasize the importance of this second point enough. In the eight years since I first started poking my nose into X-Plane scenery, I have heard this more times than I can count: “The lake near my house is in the wrong place. Can I fix it and send you the fix”?
Until now the answer has been: no. The lake comes from a data set and when we recut the scenery, any user edits would be destroyed by the conversion from source data. OSM changes that. OSM is the source data, so if you improve global data within OSM, you have fixed the problem permanently.
Not only does OSM make it easy to fix problems permanently, but OSM makes it easy to make very small changes. This morning I was viewing my own town and discovered that two railroad bridges were not marked. I clicked the edit tab, marked out the bridges, and saved my change. You can start with a single edit.
By connecting X-Plane’s source data to the OpenStreetMap community, we can join forces with many other communities that are all working to improve the availability of global mapping data; our improvements (for the sake of improving X-Plane) can help other groups that are working on completely different projects, and their improvements benefit us.
In future posts I will address some of the details of what data we are using, how you can contribute in ways that will affect the global scenery, and how we are (trying) to cope with the OSM licensing change. But I want to make one point immediately:
Just because the global scenery will use OSM does not mean that global scenery will be the only way to use OSM. There are already several existing projects (e.g. XPOSM and OSM2XP) that will build custom scenery from OSM data. OSM provides a rich and detailed geodatabase; the global scenery is only beginning to scratch the surface of what can be done with the data. So I do not see our use of OSM as making some of the other OSM/X-Plane projects obsolete.
For example, OSM2XP utilizes OSM building data, which we will not be using in the version 10 global scenery. I think that the more tools we have to use OSM data, the better, as they give authors more choice in creating scenery.
MeshTool builds a terrain mesh off of two forms of input data:
Now the density of triangles in X-Plane’s irregular mesh (see here and here for pictures of a typical irregular triangulation) is not related to the DEM density – that is, MeshTool picks and chooses from DEM points to make an irregular mesh with the best DEM points for the budget you specify (via MESH_SPECS). Thus making a bigger DEM does not make a final mesh with more triangles.
The situation with shapefiles and vector data is very different. MeshTool will add as many small triangles as are necessary to guarantee that every line segment in your shapefile’s polygons are represented in the final mesh. That means that if you integrate a shapefile with 1,000,000 line segments, at least 1,000,000 line segments will be “cut into” the triangle mesh.
If you go back and look at those two mesh examples, the second image (lines only, no fill colors) shows this happening: the white vector river at the bottom of the canyon has very short line segments, and the mesh triangles become small to “capture” this detail, even though the underlying elevation is relatively flat (and thus larger triangles would suffice).
Put simply: MeshTool doesn’t reduce the resolution of your vector data, and your vector data directly influences the density of the final mesh. What this means is: if you put a highly detailed shapefile into MeshTool, your final mesh will have a ton of triangles and MeshTool won’t fix it – there are no settings to control the coastline density because MeshTool doesn’t change coastline density. (This even includes silly cases: if you have a coastline that is basically straight but cut into 300 segments, MeshTool will make 300 triangles despite there being no purpose to them.)
This has further implications about your triangle budget. There are only so many triangles you can have in a DSF before MeshTool and X-Plane both start to run out of memory; therefore there is a real cost to having your shapfiles be too dense – your coastlines will take up triangle capacity and you’ll be forced to lower the MESH_SPECS that make the mountains more detailed.
My advice for now: if you can, use an external tool to “simplify” your shapefiles before you input them to MeshTool!
I do hope to address this in MeshTool 1.1 by providing a simplification algorithm in MeshTool itself – we have this code in the scenery tools code base from global-scenery generation, but it didn’t make it into MeshTool 1.0 as a feature.
In my previous two posts I described the problem of Z thrash in some detail, as well as the problems that polygon offset can have in fixing it. I also described how draping addresses these problems. In this post, I will tr to provide some specific rules for how to overlay geometry in your scenery.
Whenever possible ,use draping rather than polygon offset. If your goal is to put a marking on the ground, draping will always do that correctly, while polygon offset can create artifacts if not used properly.
For x-Plane 9, this means preferring draped .pol files to OBJs for putting markings on the ground.
For x-Plane 10, this means using the upcoming ATTR_draped instead of ATTR_poly_os to put markings on the ground.
When you do need to use ATTR_poly_os in an object, you do not need to increase the number – this number is not a layering indication; ATTR_poly_os geometry is drawn in the order it appears in your OBJ. Always have ATTR_poly_os geometry before any 3-d geometry you might want to include.
Finally, if you use ATTR_poly_os, be aware that you’ll want to use a low layer group like markings; if poly-os geometry is drawn after 3-d, you’ll see artifacts.
In my previous post I described Z thrash and how polygon offset is used to fix it. Now we can look at draping and runways.
The fundamental problem with sloped runways is that a runway is made up of tiles, but the ground underneath it may change slopes in unrelated locations. The following diagram illustrates the problem.
This is a side view of a sloped runwy: the green line is the underlying bumpy terrain and the black line is the runway, divided into multiple tiles. Recall from last time that we can only avoid Z-thrash using polygon offset if the two polygons are truly coplanar. Therefore, we can look at four ways to handle the situation and evaluate them for quality:
This last case is exactly what X-Plane does. This technique is called draping – the sim ‘drapes’ the overlaid runway tiles on top of the runway like a rug. The sim breaks the tiles into pieces so that each tile can sit perfectly on the underlying terrain.
The real work of draping is not just in figuring out where the terrain below the tile is, it is in cutting the tile into the appropriate pieces that can ‘sit right’. The following pictures show this process in 3-d.
This is a screen-shot of a small piece of taxiway at KSAN. I have drawn in the outline of the draped polygon in yellow and the terrain triangles in blue. (The terrain triangles are quite large, so we can only see part of them running through the scene.
This is a wire frame of the problem at hand: we need to insert the yellow polygon into X-Plane, but we need to make sure that no triangles that we generate cross the blue line. The blue lines essentially represent “ridge lines” in the underlying mesh.
If we just had to draw the yellow polygon, we could triangulate it using the thick gray lines shown in this picture. However, this would not be good; the big gray triangle in the middle of this picture runways right across a blue line – there’s no way that this big gray triangle can “drape” properly across the ridge line.
This is what actually ends up happening. The gray lines are cuts we need to triangulate the polygon; the red line are cuts we need to not cross the ridge line, and the purple lines are cuts we need to ensure that everything is broken down into triangles (since that’s what the video card really wants). Once we have this triangulation, we can place every vertex on the ground and it will “drape” the way it should.
In my next post I’ll describe how you can use draping in your scenery to create images on the ground without Z thrash.
I think I have mentioned draping repeatedly, as well as Z thrash, without ever clearly explaining what either of these things are. I happen to have some pictures from recent work on draping, so here’s the basic situation.
Warning to OpenGL purists: I’m going to play fast and loose with a number of OpenGL rules. Basically what I say here is the worst case. Sometimes things work out better than I describe, but if you don’t handle the worst case, you’re going to have problems some times. Nitpickers, consider yourself “on notice”.
When drawing 3-d polygons in OpenGL, if two polygons are coplanar, most of the time they will experience “Z thrash” – that is, the hidden surface removal hardware on the graphics card removes some parts of one polygon and some parts of the other, often removing different parts on each frame in a flickering pattern. The results look like this:
In this picture on the left, we see the raw result of coplanar airport polygons on top of the sandy desert terrain that is the airport surface area. As you can see, the graphics card has been a bit random in deciding whether the runways are “hidden” by the ground or not. If you could see the camera moving, you would see that the pattern of missing taxiways ‘flickers’ as the camera moves.
If there is an overall take-away point so far, it’s this: you can’t just layer coplanar triangles without getting a mess.
(What about moving the runway slightly higher than the pavement? This would have several problems. First, the amount we’d have to move them is horribly dependent on camera angle and video card Z-buffer performance. Second, we’d see the gap between layers; for markings that really do need to be coplanar, like a rubber mark on a taxiway, this would appear as a bug.)
Fortunately if we have truly coplanar geometry, OpenGL gives us a weapon to fight this: polygon offset. Polygon offset is a cheat that tells the video card: “listen, if you ever have doubts about the runway and the ground, favor the runways by a little bit.” It’s a little bit like putting a spread on a football game: the ground would have to be closer than the runway by a margin before we stop seeing.
When we have coplanar geometry, we can use polygon offset to handicap the geometry we want on top. Problem solved, right? So why do I keep writing blog posts with titles like: The Sordid History of ATTR_poly_os or The road to hell is paved with ATTR_poly_os?
Polygon offset has three problems that can bite you:
If there’s a take-away to polygon offset, it’s this: polygon offset can help fight Z-thrash, but it must be used in a very narrow set of cases, and it must be used very carefully.
In my next post I’ll describe how X-Plane uses draping to fight Z-thrash for sloped runways.
X-Farm has been canceled. Sorry.
However, there are some new MeshTool builds. Release candidate three fixes a crash on quit on Windows and fixes the SHAPEFILE_MASK command. Builds are here:
Speaking of Mesh scenery: Oahu’s out!
I didn’t think we’d be able to show this, but…
http://www.x-plane.com/blog/wp-content/uploads/2011/04/snout_view2.mov
Yes, X-Farm will have global lighting…
If there’s one thing I hear over and over from our users, it’s this:
Why are there so few farm animals in X-Plane? The deer on the runway are my favorite feature in the whole sim! Why aren’t there more animals in X-Plane? Please add more!!!
Now first, I’m going to let slip a little secret, because I know you guys are desperate for tidbits on X-Plane 10. The big feature in X-Plane 10 that is taking us so long to get right: moose! While the deer on the runway aren’t going to clock in at much more than 300 lbs, a fully loaded bull moose weighs about as much as a C152 at MTOW. (At least, according to Wikipedia…I’m not convinced a C152 that weighs as much as a moose can get off the ground.) Trust me, you don’t want to hit one of these things, even in a 747.
But that’s not the big news here. The big news here is a new simulator product we’ll be releasing this fall: X-Farm. X-Farm will be the first animal simulator to work entirely from first principles. X-Farm will use shoulder-blade-element-theory to calculate the forces on each part of each animal’s skeletal structure to simulate what the animal would do in the real world. Wanna put the head of an alpaca on a gorilla? Go for it! (Actually, that’s a terrible idea – Camelids spit.) Think Rover would look cute with 6 legs and a stinger? Our animal-modeling application Animal-Maker will let you fully customize your animals.
X-Farm will feature a completely rewritten Animal Traffic Control (ATC) module, with AI Animals that wander around the farm on their own, and herding dogs to chase after them. (The initial version will feature only 20 animals at a time, but we’ll be able to scale this number up over time; the animal AI is fully multi-core for great performance on your new Core i7.)
It’s too soon for me to give specific hardware guidelines, but I’m thinking a DirectX 11-class video card will be best for X-Farm; we’re putting a ton of new shader features into the core engine to support fur on the animals and grass for the fields. The facade system is greatly enhanced and can be used to build a variety of fences and paddocks to keep your animals where you want them.
Finally, I think we’ll eventually be able to get plugin support into X-Farm, so that you can customize the behavior of your animals and create custom animations. Hopefully Wade and I will have time to port XSquawkBox to X-Farm (new name: XSquawk), so that you can create flocks of birds and let them loose in your favorite VATSIM ARTCC. I hear ZBW loves that kind of thing.
*EDIT (By: Chris): I added some screenshots for all the impatient followers who just can’t wait another second to get some sneak previews of some farming. Obviously these are still rough drafts. I’m still working on getting the farmer to look as muscular and rugged as I really do. It’s close but not quite right just yet. Please do NOT ask for more screenshots. We have a pact here as developers that I’ll explain to you a bit since Ben already let the cat out of the bag about the product. Each time we get a request for more screenshots we do two things: 1) We drink from our glass of scotch 2) We go to our whiteboards and move the release date of the product out by one full week. We do this to be spiteful of course. We have so many products stocked up here just waiting for release but it’s more fun to watch the mania ensue. Coming Soon; Surgery Simulator “Demonstrate that steady hand as you remove the remote control that your dog swallowed from his upper intestinal tract”. We’re still working on the price of this one but let’s just say we’ll be doing a wallet-ectomy on you. Post Office Simulator “You get to live the life through Postal Employee Newman’s Eyes. ‘The mail never stops!’ Stack and sort bag after bag of mail trying to beat your best score.” and finally Department of Motor Vehicle simulator “Take a ticket and get back in line”. We’re hoping to release this one around fall of 2012 but that depends on how many screenshot requests we get. This one is very unique. You can play the worker at the counter handing out tickets. You also get to instruct people to get into the wrong line and then laugh at them as it takes them 45 mins to figure it out. There’s also a level where you have to put your “Next Agent Please” sign up as fast as you can. Beat your previous times. Play with your friends on multiplayer! Who gets to take their 4 hour break first?!
First, let me say that this post represents my opinions and my thoughts and does not reflect the official view of Laminar Research.
I’ll be the first to admit that the news and events that have “leaked” out regarding v10’s release date have created quite a bit of confusion, controversy and general discomfort amongst you guys; our fans/customers etc. I’m sorry to see the drama unfold in this manner. It’s certainly not intentional, it’s not a sign of v10 being delayed further and it’s certainly not a sign of v10 being canceled.
As i’ve said a dozen times already, v10 is very much alive and kicking. It consumes about 99% of all of our (the staff) time. It’s our #1 priority, it will remain our #1 priority and it has been for a long long time. There are many factors that contributed to the original delay of v10. I’m not going to go into internal details but I feel that it’s going to be a better product as a result. We’re not slacking off here. I don’t think there’s a single LR employee who’s put in anything less than a 40 hour work week in the past 3 years. I actually think the average is quite a bit higher and has been for some time.
One of the reasons for this tech blog is to give those of you interested an inside view into what it takes to write a flight simulator. It’s no simple task. In fact, in some ways it is rocket science!
I’m amazed by the amount of attention to detail that goes into XPlane’s development. Just as a quick example, I was recently working on some ATC code and wanted to get a list of the runways at a given airport that had full ILS approaches. I was expecting there to be some kind of database lookup in the simulator that would say “oh runways 06 and 33 have full ILS approaches”. That’s a pretty basic assumption. “It’ll take 2 seconds to wire up” I thought….but that’s not how it works. There is no magical database for ILS approaches. XPlane doesn’t know about approaches directly, it knows about antenna types and location, OBS and glide slope angles. What I mean is, the database says “there’s a localizer antenna facing 036 degrees magnetic at lat/lon x/y and there’s a glide slope at x/y with a 3.5 degree angle.” This made my job a little more difficult because i needed to then compute the geometry of the localizer, glideslope and runways to determine what runway would benefit from a signal in that direction (don’t forget about parallel runways!). That kind of realism is unparalleled. What it means is that if a localizer antenna is offset at an airport because of obstructions (like runway 15R at Boston), XPlane will model the approach angle perfectly just like in the real world and you’ll come in at a slight offset. This is not new, the sim’s always been like this but it’s a new discovery for me. I guess my point is, sometimes even tasks that seem simple on the surface can be a bit more time consuming because we care about realism and the world is not a simple thing to model accurately…and that’s why this blog exists. We like to share with our users how COOL all of this stuff can be.
Getting back on track here, this blog gives you guys an inside look into our world so you have some insight into what kind of moving parts are in there. Our conscious decision to open this kind of dialog with our fan-base is a great thing, but it also can sometimes lead to miscommunications. Sometimes, we might say something in an innocent manner and you might take it out of context and misinterpret what we meant. For that, I’m sorry and we’ll take the blame.
With that said, I must ask and beg and plea that we all think twice before jumping to conclusions, trying to read between the lines and make inferences from quick unofficial statements made in a forum, a blog, facebook etc. Please do not assume that if a 3rd party vendor makes their own prediction of when v10 will ship, that it’s evidence of an official ship date. Please do not assume that if Austin himself says “by the end of the year” that he literally means “the end of the year.” If it shipped tomorrow, that would technically also qualify as “by the end of the year”. And NO, it’s not shipping tomorrow either. I can’t say that I blame people for wanting to hang on our every word and analyze our statements down to the verbiage but as much as I understand it, please try not to continue doing it. Official news, announcement of official features and official dates will be clearly marked as official. You will not need to read between any lines or make any assumptions.
So if v10’s not necessarily shipping in August and if “by the end of the year” does not necessarily mean “the end of the year”, then when is it shipping? The answer is….I don’t know! And that’s why there hasn’t been any official news yet. We’re not thinking about official dates yet because the date is arbitrary to most of us. When we’re all done with the core features and when it seems stable, then it will be released.
And because every post is better with a picture….Here’s a quick visualization of the math behind computing some ILS antenna intersection
s. The green line represents the localizer antenna beam. It starts in the background at the localizer antenna’s location and extends outward at the “OBS” heading of the antenna (note that in this unusual case, the localizer is NOT down the centerline of the runway!). The blue line starts at the glide slope antenna and extends outward at some angle above the earth’s surface. Typically this angle is about 3 degrees. The red line just represents the runway end. The point of this visualization is to see if you were perfectly aligned with the localizer AND the glideslope when you crossed the runway, where would you be? The intersection of these three planes is that pink dot.
