Archived

This topic is now archived and is closed to further replies.

dmounty

Terrain Texturing!

Recommended Posts

dmounty    122
Here is an idea I have been thinking about for some time, but have not really ever got round to implementing... Let me explain. When representing a terrain as a height field, it is easiest to consider top down mapping of the texture, being projected onto the terrain... This however, leads to low quality textures, on steep slopes. My method, is simply intended to compensate for this. 1. You need a texture, as though it would be projected top down onto the terrain, but about 4 times the resolution (ie for 256x256 texture... 1024x1024 is the basis, but the bigger the better). 2. You go along each horizontal and vertical line in your height field, and calculate the length of that ridge, using pythagoras lots of times. 3. Instead of generating texture coordinates, dependant purely on the x,y (z being height) coordinates, you generate the u coordinates, based on how far, from the left edge of the texture you are, (compared to the length of that rigde), then do the same vertically. 4. You then distort the original image as follows: you make a normal grid representing the pure x,y coordinates of the points on the terrain, then you distort them to the shape of the u,v coordinates you generated... This is why you need a high res to down image, because steep slopes, need more detail (since I was using a top down map to start with). This image is then scaled down to the required resolution (or the distortion could incorporate this for you). 5. You now use your u,v coordinates, in conjunction with your new texture map. I believe that this will give you textures that are more evenly distributed over the surface of the terrain, and not purely projected down... I think that this will eliminate the problems regarding steep slopes appearing low resolution. Since you need a larger texture to start with, I thought this method may be to space intesive, but if you suply the texture maps, in distorted form, the program could calculate the texture coordinates at run-time, thus not requiring any more storage. So could you guys tell me: Has anyone tried this method/seen this method before/got a better method? and also, What do you think of it? and Do you think it will work? Thanks

Share this post


Link to post
Share on other sites
Elixir    122
This is exactly how I calculate my terrain texturing. I use this method because it avoids texture stretching on slopes. =]

Share this post


Link to post
Share on other sites
Ysaneya    1383
Hum, i thought of it before, and here is something that bothers me. Given a texture scanline, the number of texels is no longer constant, but depends upon the length of this projected scanline on the 3d terrain.

What does that mean? Well, if you have a flat terrain, you might have 500 texels in a scanline; while if you have lots of mountains, you might end up with 5000 texels in the scanline..

What do you do to fix that?

Y.

Share this post


Link to post
Share on other sites
dmounty    122
My intention, is not that you change the number of texels per scanline... this remains constant, but you simply adjust percentage of the textures width, that is placed on each slope, so the final texture is still square, and all the distortion I describes, takes place within the same, square texture.

|----|----| |----\----|
|****|&&&&| |*****\&&/|
|----|----|==|------\/$|
|%%%%|$$$$| |%%%%%%|$$|
|----|----| |------|--|

or somethign similar... ie the internal and edge grid coordinates are changed, but the grid still stays within the same square region, ie, the same number of texels per scan line.
Sorry for the dodgy drawing, but ASCII art was never my strong point. Hope this clears it up for you.

PS: I just looked at my post, and the drawing has failed horribly, thanks to the font, so never mind about it

Edited by - dmounty on July 30, 2001 6:52:26 AM

Share this post


Link to post
Share on other sites