Texture Management

In OctoPort, I considered two different algorithms for texture management, at first I just thought about using the adaptive cache mechanism to handle textures, but with the variety of texture size and formats it seemed very wasteful. I did some research on the web and came across 3DLabs Virtual Texture management. It sounded really nice (and still does!), and I wished we would get that on graphics hardware soon, but it didn't happen. Managing textures like that in software sounded like a huge task to me at the time, so I implemented something simple. The system I wrote was just managing a total memory use, and using LRU to choose which textures to remove to make room for a new one.

Although simple, it didn't solve the memory fragmentation issue, and could allocate or free memory during a frame, which is expensive. Today, with the MegaTexture technology around, it sounds like it's time to re-design that part of the engine. The system I have in mind uses the Adaptive Cache, with compressed RAM slots. With the slots having the size of power of two square textures compressed with S3TC.

A modern texture manager must be able to find the textures and the mipmap levels required to render the frame. Computing the mipmap levels needed for bilinear or trilinear filtering isn't too difficult. However, anisotropic filtering is going to change the required mipmap levels, depending on the strength of the maximum anisotropy, and the object position/orientation.

Also, to avoid too much waste, it sounds like a good idea to include an atlas capability to the manager: making an atlas with mipmaps is not too difficult. Yet again, anisotropic filtering is difficult to handle. It's likely that the manager will need be told the filtering being applied on the texture to see whether it can be put in an atlas or not. Of course anyone forcing the graphics driver's setting is going to blow the system up, but really, people shouldn't mess with driver settings!

Finally, there's something else I'd like my texture manager to handle, and it is clip-mapping, likely something similar to what's used in iD Tech 5 MegaTextures (except if it uses Unified Texture Management for Arbitrary Meshes). Clip-mapping is the process of loading only a subset of a huge texture which cannot fit the maximum texture size of the hardware.

I have no definitive solution implemented. As I said, I'm writing the FlExtEngine, and so this part will be written from scratch based on the above details.