Bedrock Edition distance effects

As the player travels far from the world origin in Bedrock Edition, the world starts to behave abnormally. This is mostly caused by precision loss of the 32-bit floating point numbers used for location.

Note: Effects marked with an asterisk (*) are well-known effects.

General effects
Some effects can occur at any distance but gradually worsen as coordinates increase. Bedrock Edition uses 32-bit floating points for many of its calculations, such as the player's position, as opposed to Java Edition, which uses 64-bit floating points. A 32-bit floating point uses 23 of these bits for precision (the other 9 are used for the sign and the order of magnitude). Thus, there are 223 (8,388,608) possible positions for any given order of magnitude. For example, there are 8,388,608 possible positions between 1 and 2, each $1/8,388,608$ apart, but there are also 8,388,608 possible positions between 8,388,608 and 16,777,216, each a full block apart. In general, between 2n and 2n+1, the valid positions are 2n-23 apart. At higher coordinates, the valid positions are farther apart, so position is less precise. This principle has several implications.

Block rendering errors
Various blocks are rendered as partial blocks, and the game uses 32-bit floating points to calculate the corners. At high coordinates, these coordinates become offset, causing the block to render incorrectly. Blocks with more detailed models usually become glitched at lower coordinates (a few blocks start to render incorrectly at a relatively low 131,072 blocks), while full blocks continue to render correctly past 8,388,608 blocks, farther out than most partial blocks.

Slow movement becomes impossible
For an entity to move, it advances a certain distance each tick. At slow speeds or high coordinates, the increase in distance per tick is so little that when rounding to the nearest valid position, the entity is placed at its original position, so it essentially does not move at all. More specificially, between 2n and 2n+1, an entity's speed is rounded to the nearest multiple of 20*2n-23, so it must move at least 10*2n-23 to actually be considered moving.

There are several ways to slow the player’s movement, such as sneaking, status effects, using an item (e.g. drawing back a bow), or certain blocks (such as cobwebs). In addition, moving diagonally decreases the player’s speed on any given axis. This effect can be amplified by moving almost (but not exactly) along an axis, and by walking into an object, one can do this without changing their coordinate on the other axis. Note that due to trigonometric rounding errors, extremely small angles do not cause the player to move as slowly as expected. The slowest form of movement without walking into objects (sneaking through cobweb over blue ice with Slowness VI while touching powder snow and drawing back a bow) becomes impossible at 256 blocks, and coincidentally, the slowest form of movement achievable by walking into an object at a slight angle also becomes impossible at 256 blocks; as a result, both methods must be used to slow the player down if one wishes to observe this effect at lower coordinates.

Jitter
The game normally runs at 60 frames per second, so when the player moves, the game must calculate the camera position on the intermediate frames between ticks. This is normally not an issue, but if the player is moving close to the slowest possible speed, the camera position on intermediate frames becomes distorted, and the game starts to jitter.

Eventually, the slow speed and precision errors reach a point where the player only advances by 1 valid position per tick, forcing that the game to render the intermediate frames at exactly the starting or ending position. As a result, the camera moves as though the game ran at 20 frames per second instead of 60.

Since slower speeds become jittery at lower coordinates, it is impossible to say exactly where jitter "starts."

Falling through the world
At extreme coordinates, small entity hitboxes shrink to width 0, and such entities can fall through the edges of solid blocks. For example, if an entity smaller than $1/4$ blocks exceeds coordinate 2,097,152, its position is rounded to the nearest quarter. Since its hitbox extends less than $1/8$ from a valid position in each direction, both sides of the hitbox are rounded to the same position, so the apparent hitbox size is 0.

In addition, it is possible to manipulate hitboxes and fall through the world at much lower coordinates. While the positions of the centers of entities are stored in NBT, the positions of the individual hitbox corners are stored in memory. If the player is crossing a power of 2, these corners may move at different speeds, if they are affected differently by floating point precision errors, thus changing the hitbox size. The hitbox size resets to 0.6 in certain situations, including: Again, if the player's hitbox size shrinks to 0, it becomes possible to fall through the edges of blocks and into the void. Conversely, it is possible to stretch one's hitbox to several blocks wide.
 * Exiting and reloading the world.
 * Using the command.
 * Switching between walking, sneaking, crawling, swimming, and gliding positions.
 * Teleporting using ender pearls or chorus fruit.

Medium effects (X/Z ±131,072–1,048,575)
Eventually, some common forms of movement begin to glitch. In addition, blocks with detailed models begin to render incorrectly.

Major effects (X/Z ±1,048,576–16,777,215)
Blocks are rendered based on their corners, whose coordinates are 32-bit floating point numbers. Generally, these are multiples of $1/16$. Thus, most blocks render normally as long the floating points are precise to the nearest sixteenth. This breaks at X/Z ±1,048,576 (220), and blocks continue to render incorrectly as the coordinates go even farther out. However, there is never any vertical distortion.

In the RTX betas, the lighting is unaffected by floating-point precision errors, although block shapes themselves are incorrect.

Besides, many "normal" forms of movement become impossible.

The different types of block model deformation have changed a lot over the years, although the update specifics and hardware requirements are unknown. Previously, blocks such as flowers and grass would appear completely 2D beyond 8,388,608 blocks, whereas they appeared as almost normal X shapes in more recent versions, but appearing as 2D again as of 1.16.220. Also, sunflower heads could previously distort to become square, which also no longer happens; the flower appears detached from the plant instead.

In addition here, the terrain starts to break down following the table.

Game-breaking effects (X/Z ≥±16,777,216)
Here, the rendering fundamentally breaks down to the point where normal gameplay is completely impossible.

Stripe Lands


The Stripe Lands are an artifact of the game's rendering and block hitbox calculation, rather than a quirk relating directly to terrain generation. The Stripe Lands start at X/Z ±16,777,216. They exist because coordinates are off by up to a full meter, causing the blocks themselves (not just their corners) to appear in the wrong places.

Past X/Z: ±33,554,432 all blocks are rendered as two-dimensional, and the gap between valid blocks doubles to 1 out of four. This gap doubles again at every power of 2 and reaches 128 blocks wide at X/Z: ±1,073,741,824. This is the widest the gaps can be since the game crashes near X/Z: ±2,147,483,648.

Vertical limits
Like the X and Z axes, the game breaks at excessive Y coordinates. Since blocks cannot be placed above Y=320, block rendering glitches do not occur, but other effects do.

Many of these effects would occur at negative coordinates, but there is a barrier at Y=-104. Beyond this entities can move only vertically using the "fall through the world" glitch, or teleporting below Y=-104. Thus the barrier can be avoided by teleporting past X/Z ±8,388,608. Also, all entities, except players in creative, disappear in the void.