Textures for Mobile Platforms

Overview

This document provides an overview of the special considerations that must be taken when creating textures for mobile platforms. Mobile graphics hardware works with different formats and handles textures differently than normal PC graphics hardware. By taking the necessary precautions and creating textures accordingly, many obstacles can be avoided.

PVRTC format

Many mobile devices (including all iOS devices) do not support DXT textures (which make up somewhere around 99% of Epic's textures). PVRTC is ImgTec's PowerVR texture format. There are two PVRTC formats, PVRTC2 and PVRTC4, which are 2- and 4-bits per texel, respectively.

The minimum texture dimensions for the PVRTC formats are:

Conversion

To use compressed textures on PVRTC-supporting devices, we need to convert the DXT textures to PVRTC. This is controlled on a per-game basis with the following setting in your game's Engine.ini:

[MobileSupport]
bShouldCachePVRTCTextures=True

If it's set, we convert all DXT textures to PVRTC format. DXT1 textures (4 bits per texel) are converted to PVRTC2 and DXT3 and 5 (which are 8 bits per texel) are converted to PVRTC4. This means that textures will be half the size overall. There is a texture setting that will force PVRTC4 for DXT1 textures if you really need the higher quality.

Caching

Converting to PVRTC is very slow, so in general DXT textures are converted to PVRTC format at package save time, and cached along with the DXT data in the source packages. At cook time, the DXT data is thrown away, and the PVRTC data replaces the DXT data as the mip data to use. Cooking for other platforms will simply toss the PVRTC data.

If there is no PVRTC data cached at cook time, the cooker will convert to PVRTC, but it won't cache it in the source package (since the cooker doesn't modify source packages), so it will do the conversion every time you cook.

There is a worse-but-faster PVRTC compression method that is used when the cooker does the conversion, or on lightmaps when you do non-Production quality lighting. This is just to speed up iteration for non-final textures. This faster compression method typically does not make shippable-quality textures.

Non-square textures

PVRTC textures in iOS must be square. As such, the PVRTC compression code in UE3 will make sure that the textures are square by row or column duplicating. So, a texture that looks like:

would turn into:

The UVs that you use in code/content won't change. Even your HUD UVs don't change (which are in texels) - base them on the original texture sizes (this makes your code portable, you never need to know that the textures are being resized).

However, even though the textures are converted automatically to square, this means that you can very easily waste memory by having too many non-square textures. For instance, if you have 2 512x256 textures, they will turn into 2 512x512 textures. If you can pack the 2 rectangular textures into a single 512x512 texture, then you will only have 1 512x512 texture after conversion.

Lightmaps

Lightmaps often create non-square textures. If you specify the following .ini setting, a lighting post-process will attempt to repack lightmaps into square textures:

   [DevOptions.StaticLighting]
   bRepackLightAndShadowMapTextures=True

You can disable conversion of lightmaps to PVRTC on save if you specify -nopvrtclightmaps on the commandline.

Texture streaming

Texture streaming is currently disabled on mobile devices (the ES2 renderer does not currently support recreating textures).

Texture clamping

Currently all textures will wrap at their edges. It has not yet been an issue for us.

sRGB / Gamma

Gamma Correction is supported on mobile devices, but can cause performance issues on all but the most powerful devices. See the Gamma section for information on creating content for use with non-gamma corrected devices.