Mega Textures

No implementation but a good idea ;-)

Given: one large texture 64k x 64k

1. Make a small version of your large terrain texture, something like 1k x 1k.
2. Subdivide your terrain/large texture into patches (i.e. 512 x 512 texture patches).
3. Create a texture cache, i.e. 30 virtual textures of the size of 512x512.
4. Associate each patch with one virtual texture or with 'none'.
4. Render each terrain patch with two textures: the first one is the small terrain version and the second one is the associated virtual texture (or 'none').
5. In your terrain shader, merge these two textures, if the second texture is 'none', just render the first one.
6. Before rendering your patch, check if your 'detail' texture has been cached,else load it using something like LRU (least recently used).


This is just a good idea ;_) Clever usage of mipmapping or other caching algos will improve this technique. The detail textures should be loaded asynchronously.

--
Ashaman
KISS - Keep it simple'n'stupid

Yes that method makes sense. However, one thing that has bugged me.. if you render your terrain as a series of patches, how do you ensure that the "seams" dont appear, where the patches meet? Wouldnt the lighting look odd at those points?

Because the vertices arent welded, the shading cant be even through them, right?

Of course they can! As long as the verts share the same normal and tex coords (even though they are not the same vertex), then all the calculations will be the same for both of them.

Quote:

Original post by Anonymous Poster Quote: Original post by Matt Aufderheide Does anyone have a sample implementation of a basic "mega textures" for terrain only? Or a good idea of how it works? I guess that Doom 3 modders are working on a basic implementation.

Link

I think its a type of Clip Mapping. More links here. [smile]

Quake Wars uses 'Mega Textures' and will be out at some point in 2007 with (I presume) an SDK. There is a Gamedev discussion about it here.

Quote:

Original post by Matt Aufderheide Yes that method makes sense. However, one thing that has bugged me.. if you render your terrain as a series of patches, how do you ensure that the "seams" dont appear, where the patches meet? Wouldnt the lighting look odd at those points? Because the vertices arent welded, the shading cant be even through them, right?

To subdivide your terrain into patches is a common practise to cull your terrain. To ensure that you don't see "seams" you need to duplicate all vertex data (position, color, normal..) at the seams.

--
Ashaman
KISS - Keep it simple'n'stupid

Ok that makes good sense.. but do you reccomend doing it in a external modeller or in the application?

Quote:

Original post by Ashaman73 No implementation but a good idea ;-) Given: one large texture 64k x 64k 1. Make a small version of your large terrain texture, something like 1k x 1k. 2. Subdivide your terrain/large texture into patches (i.e. 512 x 512 texture patches). 3. Create a texture cache, i.e. 30 virtual textures of the size of 512x512. 4. Associate each patch with one virtual texture or with 'none'. 4. Render each terrain patch with two textures: the first one is the small terrain version and the second one is the associated virtual texture (or 'none'). 5. In your terrain shader, merge these two textures, if the second texture is 'none', just render the first one. 6. Before rendering your patch, check if your 'detail' texture has been cached,else load it using something like LRU (least recently used). This is just a good idea ;_) Clever usage of mipmapping or other caching algos will improve this technique. The detail textures should be loaded asynchronously. -- Ashaman KISS - Keep it simple'n'stupid

Can you explain to me step #5? I don't understand what you mean by merging these two textures.

Quote:

Original post by ph33r Quote: Original post by Ashaman73 No implementation but a good idea ;-) Given: one large texture 64k x 64k 1. Make a small version of your large terrain texture, something like 1k x 1k. 2. Subdivide your terrain/large texture into patches (i.e. 512 x 512 texture patches). 3. Create a texture cache, i.e. 30 virtual textures of the size of 512x512. 4. Associate each patch with one virtual texture or with 'none'. 4. Render each terrain patch with two textures: the first one is the small terrain version and the second one is the associated virtual texture (or 'none'). 5. In your terrain shader, merge these two textures, if the second texture is 'none', just render the first one. 6. Before rendering your patch, check if your 'detail' texture has been cached,else load it using something like LRU (least recently used). This is just a good idea ;_) Clever usage of mipmapping or other caching algos will improve this technique. The detail textures should be loaded asynchronously. -- Ashaman KISS - Keep it simple'n'stupid Can you explain to me step #5? I don't understand what you mean by merging these two textures.

just blend them together as you like :)

I guess I don't understand the point of the small texture then. Is it a base texture or is it used like an indexed palletes for look up? Is this similiar to the base texture in splatting?

No, in this case he means a small version of the mega texture. This is used as a sort of mi mapping, so you can have all the pathces have a texture thast will vblend in somewhat, so up close you us ethe virtual texture fomr the mega texture, and far away you us e a blurry version of the whole thing mapped accordingly.

I'm still not quite getting it. Because if you have none in a texture spot then what does that patch have on it? The small texture is just a scaled down version of the large texture so if a patch has nothing in it the small texture will have nothing in it as well.

This is still not quite clicking.

Take a look at the following table:



The global texture is just too large, so we subdivide it into 512x512 large detail textures. Each level represents a mipmap-level and each level represents the same level of detail on screen.
Now lets regard just one patch of terrain.

first case: no detail texture is present
In this case just render the small version of the global texture (marked with '->').

second case: a detail texture is present
In this case the detail textures contain more 'details' down to mipmap level 8x8 than the small global texture. You could simply render the detail texture if it is present, but this would result into seam-artifacts if you regard terrain patches with and without detail texture loaded.
To limit the seam-artifacts it would be better to blend between the two textures. With the assumption that only nearby detail textures are cached it would be best to blend between detail and global texture depending on the view distance. This won't hurt at all because terrain patches which are farther away will access lower mipmap-level and with some tweaking you won't see any artifacts at all.

--
Ashaman
KISS - Keep it Simple'n'Stupid

Quote:

Original post by Anonymous Poster I'd hate to burst your bubble but the whole point to Mega-Texture is that you don't have to break up the geometry. The terrain is one mass of triangles and the texture is somehow blended across the horizon but using only 8MB of texture space in video memory. It's likely that they have a pixel shader that blends various LOD's of the terrain detail; meaning they might have eight 512x512 textures but each texture represents a larger share of the terrain. The last texture is a downsized version of the entire terrain, while the first texture is a high resolution version of the 512 inches around your feet. I know... mind blowing isn't it?

Actually, from what I've seen, it's a lot closer to clipmapping than I think you think (for me, the slam dunk was when I saw that some Doom3 guys managed to display MT's mip levels: it was the exact pattern you'd normally see for clipmapping). You are right though, one point that you mention that the others in this thread mention is that the terrain geometry is, iirc, basically arbitrary according to stuff I've read/heard from Carmack.