Part one Part Two Part Three Part Four Part Five Part Six I used different block types per biome, and a small scale on the biome generator so that you can see how smooth the edges between biomes are. Note in the last picture, the mycelium biome is supposed to be entirely flat, but instead of a sharp line, the edge gradually transitions into the surrounding biomes. The code for the above example, in the new github repository. There is a lot to cover in this tutorial, so instead of walking you through the code, I'll just show you the interesting parts, and explain how it works, along with some code snippets. How to read the suggested biomes, and set your own: Bukkit provides every chunk generator with a BiomeGrid object. It allows you to read the suggested biome of a region, and also set it. If you set a biome using this object, future calls to block.getBiome() and world.getBiomeAt() will return your biome, and this is the biome that is sent to the client. Code:java //get a biome (note that x and z are in chunk co-ordinates)biomeGrid.getBiome(x,z);//set a biome (note that x and z are in chunk co-ordinates)biomeGrid.setBiome(x, z, Biome.SWAMPLAND); Of course, the question in your mind must be, "Well, that's cool, but how do I handle transitions?" Transitions using combinations of biomes: The main reason this tutorial is over a year late is because I honestly had no idea how to handle transitions. I tried looking through the minecraft source code, tutorials and everything, and I couldn't figure out how to handle them. Perhaps I just didn't look hard enough, but I will share with you the only method I can think of to handle transitions. Hopefully, in the comments below, you can propose other ways of handling biome transitions, and also improvements to this method. In order to handle the biome transitions, we generate the biomes ourselves (so that we can quickly get the surrounding biome data). We generate a map of temperature and precipitation values using a noise function (perlin noise in this example), and then look them up in a Whittaker diagram to see how similar the conditions of our block are to the biomes we've defined. This, by the way, is a Whittaker diagram: We can then use the similarity to the most similar biomes to control how much those biome's noise features influence the features of the current block. For example, a block that has a temperature of 20 degrees (using the diagram above) and rainfall of 120cm would be mostly temperate deciduous forest, but also part temperate grassland and part tropical seasonal forest. By treating the biome of a location as a combination of nearby biomes, we can smoothly transition from one to the other. In the code, I have taken some liberties in how I defined the whittaker diagram (defined in Biomes.java), just to make it easier to write. I pretty much guessed the values, but it still serves as a useful example. Transitions using transition biomes: There is another aspect to smooth transitions, noticeably used by the default generator. By using smaller transition biomes, such as island shores and frozen rivers, you can help smooth the transition further. You could, if you desired, only use transition biomes, and then smooth out the edges of the biome with a smoothing function, but I personally think that using a combination of transition biomes and combinations of biomes creates a better look, and is cleaner in code. What's with the bands of biomes, and large artefacts in the example? The "bands" of biomes are caused because we are using a perlin noise generator to generate the temperature and rainfall maps. Perlin noise is not the best choise, and in part 7.5, I plan to show you a more biome-like alternitave, voronoi noise. Here is a map of the biomes generated with Voronoi, then simplex, then perlin noise, followed by a map of the default generator's biomes (thanks mncat77 and Courier for the images): If you look closely in the last one, you can see that it does in fact use fractal voronoi noise. The other artefacts are caused by how close together the biomes in the example are. What does generateExtBlockSections have to do with anything? I included that in the example because of the name of this series; Always up-to-date. In order to place newer blocks (with a block id higher than 127, such as a beacon) you need to use this method instead of generateBlockSections. In Java, bytes can hold values between -128 and 127, but shorts can hold -32,768 to 32,767! The generateExtBlockSections method is called the same way as generateBlockSections, the only difference is it stores shorts instead of bytes. Performance issues: Generating biomes like this triples the number of noise values you have to take. If you are using a lot of 3d noise, that can cause you to have to take up to 16*16*256*3 3d noise values per chunk! To solve this, we can interpolate (guess) the noise values for some of the blocks, without many noticeable differences. That is the subject of one of the next tutorials (Hint hint, I'd love some help). Where do I go from here? The parts I didn't cover include fine-tuning the whittaker diagram, and implementing all of the possible biomes (including oceans). I hope I can eventually cover those, but first I need to implement them! If you end up doing that, I beg of you to post your findings below. If there is another topic you want covered, a bug fix, or a suggestion to one of the existing tutorials, pm me or post below. If you would love to suggest improvements to any of the methods I discuss, I urge you to tell me! I would always love some help! Please don't be afraid to ask me anything either. No question is too small! Reserved. I would like to thank Icyene (for the state machine idea, and other help), mncat77 (for the pics, helping me think through my method above, many ideas, his voronoi noise tutorial, and his work deobfuscating the minecraft biomes for the next tutorial), and Courier for their many contributions. EDIT by Moderator: merged posts, please use the edit button instead of double posting.