Jump to content
  • Advertisement
Sign in to follow this  
Florian22222

Heightfield: how to compute y-coordinate

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

If you intended to correct an error in the post then please contact us.

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 this post


Link to post
Share on other sites
Advertisement
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!