How far away from 0, 0, 0 can I go before it starts to get buggy?

I'm wanting to know so that I can figure out if I need to develop a solution for my map size or not.

I figure I can recenter the map when I enter a save room, or anywhere else I can also sneak in the garbage collector, but that sounds hard and I dont wanna.

 

What do you define as buggy? The further away you get from the origin, the less precision you get behind the decimal point. If you want a table, I made one over here. The example I made was about Time.time which is also a float, however it applies to any single precision float just the same way. It's always just a matter how fine you need your details.

Just as an illustration, I once made this very simplistic solar system diagram which includes only the sun, the earth and the moon, but to scale. Most drawings are not to scale and it leads to many misunderstandings about the actual distances and sizes involved.

Everything you see is a single shader. All shapes (the circles and the lines) are drawn in a single shader. That's why you can zoom onto that circles quite far without seeing jagged edges as the circles are drawn using math. Anyways the key point here is that the center (0,0,0) is the center of the sun. The earth is 150 million km to the right. I did not use meters inside Unity. I can't remember exactly but I think I used one unit is 10000km. So the earth is about 15000 units off the center / origin. You will notice that visually you shouldn't have much issues. However dragging left and right at a high zoom level shows the floating point limitations. That far from the origin, the minimum possible step the position can make is a lot greater than close to the origin. If you have a moderate zoom, you would not notice that the panning actually snaps to certain point. However if you zoom quite far in you will see some floating point accuracy artifacts.

Just zoom in on the very top of the sun. At the top you can see the horizontal distance of your mouse cursor from the sun center (so only the horizontal distance, the distance on the x axis). If you zoom in so that the screen roughly covers 4 km (so +-2km) you will see that you can still pan perfectly fine to the left and right. However panning up and down already has issues since the top position of the sun is about 700000km away from the origin. Of course at that scale it's only 70 units, but you will already notice the drop in accuracy.

Now try the same with the earth that is 150M km away from the origin. The distance display itself already snaps to increments of 100km. floats can't give you more precision at that point. Always keep in mind that a floating point number only has a certain fix number of binary digits (single floats have 24 bits). The "floating" point defines where you put your "binary point" that seperates the whole number from the fraction. The more bits you need before the binary point, the less you will have behind it. Since number in a computer are based on the base 2, those changes happens at exact powers of 2 (2,4,8,16,32,64,128,256,512, ...) Each time you cross one of these whole number marks you will loose one bit behind the decimal point. For really large numbers, floats can not represent fractions at all (just see the bottom of my table). Btw: the table does not end where I stopped. floats can go up to 10^38 but only have about 7 (decimal) digits of precision. So the largest number would have 38 digits, but only the seventh from the top can actually change at such high values.

Simply put, the smallest change a float can represent at a certain size is always the value of the least significant bit to the far right. See this interactive float visualization. Just enter a value, say about 1000. Flip the last bit and see how much the value actually changes. Now set the value to 10000 or 100000 and try the same thing again. You will notice that this smallest possible change would have gown by about 10 or 100 compared to if your value would be around 1000.

To sum up:
There is not really a generally valid size or distance at which you will see problems because it's always a matter of scale and also depends on the usecase. Though single precision floats (32 bit, 23(+1) mantissa, 8 exponent, 1 sign bit) are quite limited. So having a so called floating origin is a quite common thing for large or open world maps.

 

A simple way to think of it is every time you double the distance from origin, you double the smallest gap you could have in your game between two different places in space.

Like all things exponential, the subjective experience for each doubling in distance usually goes:

it's fine
it's fine
it's fine
it's fine
it's fine
it's fine
it's a little jiggly
it's very jiggly
my eye sockets have shaken loose

Great write-up Bunny!

 

I am noticing animations start to get visibly jiggly at 1000 m, so I will almost certainly have to figure out how to recenter 0.

sounds like a nightmare…

 

it's not nightmare, but a reality. game dev isn't always as easy peasy as you might have thought. there is a lot of engineering to make something that pushes the limits. many a developer became successful only after they had shrunken their maps and other gluttonous appetites, not before.

I've successfully implemented such a system in the past, and it was a 2D space game with full physics. I've managed to fool even the physics engine into being unaware of the shifting origin.

later I made a 3D planet 6,000 kilometers across, where you could land on a surface and observe details 1 m in size. I did procedural tessellation on CPU and it was real-time on my previous computer, which was more than 10 years old at the time (Core2Duo 7600 something like that).

you can't expect these things to come with the engine, it's too specific.

 

Yeah, I get that. I just wish there was a built-in toggle for 64-bit movement.

 

Hey if your map is flat you're having much easier time than me with my crazy spherical topology based on subdivided dodecahedron Just saying.

For starters, separate the world into chunks, and begin thinking through chunks. Next, stop fixating on the idea that the motion of a camera has to maintain (technical) continuity, and the solution will come to you. Nothing else really changes, it's all smoke and mirrors anyway. The game world is yours to shapeshift until it hits the screen, frame by frame.

edit:
If I'm to be honest, my solution was camera-centric. Think about it. The world you can see 500 km away? You can go there but it never truly existed, it was just a gist of it, like some weird hyperbolic dream.

 

That is the best description of game development I have ever heard.

 

Do you still have that chart laying around somewhere? It seems the link is broken and I would love to take a look at it!

I starting making my own chart based on my understanding of how floats work, but when I started testing the changes in precision across the different ranges (2-4, 4-8, 8-16, etc.) I found that at least for shadows, the results don't conform with the expected ranges.

For example, shadow glitches at 5000 units from the origin should be the same as shadow glitches at 8000, since both values are inside the 4096-8192 range. But the glitches are more extreme at 8000.

My best guess is that shadows involve some calculations like multiplication or division, which changes the ranges and makes the values start losing precision earlier.

Anyone know if that's correct, or something else is going on?

 

When Unity migrated UnityAnswers to Unity Discussions the direct links to posts all went dead. The wayback machine usually helps to retrieve them. Once you know the actual question, Discussions usually can properly forward the link. I've updated the link in my post, but here is it again.

Shadows are a topic on its own. There are many different ways how shadows may be implemented. I'm no longer in game dev, so i'm not up to date with the curren tech, sorry

ps: it's a shame, the table fit on the screen in UA. In Discussions you have to scroll sideways. Too much unnecessary space to the sides...

 

Thanks!!