EXPERIMENTAL USE ONLY!!! -- [What?] -- Login to add public annotations [How? >>YouTube].

An author recently asked me what the relationship was between the size of PNG files on disk and the amount of VRAM X-Plane uses to store the PNG file as a texture.  I actually get that question fairly frequently, and the answer isn’t totally obvious.

The first and most important point: the size of a texture on disk in an image file is not the same as its size in VRAM, so changing the file’s size on disk doesn’t save you any VRAM.  (It does save you hard drive space, which might be interesting if you are building a huge orthophoto scenery, or maybe download size, which can be handy.)

The size of an image in VRAM is a function of its dimensions, the amount of color information, an whether texture compression is on.  The formula is basically this:

size = 4/3 * width * height * bytes_per_pixel

The 4/3 term is due to mipmapping – we save progressively smaller versions of the texture to improve the speed and quality of texturing when your image is far away.

Bytes per pixel varies depending on whether texture compression is on:

  • RGB, or RGBA, no compression: 4 bytes per pixel.
  • RGB, compression on (or DXT1 compressed DDS files): 0.5 bytes per pixel.
  • RGBA, compression on (or DXT3/DXT5 compressed DDS files: 1 byte per pixel.
  • Alpha-only: 1 byte per pixel.

That first point might be a little bit surprising to authors: when compression is disabled, you don’t save 25% for getting rid of your alpha channel.  This is because modern video cards round up the texture from 3 to 4 bytes to keep the image size a power of 2.  It is still typically a win to drop the alpha channel if you’re not using it: X-Plane can fill the screen faster if it knows that there is no alpha (and thus no blending) and the RGB-only texture will be half sized when compression is on.

DDS File Size

DDS (Direct-Draw Surface) is a file format designed to mirror exactly what video card want in VRAM.  As it turns out, a DDS file is a good representation of how much VRAM your image uses, because it is already in the format that the card wants – including the 4/3 term.  So if you need a quick and dirty estimate of your texture’s VRAM use at extreme res, the DDS size isn’t a bad proxy.  (Note that when LOAD_CENTER is in use, your texture is reduced in size most of the time.)

PNG File Size

PNG file size is unrelated to VRAM used; PNG files are internally compressed.  In fact, PNG files have multiple possible internal encoding schemes; utilities like PngCrush try all of the encoding schemes to see which one reduces file size the most.  The key is: none of this translates into VRAM savings.  PngCrush may make your downloads faster, but it won’t make your add-ons use less VRAM.

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.

7 comments on “Image Size on Disk and VRAM”

  1. Ben, you left us repaint authors rather hanging from your blog posted from 9/21/10, Revisiting Texture Compression. Are your musings still that? Or will xp10 rendering settings allow uncompressed png texture files to load for liveries?
    thanx for these further DDS vs PNG format comparisons.

  2. It’s not very related with the post, but to read apt.dat on my slow notebook HDD it needs 2.959s (average of 5 runs, always dropping caches on Linux) while the same file can be read with 1.851s if compressed with lzop (also the average of 5 runs; time is already the total of uncompressing + reading the content).

    Since today’s processors are faster than our disks, is it worth (and do you have any plans for this) to distribute optimized PNG files (by using pngcrush/optipng) and other files (like apt.dat and other possible big text files) using a fast decompression algorithm?
    Less things to read = faster loading time (and less space on disk)

    1. Possibly – except..
      – having the file uncompressed is easier for authoring/accessibility.
      – disk read time and seek time aren’t the same … in the cases where I have seen x-plane be disk bound, it’s on seek time; making files smaller (and compressed) doesn’t help that much.

  3. I have two questions along this line. If I have a texture (ortho-photo) and give it a Load_Center in the .pol file, and also want to use it to texture map part of an object, does X-Plane only load the texture once? or does it load it once for the .pol and once for the object?

    Also, ( I think I know the answer) is it possible to use the attr Load_Center in a object at this time? I realize that the object’s LOD will mitigate this in most cases, but some objects like airport terminals have a fairly long LOD distance. Is there any benefit to using it? If so, will XP 10 support this?

    1. First: the sim will load the texture only once, and the behavior is undefined…either the load center will be ignored or the texture will be de-rezed. Using load-center texes in anything but a single pol or ter is not recommended in v9.

      Second: nope – load-cener is not avialable for OBJs yet. We are looking at this for v10 though, as you are correct: the cost of VRAM for a custom airport could be reduced.

Comments are closed.