Uploaded image for project: 'Minecraft: Java Edition'
  1. Minecraft: Java Edition
  2. MC-185925

Casting issue: Mineral vein generation uses 32-bit floats, leading to precision loss and potential crashes

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved
    • Resolution: Fixed
    • Affects Version/s: 1.15.2, 20w22a, 1.16 Pre-release 1, 1.16 Pre-release 2, 1.16 Pre-release 8
    • Fix Version/s: 20w28a
    • Labels:
    • Confirmation Status:
      Confirmed
    • Category:
      (Unassigned)

      Description

      Note to anyone creating a snapshot video: the fact that these ore veins repeat is not the bug being reported here. Refer to the screenshots below, specifically the late ones which are divided into quadrants - as you can see, the exact same ore vein ends up looking different when generated in one quadrant than when it is in another. You can see even more extreme precision loss in other screenshots, where the ore veins cluster into visible squares, which eventually happens on all worlds regardless of seed due to this bug. This bug is not dependent on seed! The only reason why the seed in question was used was to show how the exact same ore vein can differ depending on where it generates, this latter thing being the bug this ticket is referring to.

      A further explanation as to why this happened, as well as other similar such bugs, can be found on the following wiki page: https://minecraft.gamepedia.com/Distance_effects_in_Java_Edition

      The 1.15.2 mod used to demonstrate extreme versions of this effect can be found here (make sure to turn Far Lands generation off in the /farlands command's menu, and do not load any chunks between 67108864 and 134217728): https://www.curseforge.com/minecraft/mc-mods/farlands


      Related tickets: MC-164352, MC-186362, MC-187664

      Unlike most population features, the generation of mineral lodes uses 32-bit floats for block positions. This causes ore seams in the world to generate in a slightly distorted fashion within the world at high distances, which is very insignificant. However, if the world generation is extended out past 30 million blocks using a mod, this issue can escalate, even causing the world to crash if attempting to load chunks between 67108864 and 134217728 blocks, due to ore veins being positioned in adjacent chunks resulting in runaway chunk loading.

      It is possible to clearly reproduce this precision loss within vanilla bounds using the following seed:

      102496288339226

      which causes ore veins to repeat diagonally (due to a different mechanic), allowing us to compare the exact same ore vein as it would be generated at different positions. (Please don't fix this, though! Focus on the ore precision loss bug.) Couple this with the superflat preset

      minecraft:bedrock,2*minecraft:stone;minecraft:mountains;decoration

      to get a two thick layer of stone for ores to generate in. (As this functionality was removed in 20w21a, a reasonable alternative would be to just use a normal world with the /fill command to flatten and expose stone, such that the mineral vein generation becomes visible.)

      After 16,777,216 blocks, a clear cutoff can be seen where the ore veins start to generate in incorrect, blockier shapes (on the 085151 screenshot, 16777216 on both axes is to the top left).

      Further info can be found here: https://www.reddit.com/r/Minecraft/comments/9u9d4i/floats_minecraft_and_the_far_lands/

      Emerald ore generation is unaffected by this bug.

        Attachments

        1. 2020-05-28_08.51.14.png
          2020-05-28_08.51.14.png
          2.53 MB
        2. 2020-05-28_08.51.38.png
          2020-05-28_08.51.38.png
          2.53 MB
        3. 2020-05-28_08.51.51.png
          2020-05-28_08.51.51.png
          2.53 MB
        4. 2020-06-04_05.15.12.png
          2020-06-04_05.15.12.png
          1.85 MB
        5. 2020-06-04_05.26.55-1.png
          2020-06-04_05.26.55-1.png
          680 kB
        6. 2020-06-04_05.27.02.png
          2020-06-04_05.27.02.png
          1.64 MB
        7. 2020-06-04_05.28.10.png
          2020-06-04_05.28.10.png
          549 kB
        8. 2020-06-04_05.28.42.png
          2020-06-04_05.28.42.png
          1.76 MB
        9. 2020-06-04_05.29.50.png
          2020-06-04_05.29.50.png
          336 kB
        10. 2020-06-04_05.29.57.png
          2020-06-04_05.29.57.png
          1.84 MB
        11. 2020-06-04_05.38.55.png
          2020-06-04_05.38.55.png
          3.00 MB
        12. 2020-06-04_05.38.55annotated.png
          2020-06-04_05.38.55annotated.png
          2.45 MB
        13. 2020-06-04_05.44.05.png
          2020-06-04_05.44.05.png
          3.10 MB
        14. 2020-06-04_05.44.05annotated.png
          2020-06-04_05.44.05annotated.png
          2.35 MB
        15. 2020-07-07_17.11.12.png
          2020-07-07_17.11.12.png
          824 kB
        16. 2020-07-07_17.12.57.png
          2020-07-07_17.12.57.png
          702 kB
        17. 2020-07-07_17.15.03.png
          2020-07-07_17.15.03.png
          777 kB
        18. 2020-07-07_17.15.34.png
          2020-07-07_17.15.34.png
          673 kB
        19. 2020-07-07_17.18.20doctored.png
          2020-07-07_17.18.20doctored.png
          2.39 MB

          Issue Links

            Activity

              People

              Assignee:
              grum [Mojang] Grum (Erik Broes)
              Reporter:
              Awesoman3000 Connor Steppie
              Votes:
              11 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved:
                CHK: