koobas.hobune.stream
Scene scale and float precision
I've been struggling with this question for a while now.
I have a big issue with scaling. My world, which mainly just consists of simply "dead" terrain is large, in real life scale we're talking about 1000km x 1000km. In that world I have aircraft, which are the size of around 10-20 meters. Now you can imagine what the problem is, there's a huge scale difference between the world and the smallest objects. While a missile might be 2 meters long, the world is 1 000 000 meters long... and no matter how you put it, downscale it by 10, 100 or 1000 the scale difference is still there and causes serious jittering when I zoom in to the small objects.
So I'm puzzled now, how do I implement the large world without the jittering problem?
I think the issue might be to do with your huge terrain. Unity won't be able to cull it properly if any of it is onscreen, so you're still calculating with an essentially massive object. If you disable your terrain, then zoom in, does the jitter still occur? If it doesn't, then you might want to look into breaking your terrain up into smaller "chunks", using several terrain objects, allowing Unity to only render the chunks that are currently in view.
The jittering is most likely due to Z-Fighting. Unfortunately, there's not many ways of solving this besides increasing your camera's near clip plane to increase the depth buffer precision and giving a depth offset to those smaller objects via a shader.
This depends whether by "jittering" he means that the game slows down erratically, or that the objects "flicker". If the former, then my suggestion is likely correct, if the latter, then it is z-fighting.
If it were the former, zoo$$anonymous$$g in would cause the game to run faster since a lower field of view would mean less things to draw. I'm also pretty sure that the built-in terrain is capable of chunk-based culling on its own.
This is not actually z-fighting - it's about objects moving and getting rendered inaccurately and jittery motion. I did some more research and it appears the problem appears when the distances increase, ie. when we move further away from the (0,0,0) origin. It's about not being possible to render high float values accurately due to the nature of floating point numbers - the bigger the number, the less accurate it gets.
It seems that the Floating Origin technique is one solution. $$anonymous$$eeping the camera at the origin while moving the scene around makes sure that we never handle high floats near the camera. I will have to try that approach.
float-based inaccuracies start after 99,000 units according to unity, and they become a noticeable issue after about hundred and 50 or 200,000 units, and beyond 500,000 units the textures and vertices are completely nonsense.
if you are making anything in unity more than 100,000 units, then you are overloading the floating points. it still takes 20 min to fly that far 300 km/h. any objects more than 99,000 from origin should generate a warning in the inspector.
