WTF is a clipmap?
by Thomas Buscaglia · 06/09/2007 (10:08 am) · 18 comments
Hey, guys. I was recently sentenced to port the Atlas clipmap to Torque X terrain. Now that it's done I thought I'd take a couple minutes to to talk a little about the concept and implementation.
What is a clip map?
Hello, Wikipedia....
What this means is that you can effectively have a freakishly huge virtual texture for a very small fraction of the memory cost. This has obvious implications for terrain, which is why I was forced to implement it.
How does it work?
You take a stack of textures the same size and fill them with texture data sampled from descending mip levels of the virtual texture. What you get is a series of textures of degrading quality. Each one represents a larger area of the virtual texture. This set of textures is the clip stack.
If your clipmap textures are 512x512 you can effectively represent a 16384x16384 virtual texture with only 6 clip stack levels. The first level would be a 512x512 piece of the virtual texture that's closest to your viewpoint, the second level would be a 512x512 representation of a 1024x1024 area of the virtual texture closest to your viewpoint, and so on and the 6th level would be a 512x512 representation of the entire 16384x16384 virtual texture.
Because the texture data in the clip stack is only relevant to the areas around you, you have to recenter the clipmap when you viewpoint changes. Below you can see a clipmap with a simple debug texture being drawn on a terrain. Each clip level's checkerboard size is the same size across the texture space to make the level transitions more obvious (4 squares on one level will appear the same size as 1 square on the next level when drawn on the terrain).

To make things more efficient, instead of updating the entire texture for a clip level, clipmaps take advantage of toroidal mapping - meaning they rely on the fact that textures coordinates can wrap. When a clip level is recentered, the clip map calculates which regions of the texture need to be filled with new data and only updates those regions. Below is the same debug texture, now toggling between three colors each time it performs an update on a section of the clip level texture. Each different color rectangle is a single region update to a clip level's texture (notice that the lowest detailed level is never updated).

As a result of using this method, instead of the seams of the source texture region that's in a given clip level being along the edges of the texture they move through the texture space and the shader compensates for that offset in the texture coordinates at render time. Below are snapshots of all 6 512x512 clip levels of the clip stack described above from highest to lowest detail.






And below, a hideuos F terrain exported from TGE and imported into Torque X with the above blender clipmap applied.

That's all for now. Hope someone found this interesting.
If you'd like more information on the topic, there's a pretty detailed paper
here.
What is a clip map?
Hello, Wikipedia....
Quote:Clipmapping is a method of clipping a mipmap to a subset of data pertinent to the geometry being displayed. This is useful for loading as little data as possible when memory is limited, such as on a graphics processing unit.
What this means is that you can effectively have a freakishly huge virtual texture for a very small fraction of the memory cost. This has obvious implications for terrain, which is why I was forced to implement it.
How does it work?
You take a stack of textures the same size and fill them with texture data sampled from descending mip levels of the virtual texture. What you get is a series of textures of degrading quality. Each one represents a larger area of the virtual texture. This set of textures is the clip stack.
If your clipmap textures are 512x512 you can effectively represent a 16384x16384 virtual texture with only 6 clip stack levels. The first level would be a 512x512 piece of the virtual texture that's closest to your viewpoint, the second level would be a 512x512 representation of a 1024x1024 area of the virtual texture closest to your viewpoint, and so on and the 6th level would be a 512x512 representation of the entire 16384x16384 virtual texture.
Because the texture data in the clip stack is only relevant to the areas around you, you have to recenter the clipmap when you viewpoint changes. Below you can see a clipmap with a simple debug texture being drawn on a terrain. Each clip level's checkerboard size is the same size across the texture space to make the level transitions more obvious (4 squares on one level will appear the same size as 1 square on the next level when drawn on the terrain).

To make things more efficient, instead of updating the entire texture for a clip level, clipmaps take advantage of toroidal mapping - meaning they rely on the fact that textures coordinates can wrap. When a clip level is recentered, the clip map calculates which regions of the texture need to be filled with new data and only updates those regions. Below is the same debug texture, now toggling between three colors each time it performs an update on a section of the clip level texture. Each different color rectangle is a single region update to a clip level's texture (notice that the lowest detailed level is never updated).

