Megatextures

#1 Bryan,

The last virtual texture solution that was in the engine was Clipmaps. These were okay, but I am really not a huge fan, conceptually. My feelings on clipmaps are similar to my feelings on terrain implementations; they are very cool, and I completely appreciate them, I just feel as though they are too specific. A clippmapped auto-LOD terrain system is great, but only if that is what you need. Otherwise it's totally useless.

I think that the next one will be some form of sparse-virtual texture implementation. I think that dynamic SVTs which encompass all scene geometry will be the way forward, because there are several problems which you actually want to solve with the implementation. You have only identified one of those problems: efficient use of data which is too large to fit into a VRAM texture. The other problems that really need solving are: global application of decals without additional geometry, and efficient use of very large unique (ie 3x 2048x2048 textures per model, and there are 10 different models) textures which can fit into VRAM, but really do poorly there.

This is not a problem that is going to be solved with version 1.0 of Torque3D (same with geometry streaming). The good news is that, if you want, you can check out the source code for TGEA (as part of your Torque3D license) and take a look at the clipmap code. While it was created for use with Atlas terrain, it can work with the current terrain with a few modifications, I am sure. It just treats the terrain block like it's one big square with tcoords (0,0) to (1,1).

#2 You can also write a shader 2.0 only version that does not require geometry conditioning and (as long as you do the center point estimation right) put it on almost any model. It sill only does LOD in UV space.

If you want full-on SVT (which is what "megatextures" are in id tech 5/Rage), http://silverspaceship.com/src/svt/ has a great explanation plus sample implementation. You could probably get it up and going on a custom object with static geometry fairly quickly. One possible optimization is to do mip estimation on the CPU instead of doing the GPU readback.

#3 It's obvious that something like this wouldn't be ideal for everyone, especially those that don't need high quality terrain, but with the loss of Atlas (Which was definitely visually superior, if not technically superior) and the steady influx of games like Quake 4, Quakewars, Red Faction: Guerilla, and others that make use of large terrain without any loss of visual quality, we really need something that can at least look like it's trying to compete. A basic implementation of megatextures without any complicated mipmapping calculations can be done quite easily and provides some nice results which function on any modern hardware, however it is true there will be problems such as decals and sub-pixel artifacts. I've not yet come up with a way to handle decals as my implementation isn't exactly megatexturing and probably won't ever be the same as John Carmack's implementation, but I'm pretty sure I'll be able to get away with precalculated mipmaps since I'm fairly certain that is how it was done in Quakewars.

As for shaders I was planning on doing most of the texturing in screen-space and UV space as long as I can figure out how to stream the data accordingly which should make the rendering pretty simple. It's quite possible that I'll still be working on this when T3D is has reached 1.0 as I'm in the middle of a move and don't have any of my books, and I'm sure I've got some misconceptions that will need worked out.

It's quite possible that I'll get bored of this and instead replace the T3D terrain implementation with a geomipmapping system which would help with both texture quality and terrain detail.

#4 The clipmap implementation in TGEA was only good for medium density texture detail. As you pushed the detail levels up you ate more and more texture memory with very little if any improvement in quality. An uncompressed 64MB clipmap stored in non-swappable render target memory was not uncommon.

The MegaTexture in QuakeWars is a much better implementation of what we had in TGEA... but isn't very high detailed. If you look closely you can see they use a repeting detail texture over the megatexture to increase its apparent quality. I believe their limit was a 32k x 32k virtual texture... even on a 1km terrain thats only 32 pixels per meter.

And neither TGEA Clipmaps or MegaTexture supported normalmaps, parallax, etc.

In the end when making decision for Torque 3D it seemed to me that clipmap and SVT approches were overcomplicating the issue for terrain in games. I would assume you might have like... trees, rocks, decals, roads, buildings, etc. All of these will add much more detail to your scene than any terrain texturing approch and their cost is minimal compared to the other choices.

IMO both of those screenshots are examples of poor usage of the tools and not anything defecient with the potential quality of terrain in T3D.

I would look at tweaking the resolution and size of the base textures in your materials. You should be able to get alot more detail in the distance with just the base texturing.

#5

Quote:
I would assume you might have like... trees, rocks, decals, roads, buildings, etc. All of these will add much more detail to your scene than any terrain texturing approch and their cost is minimal compared to the other choices.

Now that's my kind of thinking! The up close terrain is phenomenal, and judicious use of other assets goes a long way in making up for distance rendering.

In the end there are always different needs for different people.

#6 EDIT: This post was just silly

