koobas.hobune.stream
Terrain / "water" texture depth/rendering problem
Hello,
I made simple flat terrain with river. I added filler texture and i have encountered some graphical issues (it is same if i use simple unity water). I appended 2 images. Left is game view and right is scene view (issue appears identically in both views).
If camera is directly above terrain (looking down), everything looks ok (though, when i sam moving camera vertically, water is fluctuating up and down). (Scene view is not directly top down, you can already see rough edges).
When i add some angle to camera, everything looks broken, unless i am certain distance from the terrain.
How does Unity decide? What is wrong here?
This is because of floating point arithmetic. Any non-integer value tends to be floating point, which is very inaccurate. As you get further away from these objects, the visible distance between them becomes less, and errors crop up in the z-buffer. Transparent objects are particularly prone to sorting errors too, since they can't be directly written into the z-buffer. As for how to fix it, you can reduce the clipping range of your camera - either increase the near clipping plane, or decrease the far one. This shorter range allows for the z-buffer to keep more accurate depth values after projection, so you don't get the same artefacts.
I already ditched this in the process, but had same problem with vanishing objects when zoo$$anonymous$$g map out. This helped to some extend, my object never vanishes anymore while zoo$$anonymous$$g out to my "max out" limit. Still have terrible "see trough part of object" problems, but i guess my mesh is really poorly made etc.
Thank you.
You'll never avoid this effect completely - the best thing you can do is to configure it so that it never (or at least rarely) happens within the scope of your game.
Ofcourse, there is only that many floating point numbers you can represent with 32 bits (or are unity floats 64bit? dont know), but with some smart modeling i can reduce this a lot. $$anonymous$$y model at the moment is at some points really really thin and it doesent need to be so.
There is so many problems once you go past simple old games clones :D
Unity's floats are just regular floats - 32-bit ones. Unity doesn't use its own representation of floating point values. You can create a 64-bit one using the double type, but most of Unity's variables are 32-bit.
