1) Inspired by the then-ongoing pack.png seedcracking project (I just watched SalC1's videos on it), I (Tomlacko) came up with the idea to crack the original panorama too, as I was always interested in where it came from. I came to SalC's discord server to ask if there are any plans to do that (https://discord.com/channels/436405308458401803/666758275504537604/721566488556994668) (14th June 2020 3:27:36am UTC), but I didn't really get a response from anyone who knew what they were talking about. Still motivated to solve this mystery though though, I decided to pull an all-nighter looking into it myself and see how far I can get / how much info I can determine myself, hoping that doing so would have a much bigger chance kickstarting such a project and getting other people interest.

2) I immediately extracted the panorama from the game's files (the most obvious step, otherwise what else is one supposed to work with). The files are stored as 6 screenshots taken at 90FOV in all directions (axis-aligned) 90 degrees apart from each other, forming what's called a cubemap. Note that the game applies a blurry overlay when this cubemap is displayed on the title screen, but this blur is not present in the files themselves. Despite that though, it was still pretty low resolution, only 256x256 per image, but definitely useable and way better than pack.png. Here's what it looks like when stitched into a single image: https://i.imgur.com/n7z0rL2.png

3.1) Looking at the image, I started figuring out some things. Firstly, I had to narrow down the possible version it was taken in, because the panorama was introduced in beta 1.8, which sits on the cutoff where a completely new world generation system was introduced (and without knowing which version to use, nobody would be able to crack it of course). Despite the file dates being from 21st June 2011 9:43:54 AM (Sweden time), which is before even beta 1.7 came out, it wasn't immediately obvious that this wasn't beta 1.8 generation, as the updates go through behind-the-scenes development way before they are made public, and this could've already been some prototype of the new world generation despite no other beta 1.8 features being present in the image. In the end however, I was able to determine it was likely the old world generation used in beta 1.7 and prior, and despite there being no way to tell if this is beta 1.6 or beta 1.7, there was no need for that, as both versions had identical world generation. (The ways to tell it was b1.7 or older and not b1.8 are that the lighting changed in b1.8, the sea level shifted 1 block down and the clouds got raised higher, none of which is present in the panorama.) (Also later during the project, it was further confirmed to be b1.7 or older worldgen, since the sea level matched our coordinates and there was a seasonal forest biome visible in the background, which existed only before b1.8.)

3.2) Then I went on to figure out the world orientation (the player is facing south, towards +Z) using the grass texture (in these older versions textures are NOT randomly rotated, they always face the same way).

3.3) Counting the blocks up from the water level, I was able to determine the exact Y position (Y=75 for feet position, Y=76.62... for eye position).

3.4) Looking at the cloud patterns, I was able to find the exact Z coordinate too (Z = -68.7357...). Clouds are based on one big texture that sweeps across the sky in one direction (X), but Z is stationary, so looking at the texture and finding under which cloud blob you are gives you the Z position. (https://i.imgur.com/zwSys8c.png)

3.5) The exact position of the player (down to the pixel) was easy to determine using the grass block below the player, it was just a matter of marking the center of the screen relative to it. (https://i.imgur.com/dBLG1tj.png)

3.6) I marked a few other things of interest in the panorama that didn't end up being used / needed, such as the idea to use the angle of the sun, cacti, flowers or well hidden coal ore.

3.7) Here is the annotated image I used to present all of these findings: https://i.imgur.com/CYNBqsw.png

4) Later that day, I went back to the SalC1 Discord server and shared all my findings so far (https://discord.com/channels/436405308458401803/666575359411748875/721774259961200710) (14th June 2020 17:13:13 UTC), and to my surprise, it immediately attracted a lot of interest this time, after which the admins and other seedfinders took me to a then-small seedfinding server called "Minecraft Research" at the time (however a few days after that it got renamed to "Minecraft@Home" to match the format of other BOINC projects). In this server, a few channels dedicated to the panorama project were immediately created and work started being done right away (https://discord.com/channels/720723932738486323/721776112014721096/721781854339858610) (14th June 2020 17:20:34 UTC). It seems like all of the finders were burnt out on pack.png as it wasn't going too well and this project was a breath of fresh air while also looking a lot easier.

Beginning of MC@H work

Recreation & overlay

5.1) I went to set up a cubemap viewer that lets people see the cubemap in 3D instead of individual images, so it's easier to work with. (https://codepen.io/Tomlacko/pen/GRoqwWq). Other people like Maze and Poke also set up their own cubemap viewers independently of me. (https://encryptedmaze.net/menu.html)