#7 After some test hacking about it looks like writing the shaders are going to be the biggest problem and without my books it's just simpler to alter T3D's handling of it's base texture file, upscaling it, and then hand painting most of it after it's been calculated so I know what should go where. I'll probably expand on the terrain painter to help with this and possibly get around to streaming the texture into VRAM so I can use really large textures, but since I have no plans for using megatextures for anything but terrain it's just not worth a complete implementation.

EDIT: This is the best that I could manage with the textures I'm using after adjusting the size of the base texture image, the texture sizes, and playing about with detail distance vs base texture size. It still looks quite dated and any highly detailed textures would be very hard to work with, but at least the sand looks halfway decent.

#8 @Bryan -

Quote:and clipmaps have never been seen as that great as it only attempts to cheat it without actually using the 10kx10k+ sized textures that megatextures use

As far as i know... clipmaps and megatexture both use huge virtual textures like that... they just have some slightly different implementations. In QuakeWars megatexture was more like clipmaps, but in Rage/idTech5 is more like SVT.

In our last project we had a 32k x 32k png being processed into an .atlas file... the results were pretty nice, but the memory usage was huge (~90MB on the GPU) and detail level wasn't as high as we wanted.

Worse... it took 20 minutes to process the large image into a .atlas file killing any chance of an iterative design cycle for the terrain art.

Quote:it's still texturing something like 1 pixel per 10 units or whatever size I picked when I created this test terrain

Well assuming your baseTexSize in the TerrainBlock is the default 1024.... 1 pixel for every 10 units would mean you have ~10,000 unit (or meter) terrain.

Is that the case here? If not your wasting a ton of texture space in the base map.

Regardless... you do not want 1 pixel per meter resolution in the base texture anyways. The base texture is not ment to give you high resolution texturing. Its only supposed to provide a low frequency coloration which gives the appearence of detail in the distance while breaking up the patterns in the high frequency detail map.

Quote:The terrain could conceivably be made better by hand painting the basetex file that T3D calculates

I considered doing that more directly, but writing a set of painting tools was too much to ask for in this release.

I could add an option to have it never update the base texture... which would allow you to paint it live in another tool.

#9 So is the base texture tiles at all or is it 1=1 with the terrain? so if if the square size is 1 then the base texture is one pixel of color per one grid square?

#10 Here is the best example i have at the moment...




For a scale reference the top of that mountain is like 3.5km away from the player in that image.

This is with the baseTexSize cranked up a notch to 2048 (should be safe on most all video cards). Most of the materials have a base texture size of 400 meters or so with a detail size of 10 meters and detail distance of 300 meters.

Also... all the textures you see on the terrain are the original 256x256 textures from the Barricade demo. Just wait till we put 1024x1024 dds compressed base, detail, and normal maps on this sucker.

For how low quality the original texture maps are in this image... that looks pretty detailed to me even out to 3.5km.

#11 @James

There has been some confusion in the terminology... i welcome suggestions. In particular using base texture for both the cached DDS and in the terrain material settings is confusing.

The base texturing in the terrain consists of 3 parts:

- The resolution of the final composited "base texture".... this is the DDS file it saves in the level folder. It is defined by the baseTexSize field in TerrainBlock.

- The resolution of the base texture in each of your terrain materials.

- The "Size" for the base texture in each of your terrain materials.

How it works is that the cached DDS file is stretched to cover your terrain once. Each of the base textures in your materials are rendered to this DDS with the formula:

scale = terrain_size_in_meters / material_base_size;

So to get back to your question James... if your terrain heightmap is 1024... and your squareSize is 1... and the baseTextureSize is 1024. Then yes the cached base texture is 1 unique pixel per meter on your terrain.

#12 Honestly Bryan, take no offense to this, but I think it may be you who is the biggest limiting factor. When Atlas was around I worked very extensively with it, and since T3D has come out I've been working equally hard with the new system. With that said, the current one far beats Atlas. It's a bit of a different learning curve and a new set of things to learn, but once you do you can really make things visually sing for you.

#13 @Jacob: I'm definitely the biggest limiting factor, but I've found that using the tiles and the terrain painter only gives me a close approximation, at best, to what I want due to the way it's designed.

@Pat: After changing the way I work with the terrain I've managed to get some fairly appealing terrain, however I've found that the terrain painter as is almost works against any chance of getting a really high quality terrain basetexture. Being able to easily turn off the basetexture update would be great, but it would still only be a hack to work around a much bigger problem. Painting the basetexture directly is the only way to really do it right as you can't rotate a texture patch in the painter thus producing some nasty repeating artifacts in the base texture(Never mind that the detail all facing one direction can look even worse). For best results with the terrain painter I'm finding the base texture tile has to be incredibly undetailed and almost one single color to prevent repeating patterns in the background. For best results overall, painting the basetexture to closely resemble the desired texture but without any detail that would produce repeating patterns seems to be the answer. Unfortunately hand-painting the basetexture is very tedious.

