If you are here looking for into on how to change the PNG, this is probably all you're interested in:
Enjoy. If you want more technical stuff, read on.
I've been trying to figure out how biomes work on a technical level but there's not a whole lot of information out there. Principally, I'm interesting in a map renderer that will render foliage and grass faithfully, the way they are in-game. But from what I've gathered, this won't be too easy of a task until we have a solid grip on exactly what biomes are.
From what I've gathered so far, the biomes are defined by two double values. My best guess at the intent behind these is "moisture" and "temperature". They're scaled from 0 to 1. The color of grass and foliage is calculated based on these two values. The way this is done is fairly simple.
The range of colors for biomes are located in the minecraft jar in the misc folder. grasscolor.png and foliagecolor.png These are 256x256 pngs containing the range of colors in a triangle:
Note it's very similar to this triangle:
That image gets read in and stuffed into an array. It's accessed by a function that takes two doubles and returns a single pixel color value. (The grass version is in "of", foliage version is in "kb". They are identical.)
That code neatly maps moisture and temperature scaled 0-1 into a right triangle on the bottom left of a 256x256 image.
Now, how that color value factors in to the final texture rendering, I haven't tracked down exactly yet.
Biomes also have specific behaviors for terrain generation. There are 12 different biomes. 11 are determined from temperature and moisture, the 12th is exclusive to The Nether. Which biome belongs to which area is chosen by the moisture and temperature (from "fy.class"):
Each of those biome types in all caps is an object. Some of the biome types share objects with different parametars, others use entirely different objects. Decoding all of that would be quite an undertaking. Decompile "fy.class" and take a look if you want to help there.
Lastly, the burning question: how are the moisture and temperature calculated and stored? The answer is, I have no idea! Notch can generate maps with all biomes listed and temperatures/moistures listed out, so it can't be too crazy. I do know, thanks to Zahl of mcmap that this information is NOT stored in the savegame info, so it must be generated elsewhere each time the game is run.
Anyone who can pitch in and help me document this, it would be greatly appreciated. Once we have some stable, usable information, we could migrate it to the wiki.
This seems simple enough to mod. If I knew more about Java, I'd do it myself. You could do autumn biomes, better looking tropical biomes, and even crazy biomes, with purple grass and red leaves!
I can't wait to see what/if anything comes out of this great find. :biggrin.gif:
Well, if generating seed-compatible random numbers like Java were the only problem, that's not too tough. The source of java.util.Random is available online. It's relatively short and would likely take only a few minutes to port to C++ and get perfect Java-like random functionality.
I did this in SMP, after editing the grass and foliage pngs. It turned out nice IMO, except for the side-grass texture always being green...
Here are the grass and foliage pngs if anyone wants to try them out and use them. I edited based on the temperature range and what I thought would make sense. The blotch of color was just made by using Paint.NET's magic wand, and then adjusting hue and saturation.
I found the function that generates the two double biome parameters. It's in mu.java in 1.2.0_01.
It's a good 6+ obfuscated classes deep, so it's going to take me a very long time to drag out exactly what it's doing. But I can tell you that the first function to be called takes three integers (x,y,z coords of a given block, I've confirmed) and after 6 nested class method calls, returns two doubles, moisture and temperature.
The doubles are then taken and compared against known biome definitions and used to generate a coordinate in grasscolor.png/foliagecolor.png which is then taken and used to filter the color of the texture.
I would suspect that notch is merely apply the color to the texture by calling a glColor function ( there are many ), before the block gets rendered. Or he has written the blending from scratch. :wink.gif:
Those code snippets you posted, did you clean up the naming yourself? When I decompile the java class files the variable names and methods are just letters and numbers with no real connection. :sad.gif:
Yeah, I cleaned up the variable and function names myself for clarity. What good is an informational post where I just post obfuscated code!
I've been looking into this some more and I can say with some certainty that NO ONE is going to want to port this from Java to C++. Our best bet is to reverse it enough and write a java class that links to all these, sets them up the right way and pulls color coords based on block coords and the level's random seed. That is definitely feasible. I'm starting that now.
My only concern is that the input to the function is two ints. In java that means a range of -2,147,483,648 to 2,147,483,647
That can't be the maximum world size, right? Am I missing where you enter in an offset or something?
Is this maybe the biome values of a CHUNK, not each block? Any help from someone more familiar with the way minecraft stores block positions?
Edit 1: Ok, I'm just being ridiculous. I was reading those boundaries as 2 million, but they're 2 BILLION. Yes. Those are blocks. That should cover the maximum allowed minecraft world size no problem! So I'm set.
Edit: Here's a visualization of the biome color assigned to foliage as seen from the air. It's from block -2000,-2000 to 2000 2000.
Wait? So if I edit this file in gimp by changing its colors, it gets colored different automatically? No weird placing of special files?
If you want, you can open up the jar, edit the grasscolor.png and foliagecolor.png file, delete the two META-INF/MOJANG* files, then yes. If you made them both all white, it would no longer alter the color of your textures at all for biomes.
Wow DK, nice job! I really hate this obfuscated java code, but I think I just have to take a look at this stuff just because I'm curious. :-)
So as the biome map is static, it would actually be sufficient if you make a java tool that creates a color map for grass and leaves once for your world and then feed it to mcmap or whatever map generator you're using on every run. It's not that elegant, but still the best solution for now, and could be rather fast afterwards.
Btw. BiomeGenerator.a(0,0,1,1) <- what's the third and fourth parameter?
Edit: Hah, just saw you had the same idea in the mcmap thread. :-)
I don't know! The values were hard-coded right in the source files for grass and leaf blocks. On my massive stack of paper notes tracing all the values and their types though the code, they're circled and labelled "Normalization constants??".
If you want, you can open up the jar, edit the grasscolor.png and foliagecolor.png file, delete the two META-INF/MOJANG* files, then yes. If you made them both all white, it would no longer alter the color of your textures at all for biomes.
Don't need to delete the META-INF stuff if you are just replacing the art files. Also if you make the *color.png files solid white, don't forget to change terrain.png to have green grass and leaves again. (Currently they are grey which is why the breaking leaf particles and he raw leaf blocks are grey.)
I don't suppose you have any information on exactly what function is being used when doing the color blend? I've just been working on the assumption that it's similar to the multiply blend option on layers in GIMP but it would be nice to know for certain.
Rollback Post to RevisionRollBack
Tis far better to be a witty fool than a foolish wit.
Good to know that you don't need to delete the signatures just to change the pngs.
I think I found the function that does the blending but I'm not sure. I'm pretty certain it's a simple multiply though, since that produces output that looks really similar to what's in-game.
It looks so good in the carto, unbelievable strides in minecraft are being made.
Rollback Post to RevisionRollBack
Click the above link to visit my live stream channel! Remember: I am human, and I am not always on. If you would like to suggest a game for me to play or to do on my stream, please send me an email at [email protected]
Enjoy. If you want more technical stuff, read on.
I've been trying to figure out how biomes work on a technical level but there's not a whole lot of information out there. Principally, I'm interesting in a map renderer that will render foliage and grass faithfully, the way they are in-game. But from what I've gathered, this won't be too easy of a task until we have a solid grip on exactly what biomes are.
From what I've gathered so far, the biomes are defined by two double values. My best guess at the intent behind these is "moisture" and "temperature". They're scaled from 0 to 1. The color of grass and foliage is calculated based on these two values. The way this is done is fairly simple.
The range of colors for biomes are located in the minecraft jar in the misc folder. grasscolor.png and foliagecolor.png These are 256x256 pngs containing the range of colors in a triangle:
Note it's very similar to this triangle:
That image gets read in and stuffed into an array. It's accessed by a function that takes two doubles and returns a single pixel color value. (The grass version is in "of", foliage version is in "kb". They are identical.)
That code neatly maps moisture and temperature scaled 0-1 into a right triangle on the bottom left of a 256x256 image.
Now, how that color value factors in to the final texture rendering, I haven't tracked down exactly yet.
Biomes also have specific behaviors for terrain generation. There are 12 different biomes. 11 are determined from temperature and moisture, the 12th is exclusive to The Nether. Which biome belongs to which area is chosen by the moisture and temperature (from "fy.class"):
Each of those biome types in all caps is an object. Some of the biome types share objects with different parametars, others use entirely different objects. Decoding all of that would be quite an undertaking. Decompile "fy.class" and take a look if you want to help there.
Lastly, the burning question: how are the moisture and temperature calculated and stored? The answer is, I have no idea! Notch can generate maps with all biomes listed and temperatures/moistures listed out, so it can't be too crazy. I do know, thanks to Zahl of mcmap that this information is NOT stored in the savegame info, so it must be generated elsewhere each time the game is run.
Anyone who can pitch in and help me document this, it would be greatly appreciated. Once we have some stable, usable information, we could migrate it to the wiki.
I can't wait to see what/if anything comes out of this great find. :biggrin.gif:
http://www.java2s.com/Open-Source/Java- ... m.java.htm
I did this in SMP, after editing the grass and foliage pngs. It turned out nice IMO, except for the side-grass texture always being green...
Here are the grass and foliage pngs if anyone wants to try them out and use them. I edited based on the temperature range and what I thought would make sense. The blotch of color was just made by using Paint.NET's magic wand, and then adjusting hue and saturation.
Foliage:
Grass:
It's a good 6+ obfuscated classes deep, so it's going to take me a very long time to drag out exactly what it's doing. But I can tell you that the first function to be called takes three integers (x,y,z coords of a given block, I've confirmed) and after 6 nested class method calls, returns two doubles, moisture and temperature.
The doubles are then taken and compared against known biome definitions and used to generate a coordinate in grasscolor.png/foliagecolor.png which is then taken and used to filter the color of the texture.
Those code snippets you posted, did you clean up the naming yourself? When I decompile the java class files the variable names and methods are just letters and numbers with no real connection. :sad.gif:
I've been looking into this some more and I can say with some certainty that NO ONE is going to want to port this from Java to C++. Our best bet is to reverse it enough and write a java class that links to all these, sets them up the right way and pulls color coords based on block coords and the level's random seed. That is definitely feasible. I'm starting that now.
Oh hey guys, what's this?!
Source Code:
So unless I am mistaken and missing a step, and I don't think I am, that should about wrap things up :smile.gif:
That can't be the maximum world size, right? Am I missing where you enter in an offset or something?
Is this maybe the biome values of a CHUNK, not each block? Any help from someone more familiar with the way minecraft stores block positions?
Edit 1: Ok, I'm just being ridiculous. I was reading those boundaries as 2 million, but they're 2 BILLION. Yes. Those are blocks. That should cover the maximum allowed minecraft world size no problem! So I'm set.
Edit: Here's a visualization of the biome color assigned to foliage as seen from the air. It's from block -2000,-2000 to 2000 2000.
If you want, you can open up the jar, edit the grasscolor.png and foliagecolor.png file, delete the two META-INF/MOJANG* files, then yes. If you made them both all white, it would no longer alter the color of your textures at all for biomes.
I don't know! The values were hard-coded right in the source files for grass and leaf blocks. On my massive stack of paper notes tracing all the values and their types though the code, they're circled and labelled "Normalization constants??".
Don't need to delete the META-INF stuff if you are just replacing the art files. Also if you make the *color.png files solid white, don't forget to change terrain.png to have green grass and leaves again. (Currently they are grey which is why the breaking leaf particles and he raw leaf blocks are grey.)
I don't suppose you have any information on exactly what function is being used when doing the color blend? I've just been working on the assumption that it's similar to the multiply blend option on layers in GIMP but it would be nice to know for certain.
I think I found the function that does the blending but I'm not sure. I'm pretty certain it's a simple multiply though, since that produces output that looks really similar to what's in-game.
Removed my non-relivant post
Line 88: Return Dessert.
...
...
I assume you meant desert. Otherwise, minecraft could be exploited to get some yummy dessert!
...
...
All right, that wasn't funny.
This was interesting, however.
The only problem left is the grass on the side.
I'm sure Notch will fix this soon.
EDIT: whats difference with grasscolor.png and foliagecolor.png? (whats foliage even mean lol)
As a result of the research in this thread, mcmap now supports the mapping of biomes with proper colors.
Or with custom grass/foliagecolors.png files, like this example with the separate biomes in solid colors from the OP.
mcmap: viewtopic.php?f=25&t=40327
Click the above link to visit my live stream channel! Remember: I am human, and I am not always on. If you would like to suggest a game for me to play or to do on my stream, please send me an email at [email protected]