5.2) I spent time explaining to people how the panorama was rendered (direct rasterization without anti-aliasing), and how AI upscaling (which people were suggesting to use) would not be helpful here. I created this album to explain it: https://imgur.com/a/72V4HDx.

5.3) I recreated a small portion of the panorama in singleplayer to verify a few things, such as the position and FOV, by replicating the screenshots (https://imgur.com/a/Ukx2huG) and also loading them into a separate cubemap viewer (https://codepen.io/Tomlacko/pen/NWxRdRp).

5.4) For everyone to be able to collaborate on recreating the panorama based on the original images, Philipp_DE set up a Minecraft server in a modern version (1.15.2) which anyone could join after whitelisting themselves using a Discord bot he made in collaboration with vcokltfre. Despite popular belief though, the rebuilt world isn't actually physically used in any way in the seedcracking process. The reason a recreation is needed is simply to be able to precisely judge what is where, since counting blocks directly on an image is extremely error-prone and sometimes outright impossible, especially at these low resolutions. The precise info can then be used when writing seedcracking code for a given project. World download of the recreation in its final state when the project finished: https://cdn.discordapp.com/attachments/721776110261501973/1109873575739019274/panorama_recreation.zip

5.5) Lots of people helped with the recreation in other ways than just building. I made a block-locking datapack, pseudogravity made a block grid renderer, etc.

5.6) A guy called "Microsoft Word" got the simple yet brilliant idea (https://discord.com/channels/720723932738486323/722180917308686374/722228859893710989) to have a bot that would take screenshots of the recreation and assemble them into a cubemap just like the original, which could be used to compare them against the original and help guide the recreation process. DutChen18 set out to make the mod to create cubemap screenshots, Philipp_DE joined on the server with his N00bBot account with the mod applied, and I went to create a new cubemap viewer (https://codepen.io/Tomlacko/pen/mdVOOwG) that could overlay these images LIVE as the builders were building. This ended up being incredibly helpful for all the builders, and completely revolutionized how every future project is done. For example pack.png, which would probably not end up being found if it wasn't for this overlay recreation building approach. Here's the final cubemap image from the recreation from after the project was finished: https://i.imgur.com/gBOhP50.png

5.7) A few more tweaks to replicate old Minecraft rendering ended up being needed for maximum overlay accuracy. Earthcomputer developed a custom mod that, when applied to the screenshotting bot, would render the grass with the same offsets as older Minecraft versions (https://github.com/Earthcomputer/GrassAlign). Another tweak that was needed was replicating a small 0.1 unit offset that was applied to the camera opposite the facing direction in older Minecraft versions. This issue was originally noticed and researched by PseudoGravity, because our overlay didn't align too well and we noticed a seam in the original images that Mojang seems to have missed when creating the panorama. This mod however wasn't made until a few days later due to misunderstandings with Earthcomputer.

X coordinate

6) (16th June 2020) In the meantime, I found the remaining coordinate (X = 61.4880...) of the player by comparing the grass blade offsets in the panorama to the offsets in a world I made. These offsets depend purely on coordinates, not on the seed, therefore they are the same for every world. After a while of looking, I found a match, making the full coordinates known now. (when I found it: https://discord.com/channels/720723932738486323/722180917308686374/722475057699487754, images of how I did it: https://i.imgur.com/sH3mSYX.png, https://i.imgur.com/aAGZSBj.png)

Initial seedcracking attempts

Grass + tree -> chunk seeds

7) While that was happening, Earthcomputer was looking into an idea to crack the chunk seed using the tree to the east and the grass positions around it, then reversing the chunk seed into a world seed. He simulated the way grass is distributed in a chunk and created a probability map (https://discord.com/channels/720723932738486323/722180917308686374/722471117322846298). This idea however did not end up working out, because while theoretically possible, the grass patch was in an unhelpful spot relative to the chunk boundaries and it ended up not helping much with reducing the number of possible chunk seeds. Other possible locations were also checked, but none of it really ended up being worth it, and so the idea was abandoned. Here are the frequencies of grass that spawned on each block from when he ran a simulation of 100000 populations of grass in an 32x32 area (assuming a flat ground at y=75):

Tree, biomes, terrain & BOINC?

8.1) (17th of June 2020) Instead of Earthcomputer's chunk seed -> world seed idea with the grass and tree (known as the backwards approach), cortex was checking the feasibility of bruteforcing the correct world seed directly (known as the forwards approach) using biomes. The border between grass and desert looked very promising as it marked a very distinct biome border, which would work as a great filter in narrowing down all the possible seeds. The issue is that computing biomes is quite slow, and given that there are 2^48 possible seeds (only in old versions, newer versions have even more seeds, 2^64 to be exact), and checking the biomes for all of them would take a VERY long time. (The grass/desert biome borders, marked with gold blocks: https://i.imgur.com/wvQLrQ9.png)

