Recently, I began considering how I would go about rendering the planet in Myriad. I want a large (although not full planetary scale) planet, with a good looking texture spread across it - one thing that really annoys me about landscapes in games is repeating textures so I'd like to avoid that. Also, I want to be able to paint decals on the landscape.

I thought about this for a while and I stumbled across megatextures (John Carmack, ID software) and sparse virtual textures, both of which are the same thing (mostly). The idea here is that rather than taking a small texture and painting it across the planet multiple times, we have a single massive texture and only load into graphics memory what is actually needed on screen.

So that's rather cool, using this technique we're basically unlimited by how big the textures can be, the main problem is going to be storing them on hard drive! This means no repeating of textures at all, and the texture can be modified for unique decals painted onto the landscape with almost no extra overhead.

How does it work? Well it's really rather simple, first of all we need somewhere to put the loaded data, so we have a large texture which I call the DataTable, this datatable is about 2-3 times the size of the screen (which may sound large, but we can load all texture data into here and the amount of video memory used never changes. This data table is divided (in your head) into pages, I'm using 32 or 64 square pages. Texture data is loaded into the DataTable texture pages at a time, pages have no relationship at all to the adjacent pages, they're laid out randomly. How to access this data? Well that's really rather simple too, another texture is created which I call the IndirectionTable, this table has one texel for every page in the DataTable, this texel contains an offset and a scaling factor - now to read texture data you simply sample the indirection texture using your normal texture coordinates, this will retrieve the offset and scaling factor for you to modify texture coordinates by to find the appropriate pages in the data table, which is then sampled and returned. So, simply using 2 texture reads and a little bit of maths, we can support textures up to any size, with a low memory overhead.

What're the downsides? Well obviously maintaining the data in the data table has an associated CPU overhead, and streaming all that data from system memory to video memory will consume precious bandwidth, which may or may not be a problem.