I recall reading something about the biome temperature algorithm. I can't find the source, sorry.
Basically how it works is every biome gets its own temperature, and the temperature decreases by so much every block. Thing is, the hotter the biome, the less the temperature changes each block. Ergo, warmer biomes see very little color/temperature change in elevation. They also usually don't have snowcaps on mountains.
Wow, there is some serious overhauling that I'm gonna have to do with my shiz to get things updated for 1.7.
Glad you folks are experimenting the new stuff for us who are a bit wary of dealing with the snapshots.
I echo those words and sympathize.
Having just found this thread (with thanks to Alvoria), I'm realizing 1.7 is a lot more than just a greater variety of plants. Thanks guys for doin' the experimentation thing...and the hard work! Height, temperature, so many new biomes...what the flip!?
It's fascinating to watch you lot discover things, but I think I need a rest already!
I mentioned this briefly on my texture pack's thread but I should probably mention it here. I've come up with a design for a new, efficient and highly customizable biome palette which I've proposed to Kahr for implementation into MCPatcher. This will be a custom format for MCPatcher which will override Mojang's method, but allow you to still use both methods safely in your pack. If all goes well, I'll be posting an updated template for Mojang's version along with the MCPatcher specific version over here. As a head's up to anyone interested in the mechanics of it, what I proposed works as such:
-The new format should use the same 256x256 png file format with a customizable exception to vertical height.
-The X row of pixels should be for biome ID values (See here.)
-The Y column of pixels should be for relative height. (hence customizable pixel Y resolution.)
Since height can vary from map to map this will not be an absolute pixel-perfect value outside of the default 256-block tall maps. Should the map's height limit change, the palette should be completely adaptable to it, and should you want no height variance, your palette file may need to be a mere 1 pixel tall and 256 pixels wide.
-MCPatcher may have an option to include randomly-generated variance which slides up and down the Y by a specified factor.
A factor of 1 will look at 1 pixel above and below the current pixel designated for that height (3 pixel range), a factor of 2 will have a 5 pixel range, a factor of 3 will have a 7 pixel range and so on. This will be completely adjustable by the end-user only.
-The file should not use the exact same naming format but will be read with priority over Mojang's format, allowing you to mix and match if you need to, as well as provide backwards compatibility. -The new palettes should be compatible replacements for both official Mojang biome palettes (grasscolor, foliagecolor) and custom MCPatcher-only palettes both created by texture pack artists and things like the sky biome coloring component of Custom Colors.
This is just in the experimental stage and may be scheduled for test implementation once the main, existing features of MCPatcher are once again fully operational. Note that all of this information is subject to change and realize that I'm posting this mainly for educational and feedback purposes.
This system is a bit more complex than Mojang's on paper, but allows for much finer control of every single aspect of biome-based block coloring and will logically make more sense on the artist's end to set up than on Mojang's current format. Basically all of the work will go into choosing your color gradients for each biome without having to worry about merging the height value all to a single point.
I think the colormap needs more looking into, as from my testing, the height map really don't go all the way to the 'colder' colors, but stops after a little ways. It still follows a line of some sort that moves to the colder corner, but it don't use the full length.
For example:
I had made that to test the range of the forest biome.
Building up to max height, it stops at the blue, that leaves a bit of the colormap that is not used.
So not only do we need the location of the base biome, but also where it's max height also is on the map for each one.
I think the colormap needs more looking into, as from my testing, the height map really don't go all the way to the 'colder' colors, but stops after a little ways. It still follows a line of some sort that moves to the colder corner, but it don't use the full length.
For example:
-snip-
I had made that to test the range of the forest biome.
-snip-
Building up to max height, it stops at the blue, that leaves a bit of the colormap that is not used.
So not only do we need the location of the base biome, but also where it's max height also is on the map for each one.
It will be a pain in the ass but I'll fiddle around, see if there's a pattern from biome to biome. Got nothing better to do right at the moment...
I mentioned this briefly on my texture pack's thread but I should probably mention it here. I've come up with a design for a new, efficient and highly customizable biome palette which I've proposed to Kahr for implementation into MCPatcher. This will be a custom format for MCPatcher which will override Mojang's method, but allow you to still use both methods safely in your pack. If all goes well, I'll be posting an updated template for Mojang's version along with the MCPatcher specific version over here. As a head's up to anyone interested in the mechanics of it, what I proposed works as such:
-The new format should use the same 256x256 png file format with a customizable exception to vertical height.
-The X row of pixels should be for biome ID values (See here.)
-The Y column of pixels should be for relative height. (hence customizable pixel Y resolution.)
Since height can vary from map to map this will not be an absolute pixel-perfect value outside of the default 256-block tall maps. Should the map's height limit change, the palette should be completely adaptable to it, and should you want no height variance, your palette file may need to be a mere 1 pixel tall and 256 pixels wide.
-MCPatcher may have an option to include randomly-generated variance which slides up and down the Y by a specified factor.
A factor of 1 will look at 1 pixel above and below the current pixel designated for that height (3 pixel range), a factor of 2 will have a 5 pixel range, a factor of 3 will have a 7 pixel range and so on. This will be completely adjustable by the end-user only.
-The file should not use the exact same naming format but will be read with priority over Mojang's format, allowing you to mix and match if you need to, as well as provide backwards compatibility. -The new palettes should be compatible replacements for both official Mojang biome palettes (grasscolor, foliagecolor) and custom MCPatcher-only palettes both created by texture pack artists and things like the sky biome coloring component of Custom Colors.
This is just in the experimental stage and may be scheduled for test implementation once the main, existing features of MCPatcher are once again fully operational. Note that all of this information is subject to change and realize that I'm posting this mainly for educational and feedback purposes.
...This system is a bit more complex than Mojang's on paper, but allows for much finer control of every single aspect of biome-based block coloring and will logically make more sense on the artist's end to set up than on Mojang's current format. Basically all of the work will go into choosing your color gradients for each biome without having to worry about merging the height value all to a single point.
Looking forward to seeing how this works, Misa.
Any chance of a diagram for my tired old brain to better take it all in, or is this at too early a stage? Although reading your last sentence seems to indicate the system will be a lot easier to grasp and manage, if I understand it correctly.
In any event I will keep an eye on your Biome Palette Template thread, with thanks for the effort you're putting in on this.
I was testing a bit new biome colormaps in the last days.
First of all McSpider's points are quite accurate! I did not know them before I made tests pictured below so the colormap should be adjusted according to McSpider's coordinates or XSSheep image. Thanks a lot!
What I wanted to check is how far does the coloring of each biome goes according to height. It appears that it is not the same and does not go to the far bottom-right corner. Taiine is right with that. And yeah, "distances" for each biome vary and often overlap.
Image below shows my test colormap for grass palette. Sorry about the colors, those just help me determine height and biome ;-) Those small dots helped me determine "starting" and "ending" points for each biome.
-snip-
Well, you beat me to the punch!
I got about halfway through checking how long the lines extended (for height) before checking here and noticing you'd already done it. Oh well, nice to know I don't have to finish it...
I was testing a bit new biome colormaps in the last days.
First of all McSpider's points are quite accurate! I did not know them before I made tests pictured below so the colormap should be adjusted according to McSpider's coordinates or XSSheep image. Thanks a lot!
What I wanted to check is how far does the coloring of each biome goes according to height. It appears that it is not the same and does not go to the far bottom-right corner. Taiine is right with that. And yeah, "distances" for each biome vary and often overlap.
Image below shows my test colormap for grass palette. Sorry about the colors, those just help me determine height and biome ;-) Those small dots helped me determine "starting" and "ending" points for each biome.
Now a few words of explanation of what I discovered... But image first:
Numbers above describe approximate height for biome at those linear markers (black and white). I didnt mark birch forest and jungle edge :/
1. Desert color does not gradient. It is determined with the very bottom-left pixel.
2. Savannah starts at "desert pixel" and follows towards bottom-right corner just as pictured above.
3. New biomes like Birch Forest, Jungle Edge, Mega Taiga has new "starting points".
4. Mega Taiga overlaps partially with Taiga palette but has different "height points".
5. Jungle Edge "ends" on the Forest pallette (that small blue dot).
6. Below sea level (62 and below) all biomes have "starting point" color.
7. "Distance" each biome goes towards coldest bottom right corner is not the same.
I tested all the way from 62 to 256 and above gradients picture approximately full height coverage. Natural land generation reaches 128 height with exception for Extreme Hills that can now generate higher (up to 156? I didn't really check that) and if you want to see nice color changes in natural land generation, you should remember about that (ussually less than first 1/4 of whole distance the pallette for each biome goes is visible in natural land generation).
I know that images above are messy, but maybe you will find them helpfull.
Time to start working on new palette with nice gradients ;-)
Amazing! Now I might actually consider working with the new biome system... before, it would have pretty much been guesswork for me. One thing though... in my early testing, I could've sworn that the colors stopped gradient-ing past Y=64, not Y=62...
I mentioned this briefly on my texture pack's thread but I should probably mention it here. I've come up with a design for a new, efficient and highly customizable biome palette which I've proposed to Kahr for implementation into MCPatcher.
-snip-
One thing I see you don't mention is how to transition between the biome edges. I'm assuming a linear interpolation with adjacent biome colors at the edges? Would it make sense to have a setting that determines the sample size for the 'blend' so we could control how smooth the transitions are? (As in determine a block's color by sampling the blocks within 1, 2 or 3 of it and blending?)
Any chance of a diagram for my tired old brain to better take it all in, or is this at too early a stage? Although reading your last sentence seems to indicate the system will be a lot easier to grasp and manage, if I understand it correctly.
In any event I will keep an eye on your Biome Palette Template thread, with thanks for the effort you're putting in on this.
It's still an early stage so this is a really rough example. Basically it's vertically-striped gradients, each stripe being a biome, ordered by their biome ID. Top of the gradient is high altitude, bottom is low altitude. And yes, it should be easier for an artist to grasp while giving them extremely fine control over it. It's like going from analog to digital. Also I've addressed more feedback regarding this proposal over here and have refined the explanation of how it'll work a bit better if you're interested.
One thing I see you don't mention is how to transition between the biome edges. I'm assuming a linear interpolation with adjacent biome colors at the edges? Would it make sense to have a setting that determines the sample size for the 'blend' so we could control how smooth the transitions are? (As in determine a block's color by sampling the blocks within 1, 2 or 3 of it and blending?)
Yes, it will use hard-coded blending as Mojang's currently does. Also this feature for tweaking the blend radius already exists as an end-user-adjustable setting in MCPatcher. (See the Blend radius option on the Options tab of any version of MCPatcher that supports CustomColors.) And see here for more discussion on the proposal.
It's still an early stage so this is a really rough example. Basically it's vertically-striped gradients, each stripe being a biome, ordered by their biome ID. Top of the gradient is high altitude, bottom is low altitude.
Wow, this is the EXACT idea I had and posted about on this very threaD:
Well, the good thing about hex color codes is that the very software we use to make color maps outputs to hex right from the color picker
Also, about a square grid, I said this on page 1:
However, I'm going to have to disagree with you on making it *horizontal*. I think it would make much more sense with the current config to make them vertical. the Y axis being height (as now), and X still being temperature, but only "symbolically" using the placement of biomes, and height would no longer be guaranteed the same coldness, but instead each biome would have its own colormap for height. Ordering would basically be the x-coordinates now, but vertical lines, maybe more evenly distributed.
I would make a simple mock-up of this, but I'm lazy
I just wish Mojang would implement something like this, and if not just go back to single-color biomes :/
Rollback Post to RevisionRollBack
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
It's still an early stage so this is a really rough example. Basically it's vertically-striped gradients, each stripe being a biome, ordered by their biome ID. Top of the gradient is high altitude, bottom is low altitude. And yes, it should be easier for an artist to grasp while giving them extremely fine control over it. It's like going from analog to digital.
That's way simpler to grasp and manage than radiating overlapping lines on the Mojang triangle. I could definitely work with that. Also The_Fool raised the other point regarding blending, which I was only vaguely wondering about at this stage and you seem to have that covered in the way we're already familiar with in MCPatcher. So I'd be very happy with that.
Also I've addressed more feedback regarding this proposal over here and have refined the explanation of how it'll work a bit better if you're interested.
Haha! I'm very interested...and I'd already bookmarked it earlier...as soon as I realized how little I knew about the new 1.7 system. Listening-in helps me grasp things better when the penny eventually drops.
It's still an early stage so this is a really rough example. Basically it's vertically-striped gradients, each stripe being a biome, ordered by their biome ID. Top of the gradient is high altitude, bottom is low altitude. And yes, it should be easier for an artist to grasp while giving them extremely fine control over it. It's like going from analog to digital. Also I've addressed more feedback regarding this proposal over here and have refined the explanation of how it'll work a bit better if you're interested.
Yes, it will use hard-coded blending as Mojang's currently does. Also this feature for tweaking the blend radius already exists as an end-user-adjustable setting in MCPatcher. (See the Blend radius option on the Options tab of any version of MCPatcher that supports CustomColors.) And see here for more discussion on the proposal.
That's great, FAR easier to use than the current system and really allows us to fine tune the colours to exactly what we want.
Small question though, are the hardcoded overlays for swamps and whatnot going to appear on this biome sheet for us to adjust as well? Or are they going to be something separate/not possible to edit them?
That's great, FAR easier to use than the current system and really allows us to fine tune the colours to exactly what we want.
Small question though, are the hardcoded overlays for swamps and whatnot going to appear on this biome sheet for us to adjust as well? Or are they going to be something separate/not possible to edit them?
Gonna try to get all that on the one sheet per affected block(s). Currently MCPatcher's Custom Colors has a a separate grass and foliage palette for this hard-coded swamp overlay. It might be a good time to just eliminate that middleman since the new palette is precise enough to take over the role of the old one (the old technically was too--it's just that biome palettes have been out of the spotlight for awhile, that they were pretty low priority).
The original design intent behind the separate palette for the swamp overlay was that we didn't want to remove Mojang's swamp overlay for those who had developed their pack around it. If they had the swampgrass and swampfoliage palettes in their pack, it'd then be overridden. At this point I almost think it'd make more sense to just add a flag to color.properties that disables the hardcoded overlay there and allows you to use the main palettes normally for every biome. The only reason I don't think we should completely remove the hard-coded overlays at default is because some people may still wish to switch to the vanilla textures while patched for some maps.
You know to be fair that does sound a lot easier. You could add in as many files as you'd like, want a flat color A to color B? Or want C color at T height? add what you want then let minecraft smooth between.
Basically how it works is every biome gets its own temperature, and the temperature decreases by so much every block. Thing is, the hotter the biome, the less the temperature changes each block. Ergo, warmer biomes see very little color/temperature change in elevation. They also usually don't have snowcaps on mountains.
I echo those words and sympathize.
Having just found this thread (with thanks to Alvoria), I'm realizing 1.7 is a lot more than just a greater variety of plants. Thanks guys for doin' the experimentation thing...and the hard work! Height, temperature, so many new biomes...what the flip!?
It's fascinating to watch you lot discover things, but I think I need a rest already!
-The new format should use the same 256x256 png file format with a customizable exception to vertical height.
-The X row of pixels should be for biome ID values (See here.)
-The Y column of pixels should be for relative height. (hence customizable pixel Y resolution.)
-The new palettes should be compatible replacements for both official Mojang biome palettes (grasscolor, foliagecolor) and custom MCPatcher-only palettes both created by texture pack artists and things like the sky biome coloring component of Custom Colors.
This is just in the experimental stage and may be scheduled for test implementation once the main, existing features of MCPatcher are once again fully operational. Note that all of this information is subject to change and realize that I'm posting this mainly for educational and feedback purposes.
This system is a bit more complex than Mojang's on paper, but allows for much finer control of every single aspect of biome-based block coloring and will logically make more sense on the artist's end to set up than on Mojang's current format. Basically all of the work will go into choosing your color gradients for each biome without having to worry about merging the height value all to a single point.
For example:
I had made that to test the range of the forest biome.
Building up to max height, it stops at the blue, that leaves a bit of the colormap that is not used.
So not only do we need the location of the base biome, but also where it's max height also is on the map for each one.
It will be a pain in the ass but I'll fiddle around, see if there's a pattern from biome to biome. Got nothing better to do right at the moment...
Looking forward to seeing how this works, Misa.
Any chance of a diagram for my tired old brain to better take it all in, or is this at too early a stage? Although reading your last sentence seems to indicate the system will be a lot easier to grasp and manage, if I understand it correctly.
In any event I will keep an eye on your Biome Palette Template thread, with thanks for the effort you're putting in on this.
Don't forget that there is the AMPLIFIED world type now with higher everything.
If you like-- but i certainly don't feel safe assuming that Mojang is done adding/changing biomes or messing with the colormap.
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
That's awesome work! It's something for me to be going on with and certainly helps me understand what Mojang have done so far. Thank you.
The patience and insight you guys exhibit is outstanding...hats off and a bow all round!
Well, you beat me to the punch!
I got about halfway through checking how long the lines extended (for height) before checking here and noticing you'd already done it. Oh well, nice to know I don't have to finish it...
Amazing! Now I might actually consider working with the new biome system... before, it would have pretty much been guesswork for me. One thing though... in my early testing, I could've sworn that the colors stopped gradient-ing past Y=64, not Y=62...
One thing I see you don't mention is how to transition between the biome edges. I'm assuming a linear interpolation with adjacent biome colors at the edges? Would it make sense to have a setting that determines the sample size for the 'blend' so we could control how smooth the transitions are? (As in determine a block's color by sampling the blocks within 1, 2 or 3 of it and blending?)
You are a true hero.
Yes, it will use hard-coded blending as Mojang's currently does. Also this feature for tweaking the blend radius already exists as an end-user-adjustable setting in MCPatcher. (See the Blend radius option on the Options tab of any version of MCPatcher that supports CustomColors.) And see here for more discussion on the proposal.
Wow, this is the EXACT idea I had and posted about on this very threaD:
I just wish Mojang would implement something like this, and if not just go back to single-color biomes :/
"I'm an outsider by choice, but not truly.
It’s the unpleasantness of the system that keeps me out.
I’d rather be in, in a good system. That’s where my discontent comes from:
being forced to choose to stay outside.
My advice: Just keep movin’ straight ahead.
Every now and then you find yourself in a different place."
-George Carlin
That's way simpler to grasp and manage than radiating overlapping lines on the Mojang triangle. I could definitely work with that. Also The_Fool raised the other point regarding blending, which I was only vaguely wondering about at this stage and you seem to have that covered in the way we're already familiar with in MCPatcher. So I'd be very happy with that.
Haha! I'm very interested...and I'd already bookmarked it earlier...as soon as I realized how little I knew about the new 1.7 system. Listening-in helps me grasp things better when the penny eventually drops.
That's great, FAR easier to use than the current system and really allows us to fine tune the colours to exactly what we want.
Small question though, are the hardcoded overlays for swamps and whatnot going to appear on this biome sheet for us to adjust as well? Or are they going to be something separate/not possible to edit them?
Boy oh boy, this. Why mojang went for a weirdass system like the one they have now, I have no idea. >.>
The original design intent behind the separate palette for the swamp overlay was that we didn't want to remove Mojang's swamp overlay for those who had developed their pack around it. If they had the swampgrass and swampfoliage palettes in their pack, it'd then be overridden. At this point I almost think it'd make more sense to just add a flag to color.properties that disables the hardcoded overlay there and allows you to use the main palettes normally for every biome. The only reason I don't think we should completely remove the hard-coded overlays at default is because some people may still wish to switch to the vanilla textures while patched for some maps.
The bloody fog color changes now when you're in shadow.
Please tell me this can be altered... Ugh.
I don't believe this can be altered. It changes so that you can't just tell that it's day time while in caves.