In the game I'm working on a large portion of it will take place on the surface of Mars. Since it will quickly get boring to repeat the same texture over the whole landscape I will need a way to vary the texture across the surface. Because it is unfeasible to store one texture representing the whole landscape I will need some way to have textures transition smoothly. The way that this is usually done is through alpha blending but I don't understand how this is implemented. My shaders take one texture made of several components (diffuse, normal, height, specular) per object. The only way I could think to make alpha blending work is to take multiple textures as inputs but then I would have no way of knowing how many textures are being blended and would need a finite limit. Would I need to store multiple sets of tex-coords in the model format? How is texturing usually implemented on large landscapes? Would it make more sense just use to sets of tiled textures and put transition textures between them?
Texturing big landscapes
Yes, terrain texture splatting uses alpha blending to achieve its look, it also uses multiple texture lookups per pixel fragment, but a lot of terrain engines use it and it can look good. The usual limit is 3 blend maps, each with 4 (a,r,g,b) channels, which yields 12 textures which fits nicely within even PS 2.0's 16 texture lookup limit. You don't need multiple texture cords in the model, nor do you need to input multiple texture cords to your VertexShader. You can produce the multiple texture coordinates inside the Pixel Shader using some arithmetic.
So the other method you suggested is something I've seen in Dekaron Two Moons terrain, its a tile-based terrain engine and either an artist or a pre-process tool generated bitmap images for all the different kinds of material blends (grass to rock, rock to sand, etc). Personally I think the terrain texture splatting is more versatile and looks better.
One thing you can do, which I've seen the Dark Age of Camelot terrain engine do, is use the high detail terrain splatting for terrain patches within a close radius of the camera and then just stretch a single large LOD texture across all the further away terrain patches. If you select the distances correctly, you won't even notice any seams unless looking straight down on the landscape.
You can increase the amount of textures you can use (and performance?) by drawing the terrain in chunks, and for each only activating the textures that particular chunk uses.
You will likely not use every single texture in every single chunk so this might allow for a larger selection.
Another thing that you might need is triplanar texture projection for mountains so that the stone texture don't look stretched.
Another option is using a texture atlas. That lets you have a single texture for the terrain (plus another one for normal maps, or gloss maps or whatever), and another for the blend map.
There is an article in GPU Pro2 called "Large-Scale Terrain Rendering for Outdoor Games" that describes this.
I describe my implementation here:
What about if you need to have normal mapping an possibly gloss mapping for each texture? Won't that reduce the number of materials you can use per chunk drastically? I do multiple passes on my chunks, works great and means I have no limit to the number of textures per chunk.
What you mention sounds very intriguing do you mind explaining it a bit further?
What about if you need to have normal mapping an possibly gloss mapping for each texture? Won't that reduce the number of materials you can use per chunk drastically? I do multiple passes on my chunks, works great and means I have no limit to the number of textures per chunk.
What you mention sounds very intriguing do you mind explaining it a bit further?
He means he redraws the chunks of terrain multiple times using different textures and material parameters instead of trying to pack all the data into a single draw call.
Another thing that you might need is triplanar texture projection for mountains so that the stone texture don't look stretched.
Triplanar texture mapping also carries another advantage- by using the normals of the terrain mesh to indirectly set the texture coordinates, it may no longer be necessary to have Texture Coordinate data in your vertex structure. I did away with it when I noticed the that Texture semantic was no longer being used, and for large enough terrain it can reduce the memory footprint a bit.
He means he redraws the chunks of terrain multiple times using different textures and material parameters instead of trying to pack all the data into a single draw call.
What about if you need to have normal mapping an possibly gloss mapping for each texture? Won't that reduce the number of materials you can use per chunk drastically? I do multiple passes on my chunks, works great and means I have no limit to the number of textures per chunk.
What you mention sounds very intriguing do you mind explaining it a bit further?
That's it yep, but I don't draw the whole chunk, each terrain material (which is different to the default material) has its own subset within a larger index buffer for the area of the terrain it covers - I use this instead of a large blend map. I believe this is how Crysis do their terrain painting.
It sounds like it might be heavy on memory and possibly slow but mine is lightning fast. A 4k x 4k mipmapped terrain with painted areas (which are only shown within viewing distance) is running at around 1-3ms on my setup depending on complexity.
Ala Crysis, the overall low resolution base texture which is always visible from anywhere shows the basic colours of the 'splatted' materials, so from a height, it looks like the whole terrain has individual materials. From a specific distance which doesn't have to be too far for great results, I gently blend in the detail textures.
I think I've written a post about it before which I'll try and find if you're interested.
