Both Minecraft and Unity use floating-point precision for X Y Z, but why does unity loose precision faster than Minecraft does? You can travel to 30 million in java edition without any jitter, but with Unity you have large precision loss at just 75,000. Why is this?
Thanks in advance.
Minecraft uses a technique known as “floating origin”. This technique is moving the world centered around the player back to origin (0,0,0) once the player has traveled a certain distance.
Edit: This was inaccurate. Check below for actual details.
3 Likes
Minecraft uses double values (64 bits) while Unity uses single (float) values (32 bit). Note that even Minecraft uses 32 bit floats for a lot of things. Especially the GPU is optimised for 32 bit math when it comes to vectors and matrices.
The common solution is to use a “floating origin”. That means you store an additional offset where you are in the world at the moment. You should always stick close to the actual world origin. However you can simply offset everything by a global offset as you move around in the world. Since you usually load in individual chunks, it’s kinda trivial to just offset the loaded chunks once you get too far from the origin.
The actual offset could be a pair of double values or just integer values. Integer values may be easier
2 Likes
Actually MC did not use a floating origin as far as I know. That’s the actual reason why MC has set a hardlimit of 30 million blocks. If you look at double precision values around 30 million, try toggling the least significant bit. You would notice that we still have a lot precision behind the decimal point.
Now look at the same value as a 32 bit float. When you toggle the least significant bit you will see that we jump by a value of “2”. A lot things in MC uses doubles (player, entity and item positions / velocities, etc) however for certain things, especially rendering it also relies on 32 bit floats. That’s why some things break down at those distances.
If I would implement a floating origin, I would probably go with a max distance of 1024 and use a long as offset. So the offset would be a multiple of 1024. However that means you have to store each entity position with an offset and a relative position. This could be simplified by only giving chunks an offset and having entities be relative to the chunk their in. Though splitting up the positions that way will add quite a bit of overhead whenever you need to know the actual effective world position. For example for distance calculations. You would probably use a double for such things anyways.
Over here I posted a table for 32 bit floats how the precision goes down as the absolute value goes up. Generally when you double your position you need an additional bit before the decimal point so you will loose one behind the decimal point since a float has a fix number of significant digits / bits. In case of 32 bit floats that’s 23 bits. So if you have a value between 8 and 16 million, the smallest representable change is a whole number. So no fractions anymore. When you double number (range 16 - 32 million) you loose another bit at the low end and the smallest representable difference between two numbers is now 2. So at this point you can only increment / decrement the value in steps of 2.
For physics to work properly you need “enough” precision behind the decimal point. What’s enough is debatable. In MC it’s actually quite funny when you’re running forward and then stop running, you actually still move, but very slowly becuase drag takes quite a bit of time to completely halt a gameobject. With computercraft ( plethora you can see your own position / velocity as double precisions So even though it looks like you’re standing still, you may still move at 1/ millionth of a block. This can not be seen with the naked eye.
Anyways, using a floating origin is almost a “must have”.
3 Likes
I was just double checking after the post before yours mentioned double precision math.
https://minecraft.fandom.com/wiki/Java_Edition_hard_limits
https://minecraft.fandom.com/wiki/Java_Edition_distance_effects
1 Like
I checked and turns out, the value is a double. But does anyone know of a game engine that uses doubles instead of 32-bit floats? Just wondering.
Well as far as I’m aware of most major engines use 32 bit floats. This is usually not an arbitrary choice but the least common denominator. Some platforms / hardware does not have double precision support or bad support which comes with huge performance impacts. Keep in mind all major math structures would need to use doubles as well. Especially Matrix4x4 and Vector4. Most games I know which require or use double precision values at places almost always use their own inhouse engine because they had special needs. Common examples would be space games like SpaceEngineers. However in the end that game suffers from precision loss just as other games do. I once completed an actual “space elevator”. However a single “grid” (ingame voxel structure) that reaches from the 0g border down to the earth surface (~43000km) receives heavy placement issues up to a whole block which made it almost impossible to properly align it with another local structure for docking.
Most games, even when they use double precision for object positions and matrix multiplications, would still use single precision vertex buffers since they are defined in local space and don’t reach out that far… usually. Until a lunatic comes across and builds a 43000km long structure (in suvival mode) 
So don’t expect engines to solve all your problems for you. Think about what limitations you actually hit and find ways to mitigate them. Just throwing doubles at the problem does not automatically solve all issues. For example I once made this simple parallel Mandelbrot renderer. However it also just uses double precision values for the whole calculations. This only allows for a zoom factor of about 2^43 until it breaks down. That’s why “proper” mandelbrot renderers use variable precision number implementations. Those are usually a lot slower since they don’t have hardware support. However if you want those really deep mandelbrot zoom levels there’s no way around that.
2 Likes
There’s an experimental feature in UE5 called LWC, which enables the use of doubles for coordinates. Not sure how far along that is.
Unigine’s Engineering / Simulation tiers support double precision. https://unigine.com/
I was experimenting and found that every power of 10 will cause the object to loose 1 digit of precision.
In beta 1.7, at 32,000,000, and exactly at 32,000,000 the game would become unphysical just like in bedrock, but in Bedrock, at 8 million, only where the precision loss was half a block, allowing you to fall through it. Only entities more than one block wide can stand on that land. Multiply the coordinates at which this occurs by 2 and you get 16 million. The precision loss is a full block creating stripe lands. attempting to travel via teleportation into those void gaps will make your camera jitter a lot. I don’t know why, but… how was it that beta 1.7 of mc used doubles, but the game became jittery at just 528k?
That is how floating point works:
1 Like
Right, though it’s actually every power of two that you’re loosing a bit. Though that roughly means the same thing in the end. In fact you’re not loosing any precision because the number of significant digits is constant. However as the numbers get larger, the more digits you have before the decimal point and therefore less behind it. At extreme values the “end” of the significant digits can actually be way before the decimal point as well. At 30 million a single precision float (32 bit) has only a precision of ±2. So there are no fractions anymore. Any larger value would just make it worse. At about 33.6 million we passed the next power of two and the precision would be down to ±4
1 Like
This is origin/world shifting, or rebasing as unreal used to call it. Floating origin actually does not move the player: it stays at the origin.
Well, it’s kinda irrelevant how unreal calls it. Different engines always come up with their own naming conventions. Some match the general consensus, some do not.
Whenever you look for floating origin you will find the origin shifting technique. Like here, here and here for example. It’s also the most descriptive name as if essentially follows the same logic as floating point numbers themselfs which also have their range jump in increasing intervals (floating point numbers use intervals which grow at powers of two).
I have never heard of that definition and I would call it more like a fix origin as the origin does not float at all.
Technically the origin of the rendering system is always fix and the whole world moves around the origin. Though this transformation is done with the camera / view and projection matrix. Though since those are also just 32 bit floats, using large numbers would exactly result in that jittering. So in order to actually have a fix origin, you would need to literally move everything in the world every single frame. That may work for some game types (simple 2d scrollers), but for most game types this would not be feasible. It usually makes more sense to have a floating origin that just gets repositioned / shifted every now and then.
Imagine you have a 3d shooter where the player has momentum, can jump, duck, roll and you apply all those physics not to the player but to everything else but in the opposite direction. The usual matrix transformations are more than enough for short range movement so we only have to reposition when we get too far from the origin. This makes most of the game logic way simpler.
Developers who read this forum deserve a representation and view that is balanced and not confused or misleadingly biased. They also deserve to know of original authorship and implementation. The author of your middle reference disagrees with you, and presents a more balanced view:
Note that he states the shifting method is not real floating origin.
The url of your first link offers confusion. The url contains “origin-shifting”, as does the heading of the page. Then it switches to “floating origin” in the sub-heading.
None of your references are from the original author.
Searching on “floating origin” can also show links to the original 2005 publication and implementations of real floating origin.
Did you just necro-ed a two years old thread to tell @Bunny83 that you think he called a “thing” wrong when everybody and their grandma’ use these terms more or less interchangeably? Wow.
2 Likes
I just came across it and may 2022 is not that old.
The two algorithms are opposite:
one moves the player and not the World, the
other moves the world and not the player.
Always moving the player and never moving the player are exact opposites and therefore worth clarifying and using different terms.
If I search for it I might just find YOUR 2005 publication on it?
Bruh… like ok. I get the pedantry. I’m pretty pedantic myself so it’d be a bit of pot and kettle if I criticized that. It’s why I didn’t really say nothing at first. But like… Lurking-Ninja got a point. It’s a 2 year old comment in regards to some basic naming (a name that yeah, a lot of people do use interchangeably a lot. Hence why the 1st article “offers confusion”). And your response included dropping a link to your own article but wording it like “oh it’s just a thing you might find if you searched for it”.
I get it… you’re a dr I guess (dr chris thorne?), you wrote a paper on the topic, your preferred naming convention in said paper has a very distinct and exact definition for the phrase “floating origin”, so much so you even have a website called “floatingorigin.com”. But you know… it kind of just comes off as… arrogant.
Take it from me! An arrogant full of themselves pedantic know-it-all.
1 Like