Floating origins: preserve local precision in large game worlds

Purpose

A large coordinate can fit inside a floating-point type while still lacking the precision needed for a small movement. Visible shaking, unstable contacts and camera-relative jitter can therefore appear well before numeric overflow. A floating origin keeps the active region near a small local coordinate by moving the coordinate frame. It changes how positions are represented, not where the player is located in the persistent world.

How it works

Represent a location conceptually as x_global = origin + x_local. Keep the global origin in a representation adequate for the world's scale, and perform nearby simulation or rendering with small relative values. Some engines also offer higher-precision world types or shader arithmetic that preserves low-order information.

Camera-relative rendering and rebasing an entire local simulation solve different parts of the problem. A rendering-only conversion does not automatically improve physics coordinates. For a pure translation of the frame, apply the same offset to all relevant positions; velocities do not acquire a new physical value merely because the positional origin moved.

Worked example

Assume one world unit equals one metre. In the normalized binary32 interval [2^20, 2^21), adjacent representable values are separated by 2^(20-23) = 0.125 metres. A requested adjustment of 0.01 metres at that magnitude cannot be represented as an independent positional step.

If the global representation preserves the desired position, subtracting a nearby origin before conversion to a local float can retain the small offset. Converting an already rounded global float to a double cannot reconstruct the information lost earlier. This is a representation example, not a measured limit for every game's physics engine.

Practical workflow

Define which system owns the global coordinate frame and when a rebase may happen. At a controlled simulation boundary, update active transforms and notify systems retaining spatial history. Include previous-frame transforms, camera smoothing, particles, audio emitters, navigation data and physics structures where they use the rebased frame. Use engine-supported update paths so cached acceleration structures remain consistent.

Keep saved locations and network messages tied to a stable global or sector-based representation. Convert explicitly at subsystem boundaries. Use a threshold policy that avoids rebasing repeatedly around one boundary. Record the origin identifier with diagnostic positions so reports from different local frames can be compared.

Limits and verification

Test travel far from the starting point, repeated rebases, small contact motions and effects spanning the transition. Compare relative distances immediately before and after the shift. Confirm that temporal rendering history follows the coordinate change without interpreting it as physical motion.

Higher precision carries memory and computation costs, and a giant mesh can still contain poorly resolved local geometry. Audit every conversion back to ordinary floats. Rotating or accelerating reference frames require additional physical treatment; this translation-only procedure does not cover them. Choose the representation from required spatial resolution and scale, not from map size alone.

Sources

• Large world coordinates — Godot Engine contributors
• Large World Coordinates Rendering Overview — Epic Games