As a result of using this method, instead of the seams of the source texture region that's in a given clip level being along the edges of the texture they move through the texture space and the shader compensates for that offset in the texture coordinates at render time. Below are snapshots of all 6 512x512 clip levels of the clip stack described above from highest to lowest detail.






And below, a hideuos F terrain exported from TGE and imported into Torque X with the above blender clipmap applied.

That's all for now. Hope someone found this interesting.
If you'd like more information on the topic, there's a pretty detailed paper
here.
About the author
Formerly GarageGames designer and gameplay/engine programmer of 5 years. Founder and President at Flying Mongoose Labs, Lead Gameplay Engineer and Senior Designer at LumaArcade, head of the Las Vegas chapter of the IGDA.
#2
Terrain is groovy stuff. Perhaps tonight's bedtime reading will be the Atlas source :)
06/09/2007 (8:26 pm)
I must say, that was an interesting paper.Terrain is groovy stuff. Perhaps tonight's bedtime reading will be the Atlas source :)
#3
06/09/2007 (9:50 pm)
Awesome write-up, Thomas. Thanks for taking the time to put together all the visuals and explanations.
#4
06/09/2007 (9:51 pm)
Oh yeah - this is the same basic tech as Quake Wars is using for MegaTexture.
#5
06/10/2007 (11:00 am)
Very cool!!
#6
06/10/2007 (11:10 am)
From my experience it seems that the clipmap is great with huge unique textures, but is not as well suited to blender terrains. In a blender terrain the clipmap imposes an artificial resolution limit and sucks up CPU cycles filling the clipmap stack. In that case it seems like a poor trade off of CPU time and resolution for video card fillrate.
#7
06/10/2007 (5:39 pm)
*drools*
#8
06/10/2007 (7:01 pm)
@Tom - Actually, the blending is all done on the GPU. Render to texture during rect updates instead of reading from cached data. It's a little tricky in XNA because you have to use a RenderTarget2D object instead of just using a texture. Fill rate is optimized by calculating which clip levels each terrain chunk actually needs and batching them. I got a huge performance boost on my x300 here at the office (huge = 100%+), so I guess it depends on the implementation.
#9
My beef with the clipmap in TGEA is that the "virtual map" size is limited by the clipmap size. This keeps us from having tightly repeating terrain textures in the blender.
Your probably thinking... "Why the hell would you want your textures to repeat more? Doesn't that look like ass?". It actually looks great if you repeat your detail texture at a very low frequency over the terrain... sort of what Brian did over here.
The results are really freaking good...


This "macro detail" texture works better in a blender terrain as it is not blend layer specific unlike the common complaint about using detail textures.
06/10/2007 (7:50 pm)
@Thomas - Is this example here a blender terrain or unique texturing? My beef with the clipmap in TGEA is that the "virtual map" size is limited by the clipmap size. This keeps us from having tightly repeating terrain textures in the blender.
Your probably thinking... "Why the hell would you want your textures to repeat more? Doesn't that look like ass?". It actually looks great if you repeat your detail texture at a very low frequency over the terrain... sort of what Brian did over here.
The results are really freaking good...