8.2) Together with Earthcomputer though, they came up with the plan to use the already mentioned nearby tree to the east as a fast initial filter. If the tree's position and corner leaves didn't match, the seed could be immediately discarded, skipping the complex biome check, making the code a lot faster. Any seeds that would pass the tree filter and then also the biome filter would be saved, and later separately filtered using terrain, which is the slowest (even slower than biomes), and so it's always left for last, for when only a few remaining seeds are left. (Tree to be used: https://i.imgur.com/aJBGc4g.png)

8.3) Despite that though, the main filter was still going to require a lot of computational power, and for that, 2 things needed to be done. Firstly, they would need to run the code on GPUs, which due to their massive parallelization can check millions of seeds per second, and secondly, for even more parallelization and computing power, they needed a new BOINC project to be set up. BOINC is a distributed computing platform used all over the world for all kinds of research (you might be familiar with Folding@Home), and just like that, the Minecraft@Home team was already using BOINC for finding the tallest cactus, which was set up just a few days prior. And so everyone got to work...

9) (18th of June 2020) Up until now, the overlay and recreation was helpful, but there was still that one annoying issue with the camera offset mentioned earlier. The inaccuracy was starting to be an issue when trying to get some of the more distant blocks placed accurately, and so Earthcomputer looked into it again and managed to finally replicate this old camera behavior with another custom mod. After applying that mod to the screenshotting bot, it was immediately clear that it was worth it as our overlay was now basically pixel perfect, and it was now possible to build even more of the panorama with perfect accuracy. (https://discord.com/channels/720723932738486323/721776112014721096/723224491697635372)

10.1) (18th of June 2020) Neil helped with the seedcracking by preparing all the necessary biome and terrain code. He looked at the code beta 1.7 uses to generate worlds, and rewrote all of the necessary parts of it in C++ while also heavily optimizing it (https://github.com/minecrafthome/minecraft-beta-alpha-terrain-generation-cpp). This C++ code would then serve as a reference for writing the GPU CUDA code for the actual cracking of the seed.

10.2) Chip, Hypprs and others went ahead and started preparing the new BOINC project, so when the GPU code is done, it could be uploaded and distributed through BOINC, with everyone being able to contribute their computing power.

10.3) Cortex and Earthcomputer got together, and, with the help of the code Neil prepared, started working on the GPU (CUDA) seedcracking code, which filters the seeds first using the tree and then the desert/grass biome borders. They then kept optimizing that code as much as possible, to the point where the code was fast enough (over 1 billion seeds per second) that cortex didn't want to use BOINC anymore as he didn't deem it worth it at this point. Here is the code they ended up with at this point: https://cdn.discordapp.com/attachments/721776112014721096/723820601302712321/crack.cu, and here is Earthcomputer testing the code and looking at a valid candidate seed that passed the filter: https://discord.com/channels/720723932738486323/722180917308686374/723671961770655795

11) While all of that was going on, there were people still working on the recreation, and despite already having all the necessary details figured out after only 4-5 days since the project started, people who had nothing better to do were still having a lot of fun continuing to build as much of the difficult background details of the panorama as possible, probably just so the coders have as many options and data to work with as possible, but also just for fun.

