Landscape; blend the textures?

please help!

I want to render a verry big landscape, so it is not possible to create one texture. Now I take textures and put them together it works great but there are borders between diffrent textures.
I want to have soft (blended?) borders because there is not enoth memory to precreate all the textures for the borders. I need a verry fast ROAM-compatible solution without any extentions.

thanks!

Heyla,

You /might/ try using a mutlitexturing technique, where polygons in the transition area between one texture and another use an alpha component relative to their position in the blending process.

I do not know what kind of visual you would get, and it would definitely be faster with a single-pass multitexturing extension than multi-pass vanilla OpenGL, but it might work for you.

Good luck,
– Jeff

Originally posted by TB-Rex:
[b]please help!

I want to render a verry big landscape, so it is not possible to create one texture. Now I take textures and put them together it works great but there are borders between diffrent textures.
I want to have soft (blended?) borders because there is not enoth memory to precreate all the textures for the borders. I need a verry fast ROAM-compatible solution without any extentions.

thanks![/b]

I am not sure completely, but try it:
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP);
glTexParameterf(GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP);

the only way without extensions is
A/ have 2 textures (grass rock) draw the rock texture + in the grass texture have an alpha channel + just blend that over the top with src_alpha, one_minus_src_alpha
B/ blend the 2 textures in some paint program before hand (this is quicker than A but is gonna use quite a bit of texture memory)

For my simple landscape engine I always blend to textures together. Now I just have two textures (grass + rock), the first texture is drawn and then the blend coefficient is caluated based on height ( and soon to be based on slope), this could be precalulated if you want. This works very well although there is not much randomness.( I don’t know how to blend two textures based on a alpha texture) This method should look a lot better when more textures are used (always in pairs); mud->grass->rock/grass->rock->snow, and when slope is taken into acount. This method is also simple and if you make use of multitexturing it is also fairly fast. The only problem with it at the moment is that it looks like a giant chess board if you look at the flat valley bottom and mountain plateau.

I use multitexture and multipass texturing. For each pass i use 2 TMUs : 1 for the rgb texture, 1 for the luminance texture.

Currently i have 3 passes which enable cool stuff like in warcraft 3 (i don’t know how they do they landscape texturing…).

Is it possible to do this with a single pass (using multitexturing extensions)? If so, how?

TB-Rex,

There are many different ways to create what you want. The two main methods are “artistic” and “procedural”.

Artistic landscape textures assume that the entire landscape is a sigle unique texture which has been cut up into smaller texture tiles. You use a simple indexing scheme to pull the correct texture tile from the database and bind it to the set of triangles under it (very ROAM-friendly). Texture seams are eliminated by a trick called ‘texture borders’, there’s a thread on how to do this - just do a search.

The advantages here are: Unique texture everywhere, lots of freedom in texture creation, and usually looks a lot better. The disadvantages are needing to load from the database (thus need some caching system, etc.), and the database gets very large with increased landscape size, and the need of an artist or other texture creation scheme.

The procedural method is what the other posters have been describing. Basically you have a ‘stack’ of textures (grass, rock, sand, shrub, show, etc…) and for each unit of area (a small sub-branch of your ROAM tree) you choose two of the textures. Using multitexturing you bind the two textures and draw them on with an alpha map to blend them.

The advantages here are: it’s simpler, very efficient on modern cards, gets good results. The disadvantages being: you’re limited to your ‘stack’ of tiles, the textures naturally repeat (very visibly in some cases), much slower on older cards (requires two passes), and you don’t have a lot of flexability artistically.

One of the problems I find most anoying with the stacked-texture blendin system is adding ground effects, like roads, debris, chared ground, etc… With a texture database, you can actually make changes to the textures (when an explosion occurs, or blood splatters), with a stacked-texture blend system this isn’t possible.

I’ve implemented both and chosen to go with texture database for my project.
–Bryan (bryan.turner@pobox.com)

BryanNC
One of the problems I find most anoying with the stacked-texture blendin system is adding ground effects, like roads, debris, chared ground, etc… With a texture database, you can actually make changes to the textures (when an explosion occurs, or blood splatters), with a stacked-texture blend system this isn’t possible.

I think that for these kind of effects you could use simple quads on your landscape that will nicely fade out like in q3a, unless you want the effects to stay.

holocaust,

Unfortunately, quads are not good enough for high-resolution terrain. It is equivelent to placing a quad on a curved surface. Even Quake III has problems with this, it’s not a trivial task. To properly place a damage sprite on landscape requires you to redraw all the vertices under the sprite, binding the damage sprite texture to each. This is not only a fill-rate intensive activity, but it also uses more texture memory, bus bandwidth, and triangles.

When using a texture database, you simply blit the sprite onto the texture (or textures, if it crosses the border) and continue using the textures as normal.

The speed hit is far less than the Quake method, and it’s permanent. Its only downfall is the memory requirements (and potentially the mipmap generation).

–Bryan (bryan.turner@pobox.com)