One user asked me about slow performance with an overlay scenery he created using GMaps.  There are three things you need for fast orthophotos in X-Plane, and unfortunately his scenery is missing one.


I’ve written before about DDS.  They key points here for orthophoto performance are:

  • Since DDS is already compressed, the CPU has to do less work preparing the texture if it is going to be compressed.
  • Since DDS is already pre-minified (meaning the smaller versions of the texture are already computed), if you are not running at ‘extreme’ resolution, the sim can simply load a lower res version.  With png, X-Plane must load the full size version and scale it down on the CPU.
  • Since DDS is already pre-minified, the sim doesn’t have to compute those minified versions of the texture on the CPU.

All of these things lead to much faster texture load times with DDS.


LOAD_CENTER is a directive that can be put in a .pol or .ter file to tell X-Plane at what location the texture needs to be at maximum resolution; X-Plane will reduce the resolution of the texture as you fly away from that point.  LOAD_CENTER is important for orthophotos for a few reasons:

  • It saves VRAM, since textures that are far away won’t be loaded at full resolution.
  • When combined with DDS, it improves load time.  Since some textures are loaded far away, they can be loaded at lower resolution, which (per above) is quick for a DDS file – less data, less load time.

Note that LOAD_CENTER causes X-Plane to reload the textures while you fly, so it requires at least one extra core to work well.  It’s really important to use DDS with LOAD_CENTER; otherwise that reload time can get expensive.

Use a base mesh, not draped .pol overlays.

This is probably the most important thing: if you want to cover a lot of area with orthophotos, you need to rebuild the base mesh using .ter files, not cover it with .pol files.  There are a few problems with using .pol files:

  • Draped polygons are only ‘built’ for areas relatively near the airplane.  So even under ideal circumstances, they are going to disappear in the far view.  This way of using them (only when near the airplane) is a memory savings based on their intended use: for small surface areas like airports.
  • Similarly, since the draped polygons are being built and destroyed as you fly, the amount of extra CPU work while flying is quite a bit higher with .pol files than with a base mesh (which only has to page the actual terrain).  So a computer that might be fine paging .ter files can get behind in its work for .pol files.  (Authors often use .pol files because they are easy to work with – specify a rectangle and X-Plane does the cutting and slicing…well, that work is happening while you fly, burning up CPU power that could be used to page the orthophotos.)
  • Since .pol files cover the base mesh, you pay for your mesh twice – once when X-Plane draws the base mesh and once when it covers over it with polygons.  This means twice the VRAM used to draw a frame and twice the fill rate.

If you want high performance orthophotos over an area any larger than an airport or down-town, please use .ter files!

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.

5 comments on “Three Things You Need for Fast Orthophotos

  1. Hi Ben,

    thanks for the post, I’ve learned the points you’ve mentioned the hard way 😉
    I still have 2 questions related to this topic:

    1. Is it possible to have multi-sized polys with ortophoto texture in the base mesh? I think yes but haven’t had time to test it yet. Reason is that raw orto I have is in resolution of 512×512 what means tons of small files. To cope with this, I’m merging them up to 2048×2048, but on boundaries I cannot do it and have also 1024×1024 and 512×512. Will this work?

    2. Assuming I already have .ter files generated, what is the easiest way to generate dsf from them?



    1. 1. Yes, you can definitely have different sized orthophotos – just make sure the LOAD_CENTER directive has the real sizes of the real orthophoto in both meters and pixels.
      2. I don’t know. If you use MeshTool, it does both the DSF and .ter files, but I would not call MeshTool easy to use. A .ter file doesnt’ really have enough info to build the whole DSF.

  2. Is it possible to rebuild/patch a base terrain file using .ter files for only part of a tile, or does it have to be done for an entire tile?

    1. The end result _must_ be the entire base mesh. The only tool set that LR provides is MeshTool, which builds base meshes from scratch – it’s the only tool chain we have.

  3. Just tried to convert my ortho pols for KLAX from PNG to DDS and Grinder gives me the error that it can’t convert it. Is this because they are 2048 x 2048?


Comments are closed.