12.1) (20th June 2020) The BOINC project for the panorama seedcracking code was prepared during the early morning, with the code cortex and Earthcomputer wrote uploaded to it, and everyone was already getting excited as the seed was expected to be found pretty soon now, however there were some issues with BOINC and the tasks weren't getting distributed properly, which they weren't able to resolve for quite some time.

12.2) Meanwhile cortex and Earthcomputer got impatient and instead decided to rent a cloud GPU cluster on AWS in the meantime (in line with cortex's beliefs that BOINC was unnecessary for this) and ran their seedcracking code on it, searching through all the 2^48 seeds. After a few hours, the code finished and cortex went to further filter the resulting seeds using some Java terrain checking code they wrote. Unfortunately though, they did not end up finding even a single matching seed in the end.

12.3) They speculated that this is likely due to something in the chunk throwing off their tree filter calculations, such as the spawning attempts for clay, underground dungeons or lava lakes, which spawn differently depending on existing terrain (which cannot be predicted at this stage). And so they went back to their code to add more edge cases and attempted to fix stuff.

Second attempt

13.1) Over the next 2 days, they kept updating the code and trying to get it all to work, until finally ending up with this version https://github.com/minecrafthome/b1.7_seedfinder/blob/master/crack.cu and running it on BOINC again on 22nd June 2020.

13.2) Later that day, the run has already finished, with surprisingly little results again (https://discord.com/channels/720723932738486323/722172314313293864/724725498969718876).

13.3) Nevertheless, Neil immediately went ahead and ran the final terrain filter on it, this time using his own code (https://github.com/hube12/TerrainAlphaTemp) instead of cortex's, but despite trying multiple different blocks as the filter, all attempts resulted in yet again 0 matching seeds being found, leaving everyone a bit disappointed after thinking the seed was within our grasp this time.

13.4) Neil double-checked his code and concluded that the problem definitely has to be in the first filter. Either something in the chunk population is still throwing off the tree filter calculations, whether it was lava lakes or something else (I speculated that maybe they didn't identify the grassy biome correctly (as they were all quite similar), but regardless, he believed it was time to abandon the fast tree-based filter due to its unreliability, and instead figure out a way to crack the seed the slow way using just biomes right away.

14) At this point, things would need to be done the hard way and everyone was left a bit demotivated, so progress on the project quickly slowed down compared to how fast it was going up until now.

Grass colors -> biome values

15.1) (24th June 2020) The current idea that was being floated around by cortex was to somehow reverse-engineer the colors of the grass into the underlying temperature and humidity biome values from which the colors are derived by the game, and use these in combination with the already known desert/grass border biome values to filter for matching seeds (which would still need to be further filtered using terrain later). As mentioned earlier though, this was gonna take a lot of computational power and time, and would actually require the full power of BOINC this time, but at this point everyone just wanted to be done with it, and since everything was already set up for it anyways, they decided to move forward with this approach.

15.2) cortex then dug up the game's code responsible for the biome->color calculations (code: https://discord.com/channels/720723932738486323/722180917308686374/725191805305487370, gradient texture that gets sampled: https://cdn.discordapp.com/attachments/722180917308686374/725186787395502080/grasscolor.png), explained how it works, and also laid out the plan for how it's going to help us. In the previously used seedcracking code, humidity would be checked first at each measured location, filtering out 95% of the seeds, and for the rest of them temperature would be checked too, removing 75% of the remaining seeds. This was a decent reduction when working with an already reduced amount of seeds by the tree, but now when working with the full amount of seeds, it's barely anything (from 2^48 seeds to 2^47.5). That's why a lot more biome checks (using the values obtained from grass) were now required to reduce the amount of seeds that passed the filter.

