04-09-2024, 11:04 PM
(04-09-2024, 10:35 PM)josemendez Wrote: Hi!
Terrain holes are encoded as the sign of the heightmap values: positive height means solid terrain, negative height means a hole. According to IEEE floating point standard, -0 is equal to 0, which means a hole at height zero is actually considered solid terrain (because -0 is not < 0). The alternative in this case would be to have -0 be less than 0, which would cause all terrain at height zero to be a hole - probably a worse option.
It’s not usual to have completely flat terrain with zero height, maybe in this case a MeshCollider would be a better fit? If you do need flat terrain, increasing its height uniformly to a non-zero value would be a valid workaround.
Let me know if you need further help,
Kind regards
This is just a side effect of my test scene, so it's not really an issue as my terrain would normally be elevated. That being said, I was fiddling around noticed that the current logic of "GetOrCreateHeightField" assigns the the height value multiplied by -1 or 1 depending on if there is solid terrain or holes, respectively. This means that at height zero it results in 0 * -1 = -0 which is not <0 as you point out. I changed the logic to instead just assign the height value if there is solid terrain, or a constant -1 if there is a hole, and it seems to behave as expected. Is this a viable solution or are there any negative implications of this I'm not aware of?