1.16 snapshots: add ability to see the nether

[burgerindividual]

20w06a came out just a few days ago, and there are already issues about whether support for it will be coming to amidst (#691). While 20w06a does run on the latest version of amidst, none of the changes/features that came with it is are visible.

The first and most obvious changes are to the nether. Three new biomes were added in the update:

• Warped Forest
• Crimson Forest
• Soul Sand Valley

This gives us a total of 4 different biomes in the nether, which isn't much to work with. However, it is a big step up from the single biome we had previously

One of the main problems with having a nether dimension is the inability to see lava lakes. IIRC, the only way to find where lava lakes are is is to see the height of the terrain. The only way we could do this is by creating something similar to the influence algorithm used in the End.

Another thing that you may have missed in the patch notes of 20w06a is this:

• Shipwrecks and ocean ruins are now less common.

~This probably won't take too much work. It's probably just a small change in the algorithm that was used.~ Fixed in pull request #693.

If there's something else I missed let me know. Any ideas on nether implementation?

[burgerindividual]

Just made a pull request (#693) to fix the second issue.

[burgerindividual]

I've made a very rough early version of getting nether biomes in alt-1.16-snapshots, which currently replaces the overworld. This is built off of my modifications to LocalMinecraftInterface, but I can adapt it to the current version. We need to add another layer to split the two eventually, but for now if you want to enable the nether you have to go to the BiomeDataOracle declaration in WorldBuilder and change it to new BiomeDataOracle(minecraftInterface, true).

Issues:

• Really slow. Much slower than overworld generation, and that's already slow. I need to profile it to see if there's a bottleneck somewhere.
• Coordinates may be off and there's no way to switch between nether and overworld scale (somewhat easy fix)
• Nether Fortresses should only generate in the nether (easy fix)
• No way to switch between Nether and Overworld through amidst (should be a relatively simple fix)

I haven't had time to compare between actual minecraft and what's being generated, so it could be horribly off for all I know. If you want to make some modifications to it, send a pull request on the fork. I haven't made a pull request for it to here because I want to adapt it to the current LocalMinecraftInterface first.

[moulins]

Supporting the new Nether biomes in Amidst is definitely something we want to do, but I don't think we should rush to land an implementation yet. This is a big change, and the Minecraft code will certainly evolve between now and the final version of the Nether biomes, so I don't want to commit to an implementation which may break in the future.

---

Regarding the issues you've raised:

Lava lakes

The only way to get the necessary information seems to use the Nether's ChunkGenerator and look whether the block at "sea level" height is solid or not. However, there are two issues :

• First, the ChunkGenerator interface doesn't allow to query a single block; you have to generate the whole column. This will probably have abysmal performance.
• Even if we could query a single block, this won't detect overhangs, which are very common in the Nether.

Maybe there is a faster way of obtaining the needed information, but this seems very difficult.

(The End's "influence algorithm" used by Amidst is actually an adaptation of Minecraft's own biome generator, which isn't used because it is very slow (because of all the overhead in the Minecraft code) and gives very blocky results (a single biome per chunk))

Performance

I've quickly (and very messily) implemented your changes on the current MinecraftInterface code (mainly by replacing the code in createBiomeProvider), and I get comparable performance as for the Overworld, maybe a tiny bit faster. By looking at your code, I would say that your performance drop comes from the fact that you aren't using the overworld's "chunked loop" when populating the biome array.

Amidst changes

I think the best way would be to add a Nether submenu in Layer, like what is currently done for the End; then, the Nether Fortress toggle could be moved here. However, being able to see Nether structures on the Overworld map (and vice-versa) is useful, so we should add "View Nether structures in Overworld" and "View Overworld structures in Nether" settings to restore the current fonctionality.

Other

A point you didn't raise is the fact that the Nether biomes are height-dependent. This is probably not an issue, because we can just pick a fixed height for generating biome data and be done with it, but I think we should keep an eye on that, in case Mojang introduces large biome variations along the height of the world.

[burgerindividual]

I understand all of the things you said except for two:

By looking at your code, I would say that your performance drop comes from the fact that you aren't using the overworld's "chunked loop" when populating the biome array.

Unless I screwed up completely, my function in the latest commit has it's own normal loop, and on my machine it is much slower than the current overworld. The fragments seem to generate at a consistent timing, however, rather than the fluctuating loading in the overworld. Maybe your LocalMinecraftInterface adaptation is faster in that case, but I doubt it as it was almost exactly the same in overworld performance as mine.

EDIT: I misread the aren’t for are in your statement. Ignore everything I said above. When I did use the chunked loop, it gave me basically the same performance, which is due to the fact that the Nether biome generator doesn’t use LazyArea at all. This is why I removed it in the first place. I’ll have to profile it to see what’s wrong with my version.

A point you didn't raise is the fact that the Nether biomes are height-dependent. This is probably not an issue, because we can just pick a fixed height for generating biome data and be done with it, but I think we should keep an eye on that, in case Mojang introduces large biome variations along the height of the world.

I mean, you're probably right because my testing wasn't very extensive, but I tested between y=0 and y=30 on the same seed, and their nether biomes were exactly the same. For those cases that there are multiple biomes in a column, we could probably take the most prominent biome in that column, or kind of merge the colors to make a sort of blend effect.

Also in terms of the lava lakes, all we need is the certain Y level for that, which sounds like it could be done with the HeightMap in the game already. I think it’s connected to the chunk generator though, so it’s probably not a good idea. I’ll look into it though.

[douira]

just FYI, they recently added another Biome in the 20w15a snapshot: https://minecraft.gamepedia.com/Java_Edition_20w15a "Basalt Deltas"

[GoodGuyJohn]

A point you didn't raise is the fact that the Nether biomes are height-dependent. This is probably not an issue, because we can just pick a fixed height for generating biome data and be done with it, but I think we should keep an eye on that, in case Mojang introduces large biome variations along the height of the world.

This could also be fixed, or rather, be adapted into the tool, by adding a setting for that, just like we have for biomes, so that way the user actually knows which level is being mapped, and they can change it easily. Also, the option of making a blend for the biome prevalence per chunk or region is not an option, at least not a practical one, as we currently only have 5 different biomes, that's 'only' 360 different combinations, so adding different colors for different biome intersections would not be a good choice.

Another option for viewing the different intersecting biomes is osing the "find" feature already present. So, when you highlight a specific biome, say, the Basalt Deltas, it every chunk it appears on is highlighted, and when unselected, either a) it is only shown when on the selected "scan" layer; or b) it is only shown when it is the most prevalent biome in the chunk;

I don't really like having a fixed layer to build the map from, I think that will likely be very harsh to new users, and will definitely cause some problems. But having different layers for different dimensions is a very good idea, as I, the first time I used it, found it weird having the nether in the same map as the overworld. But adding functionality of nether-overworld indicators could also do the trick.

Note that I am using the word chunk as to describe a single "pixel" on the map, not a in-game chunk.

Overall, this 3D biome thing will definitely be very hard to properly implement in a 2D environment, and a 3D environment will almost surely be very resource heavy and complicated to use and understand, effectively defeating the purpose of the tool.

This could, however be the start of 3D biomes in the overworld, so developing this feature would come a long way to future-proofing the code.

[burgerindividual]

Also, the option of making a blend for the biome prevalence per chunk or region is not an option, at least not a practical one, as we currently only have 5 different biomes, that's 'only' 360 different combinations, so adding different colors for different biome intersections would not be a good choice.

What we would probably do in this case is actually have an automated color blending process. An algorithm similar to what this website does could work out pretty well. This means that we don't necessarily have to "add" new colors, but they can instead be procedurally generated.

Another option for viewing the different intersecting biomes is osing the "find" feature already present. So, when you highlight a specific biome, say, the Basalt Deltas, it every chunk it appears on is highlighted, and when unselected, either a) it is only shown when on the selected "scan" layer; or b) it is only shown when it is the most prevalent biome in the chunk;

