World vs System Units and accuracy.

I apologize if this has been covered somewhere else.

I would absolutely love a system unit configuration option. Its hard to describe what I am after, but the equivalent system would be in 3d Studio Max, where you have your world units that are set separate from the System Units. This means you can have true meters (as we have now as Unity Units) as the base, but how the floating point accuracy is handled behind those meters is handled as configurable.

This is because I have created my software in real meters, but I start to run into accuracy problems when you get around 8000m away from origin. You can watch the models shimmy and shake as they search for the nearest decimal.

I could reduce my entire game scale to increase the accuracy, but then I would have to basically rebuild an awful lot of the game. Just a simple unit accuracy shift multiplier in the preferences somewhere. A "virtual/mathematical scale" of sorts. I have read a lot of threads where the answer has either been "just deal with it" or "scale down your project", so heres a good opportunity to change that response.

Cheers

 

or some sort of origin reset call based on camera position. How sexy would that be?

 

you're running into problems with floating point precision, it's a hardware limitation. I'm not sure that scaling down the entire coordinate system is going to solve anything, the floating point precision problem goes both ways.

See this video for some good information on streaming terrain and dealing with floating point precision issues:

the solution proposed in that video is to "chunk" your terrain, and when the player gets too far away from the origin, move everything back towards the origin.

so yeah it's a somewhat complex system to code. but if you game is that large, you most likely need to split the scene into chunks and stream it anyways.

 

Great, thanks for the vid.

Ya I have read about the Seige engine. Its a good solution. Im not even looking for something that sophisticated, just an "adjustment" option for limited terrain games that might need that final scale tune to keep everything reasonably stable.

He mentioned that in Unity, you can have stable scenes up to around 40 km! How do you get this, as mine starts shaking at 8? I wouldnt have any problems around 40km, I have no plans for endlessly expandable terrain.

 

well, the dungeon siege engine was brought up as an example of an overly complicated implementation. Skip to 9:38.. watch the rest of the video. that should get you started

I'm not really a mathematician or anything, but I believe the floating point precision problem goes both ways. In the 4 bytes of a float, you can only represent so many values. In other words, floats can only store so many digits. So that's why you run into issues with larger / smaller values. So for example if a float can only store 7 digits, once you start getting large numbers like 10000, then you only have a few digits of precision remaining and can't accurately represent smaller values like 10000.00001 etc.

If it was as simple as using a different coordinate system or scaling everything down, unity would probably have that built-in

 

Let me try to explain in a different way:
You know how with the camera you can adjust the clipping ranges from near to far, and that has to be balanced within a certain reasonable range because of the frustum accuracy. What I am proposing would basically be the same thing, but for positional accuracy from the origin.

Some one at Unity had to make the decision as to what "reasonable" was when they set up the engine, and that value is hidden from the users. Floating point doesn't care how its value corresponds to feet or meters, etc. It definitely would effect the near side of it, like you say; works both ways. But I am prepared to sacrifice 50% near accuracy for a %200 far accuracy.

That all being said, I get that I could set up some ridiculous tile system and be on my way. I just worry about it effecting things like multiplayer, losing static mesh optimizations, and last I checked, rigidbody collections don't appreciate being warped suddenly!

Im soaking up what you are telling me, I just need to double check that what im asking can/cant be done now/ever.

 

I suppose it depends on whether or not Unity has internal systems that are tightly coupled to that default scale. it's an interesting question, for sure.

I know when you switch the default units in Maya, like say change it from CM to M, half the tools break and it's impossible to use (lol). In that case I think some of Maya's tools are tightly coupled to the default CM scale.

 

Thats very interesting problem, but I can't see how it is related to the float ? It's have 7-digit precision, so why are you losing precision at 8km~, when 1km~ have the same amout of digits? -.- It's Unity-related problem, not float precision. And Imho you dont wanna such big worlds anyways, unless its flight simulator or something like that with almost no objects or only trees and very simple buildings. Bohemia interactive managed to have playble 274km^(16.5x16.5km) world in Arma3, but optimizations they have done to make it possible are unbelievable.

 

Actually none of this makes sense, Unity just uses 1 unit = 1 metre, which is the recommendation that has run with OpenGL and DirectX since I can remember (and I started before they existed) I think you are seeing something difference here, best thing to do would be to upload a web build with repro steps so we can actually see the issue.

 

I was so curios of this problem, I checked accuracy in my project, and moved objects that are at 14km+, and still have perfect precision, so it's your project related problem(thats relief ).

 

This is true, but its probably just outside of 8km that things start getting wobbly.

It is float precision, see video above

I am making a flight simulator, lol.

Yes, 1u = 1m. I dont want that to change. Its how the float values are related to the base units that I would like to see configurable.

I can probably put together a quick video to show the issue.

Well im not sure how you calculated that precision, but it has nothing to do with my specific build. If you just looked at the transform values, I am pretty sure those dont change. Try this:
-Create a terrain object thats 20km wide.
-Take your camera/player and put it near the origin.
-Create a little "virtual cockpit" out of primitives, that are near the camera. Maybe a couple spheres and cubes that are right -in front of the camera. It needs to be maybe 3-4 of them, all parented to the camera so you can see them.
-In play mode, move your camera to the far end of the map ~ 20km.
-Witness the jiggles.

It is especially apparent in my game because I have a cockpit view and grouped objects are right up against the camera.

I hope this makes more sense.

 

here we go.

 

It starts a lot earlier than that... they start jiggling around 3k, you can see it in the hatch on the right side.

 

This looks like a floating point math issue. Difficult to advise without seeing the code, but the following options may help.

1) To test if the issue is related to distance, try making you ship spawn at 8km, I have a feeling distance is not related by it's the amount of time your scripts have run and the issue is increasing with time.
2) It looks like your objects are not nested and instead you are trying to sync the positions manually, that would probably cause this issue. You could try nesting them to try and resolve it.
3) Alternatively, do all you positions and math in Decimal variables and then set the gameobject positions to these variables in the lateupdate.

Good luck,

Jon