Category: Scenery

The Limits of Scenery Precision

What is the limit to how precisely you can build scenery in X-Plane using WorldEditor?

In this picture, I created a runway “OBJ” exactly the same reported size of the runway, in the same location and orientation in WED.  The windsocks are also placed on the exact corners of the runway in WED.  This is a typical “MRI” scenery pack – that is, a test scenery package designed to show how well/poorly the sim is performing.

So what do we see?

• The alignment of the windsocks with the runways is pretty damned good.  It might not be perfect, but it’s awfully close.
• The alignment of the OBJ runway and the real runway below it is not particularly good – the heading isn’t quite perfect enough to stay aligned over a 10,000 foot runway.

This lack of precision is a design limitation – that is, X-Plane does not try to provide unlimited precision in scenery authoring.  (At some point, increasing precision increases file size and processing time, which would have a detrimental effect on overall system performance.)

In particular, X-Plane tries to provide high quality point-to-point matching.  That is, given two locations that are both specified by latitude and longitude, X-Plane tries to get them to be as close together as possible.

What doesn’t work well is trying to correlate a specific location (specified by latitude and longitude) with another location specified by relative location (e.g. from this location, go 50 meters to the west).

Generally, the longer the “arm” of relative location, the worse the precision.  in this example, the runway is specified by the center of the ends, and the windsock locations are specified directly.  Thus the runway corner is on a 25 meter “arm” from the runway end center.  We may pick up a little bit of imprecision on a 25 meter arm, but the correlation is good.

By comparison, the object end is on a 5 km “arm” because it is specified by its center location and heading, while the runway end center is specified directly.  As you can see, over a 5 km arm, a fair amount of error is accumulated.

Thus we can come up with a working strategy for scenery placement:

• When placement precision is important, keep objects small.
• When two scenery elements must be locked together, be sure to use scenery elements that can be specified by exact location and not by a metric distance from another location.
• “Looks close” in WED only means “pretty close.”

The hardest part of this work-flow is using art assets other than objects for large scale features.  But (for example), a draped polygon is better both for precise positioning over a large area and for polygon offset/Z-thrash, so you probably need to use draped polygons anyway.

Global Lighting – What is it Good For?

Poor Tom…he sends me his work in progress (at my demand) so I can more easily investigate sim bugs and I turn around and post it to the developer blog.

Tom is working on the new airport scenery library.  This is something that Sergio had started to work toward with version 9 (you’ll note that in version 9, a lot of the custom elements from LOWI are actually in the library), but with version 10, the goal is to have a complete set of library art assets.  This will facilitate:

• Casual authors creating detail at local airports without having to create their own 3-d models.
• The X-Plane community to share default airport structures in an open source database, the way we already do for taxiway layouts.

The spill lighting in these pictures comes from version 10’s global illumination – there is a light source at the top of each light pole, and it casts light down onto whatever happens to be below.  There are a few reasons why we think this is going to be a great feature for scenery creation:

• It’s really easy to use.  A light source is part of an OBJ (like light billboards now – in fact, the light source is added to an OBJ using LIGHT_PARAM or LIGHT_NAME) so adding lights is as simple as placing objects in OE or WED.
• Since the lights simply throw spill, you don’t have to worry about whether the light is aimed at an object that you can then “draw” lighting onto.
• The lights are fully dynamic – if yo animate the object, the light moves.  If you drive your airplane under the light, the airplane is lit up.

With X-Plane 9 (or any rendering engine that can’t do global lighting) you have to “bake” lighting in order to create night effects.  In other words, you have to draw the light effect onto the textures the light shines onto.  With real lights, you don’t have to set up any baking or complex texturing layout, you just place the light and you’re done.

Not having to bake is good for plausibility.  In real life, light shines all over the place – in the case of the fuel depot picture, the light illuminates not only the asphalt road, but also the grass nearby.  When creating LIT textures, the author is forced to constrain light effects to parts of the scenery that actually have LIT textures.  (We had to do this for X-Plane 9 – the lights on the highway don’t ever illuminate the ground nearby, because we can only light the LIT texture.)  Global lights give you spill onto all sorts of nearby surfaces for free, without setting up a ton of complex baked textures.

(The global lights do not cast shadows – only the sun does that.  The shadow below the airplane at night is a bug – more on that tomorrow.)

What Is the Cost of 1 Million Vertices?

Hint: it might not be what you think!  Vertex count isn’t usually the limiting factor on frame-rate (usually the problem is fill-rate, that is, how many pixels on screen get fiddled with, or CPU time spent talking to the GPU about changing attributes and shaders).  But because vertex count isn’t usually the problem, it’s an area where an author might be tended to “go a little nuts”.  It’s fairly easy to add more vertices in a high-powered 3-d modeling program, and they seem free at first.  But eventually, they do have a cost.

Vertex costs are divided into two broad categories based on where your mesh lives.  Your mesh might live in VRAM (in which case the GPU draws the mesh by reading it from VRAM), or it might live in main memory (in which case the GPU draws the mesh by fetching it from main memory over the PCIe bus).  Fortunately it’s easy to know which case you have in X-Plane:

• For OBJs, meshes live in VRAM!  (Who knew?)
• For everything else, they live in main memory.  This includes the terrain, forests, roads, facades, you name it.

Meshes In VRAM

If a mesh is in VRAM, the cost of drawing it is relatively unimportant.  My 4870 can draw just under 400 million triangles per second – and it’s probably limited by communication to the GPU.  And ATI has created two new generations of cards since the 4870.

