Floating Origin is a [[Game Design]] technique for enabling large open worlds. [[IEE-754]] floating point numbers get less precise the larger they get, and more precise when close to 0. It makes sense to have all gameplay action in a game around coordinate 0, as you get the most precision when it comes to physics and on-screen movement. Enabling that in a large open world means that you move the gameplay space in the opposite direction of player movement, so that the gameplay space stays within precise floating point range. ## Simple Strategy When the user moves, say, 100 units away from the origin in an axis direction (X, Y, Z), move the world 100 units in that direction, and move the player -100 units back. This keeps the player within the same space in the game world. Generally, on the frame this happens, physics interactions (especially with PhysX based solutions like Unity) need to be paused. Otherwise, the system will believe there was an acceleration 100m/frame applied and go crazy. ## Extended Coordinate System Extending the simple strategy, larger worlds can be represented by having positions represented by a chunk (macro) and sub-chunk (micro) position . Sub-chunk positions are bounded by a term called *chunk size*. If chunk size was 1024, and a sub-chunk position was 1025, the chunk would be incremented by 1, and the sub-chunk would be modulo'd by chunk size to 1. For example, a position could be represented as $(1,5,4) => (102.42, 240, 241)$, which is a position within the chunk $(1, 5, 4)$. I've worked on games that cover very large (galactic-scale) distances. Rather then fake it, extending the coordinate system has a few advantages: * Macro-positions are based on integers, and therefore are precise and network stable. * Micro-positions are bounded within a range, so they get benefits of being close to 0 in IEEE-754 * Micro-positions are sufficiently compressed that they can be optimized in a [[Data Transfer Object|DTO]] * Micro-positions can never be negative * Malformed micro-positions lose precision but $\epsilon$ is very small, within margin of error. ### Mathematical Properties * Values that be represented: $2^{32} + 2^{m} + 2^{22} = 2^{54 + m}$ * Maximally representable integers: $2^{32+m}$. * Maximum imprecision (for m=10): $2^{10 - 23} = 0.000122070312$ This is because the factional exponent is limited by our chunk size, but we fully use the mantissa. ### Performance The tradeoff is the additional calculation per position. There is more work being done per position. There are two strategies for performing calculations: * Perform proper calculations to preserve low floating point error * Simply operate on the micro position and "fix up" the chunk at the end of the calculation. * Perform calculation in world-space, and re-integrate to extended coordinate system. For physics, which are already imprecise and should only be done near the camera anyways, re-integration is useful in systems like [[Unity]] where you don't have control over the physics simulation. #### Locality * $x$ = distance in chunks * $m$ = size of chunk Locality tests, or tests to see if two coordinates are close, are significantly easy to perform on chunk-level scales. The relationship below demonstrates that if the chunks are within a certain distance, then the actual distance between them is bounded a multiple of the number of chunks and the chunk size. $ \lvert A - B \lvert \leq x \Longleftrightarrow x\times m \lt \lvert A-B \lvert $