Texture caching systems are designed to overcome the texture budget limitations of 3D games. Only the textures required to display the current scene are held in RAM. When new textures need to appear in the scene, they are loaded from a larger and slower repository, or they are dynamically generated.

For example, textures can be pulled from disk into system RAM or downloaded from system RAM into the video RAM of a 3D accelerator. Textures can be dynamically generated by combining illumination maps with unlit source textures. QUAKE was one of the first games to implement a texture caching system that interacts closely with the 3D pipeline to cache graphics in an efficient manner (see References). DOOM cached textures as well, but its system was more of a solid- state approach, as was the data caching scheme in the 2D side-scroller ABUSE. The source code to both ABUSE and DOOM is now available; see the References at the end of this article. This article is broken into two parts. First, we’ll discuss the nature of texture maps and the issues involved in implementing a texture cache. Then, we’ll look at some concrete implementations of caching systems used in games that are currently under development.

Textures and MIP-mapping
Texture storage is all about MIP-maps. MIP-maps are prefiltered versions of a texture map stored at varying resolutions. To simplify this discussion, we will focus on MIP-maps that are square and are a power-of-two in width (1×1, 2×2, 4×4, ). We will speak of a MIP-map level (or MIP-level) as a nonnegative integer that describes the resolution of a MIP-map: a texture at MIP-map level n is 2n texels square. MIP-level 0 is the smallest size at 1×1 texels, increasing with conceptually no upper bound (though we might voluntarily choose one to ease implementation)

Download pdf Implementing a Texture Caching System