We probably would just highlight the pixel if it has even the slightest amount of that biome in it. It would be both faster and easier to implement.

---

I have a feeling it would make more sense to have some sort of slider to generate a certain amount of heights of the nether. I was thinking we could scan evenly spread out Y levels for a given pixel based on what value the slider is. For example, if you had it set to 1, it would only generate y=63. If you had it set to 2 it would generate y=31 and 95. If you had it set to 3 would generate y=0, 127, and 63. A sort of averaging pattern like this could keep the production of biomes running fast and somewhat accurate.

[moulins]

Actually, I've done some tests, and horizontal biome variation when changing Y levels is only a couple blocks. So I think it's not necessary to expose a "height" setting or anything like that, we can just pick a reasonable height (for example Y=64) to calculate biome data.

[machinesmith42]

While we are on the topic displaying the bastion remnants would be nice in this ver

[machinesmith42]

Any hope for this?

[burgerindividual]

Currently, I've been working on other parts of amidst, and to start working on 1.16 features before those get finished/merged would mean I would have a lot of work to do making those changes comply with everything else I've been working on too. Once all of my PRs get accepted and I finish working on fixing the structure code, then I'll probably start working on it.

[troywweber7]

1.17 is most likely going to have 3D biomes in it because of the overhaul on caves and water levels!

[machinesmith42]

any news on nether generation