Hello

I searched for this question for a long time, and I stell haven't got a 'real' answer:

How does terrain size / quality work? I'm working on some RPG like game. And want to create a terrain with a heightmap and a terrain texture. For simple measurements, when creating a heightmap 1 pixel equals 1 square meter. So a 256 x 256 pixel heightmap is a 256 x 256 square meter map. That's easy.

But now on the terrain texture: If I should create a terrain texture with the same ratio, one would stand on 1 pixel (1 color) per square meter, which is not exactly high definition.
So I could multiply the ratio, by let's say4 or 8 (which seems to be a consensus), but if I multiply by 4, I have a 4x4 terrain texture per square meter, so that equals 16 different color blocks under the feet of my character. This can't be right either..

When just Google a random RPG (WoW for example), and look at 1 square meter under the character: World of Warcraft image example
Those cobblestones are 'sharp', I mean, that must be at least a 256x256 pixel image in 1 square meter.

So when I need 256x256 pixels per 1 heightmap pixel, and I have a 256x256 heightmap, that would account for more than 4 billion pixels. Such an image would be several terrabytes of hard drive.

So, how does WoW does this? How do I draw somewhat of quality on the ground, without needing a massive hard disk and loading times?

And how are those thousands of free repeating grass/sand/etc textures used that you can find on the internet? (Sometimes with massive 4096x4096 pixel quality.)

Thanks for pointing me in the right direction!

While I was further thinking about this:

Could this be solved with only loading the textures of the terrain that are actually seen? So if I can only see like 20 square meter, only 20 256x256 textures should be loaded.

That would limit the memory consumption, but not the harddrive. Altough textures could maybe be reused.

You don't need to have a single texture for the entire terrain, you can repeat textures. For example, you have a small cobblestone texture, and a small grass patch texture, and a small dirt road texture, and then you repeat them in all the places where you need cobblestones, grass or dirt roads.

Here's an example of bad tiling: (it's bad tiling, but a good example )

There are 4 small textures that are repeated, you can clearly see the patterns repeat. So for this (let's say 1000x1000) terrain, there are only 4 small (100x100) textures. There are tricks to make the repeating less visible, but that's the basic idea.

Terrain have a lot of approaches to achieve high quality while maintaining performance.

One of the easiest ways is project the textures based on the world space position, that way it will "paint them" with the given texture.

Another way is using the lightmap uv chanel and tile the textures there

Anyway, you will need to tile a looot of times the same texture, and it will look repetitive. So remember also have enough variation in your shape and props so that doesn't look odd.

Good luck with your project.

To add to all this, you don't necessarily have to use a ready made texture to texture something. One can always calculate a colour with a formula, based on whatever. Probably arguably the best a good approach for large worlds. Umbrella term "procedural texturing" ...

Some common approaches are called "splat maps", "terrain clipmaps", and "virtual terrain texturing" - these techniques try to fix the problem you're probably thinking about, where the heightmap resolution is much less than the required texturing resolution. As previous posts have mentioned, the basic idea is to map higher-resolution textures in some way to the lower-resolution heightmap through various techniques. The simplest approaches will give you obvious tiling artifacts, but you could look into "voronoi texture tiling" as a possible solution, or possibly combine textures at different scales to hide tiling artifacts.

Side note, 0.5m - 1.0m are commonly-used heightmap resolutions even for recent AAA games.

23 hours ago, Green_Baron said:

To add to all this, you don't necessarily have to use a ready made texture to texture something. One can always calculate a colour with a formula, based on whatever. Probably arguably the best a good approach for large worlds. Umbrella term "procedural texturing" ...

That works pretty well. The main issue I found when I tried it in DirectX9 a few years back is anti-aliasing. The standard methods didn't handle it (But maybe there is something better now).  Also you can't just ignore it because the image quality degradation is huge at distance. The problem is pixels aren't averaged so your terrain ends up looking like it's sparkling at distance when you move.  There are some tricks you can do however. One thing I tried that worked pretty well was to fade the pattern to single color at some distance before the aliasing problems start to take effect.   If I remember correctly you reduce the amplitude of your function starting at some Z value until it becomes flat at some farther Z value limit.  it's probably trickier with complex functions though.

Terrain is an interesting beast.  While you are looking from above, or looking at distant features, terrain looks okay.  But when you are down at ground height you'll notice that terrain is just a flat sheet with a picture painted on it.

You need both terrain and modeled objects placed on terrain to make things look good inside the game world.

First you start with a generic terrain and paint it.  This gives a general impression of stick and rocks, of grass, of tree debris, or whatever you want, but it doesn't look good up close. Then you need methods to actually draw grass, trees, rocks, buildings, and other modeled items to look at.  

Which, if i am not mistaken, leads us to modelling and placement of objects for the things like the ubiquitous cosmodrome ;-), instancing for buildings, rocks, trees and eventually particle systems for the tedious little things. Is that so ? ?

I found a working example for coherent noise based terrain generation and colouring: http://libnoise.sourceforge.net/ that might be worth looking over. Here you don't have to store the terrain, the function produces the same result every time it is called with the same parameters.

The land-surface of the Earth or the Marsian surface in 16bit/heightmap-post and a post every 10m would be a little under 2TB. That's what we have to count with if we want to do physically based terrain generation. Might be worth considering a water world, with only sporadic small terranes, like the early earth in the late hadean/early archean ...