This "macro detail" texture works better in a blender terrain as it is not blend layer specific unlike the common complaint about using detail textures.
#10
This is because the clip map effect uses a vertex shader to calculate when to fade between clip levels. If you try to blend between clip levels between verts on a mesh you get visible wrapping of one of the clip levels because the fade doesn't account for surface area between verts. That's the only limitation and it can easily be solved by adding more vertex density to your terrain or decreasing the distance between verts, rather than increasing the clip stack depth (essentially, shrink the terrain - which sounds limiting, but I think we're going to have support for multiple terrains per level to allow people to create vast landscapes).
There might be another solution involving clip level alignment against edges, but I haven't experimented with that at all.
06/10/2007 (9:03 pm)
I see what you're saying. In Torque X you can tell the clipmap how many times you want to repeat the base textures and it will generate the clip stack accordingly. If you double the repeat count, the clipmap will generate a deeper stack (tested up 1024, but there's no hard limit). There is, however, a limit on the amount of detail you can get away with using a clip map with our current implementation, but it's based on vertex density, not clip stack depth. This is because the clip map effect uses a vertex shader to calculate when to fade between clip levels. If you try to blend between clip levels between verts on a mesh you get visible wrapping of one of the clip levels because the fade doesn't account for surface area between verts. That's the only limitation and it can easily be solved by adding more vertex density to your terrain or decreasing the distance between verts, rather than increasing the clip stack depth (essentially, shrink the terrain - which sounds limiting, but I think we're going to have support for multiple terrains per level to allow people to create vast landscapes).
There might be another solution involving clip level alignment against edges, but I haven't experimented with that at all.
#11
Well the other option here is to allow per-blend layer detail maps. If the clipmap is that much of a performance gain then using a unique detail texture per layer shouldn't be that much of a burn and would resolve my issue just as nicely. You can also fade the detail map out based on the clipmap level, so that it is only really used on the closer more detailed areas.
06/10/2007 (9:27 pm)
@Thomas - Yea that jives with what i was seeing in Atlas.Well the other option here is to allow per-blend layer detail maps. If the clipmap is that much of a performance gain then using a unique detail texture per layer shouldn't be that much of a burn and would resolve my issue just as nicely. You can also fade the detail map out based on the clipmap level, so that it is only really used on the closer more detailed areas.
#12
I'm thinking we'll probably go the range-based route with TX. If I'm feeling fancy I might add support for multiple detail textures (one per base texture) if it's not too slow in XNA. I guess you could just specify the size in texels you want the detail map to be, then whenever it updates the smallest layer that would fit the detail map, you would update that aswell. Hmm...
06/11/2007 (1:42 am)
I think Atlas does that (the detail texture only draws to a certain distance), but I could be wrong. The TX terrain doesn't support detail maps yet, but it's something we plan to add at some point, so this is valuable feedback. I'm thinking we'll probably go the range-based route with TX. If I'm feeling fancy I might add support for multiple detail textures (one per base texture) if it's not too slow in XNA. I guess you could just specify the size in texels you want the detail map to be, then whenever it updates the smallest layer that would fit the detail map, you would update that aswell. Hmm...
#13
06/11/2007 (1:56 am)
@Thomas - Please feel fancy... support per base texture detail maps. :)
#14
06/14/2007 (11:40 am)
would that be back ported to Atlas for TGEA?
#15
06/23/2007 (6:03 pm)
Thomas, Atlas does draw detail textures only to a fog limit specified in the shader. However, it still uses only one detail texture. Having a seperate shader applied to each base texture used on the terrain would be great, if amazingly expensive. If I understand correctly, Legacy terrains in TGEA use RendertoTexture for realtime blending. If this is the case, would dynamic shadows and lighting be somewhat practical?
#16
06/24/2007 (2:12 am)
If you used a 32 bit texture and each detail (for the four textures) was using an 8 bit detail texture (black and white for blending purposes) then you would be able to get a decent looking effect with differnet details on each of the four textures. Problem is getting it to work. I have made a couple of attempts at it, never could get it to work.
#17
however having a 4 sepperate sets of these for blended atlas terrains I would think would require atlas blended being a sepperate class. then again I'm not a programmer.
06/24/2007 (10:21 am)
I'm not sure I follow I have to detail textures on my Atlas terrains. I have not tried it on a blended terrain though. I also have implemeted the resource that adds then to the editor so you can change and adjust them from there.however having a 4 sepperate sets of these for blended atlas terrains I would think would require atlas blended being a sepperate class. then again I'm not a programmer.
#18
06/24/2007 (11:05 am)
Well, what I'm talking about anyway is using a custom material for each texture on the terrain. In Atlas this probably wouldn't work well, but in Legacy it might work nicely. 
Torque Owner Dan MacDonald