Tom asked a good question in the comment section of a previous post: what is the difference between DSF mesh formats for v9 and v10. Here’s the story:
Mesh: In X-Plane 8 and 9, the terrain mesh is stored as a set of triangles in 3 dimensions; each corner of the triangle has a latitude, longitude, and altitude. The shape of the mesh comes from the location of those triangles and the heights of each corner.
Mesh + DEM: X-Plane 10 can also handle a new extended DSF with raster (array) data. In this mode, the mesh contains triangles (just like it did) but they contain only latitude and longitude. The elevation for the entire DSF tile is stored in a 2-dimensional array of elevations (a raster DEM). When X-Plane 10 loads this format, it reads the height for each triangle out of the array of elevations to “rebuild” the 3-d triangles at load time.
X-Plane 9 supports only the original “mesh” DSFs.
X-Plane 10 supports both the original mesh DSFs and the new Mesh + DEM DSFs.
Therefore, old scenery from v9 loads fine in v10. But you cannot load the new v10 global scenery in v9.*
Why Did You Guys Do This?
Moving elevation data out of the triangles and into a separate raster layer actually makes the DSF smaller.** That’s a nice-to-have, but that’s not why we did it.
DirectX 11 class graphics cards can enhance meshes on the fly, on the GPU via tessellation. We wanted to shift the DSF elevation mesh toward raster data so that we would have the full source raster to feed into the GPU. In this configuration, we can make a low resolution mesh, give the graphics card the full data and say “go to town.”
If the graphics card can ‘enhance’ the mesh quality, this solves a problem we have now: there is no rendering setting for mesh complexity. Right now everyone uses the same meshes, so we have to limit mesh detail to meet the specs of low-end supported computers. With GPU-enhanced terrain, users with more powerful systems can crank up the detail.
We’re not ready to code this yet, but one first step was modifying the DSF format to be ready for tessellation. We did this with the X-Plane 10.0 global scenery, and a nice side effect was smaller DSFs.
What About MeshTool?
MeshTool 2.0 writes DSFs with the classic “mesh” format, and it uses the v9 global terrain definitions to fill in land classes where there are no custom orthophotos.
MeshTool 3.0 will write DSFs with the new mesh+DEM format, and it will use the new v10 terrain definitions.
Therefore, MeshTool 2.0 will make v9 scenery (that can be loaded in v10) and MeshTool 3.0 will make v10-only scenery.
* There are also a million other v10 0nly features that the global scenery requires that v9 does not support. Besides not supporting Mesh + DEM, v9 doesn’t support the new terrain shaders, the new draped road system, or the new autogen!
** The space savings come from two places: first, we don’t need to save terrain normals. Instead we calculate them since we have the full DEM. Second, we use 7-zip compression, and it actually gets better compression ratios on less heavily encoded data. So the raw raster DEM compresses better than the highly encoded triangulation mesh. The triangle mesh encoding format was designed a long time ago for classic pk-zip, not 7-zip.
