Provide feedback related to crafting, combat, enchanting, and general gameplay. Do not post bugs, support issues, or lists of random ideas. Please search!

← Gameplay
2
Follow

Engine Fix for Far Lands: Stable Infinite Worlds with Local Coordinates

We propose a core engine fix for the floating-point precision errors that cause chunk glitches and physics breakdown at large distances (~16M blocks). The Solution: A hierarchical coordinate system. Keep global coordinates for positioning/saving. Perform all physics/redstone/rendering INSIDE each chunk using stable local coordinates (range 0-16). This is seamless! A translation layer makes it 100% compatible with existing mods and commands - they see normal global coordinates. Players see no difference except perfect stability anywhere. Benefits: Permanently fixes jitter, broken redstone, and chunk errors at any distance. Enables truly stable infinite worlds or a seamless wrapping world. Future-proofs the engine for 64-bit expansion. We have detailed the math and a migration path for old worlds. This solves a decade-old technical debt and unlocks boundless building and exploration. If Mojang considers this proposal, the core formulas for the world migration tool and in-engine conversion would be: n2 = floor(n / 16) // Chunk coordinate from global n3 = n - n2 * 16 // Local in-chunk coordinate This solves a decade-old technical debt and unlocks boundless building and exploration.
Avatar
Registered User shared this idea

4 Comments

Please sign in to leave a comment.

Date Votes
Sorted by oldest
  • 0
    Registered User commented
    Comment actions Permalink

    The core issue is that Minecraft relies on 32-bit floating-point precision for all in-game calculations. As coordinates grow larger (beyond ~16 million blocks), this data type can no longer accurately represent the small increments between block positions. The game engine literally cannot tell the difference between two adjacent blocks, causing physics, collision, and rendering to completely break down. This hard limit betrays the promise of an "infinite" world and is a fundamental architectural constraint.

  • 0
    Registered User commented
    Comment actions Permalink

    The core issue is 32-bit float precision loss at large coordinates (>~16M blocks), causing physics and chunk errors. My solution changes the internal data format while maintaining full compatibility.

    New Internal Format:

    Chunk Coordinate (Macro): 64-bit integer, the chunk's unique ID. Formula: ChunkX = floor(GlobalX / 16).

    Local Coordinate (Micro): 32-bit float within [0, 16) for all physics/rendering inside the chunk. Formula: LocalX = GlobalX - (ChunkX * 16).

    Implementation:

    The engine internally uses the new format. A transparent "translation layer" at the API boundary instantly converts between legacy global coordinates and the new format for mods, commands, and the F3 screen. This ensures zero changes for players/mods while fixing the precision limit at its root.

    Example Conversion:

    The global position (34946, 44, 464967) is processed internally as:

    ChunkID: (2184, 29060), LocalCoord: (2, 44, 7)

    ChunkX = floor(34946 / 16) = 2184

    LocalX = 34946 - (2184 * 16) = 2

    This locks precision-critical calculations into a safe, small range, permanently solving the problem and paving the way for 64-bit worlds.

  • 0
    Registered User commented
    Comment actions Permalink

    Just like the longitude and latitude of the earth, the larger floor uses the standard "longitude and latitude" as the unique ID of the floor, but the difference is that each floor is independently calculated in floating-point precision from X: 0 and Z: 0.

  • 0
    Registered User commented
    Comment actions Permalink

    I don't believe this is a simple solution because there are many nuances that developers need to consider. Like the many types of computing architectures, as some bugs only happens on certain devices. But still, I wonder why isn't like this from the start...