Furthermore, mesh draw costs are only paid when they are drawn, so with some careful LOD you can get away with the occasional “huge mesh” – the GPU has the capacity if not everyone tries to push a million vertices at once.  (Obviously a million vertices in an autogen house that is repeated 500 times is going to cause problems.)

But there is a cost here, and it is – the VRAM itself!  A mesh costs 32 bytes per vertex (plus 4 bytes per index), so our mesh is going to eat at least 32 MB of VRAM.  That’s not inconsequential; for a user with a 256 MB card we just used up 1/8th of all VRAM on a single mesh.

One note about LOD here: the vertex cost of drawing is a function of what is actually drawn, so if we have a million-vertex high LOD mesh and a thousand-vertex low LOD mesh, we only burn a (small) chunk of our vertex budget when the high LOD is drawn.

But the entire mesh must be in VRAM to draw either LOD!  Only things drawn on screen have to be in VRAM, but textures and meshes go into VRAM as a whole, all LODs.  So we only save our 32 MB of VRAM by not drawing the object at all (e.g. it being farther away than the farthest LOD).

Meshes in Main Memory

For anything that isn’t an object, the mesh lives in main system memory, and is transferred over the PCIe bus when it needs to be drawn.  (This is sometimes called “AGP memory” because this could first be done when the AGP slot was invented.)  Here we have a new limitation: we can run out of capacity to transfer data on the PCIe slot.

Let’s go back to our mesh: our million vertex mesh probably takes around 32 MB.  It will have to be transferred over the bus each time we draw.  At 60 fps that’s over 1.8 GB of data per second.  A 16x PCIe 2.0 slot only has 8 GB/second of total bandwidth from the computer to the graphics card.  So we just ate 25% of the bus with our one mesh!  (In fact, the real situation is quite a bit worse; on my Mac Pro, even with simple performance test apps, I can’t push much more than 2.5 GB/second to the card, so we’ve really used 75% of our budget.)

On the bright side, storage in main memory is relatively plentiful, so if we don’t draw our mesh, there’s not a huge penalty.  Careful LOD can keep the total number of vertices emitted low.

Take-Away Points

• Non-OBJ vertex count is significantly more expensive than OBJ vertex count.
• OBJ meshes take up VRAM; the high LOD takes up VRAM even when the low LOD is in use.
• To reduce the cost of OBJ meshes, limit the total LOD of the object.

OSM: Is This Legal?

No discussion of OSM would be complete without a discussion of licensing and copyright.  OSM makes this particularly complex because the project is in the process of changing their license from CC-SA-BY to ODbL.  For a full discussion, I recommend the OSM Wiki, but the short version is:

• CC-SA-BY (Creative Commons, Share-Alike, with Attribution) is a license that says that anyone can use a work and modify it, as long as attribution to the original author is maintained and the terms don’t change for the derived work.  This isn’t particularly surprising, it’s a typical “open source” license, similar to the GPL.
• ODbL (Open Database License) is a slight twist: with the ODbL, anyone can use the original data, but if you modify the data, you have to give back your changes.  You don’t have to make your derived works open source though.  (So under the ODbL if you build custom scenery out of OSM, your scenery doesn’t have to be open-source licensed, but if you ‘fix’ any roads, you need to submit the fixes back to OSM.)

OSM is CC-SA-BY now and is working to switch to ODbL.  Basically their lawyers realized that CC-SA-BY is great for images and text, but isn’t actually legal for databases (which is what OSM is).  The ODbL will protect OSM as it is – that is, as a “database”.  Since OSM is a huge open project, the license change is going to take a long time and lots of people will post lots of rants on lots of mailing lists in the process.

Here’s our plan: we are going to make the v10 global scenery abide by both the spirit and the legal requirements of both licenses.  (At least, I hope we are going to try to do this.  I am not a lawyer and wouldn’t mind if this was all a lot simpler.)

• The version 10 DSFs will be CC-SA-BY.  This means that you can modify and redistribute the global scenery DSFs.  In the past, we haven’t officially supported this, but we’ve allowed it to go on in the community.  With version 10, modifying DSFs will be officially okay.  (Please note that copying the sim DVDs will not be okay.  You can modify our DSFs, but we are not inviting anyone to sell pirated DVDs!  X-Plane is still a commercial product!)
• We are encouraging all users to improve OSM directly in the OSM database – we will not accept modified DSFs as a way to fix roads.  (This helps us comply with the ODbL.)
• All of the scenery tools used to create the global scenery will be open source.

This last case is important because we do a lot of processing to the raw OSM data before we create the DSFs.  Technically we are required by the ODbL to “give back” thsoe changes, but the truth is that I don’t think anyone really wants the hundreds of GB of temporary files we create as we process.  So instead we will give back the tools that do that processing, so people can recreate our processed database as desired.  From my discussions with OSM community members, this is apparently an acceptable way to ‘give back’ our changes.

I should say that nothing is guaranteed here.  Heck, it’s even possible that OSM will change its license in a way that screws up the whole global scenery project before we ship.  (This is highly unlikely – I’m just saying that there is legal uncertainty with OSM that we haven’t had to deal with when using other data sources.)  But I think we’ll be okay; X-Plane’s use of OSM (to create a mash-up of OSM plus other data sources like SRTM elevation to create a derived copyrightable work like a DSF) is definitely one of the use cases that OSM wants to make possible.