Observations on Manual Caching of photogrammetry

I have just started to use the Manual Caching feature in MSFS v1.29.30.0. I was wondering, “just how much data does this feature actually use?”. Here are some numbers.

The manual caching system includes 3 levels of detail, “Low”, “Medium”, and “High”. The user decides which of these three levels are desired, then by zooming in or out, the system will show one of three grids. The Low Quality uses a grid of tiles that are about 3,840(±2) meters on a side, covering about 14.75 square kilometers of land. I determined this by comparing the Bing map that MSFS uses, to the same positions on Google Earth, which has tools for measuring distances and areas. The Medium quality tiles are 480m on a side = 230,400 sq. m, and the High quality tiles are 60 m on a side = 3,600 sq. meters.

  1. Caching scenery in a non-urban area, specifically, Death Valley National Park in California.

Furnace Creek Visitor Center:
1 tile at Low quality = 2.1 mB = 7.07 m² / byte
36 tiles at Medium quality = 993.33 kB = 83.33 m² / byte
15 tiles at High quality = 897.59kB = 0.0602 m² / byte

Eureka Dunes:
1 tile at Low quality = 1.79 mB = 8.325 m² / byte.
1 tile at Medium quality = 729.11 kB = 0.316 m²/byte.
1 tile at High quality = 695.35 kB = 0.00518 m² / byte.
The difference in data density/unit of area: High is 61x the density of Medium, and Medium is 26x the density of Low.

  1. Caching scenery in Urban areas around Los Angeles, California.

4 Low quality tiles = 3.33 mB = 832,500 bytes/tile = 17.71 sq. m / byte
256 Medium quality tiles (same area as the Low quality) = 38.36 mB = 149,844 bytes/tile = 1.54 sq.m / byte
16,384 High quality tiles (same area as Medium and Low tiles) = 1.36 gB = 83,008 bytes/tile = 0.043 sq. m / byte

  1. And here’s one other dataset of an Urban area that I am very familiar with: San Francisco (the city itself, and the northern portion of San Mateo County south to KSFO).

28 tiles at Low quality = 8.13 mB = 290,357 bytes/tile = 50.78 sq. m / byte
1792 tiles at Medium quality = 176.11 mB = 98,276 bytes/tile = 2.344 sq. m / byte
114,688 tiles at High quality = 11.5 gB = 100,272 bytes/tile = 0.0359 sq. m / byte

In analyzing the data, it can be seen that the numbers are consistent in the two urban areas and at Eureka Dunes: the density of the data / land area covered at each quality level increases as the quality increases, but the data for Furnace Creek is less dense at Medium quality than it is at Low. I can’t explain this, except to assume that either the program is downloading the wrong data at this location (unlikely), or maybe the Bing database has no data at this location at Medium quality and is defaulting to a download of the Low quality data.

Furnace Creek is a partially developed area: there are several buildings, roads, parking lots with solar panel shade roofs over them, and two campgrounds, and the Bing Database has street-level photogrammetry of the area as of June 2015. Whereas Eureka Dunes is a wilderness area with no street-level data.

The question then really comes down to this: “What data is actually being cached?”. Aerial Photogrammetry typically contains raster pixels with color and luminence values, and either an elevation coordinate for each pixel, or a digital elevation model for the whole area. But does the Los Angeles data set contain street-level photogrammetry also, whereas the Death Valley data set is aerial photography only? Since the data in the manualcache.ccc file is all compressed, there’s no way to tell what it is just by looking at it in a Hex editor.

Caching Bing scenery data has it’s good and bad points. The good:

  1. It does provide a more accurate color map for the terrain than what’s built-in to the sim, but sometimes the Bing data doesn’t agree with the built-in scenery as to location: for example, roads may be offset laterally by a noticeable amount, areas of vegetation, or large individual trees, will show as green areas in the Bing data, that don’t correspond with AI-generated trees, which can be a bit disconcerting when flying low and slow.
  2. The colors of the terrain in the Bing data can be very different than the built-in scenery colors, and the boundary between default scenery and cached Bing scenery will be a strait line at the edge of the tile(s) that can extend for dozens of miles across the landscape - however large an area you defined to cache.
  3. The Bing data is just a color map - it doesn’t change the texture of either bare ground or man-made surfaces, and in urban areas, it may actually make buildings look worse; the AI buildings are generally of pleasing, smooth colors and textures, and while they are obviously “generic” and not hand-modelled from photos of the actual buildings in most cases, they look a lot better than the AI buildings in FSX. But in San Francisco, I’m sure if the city looks “better” with Bing data, in terms of colors, than the default city colors. The biggest problem is that 3-D surfaces and edges of buildings look crisp and sharply defined in the default scenery, but when you overlay Bing photogrammetry on top of them, everything looks “fuzzy”, and a lot of the buildings have trees growing right up out of the roofs.
  4. Caching the Bing scenery for an entire city at High quality takes a huge download, 11.5 gB for San Francisco, and I’m convinced that it was an actual “improvement”. Medium quality might be a better option, if it still includes the landmark buildings that are missing in the sim, like Coit Tower, the Transamerica Pyramid, and the Twin Peaks TV Tower.

That’s useful in terms of size but what data are actually being downloaded?