Make better textures, the 'Power of two' rule & proper image dimensions

Textures and the "Power of Two" rule

There are a couple of fundamental 'rules' to consider when making content for games or other types of interactive media. And whilst ignoring them won't necessarily break a game, doing so does tend to detrimentally effect performance to varying degrees depending on how loosely implemented they are.

The following discusses one of these rules; that of texture size, their dimensions and how these relates to a form of texture optimisation, commonly referred to as the "Power of Two" rule.

What type of games use this rule ^

All of them, because it's an underlying feature of the technology, so "Power of Two" is equally applicable to PC and console games as it is to tablets and mobile platforms; the same fundamentals apply across the board irrespective.

Why do I need to use 'power of two' ^

The "Power of Two" rule is a fundamental necessity due to the way game engines work. There's actually a long history associated with game and content development that has to do with the way computers manage and process data in limited 'chunks', rather than all at once, for purposes of efficiency. These chunks are important in regards to the "Power of Two" rule because they establish a set of hard coded, physical restrictions on media that must be conformed to, else a given games rendering engine will waste resources 'fixing' the assets so they do. In essence "Power of Two" is a form of data 'optimisation', a necessity so images are as efficient and 'lite' as possible, whilst simultaneously providing an appropriate visual experience.

Design note: so what's the problem?. Whilst the resources spent correcting a single texture might be minimal, across an entire level during play, the hundreds of assets loaded and streamed in for use add up quite significantly. And not as a singular event either, as this may happen every time images are loaded, used and dumped in/out of memory when a particularly 'bad' image is needed.

What games would be doing if they didn't resize and fix badly proportioned texture images Power of Two simulated in BLender 2.49

An approximate visual representation, in Blender (2.49 lower, 2.73 upper), of what a games rendering engine would do to a incorrectly sized/proportioned texture when applied to an object if it were not fixed; A) texture loads 'as is' - red indicate 'null' areas of the mesh; B) image is force-resized to fit causing mismatch between surfaces; C) correctly sized texture applied without issue

What is the power of two rule ^

In short it's a set of simple criteria ensuring 2D image assets conform to regulated sizes and dimensions, which typically manifest as; 1) width/height being divisible by "8", and/or 2) width/height that can be doubled-up or divided-down by "2". In other words any image that is "8", "16", "32", "64", "128", "256", "512", "1024", "2048" (or higher for more modern games) pixels in one or more width/height direction, is considered valid and properly optimised for quick loading into a game and processing into memory. These two simple points in practice means texture assets being "64 x 64", "128 x 64", "2048 x 512" and so on.

Design note: modern games have preference for square ("1:1" height/width), or limited rectangular dimensions ("2:1"/"1:2" height/width) for ease of use/speed of loading/processing. This is notwithstanding the additional preference for the use of texture 'sheets' where a single image may contain several areas that are independently mapped to completely separate objects.

For example shown below is what the "Power of Two" rule might typically be in practice for game content. On the left (orange-ish tinted checker) textures are correctly sized ('valid') relative to power of two dimensions - "64 x 64", "256 x 64" etc. On the right (blue tinted checked) textures are improperly sized, the difference being highlighted in red, an area representing the amount of space the textures should be occupying but isn't, which then forces the render engine to scale up or down to the nearest 'whole' or 'valid' unit of measurement.

Design note: depending on the way an engine is coded, and the rules that may be in place to address problems like "Power of Two" conformity, the red areas shown below indicate how much scaling might be needed, the image scaled up or down to the nearest fixed unit. In other words if a texture is 258 x 127 height/width, it may be rescaled down to 256 for height but up to 128 for width because those are the nearest 'whole' numbers relative to PoT. Either/or depends on the engine and whether it has a 'simple' or 'complex' correction system in place, i.e. incorrectly sized images may be universally scaled in one direction, either all 'up' or all 'down', but not both (up and down) - 258 x 127 might be scaled 512 x 128 in such instances.

valid versus invalid texture sizesvalid versus invalid texture sizesvalid versus invalid texture sizesvalid versus invalid texture sizes

On the LEFT are a set of typically valid or recommended sized images (64x64, 128x128, 64x256, 128x256, 256x256). On the RIGHT, invalid or texture dimension not recommended (46 x 60, 120 x 123, 235 x 57, 250 x 111, 239 x 216) - red indicates area of resizing required in-game

Conclusion ^

Although textures might be automatically resized once loaded fixing the technical aspect of images being incorrectly sized, a significant side-effect the process relates to the way whatever was represented by the image itself - a wall, wood, flesh and so on - tends to become blurry, fuzzy, or in some cases significantly corrupted as a result. This happens because in resizing the asset, the necessary data required to fill the gaps so the image conforms to size, has to be extrapolate from what's actually available.

Design note: resizing and extrapolation is done to the detriment of fine detail and overall image fidelity - the freckles of a characters skin, the pattern of fabric on a piece of furniture - degrades as they are stretched across a surface, re-sampled and changed.

For example, an image that's 239x216 (51,624 pixels) is missing the additional 13,912 pixels, which have to come from somewhere, that would otherwise make it a correctly proportioned, and valid, 256x256 image (65,536 pixels). As this extra data does not initially physically exist, the engine looks at what's available and extrapolates as best it can, the missing data, essentially making stuff up. Blurring is the direct result of 13,912 additional pixels having then to be auto-generated and interpolated by the process.

Design note: to put this in perspective, although visually the amount of 'missing' space might appear negligible - the 'red' seen in the above images. In terms of raw pixels however, the numbers can be quite significant, 13,912 pixels discussed above for example are just short of being enough data/pixel resources to display a 128x128 eye texture (at 16,384).

As a consequence texture artists might then assume any number of problems are occurring, from format, exacerbated when using a 'lossy' formats like JPEG, to 3D mesh issues, not being UV mapped properly for example, to rendering problems breaking the image 'because', when in fact it's simply a matter of not knowing about proper texture proportions and the "Power of Two" rule - their images are simply the wrong size.

Design note: it goes without saying (but will be said anyway) the fix to these types of issues isn't to change image format to one with 'better' compression, i.e. a format using 'loss-less' compression like PNG, TGA et-al, usually at the expense of increasing file size a few kilobytes or megabytes. Nor is it to use much larger textures, again at the expense of increasing file size, especially moot where textures are physically resized smaller at runtime. The solution is to pay greater attention to image dimensions so properly comply with "Power of Two" dimension requirements.

Texture artifacts upon resizing

Forced re-sizing of texture assets tends to cause two inherent problems; blurring combined with JPG compression artifacts. On the right a close-up shows increased pixelation issues due to the image being re-sized by the game engine resulting in additional artifacts and aberrations which distort the "3" (when compared to the original below)

Texture artifacts upon resizing

Compression artifacts as a result of using JPG images; when using the bitmap would remain 'as is' (unmodified by the game engine). This means, shown in the close-up on the right, only jpg compression artifacts cause issues - despite the jpg format the number "3" is still relatively clear and distinct