9.18.2007

"MegaTexture" *cough*

I'm sure by now we've all seed the QuakeWars demo. And I'm sure for the past two years that you've been mind-numbingly aware of "MegaTexture" and the spin that surrounds it. I wasn't too impressed with it when it was first announced, and after looking at some videos, I'm even less impressed. (*Rant* In general, I'm also pretty pissed about the hype that this tech is recieving. If anything, Carmack knows how to put media spin on things)

So here's how "MegaTexture" works*:
(* NOTE this is based upon observation and discussion of the technology. I do not have first hand experience with Tech5)
A) Artists Model the terrain environment in MAX. They can texture & uv as much as they want.
B) Upon export, all the UVs and Textures are composited together to create the 1st layer Unique texture. This texture is saved to disk in a chunked format (check here for a description of how this file was once laid out.)
C) The 'Terrain Editor' Loads up the static TIN based terrain geometry, and the new unique texture. In this editor, the designers can place the 2nd layer (splatting) and 3rd layer (decals)
Splatting occurs by the aritist painting in 'blocks' of a given texture, and the system will auto blend the transitions between them. Splats always occur above the 'unique texture'
Decals are instanced based textures, which work just as you assume.

On a whim, all of this data is composited back into the unique texture format.
And there you go! Megatexture! From a tools standpoint, this is not that impressive. (par for the course wrt ID...)

Where this tech does do it's walking is in the efficient management of this 32kx32kx96bpp texture. Console games have been handling Streaming of linear level data for years. Carmack is essentially implementing an already-solved problem with how his levels work. (And LO! To show it off in a driving game? That's as linear a playstyle as you can get..)

Why am I not impressed?
Check this post out; which will eventually point you here.


Let's put things in persepective, Writing an RTS terrain engine is night & day different than an FPS engine. Linear engines (as we'll call them..) give you a great ability to 'predict' what's coming next, which allows the system to begin the streaming process from the hardrive. With some nifty compression, you can pull some large datafiles from disk and have a small in-memory footprint. These types of Out-Of-Core systems are quite common w/ consoles.

RTS games on the otherhand, do not allow that luxury of linearity. For instance, a user can simply click the minimap and bounce to any portion of the map at a given time. For large memory textures, this can wreak havok on your paging mecahnism, as you'll be constantly banging the harddrive for data.

The Halo Wars terrain is essentially a 16kx16k texture; Which is about 3GB of terrain texture data (16kx16kx96bpp) if you represent it in a unique state (ie 'megatexture'). the 360 only has 512MB of memory for your entire game at a given time, and due to CERT requirements, you cannot assume the user has a hard drive. Even at better-than-state-of-the-art compression of 0.25bpp, we're still at 768mb... still too large.

To combat this, we do a number of things:
A) We don't store a unique texture. Rather, we store our per-chunk blend maps and our tile texture representations in memory. All compressed
B) Per chunk we composite the blend maps into a single unique texture and DXT compress it on the fly into an overlaid cache system (360 is very nice, in that it allows virtual memory management of GPU memory)

Granted, we don't get the exact, per-pixel uniqueness that you would get otherwise, but we're working with what the 360 will give us.


Now, if we can just get the artists to use it..


~Main