15.3) Someone just needed to look into reverse-engineer those colors of some of the grass in the panorama, and that somebody ended up being PseudoGravity, who initially picked it up on 26th of June 2020 (https://discord.com/channels/720723932738486323/722180917308686374/726189488543629417) and continued his research in the following days (https://discord.com/channels/720723932738486323/722180917308686374/726638299493433416). I also tried helping by comparing the panorama grass colors to grass colors in random worlds in different biomes, however that didn't really lead anywhere, and so I left it on PseudoGravity as he was already doing a good job with this.

15.4) Despite thoroughly analyzing the colors though, he still wasn't sure how the conversion between temperature and humidity into colors worked, as the snippet of code that cortex posted didn't really tell the full story, but after looking into it a bit more and experimenting with it a lot, he managed to figure it out in the end (or so he though). By matching the hue and saturation of the grass to the look-up texture, he was able to get the possible temperature and humidity ranges for that block, although with a catch, since the game actually samples a random nearby location instead of sampling the current block's location directly, but this pseudorandomness can be accounted for since we know the coordinates. Here's his first successful attempt at reverse-engineering some of the grass: https://discord.com/channels/720723932738486323/722180917308686374/726901784794103959 (spoiler alert: this wasn't completely correct yet).

15.5) Despite the seeming success though, nothing much seemed to be happening around the project. But PseudoGravity kept at it, narrowing down the uncertainty in the values he obtained even further while also reverse-engineering even more of the grass in the panorama, until he came up with with this list of temperature and humidity values for 18 grasses on 30th June 2020: https://discord.com/channels/720723932738486323/722180917308686374/727355222304882748 (and right under that he also graphed those values onto the actual coordinate grid of the panorama's location, which is cool to see).

15.6) This was more than enough for the use in the seedcracking code (note that in the end, only a few of the grass locations would end up being used, not the whole list), but other people were currently too busy and therefore the project stood still despite everything else being ready now.

15.7) On 7th of July 2020, PseudoGravity got an even bigger list of biome measurements based on grass colors: https://discord.com/channels/720723932738486323/722180917308686374/729832598628597780

16.1) (13th July 2020) In the meantime, while waiting on cortex to finish the new seedcracking code, DutChen18 with PseudoGravity decided it would be a good idea to double-check everything, and so DutChen18 created a quick mod to dump biome values from a known seed in order for PseudoGravity to replicate his process on it and see if it all agrees, which it did so far.

16.2) At the same time, cortex and Earthcomputer further reversed the panorama's temperature and humidity values previously obtained by PseudoGravity into the raw simplex noise values that could've produced them, and figured out the necessary ranges to check for (https://discord.com/channels/720723932738486323/722180917308686374/732207842919972955). (The real temperature is a combination of temperature and precipitation, same for humidity. Precipitation just changes the bounds of temperature/humidity.)

16.3) (15th July 2020) cortex, Earthcomputer and PseudoGravity were then further testing stuff by creating a copy of the panorama in beta 1.7 and most likely applying the reverse-engineered biome values to it to yet again double-check their method and confirm that all is correct, since running the final seedcracking code was likely going to take over a week, so everyone wanted to be sure to get it right on first try and not waste people's resources. DutChen18 also helped by providing more testing samples with his biome data dumping mod.

16.4) And good thing they did all that! Because they did indeed find an issue. Due to previously not being too sure about how the biome color was blended with the default grayscale grass texture, PseudoGravity made a mistake and ended up with the wrong temperature values (humidity was ok). After that, everyone looked into how to do it properly and the error was promptly fixed, with all the subsequently derived values soon fixed as well.

16.5) Here are the actual properly fixed measurements now, with graphs above it: https://discord.com/channels/720723932738486323/722180917308686374/732956927793037324

Final attempt on BOINC (biomes + terrain)

17.1) With everything finally ready, cortex and Earthcomputer prepared the final version of the GPU CUDA seedcracking code on the next day (https://github.com/minecrafthome/b1.7_seedfinder/blob/master/grass_crack.cu). This code first checked the least correlated humidity values at 3 different positions figured out using the grass earlier, then it checked the correct temperature range, biome and humidity at the player's position, and lastly it checked 2 different spots along the border with the desert (2 blocks per spot, one at each side of the border) for desert and a grassy biome. In the end, this would narrow down the seeds from 2^48 to only 2^23.5 total seeds expected to pass all these filters, which is a really good reduction rate. All these results were then planned to be (just like last time) further filtered using separate terrain checking Java code later. (The biome borders used in the filter, same as previously: https://i.imgur.com/wvQLrQ9.png, border 1: https://i.imgur.com/b4vn6Ws.png, border 2: https://i.imgur.com/HR5BGNK.png)

17.2) The speed of this code was around 10 million seeds per second on an average GPU (GTX 1060), which might sound fast, but checking all 2^48 seeds would've taken almost an entire year, so it was necessary to use BOINC for it this time. That's why Chip, Hypprs, Earthcomputer and cortex were hard at work on 16th July 2020 and especially 17th July 2020 setting up the project on BOINC, so that this long time could be reduced to just a few days thanks to all the computational help our contributors would provide.

