This is a discussion on Procedural Texture Generation for Height Mapped Terrain - By Perspective within the Article Discussions forums, part of the Community Boards category; For our next article - Procedural Texture Generation for Height Mapped Terrain - By Perspective
http://cprogramming.com/discussionar...eneration.html...

Very good article and the procedure works very well with pre-designed textures. You can have some issues where the texel color does not match the height very well, but with carefully designed textures this technique can yield some very nice results. Also an addition to it would be to have the height ranges overlap so that when you are in the overlap area you perform a linear interpolation or do an additive blend between the two.

Also an addition to it would be to have the height ranges overlap so that when you are in the overlap area you perform a linear interpolation or do an additive blend between the two.

indeed Bubba, this is a cool way to increase the range of colours (blending) in the texture. The only thing to watch out for when doing this is the percentage calculation. Calculating overlaped ranges the way i described in the article can result in percentages that add up to more than 100! which means texture values overflowing. With some modifications this can be accounted for though.

Another thing id like to point out is the convention used for texture selection. I kept the article simple but another (more realistic) approach is to use slope in selecting a texture. You'll notice that the examples i posted have grass (in the grass range) on the side of a steep mountain. This would more likely be rock in a realistic situation because the slope is so steep. I'll leave slope calculations for texture selection as an excersize for the reader

To fix the overflow problem you would just normalize all coordinates so that they always fall between 0.0f and 1.0f. This would then work with any size texture and with any type of color addition, multiplication, etc. With addition you would have to clamp, but that shouldn't be too much of an issue.

>>This would then work with any size texture
ah yes, you raise a good point. The article assumes you pull indices from the textures which directly map to the height map. ie. the height map and the textures have to have the same dimensions.

If your textures arent the same size as your height map you have a couple of choices. Clamping, as Bubba mentioned, is one option to essentially stretch your smaller texture (or shrink your larger texter, though the latter is more often the case) to cover the height map.

The advantage to clamping is that there will be no visible repeating in the texture.

The disadvantage is that you will lose detail in your texture (assuming the texture is larger than the height map)

An alternative to clamping is repeating. Here, instead of normalizing, you wrap the texture indices to make the texture repeat.

The advantage to repeating is that you get the maximum possible detail from the texture at any given spot on the terrain... there is no "stretched out" effect.

The disadvantage to repeating is that areas on the boundries of the texture dimensions can have noticable edges where the texture repeats. Also, different areas of the heightmap can have the same area of a texture on them (which is only a problem if your texture has very distinctive fearures)

"Tile-able" textures can solve the noticable edge problem when repeating.

This will cause the texture to be mirrored on both the vertical component (v) and the horizontal component (u). This is very useful for texturing large areas with the same texture w/o all the hassle of creating seamless textures. Any coordinate below 0.0f or above 1.0f is correctly mirrored. So if you set mirror and specify tex coords of

0.0f,0.0f
4.0f,0.0f
0.0f,4.0f
4.0f,4.0f

You will see 4 mirror images of your texture. Note that because of the nature of the mirror operation you will probably need an even number of repeats in order for the last texture to correctly mirror with the first. This is only necessary if you are wrapping the texture across an object where the left side of the texture meets the right side - as in the case of texture mapping a sphere or a cylinder. I have experienced problems on my video card with the mirror function. It seems to be 1 pixel off in both directions so you get this nasty grid which kills the idea of trying to hide the underlying grid in the first place. Perhaps there is a driver patch that addresses this issue.

The other address mode that Perspective described above is D3DTADDRESS_CLAMP.