Jump to content
  • Advertisement
Sign in to follow this  
  • entries
  • comments
  • views

Procedural Terrain Texturing

Sign in to follow this  


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.
Sign in to follow this  


Recommended Comments

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.

Share this comment

Link to comment
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.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!