17.3) On the evening of 17th July 2020, the project was launched and announced, the floodgates were opened and people could begin crunching. We ended up having a combined computational power of 15.4 PetaFLOPS, which would rank us as the 16th most powerful supercomputer in the world at the time. During the run, we had a total of 137 users contributing 231 total GPUs.

17.4) The whole BOINC run was expected to take 3-5 days (estimates varied), but as the first results were coming in, cortex kept frequently checking them with the terrain filtering Java CPU code they had ready (some of the code: https://i.imgur.com/0BmVGRB.png). This code was set up to check 8 different block heights near the player (relative to each other, to not rely on exact Y positions just in case), which was strong enough of a filter to be able to find the exact matching seed (or nothing, if something didn't work still), at the speed of around 2000 seeds per second on an average CPU, which in comparison is insanely slow and that's why the initial biome filtering was needed, as now it was able to keep up.

Seed found!

18.1) (18th July 2020) Only about 6 hours later since BOINC was started and the seedcracking began (so far processing only around 1/8 of the total amount of seeds), at around 5:45am UTC, the impossible has happened! Cortex immediately (at 5:49am UTC) sent an image (https://cdn.discordapp.com/attachments/722006366062903326/733923648968065145/unknown.png) in private-chat showing that the seed has finally been found! (Our immediate reaction: https://i.imgur.com/VF4IphS.png). This marked the first time anyone has visited the panorama world since Notch created it 9 years ago (relative to the year of the finding). The BOINC user who's machine got lucky and found the seed was "vanos0512" (they seem to be someone who contributes a ton of computational power to many other BOINC projects outside of Minecraft@Home).

18.2) So, what was the seed? Well, there are actually 2 possible seeds (2151901553968352745 and 8091867987493326313) that could've been the original seed, both equally likely (more on this later), and both generating exactly the same world. The reasons for this are a bit technical. The way old beta (and partially even modern) Minecraft internally works with seeds (which are stored as a 64 bit integer) causes only the lower 48 bits of the seed to actually be used, and the top 16 bits are completely ignored. This actually means that there are 2^16 seeds that all generate this panorama, with absolutely no difference between them. So why are the 2 seeds mentioned earlier special? Because for even more technical reasons, those are the only 2 numbers produceable by Java's random number generator, because while the RNG can generate numbers as big as 2^64, it can only generate 2^48 total unique values, and these values are sparsely distributed across the whole 2^64 range, meaning that most numbers will never be produced by the RNG, only a handful of values will, and out of the 2^16 possible seeds that can generate this panorama, only the 2 mentioned are produceable by randomly generating a world. All the 2^16 seeds can otherwise be obtained by this formula: 25357015387625 + (2^48)*k, where k is any whole number between 0 and 65535.

Seed reveal & Dinnerbone

19) Before the finding was announced to the public, we wanted to make sure we're ready for the chaos, and so Earthcomputer wanted to create a short reveal video to use for sharing the finding. Cortex created a group DM on Discord and invited Earthcomputer, DutChen18, me (Tomlacko), Neil and PseudoGravity, as we were considered the main contributors to this project. Unfortunately though, PseudoGravity couldn't make it in time, so he wasn't in the video. We joined into a voice chat and Earthcomputer made a beta 1.7.3 server with the panorama world on it. After we joined though, it took us some time to finally decide what we want to do in the video, and then it took some more time and multiple tries to get it right. When we were done, we started messing around on the world for a bit of course. :D The recording was then sent to Neil and he edited the video.

