Jump to content

April 2017 »


Recent Entries

Recent Comments

Recent Entries

Recent Comments

- - - - -

Procedural Terrain Texturing

4: Adsense

I've been working on this terrain engine for quite some time. It has also been a long learning project for me. I started the engine with basically knowing only how to draw some simple shapes to the screen using OpenGL, and now I'm generating terrain textures procedurally and in a fresh new engine architecture.

I'm using a fairly simple algorithm that is based off of Trent Polack's implementation as defined in his book "3D Terrain Programming". The algorithm simply iterates through each triangle row and column and interpolates the height of the of surface at that point and determines its pixel from the textures that affect that height. For example, if we have 3 textures, grass, dirt/rock, and snow that affect the following height ranges:

Optimal: 20
Min: -15
Max: 50

Optimal: 115
Min: 20
Max: 175

Optimal: 175
Min: 115
Max: 255

Pseudo overview

Loop(through each element row of the map)
Loop(through each element column of the map)
Loop(through each texel of the corresponding destination texture area)
Loop(through each layer)
Calculate blend percentage of layer based on height
Calculate blended RGB value from source texel
Add blended RGB to overall texel RGB

Set texel RGB in destination texture

This algorithm has generated the following images from my terrain editor (work in progress [wink]).

Shot 1

Shot 2

Shot 3

There is no detail texture yet, and I have disabled lighting from my previous work to help simplify the new engine architecture implementation testing and the procedural texture generation. I plan to do some more research into procedural texture generation and implement slope variation and other variables into the algorithm to produce a more natural looking terrain. That's all for now.

Oct 23 2006 12:23 PM
I've never much liked the idea of texturing based on height myself. It's always looked better with the texture applied as a combination of grade and height. Also, a polygon soup terrain gives much more control which some game types need.
Oct 24 2006 05:07 PM
I have kept a polygon soup, I just use the logical patches (which store some basic LOD values and the rendering indices for that patch) to actually render from the terrain mesh as a whole. I've seen a lot of methods which insist on completely dividing up the terrain mesh into tiny subdivisions, but this seems grossly inefficient to me, and as you mentioned, you lose a lot of functionality of having the whole mesh to work with. For example, when calculating average normals or interpolating overall slope of an area, the edges of the patches/subdivisions lose their precision since they do not have access to adjacent data.

I'm doing some more research into more natural texture generation, using slope and other factors as determinants as well as the height. I hope to have some more stuff soon.

Note: GameDev.net moderates comments.