mojira.dev
MC-159283

The End terrain does not generate in multiple rings centered around the world center

The bug

The End generation is broken at long distances since 18w46a.

In the End, the terrain stops generating and then generates again from a certain distance from the center of the End, according to a ring pattern.

This donut-shaped pattern repeats over and over to the edge of the world on a regular basis, starting at 370,720 blocks from the center of the End.

How to reproduce

Use the following commands to teleport you:

/execute in minecraft:the_end run tp @s 370720 90 0
/execute in minecraft:the_end run tp @s 21007528 90 0
/execute in minecraft:the_end run tp @s 21010807 90 0
/execute in minecraft:the_end run tp @s 21377192 90 0
/execute in minecraft:the_end run tp @s 21380415 90 0

Examples

[media]

[media][media]

[media][media]

Code analysis

The code is trying to process numbers that are much larger than what Minecraft is actually capable of for its world terrain noise which causes part of the terrain noise to generate numbers that ultimatly get read as NaN (Not a Number) and causes the terrain generation to fail outright.

[media]

For more information and a possible fix, see this comment from @unknown.

Source

Here is the source used to complete this ticket (examples, code analysis, visualization of what's going on...): https://youtu.be/91Feq0dHw28
Video by AntVenom.

Linked issues

MC-160770 End generation is broken beyond a few hundred thousand blocks Resolved MC-168609 Terrain in the end not generating in certain regions Resolved MC-169005 The End dimension terrain is generating in stripes beyond 370720 Resolved MC-169816 A mistake in Ender's world Resolved MC-178658 End 2 generation stops after a certain distance, then continues again. Resolved

Attachments

Comments 44

Can confirm. Those appear to be multiple "rings" around the world center that just don't generate terrain.

Also, interestingly enough, they're not chunk borders, they're quarter chunk borders.

Starts at or before 524288.

Starts at 370720

I found that these rings get exponentially smaller, approximately generating around a radius of sqrt(x / 2) * 2^15. That would mean that up until the world border of 30,000,000 blocks, there are at least well over 6500 rings, or over 3250 void gaps. That's not counting partial rings in the world's corners. If it's of any help, I documented my findings here, along with a list of coordinates of the first 10 rings for those interested:

https://gist.github.com/Deltanic/b98d005c9025f10a67de9e966fa57ebb

Can the 370720 be added to the main text, so it doesn't appear to be an issue that happens at impossibly high distances?

34 more comments

Can also confirm in 1.21.5. I also found that the rings become thinner the further you go out from the central island, according to mcseedmap:

[media]

The image shows the rings at coordinates x: 3 000 000 000 and z: 3 000 000 000

Here is a mathematical formula that predicts the onset of each ring on the x and z axes.

p = 2 ^ (18.5 + log(t)/(2 * log(2)))

where p is an unadjusted position and t is a parameter that are natural numbers (integers starting at 1).

When t is odd, it predicts the location where a void begins. When t is even, it predicts the location where normal terrain generation resumes.

For odd t, the true position of the void starts at:

n = floor(p/8) * 8

for even t, normal terrain resumes at:

n = ceiling(p/8) * 8

Some consequences:

  • The rings get progressively narrower as distance from the origin grows larger. This effect is logarithmic as shown above.

  • If any part of an 8×8 sub-chunk is out of range, the whole subchunk will not generate.

  • At sufficiently large distances, terrain will stop generating completely. This occurs when the step size of each ring reaches the size of a subchunk: 8. This will not occur within the 30 million radius of the world border.

The above formula has been shown to predict correctly the locations of the first 8 rings on the x axis with z = 0. These rings occur at 370720 (void), 524288 (normal), 642112 (void), 741456 (normal), 828968 (void), 908096 (normal), 980848 (void) and 1048576 (normal); all these coordinates were found by empirical observation.

For locations in other coordinates, p should be compared to the result of sqrt(x^2 + z^2), while being careful to avoid integer overflow.

The formula in my previous comment can be simplified slightly:

p = 2 ^ (18.5 + log(t)/(log(4)))

Maybe the formula should be this:

r = sqrt (n) · 262,144 (n N+)

[media][media]

I used long for coordinate storage and squaring calculations and this solved the issue in version 1.21.4

(My English in not good)

[media]

Stephen Shaffran

(Unassigned)

Confirmed

Platform

Low

World generation

end, rings, terrain, the_end

1.14.4, 19w36a, 1.15.1, 1.15.2 Pre-Release 1, 1.15.2 Pre-release 2, ..., 1.20.2, 23w40a, 1.21, 1.21.2 Pre-Release 2, 1.21.4

Retrieved