# Heightfield: how to compute y-coordinate

This topic is 2852 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hello!

I made a 3d heightfield that loads the y-coords from a given texture. Then i made a random map with gimp.
In my algorithm for the creating of the heightfield i compute y like this:
y = (r+g+b) / (255*3)
but on the attached heightmap the shallow water areas are(logically) under the normal, deep water. How can i solve this problem? (I dont want to make an extra texture for this)

##### Share on other sites
You should only use the red channel to store the height... And maybe use a different format that gives you 16 or 32 bits of precision so you can store higher values.

With that said a heightmap is usually a black/white texture...because white areas = higher y. So as the shores in your texture are almost white so they'll be higer than the green zones.

If you only want to use a texture, store color in the RGB channels and height in the Alpha channel

##### Share on other sites
y = (r+g+b) / (255*3)
but on the attached heightmap the shallow water areas are(logically) under the normal, deep water.
This formula does not make much sense to me in the first place (I'd suggest to just pack 8-bit components to a 24-bit "word"). I don't see any "logical" connection between the heightmap value and the actual position relative to sea level unless we assume all heightmaps are based at 0 height in world position which world be fairly limiting in my opinion.
Terrain is a box with a base level and a basis, I'd suggest to author the heightmap in this local space rather than world space (eventually, the mapping will be identity).

You should only use the red channel to store the height... And maybe use a different format that gives you 16 or 32 bits of precision so you can store higher values.
Let me elaborate. Assuming OP is using PNG or other lossless formats, what the format offers is not really limiting. What we have is 8 bits per channel; whatever mapping from RGB(A) pack to float value is valid and will work.
I agree however that using multiple-channel representation is a bit cumbersome in terms of authoring, 16-bit gray is indeed preferable from this standpoint - and it is indeed suggested by Epic to work on UE3 terrain. Unfortunately, some tools will just clamp the contents to 8-bit at every chance so it's really some sort of what integrates better with the tools available.

##### Share on other sites
having multiple water levels is advanced, just stick to the maybe unrealistic single water level model, its a lot easier.

##### Share on other sites
I solved the problem know with tiles. Atm I only have one grass tile. Should i write code or something like that to decide which texture I want to use for the current quad? e.g. this:
 struct Tile { Texture tile; float height; }; render() { //interpolate between two nearest tiles } 

##### Share on other sites
You haven't mentioned which API you are using, but you could provide a per-vertex flag to indicate which tile you are currently on and then use a TextureArray to store all of your tiles. That way, your lookup routine would be fairly straight forward by simply selecting the array index from your input data.

##### Share on other sites
I am using dx9. do i have to write a vertex shader for this or is there a flag?

##### Share on other sites

I am using dx9. do i have to write a vertex shader for this or is there a flag?
You would need to write a vertex shader. If you are currently using the fixed function pipeline, then it would require a minimal vertex shader and pixel shader. Then you would create a vertex buffer with a declaration that includes the flag for each vertex, and your vertex shader would expect that flag on its input structure.

• ### Game Developer Survey

We are looking for qualified game developers to participate in a 10-minute online survey. Qualified participants will be offered a \$15 incentive for your time and insights. Click here to start!

• 16
• 15
• 9
• 11
• 15