1.17 Implementation details for vertical chunks and release timeframe

[StoneLabs]

First of all, I absolutely love this! Great job, honestly.

Are there currently any plans regarding 1.17 compatibility?

If so, how long after the release of 1.17 would you estimate this mod will be updated to be compatible?

~ Stone

[28Pollux28]

From now there are no plans for a 1.17 update of this mod, as the generation will be changed by a lot and biomes will now be on a 3D grid, when an image is only 2D. So I don't know how I could handle this extra dimension, perhaps just handling the surface biomes and leaving the rest vanilla generated.

[StoneLabs]

Possibly yes. I see the problem.

• Perhaps making an exception list of biomes that will not be overwritten would be a possible solution. This list could for example include lush cave biomes. However, this could produce some weird effects I'm not thinking about.

• Alternatively, it might be possible to allow the user to add "overlay pictures" these could contain information on overwriting chunks. For example, the R-value could be used to represent the type of overlay (e.g. lush caves). The G and B values could then be used to specify the lower and upper limit of that overwrite. Here is an example to illustrate.

  Pixel (45, 33) of overlay1.png could be (1, 20, 60). This could mean LushCave from Y=20 to Y=60. on X=45, Z=33

  Allowing the user to input as many overlayX.png's as he wants would solve the problem. Of course, we would run into limits due to the fact that we only have 255-bit color depth on normal pictures. But this could be solved using TIFFs which have 16bit color depth.

• Or we could use some multi-layer image format like gifs for example. Height chunks go from -4 to 19 (I think). This would make 24 layers which is not too bad. (Then again this would not allow biomes to change within a vertical chunk which might be annoying).

• Or appending to the above idea we could simply create a gif/multi-layer image file with 3XX layers representing Y-Coordinates which would give more control compared to the idea above for giving up user-friendliness.

I would love to hear your thoughts on this.

If you don't plan on continuing your work I'd start working on my own version of this mod (crediting you for your work ofc!)

~ Stone

[28Pollux28]

I like the idea of overlay pictures and the Gif one. It really could be interesting and pretty easy to use. I don't plan at the moment to update the mod since 1.17 is susceptible to be changed quite a lot and I don't have the time to check if the changes would break something and I have a lot of things to do for the 1.16 version too. So I'll be waiting for pre-releases or release of 1.17 to really dig into it and make it work.

[StoneLabs]

I think the overlay picture idea is the best solution. Realistically you would only ever need two overlay files (if you're not doing something crazy that is). The gif idea is cool but I am worried the file sizes for bigger maps might be a little extreme...

Looking forward to your implementation.

[28Pollux28]

Was thinking the same. Your idea of using RR for biomes and GGBB for coordinates is nice. The only problem I can think about is the negative heights. Maybe we could play on the transparency to get one more parameter to play with and handle this. Concerning timeframe, as I said, not before 1.17 release and may be later because my studies are quite time consuming and I only get to develop on Saturdays evening. But I can assure you I don't plan on dropping the mod 🙂

[StoneLabs]

Regarding negative Y coordinates: We could use .tiff files. They are basically RGB (no alpha) images with 16 bits per channel. Height y=-64 could then be channel value 0, giving us a max possible height for G/B values of 2^16 = 65,536. Or perhaps just interpreting them as signed integers giving us 2^15 values from -32k to +32k. I'd imagine there must be some editor out there that has a 16-bit color picker (though I can't find one right now).

[28Pollux28]

From now there are no plans for a 1.17 update of this mod, as the generation will be changed by a lot and biomes will now be on a 3D grid, when an image is only 2D. So I don't know how I could handle this extra dimension, perhaps just handling the surface biomes and leaving the rest vanilla generated.

Pixel (45, 33) of overlay1.png could be (1, 20, 60). This could mean LushCave from Y=20 to Y=60. on X=45, Z=33

This sounds like overlay images will be super painful to draw because using a small color palette (comparable to the one for biomes) will likely result boring caves at least when it comes to the height levels. Moreover you will have to type in all of those colors codes manually all the time because that would be too many to store somewhere. Therefore it's important to allow for only specifying one image that will be used for surface chunks while everything else will be filled with vanilla biomes.

Yeah will definitely need an config option on that to allow for vanilla underground biomes. But this is not my top priority at the moment, still need to improve lot of things before starting to think about 1.17

[StoneLabs]

Pixel (45, 33) of overlay1.png could be (1, 20, 60). This could mean LushCave from Y=20 to Y=60. on X=45, Z=33

This sounds like overlay images will be super painful to draw because using a small color palette (comparable to the one for biomes) will likely result boring caves at least when it comes to the height levels. Moreover you will have to type in all of those colors codes manually all the time because that would be too many to store somewhere. Therefore it's important to allow for only specifying one image that will be used for surface chunks while everything else will be filled with vanilla biomes.

We also have to keep in mind that not all vertically different biomes are underground. If I'm not mistaken the tips of the new mountain ranges will have their own biomes. Additionally, what is the "default" biom of a chunk? Is there still such a thing? Or would we define the default biom as the biom at water height? It's definitely not trivial.

Adding a config option to specify which chunks will persist would be a good solution. These could contain the underground biomes by default e.g. lush cave biom. The overlay images could of course still be used if desired.

[28Pollux28]

I'm currently writing code to implement #10 and #4 so default biome could still be used, but people will also be able to use these two settings

[28Pollux28]

it will be painfull

that's for sure...

[StoneLabs]

I'm currently writing code to implement #10 and #4 so default biome could still be used, but people will also be able to use these two settings

If #10 is implemented and we have a good method of generating vanilla terrain it shouldn't be too difficult to implement an exception list of biomes that will persist (as I described here). Calculate the default biom as well and if it is in the exception list use it instead. I'll go ahead and open a issue for it.

[28Pollux28]

II've thought this through. I have a couple things to do before but I think I'll try implementing 3D biomes on a different dimension for now, perhaps in the nether. Will see how it goes.