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)
Heightfield: how to compute y-coordinate
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
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
y = (r+g+b) / (255*3)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.
but on the attached heightmap the shallow water areas are(logically) under the normal, deep water.
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).
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.
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.
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.
having multiple water levels is advanced, just stick to the maybe unrealistic single water level model, its a lot easier.
Author
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
}
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.
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.
I am using dx9. do i have to write a vertex shader for this or is there a flag?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