No offense, but in that screenshot, while having some nice looking terrain, the textures are terrible. The background isn't bad, but that is probably more luck than anything else since your working from low-resolution textures with no real detail to start with.

One possible solution to the ugly terrain would be to do mipmapping detail tiles (IE. Up to a certain distance is the full quality detail tiles, further along is a larger but lower detail tile, and further still an even larger and less detailed tile). This would transition to the basetexture much better and would allow the basetexture to be used for exactly what it's meant for (IE. distances beyond which any detail would be noticeable).

I'm still working on some textures that transition well between the detail and the basetexture while still getting the color right with the detail applied but I'll post my results when it's done.

#14 Bryan, I think you mean @Tom ;)

Here is terrain from a mission I am poking at. The foreground is terrain, 1024 source textures. (The background looks terrible with no fog, no DOF, no ground cover, etc...so ignore that)


I agree that virtual texturing needs to happen, but I am also in agreement that the limitations of the current technology have not been appropriately presented/documented/demo'd.

#15 @Pat(for real this time): No idea how I managed that :D I must have been writing another response somewhere else at the same time.

It is true that my ability doesn't exactly stretch the limits of the current terrain painters capabilities but I'll still hold to the belief that a virtual texturing system would significantly improve quality for far less work then actually trying to design textures to the current limitations.

Terrain texturing is hard regardless of how the engine handles it. When working from source images any recognizable detail has to be removed and then it has to be filtered to remove any major contrasts in color so it doesn't clash with the lighting or become noticeable in the distance as the tiling becomes more noticeable. I've been noticing that some of what I've been complaining about is actually the result of not using enough unique textures. 3 or 4 textures to cover an entire terrain block will look terrible, but since the terrain can apparently handle up to 256 or more unique textures separate textures can be used for close detail and even for places where just the directionality of the texture would be changed. Megatextures does remove the need for this sort of work-around but it's not the answer to all problems involving terrain texturing.

#16 @Bryan -

Quote:Painting the basetexture directly is the only way to really do it right as you can't rotate a texture patch in the painter thus producing some nasty repeating artifacts in the base texture

If your base texture has visible repetitions your doing it wrong. Your input textures used on the base are way too low a resolution or you have a very small size to it... like under 100 meters.

Quote:No offense, but in that screenshot, while having some nice looking terrain, the textures are terrible.

No offence taken... they are terrible... i said that they were the original Barricade textures (TGEA Demo circa 2005?) at 256x256. Worse 3 of them are the same texture with slightly different tints.

Still... even with that limitation i'm able to get detail in the distance.

Quote:The background isn't bad, but that is probably more luck than anything else since your working from low-resolution textures with no real detail to start with.

One man's magic is another man's engineering. ;) I sort of know how it works so i guess i have an unfair advantage.

Something i've been wanted to post for a while.... nudie shots... of Crysis. :)


First the scene as you would see it in the game....


Now lets turn off everything but the base and detail textures...


Finally... just the base texture...


Now i think this is running at a bit less than normal quality and i just picked a location on the map with a far view distance... so maybe its not as tuned as much as it could be.

Still i think illustrates how well we stack up visually in this one area.

#17 Mmmmm...nice forests with destructable trees. I spent a lot of time shooting trees in Crysis, but I guess this is off-topic.

#18 @Tom: Most of your detail in your screenshot is actually the terrain and not the base texture or detail texture, hence the fact that I say it's more luck that you have a relatively clean base texture(Which using those really low resolution textures are basically a solid color).

Removing Crysis' detail textures and leaving the base texture only shows that the technique used in T3D is similar to the way Crysis does it. Crysis never really had all that great of terrain where they weren't relying on Speedtree to fill things, but it's detail texture isn't following a linear distance based tiling algorithm(It appears to be screenspace based) which greatly improves it's overall appearance when just using the detail texture.

#19 How come the distance terrain looks so much better than the up close terrain? It is exactly the opposite of what you see in T3D.

Also of note: Crysis uses an enormous amount of decals on the terrain.

also just a though how about a base normal map? this would go a long way to improving the distant terrain I think. and L3Dt and most other terrain editors can have then exported.



@Tom
By the way for terrain in Beta 4:

1: Are side projections going to be in?
2: Are decals going to work with lights? IE obey lighting?
3: Was a decision on Konrad Kiss's rule based terrain painting system being implemented ever made and will it be in for it was adopted?

Edited for spelling

#20 deleted.