The Future of Precomputation

My previous post announced that a previously pre-computed operation (setting up the elevation of a DSF) will move into X-Plane in version 10.  We have multicore and we can save some space and improve quality.

This led one commenter to speculate as to whether the entire meshing process can move into X-Plane.  Unfortunately it cannot; a lot of other scenery creation processes are tied to pre-building the mesh, and some of those are still very, very slow.  But it does beg the question of how more we might move into X-Plane.

The Original Precomputation Decision

The original DSF strategy (designed for X-Plane 8.0 a long time ago) was to pre-compute all of the difficult problems for scenery tiles so that X-Plane could simply load the data and draw it.  This got us four things:

1. We could use expensive algorithms to build scenery without hurting sim performance.
2. We could pre-optimize the scenery for fast frame-rate, even if those optimizations were slow to compute.  (No one cares if building the scenery takes longer, that’s done before your DVD is burned.)
3. In some cases, we could reduce data size if the finished computed output was smaller than the input files.
4. Scenery is deterministic – because the work is done ahead of time, changes in the sim don’t affect how scenery looks.  New scenery technology mostly goes into the off-line scenery generator, which means less backward compatibility work.

The down-side of this decision was that we didn’t have a good way to integrate or modify scenery data on the fly.  Changes in apt.dat files, for example, are not reflected in the scenery, since the scenery is already “fully baked” when the sim boots.

From Precomputation to Multicore and GPU

With X-Plane 10 we’re doing a few things to move rendering work from “ahead of time” to “while you fly”, using multiple cores and the graphics card for the work, since those are areas where computers have gotten a lot more powerful.

• In X-Plane 9, terrain is selected by slope (among other things) – this is why you see steep cliffs and moderate scree above grass and forests on a mountain side.  In X-Plane 10, some of this happens on the GPU – we build a single shader with three terrains, and the GPU picks amongst the terrain on the fly.
• In X-Plane 9, we pass the raster elevation mesh to the DSF loader, rather than bake it into the mesh.  Eventually we may be able to pass this data directly to the GPU.

These two techniques are meant to someday play together: if the GPU has the elevation and knows how terrain changes with slope, then we can have detailed terrain on the GPU without bogging down the rest of X-Plane.

Going Further

How might we further push this technology?  I can imagine that at some point, if the sim can arbitrarily increase the triangle density of a mesh using the GPU and the raw elevation data, then we could reduce the triangle density in the DSF to only the triangles needed to represent land class changes, saving DSF space.

Using a triangulation to represent polygonal vector data isn’t as crazy as it might sound; there are a number of computer algorithms that subdivide polygons into triangles to lower the computational cost of processing them.  (We even use one such algorithm to simplify complex polygonal shapes – see MapHelpers.h in the scenery tools code for the scary details.)

So in the long term the triangle mesh that drives X-Plane scenery can change from an approximation of elevation (with terrain along for the ride) to an optimized way to store terrain polygons (with elevation to be applied later).

Here’s a clearing house of past links on the topic of precomputation and global scenery:

• Why Does the Global Scenery Take 6 DVDs?
• Precomputed Scenery – the Good and the Bad
• Algo-Gen
• You Can’t Unbake a Cake

About Ben Supnik

Ben is a software engineer who works on X-Plane; he spends most of his days drinking coffee and swearing at the computer -- sometimes at the same time.

View all posts by Ben Supnik →