20.1) The seed was then publicly revealed for the first time by sharing the video we've made (uploaded to Earthcomputer's channel) in the project-announcements channel of the Minecraft@Home server on the same day at 14:43 UTC. (https://www.youtube.com/watch?v=caLCZNLPgrM)

20.2) Just a few minutes after that, I published a reddit post I wrote about the finding on r/Minecraft, which gained a lot of attention and caused the main spread of the news. (https://www.reddit.com/r/Minecraft/comments/hthrmk/big_news_we_have_found_the_seed_of_minecrafts)

20.3) It even gained the attention of Mojang, and Dinnerbone ended up not only sharing some previously unknown facts about the panorama's development in the comments (sharing the original plans for a different panorama https://www.reddit.com/r/Minecraft/comments/hthrmk/big_news_we_have_found_the_seed_of_minecrafts/fyherp0 and showing the image of it https://cdn.discordapp.com/attachments/721776112014721096/734129117058039808/unknown.png), but he also joined our Discord server later that day and continued to share things like the image or other hardcoded seeds ("Don't Look Back", "MpServer", -8405390683083817, -4906777807712887154, -7699423886474875186; with hardcoded spawn positions at -90, 72, -1113 or 796, 72, -731 for some of them) and even joined voice chat with us for a while.

True seed via nanoseconds attempt

21.1) Sometime later after the seed was found, Earthcomputer tried looking into the possibility of figuring out which of the two candidate seeds was more likely to be the original seed that Notch happened to randomly generate all those years ago, and in the process hopefully also figure out the exact time at which it had happened. In Java 6 (which was the latest version of Java used at the time), the Java RNG would generate the initial random seed based off of the number of nanoseconds since system startup, although after 3.26 days, the value would unfortunately wrap around back to 0. The idea was that assuming Notch turned off his computer every day, if one of the seeds fell within the range of a single day while the other didn't, it could suggest that it's the actual seed Notch got when he generated the panorama. Unfortunately though, neither of the 2 candidate seeds had the number of nanoseconds in the range that would suggest one being more likely than the other.

21.2) Before the idea was fully abandoned though, we later decided to approach Dinnerbone about it on 30th July 2020 (https://discord.com/channels/720723932738486323/721776112014721096/738512883335299102), and got him to look into any Mojang files/records he could find that would help us answer this question. He was able to estimate a range of dates during which the panorama must've been created, likely after June 1st 2011 and definitely no later than June 15th 2011 (which, by the way, is earlier than what the file dates in Minecraft suggest, apparently due to Mojang's versioning / build system) and also told us that it was likely generated by Notch on his laptop while he was traveling. Unfortunately though, despite this being some interesting info about the panorama's origins, it didn't end up helping with answering the question about which seed was the true one, and so it is likely to remain a mystery forever.

MC@H since then

22) Shortly after the original panorama project concluded, we took over the currently stuck pack.png project and later finished that one as well with our new techniques and members. Since then, we've cracked many other famous seeds, including all the other panoramas Mojang released since then (except 1.17 which seems too modified). Nowadays we're no longer using BOINC though, as most things can be done in a more clever way and quickly enough to not need so much computational power anymore. We're still working on other projects and cracking any new panorama that Mojang releases. The best way to keep up with our progress is to join our Discord server (https://discord.gg/UYURDnufWt) and/or subscribe to our YouTube channel (https://www.youtube.com/@MinecraftAtHome), where we publish our finished projects.

Extra information

FAQ

Q: Why didn't you ask Mojang for the seed?

A: Mojang didn't have the world nor the seed anymore. Just like with pack.png, they just randomly generated it and forgot about it. It was as much of a mystery to them as it was to us.

Q: Why are some of the trees not in the exact same places as in the panorama? Is the seed wrong?

A: No, the issue is that not all aspects of world generation are fully determined by the seed alone. Other factors can sometimes come into play, such as the order in which chunks generate, and also there is a bug where all the large trees generate with the exact same height, which is randomly decided independently of the seed, so every time you launch Minecraft and generate the panorama world, you might get a slightly different configuration of trees or other details. Terrain should always stay the same though.

Q: Could someone have accidentally discovered the panorama at some point before / load into the same seed and not realize it?

A: Theoretically yes, practically no. Despite being generated in beta 1.7 or earlier, the panorama was only introduced in beta 1.8, at which point the world generation algorithm has already been changed, meaning that even if someone accidentally happened to generate on the same seed, the world would've been completely different in these newer versions. But even if we assume the correct version is used, the chances of randomly generating this world is 1 in 2^47, which is astronomically low (469124961 times lower than winning the lottery), so it is safe to assume nobody ever got this impossibly lucky (not even with Dream luck).

Q: Are there any other seeds that generate the panorama other than the ones found?

A: No, that's not possible. Other than math / implementation quirks leading to some seeds being the same in some aspects, it is not possible for two otherwise unrelated seeds to generate the same world.

Q: Can the panorama generate in different versions, perhaps on a different seed?

A: No, that is not possible either. Different versions use different world generation algorithms and their seeds cannot generate seeds from other versions on any seed. The panorama can only be correctly generated between mid/late alpha and beta 1.7.3 on Java edition.

Q: Is there any text that can generate the panorama seed?

A: No. Text seeds only ever produce seeds smaller than 2^32. Seeds larger than that either have to be randomly generated by the game, or directly entered into the game as a number.

Quick timeline of events related to the panorama and its introduction into the game

31st May 2011: Last MC Beta 1.6 version released (Beta 1.6.6).
1st-15th June 2021: The period of time during which Notch must've generated the panorama, according to Dinnerbone.
21st June 2011 9:43:54 AM: Date of creation (aka "date-modified") of the panorama files getting included in the game. This means b1.8 was already starting development before b1.7 was even released.
30th June 2011: First Beta 1.7 version released.
8th July 2011: Beta 1.7.3 released, which was the last release BEFORE the panorama was included, and also the last release in which the panorama world can generate, funnily enough.
26th August 2011: The panorama is for the first time seen by the public (as far as I know) at PAX Prime where Notch was showcasing the upcoming beta 1.8 / Adventure update. (https://www.youtube.com/watch?v=XKmesnFpRJE)
9th September 2011: First publicly available version with panorama was released - Beta 1.8 Pre-Release 1 (pre-reupload).
6th October 2021 13:31:14: The panorama (specifically the "panorama0.png" file only) got manually edited by someone at Mojang to remove the pink line in the water. (Mojang timezone, time known from "date-modified", might not reflect when it was actually edited, only when added to the build / source control)
6th October 2021: Beta 1.9 pre-release 3 was released containing the edited panorama file for the first time, which is how it stayed for the rest of its lifetime..
4th June 2018: A new panorama was introduced for the Update Aquatic in 1.13 pre-release 1, finally replacing the original panorama after 7 years.
14th June 2020 3:27:36am UTC: The panorama seedcracking project was first proposed and started to get researched.
18th July 2020 5:45am UTC: The seed has been found by Minecraft@Home.

The mentioned pink line

When the panorama was first introduced, there was a rendering error visible, a pink line to be seen running across the water, which was manually edited out shortly after in a later version. They used Paint.NET (v3.5.8) to stretch the row of pixels above the glitchy pink line downwards one pixel (duplicating it) to cover the glitch up with water pixels. This suggests that they probably didn't even have the world/seed saved anymore to re-screenshot it again (or they could've been just lazy, who knows :D).

The reason this pink line (and other artifacts around some block edges) appeared in these versions is because when the game samples from the "terrain.png" texture while rendering block pixels near the edges, it occasionally rounds towards the neighbouring tile and draws pixels from it instead of the block it's supposed to draw. It just so happens that there are empty pink squares in "terrain.png" next to the water texture, so that's why the water can have pink lines appear in it sometimes. This bug was fixed in later versions of the game.

Original album where I explained this: https://imgur.com/a/DDrH3dA

Comparison between the original and the fixed version:

Final info

THE SEED(S)

2151901553968352745 or 8091867987493326313

(both are the same seed internally)

Coordinates

X = 61.4880…

Y = 75 (eye pos = 76.62…)

Z = -68.7357…

Version:

Java Edition - Beta 1.7.3 (or earlier)

This documentation was written by Tomlacko during 18th-23rd May 2023.

Contents

The full chronological documentation of the project

Beginning & initial research