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'm not in a position to do anything about it, but talk, but i've been thinking about what a better colormap might look like. I definitely agree there are a lot of better solutions than the triangle, with all biomes converging to the bottom corner.
-The X row of pixels should be for biome ID values (See here.)
The advantage of the old colormap that this looses is easy extensibility. If you make a sensible colormap, than a mod that adds biomes can say add a biome that's half-way between forest and jungle, and choose a spot on the old colormap between those two points. It should get a sensible, but new color, if the texture artist filled in the whole thing.
How does this system work for biome mods-- especially with large numbers of biomes?
Seems to me we can have the best of both worlds, by using a full square, positioning the origin points of biomes by temperature and moisture-- but moving in a straight (not diagonal) line towards the cold side. That way as long as you didn't have origin points on the same line biomes wouldn't cross.
-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.
It seems to me that height isn't exactly the relevant property, but whatever they use to calculate the level at which snow falls. I don't know how that is calculated, but i wouldn't want to see lush green grass under the snow, just because the world height was increased over the vanilla (assuming the snow level stayed the same).
The advantage of the old colormap that this looses is easy extensibility. If you make a sensible colormap, than a mod that adds biomes can say add a biome that's half-way between forest and jungle, and choose a spot on the old colormap between those two points. It should get a sensible, but new color, if the texture artist filled in the whole thing.
How does this system work for biome mods-- especially with large numbers of biomes?
Any biome mod that's using Mojang's default palettes is probably not a very well-made mod to begin with (they should be adding their own resources instead of recycling those from Mojang). However you lose nothing with this new palette and it is only read by MCPatcher in favor of Mojang's palette usage if present. The old palettes should still be able to be used by mods. MCPatcher will likely only be reading the biome ID's used by Mojang, so unless mods are overwriting Mojang's biome ID's (which would be a really bad idea), conflicts should be easy to avoid here.
Seems to me we can have the best of both worlds, by using a full square, positioning the origin points of biomes by temperature and moisture-- but moving in a straight (not diagonal) line towards the cold side. That way as long as you didn't have origin points on the same line biomes wouldn't cross.
That's not really the best of both worlds, as it's lacking the huge key bonus of this new system. As it is, certain biomes share the same coordinates or clamped coordinates and cannot be currently split, and Mojang's concept of biome color schemes don't necessarily translate well to actual temperature/humidity graphs. For instance we could not have a custom Nether biome and a desert biome next to each other with drastically different appearances (remember, this will also affect custom colors skies/fog). The new palette format allows you to edit every single biome in the game, not just the coordinates several biomes happened to be grouped to. This greatly increases the amount of variety by a factor larger than 4x that could not be obtained with a temperature/humidity graph of any kind using Mojang's current values.
It seems to me that height isn't exactly the relevant property, but whatever they use to calculate the level at which snow falls. I don't know how that is calculated, but i wouldn't want to see lush green grass under the snow, just because the world height was increased over the vanilla (assuming the snow level stayed the same).
To my knowledge, biome altitude is what Mojang is using to calculate this. They just apply a noise filter calculated by the worldgen's seed so the snowfall layer on their altitude scale doesn't always land at the same block height--this prevents having "bowl cut" snow caps. Essentially it is a combination of biome altitude data with block height that determines snowfall and we'll likely just be using their system for this. 'Relative height' is just the term I'm using for the Y since it's what it'll most generally correspond to. If this works as expected, you should have no problem having dead grass under all naturally-occuring snowfall everywhere in the game.
One methood in biomes I wouldn't mind seeing is instead of using one colormap, why not a strip of color per biome all in their own files?
A 6 pixel high (or more for random color shuffleing) by X wide strip file for each biome where one ends the default color and the other end is max height, top half can be for leaves, bottom for grass.
Something like that.. each biome gets their own strip. Mods that add biomes just need to add their own.
Be better then trying to pinpoint exact locations on one colormap.. or wasting a large colormap for one biome.
One methood in biomes I wouldn't mind seeing is instead of using one colormap, why not a strip of color per biome all in their own files?
A 6 pixel high (or more for random color shuffleing) by X wide strip file for each biome where one ends the default color and the other end is max height, top half can be for leaves, bottom for grass.
Something like that.. each biome gets their own strip. Mods that add biomes just need to add their own.
Be better then trying to pinpoint exact locations on one colormap.. or wasting a large colormap for one biome.
Because this format, being an MCPatcher-specific feature of Custom Colors needs to be compatible with MCPatcher's custom palettes feature. This method would also greatly increase the file count and size--making the file structure far more complicated than it needs to be to still have much greater control over biome colorings than the default Mojang method. Remember that MCPatcher supports birch, pine, sky, fog, swamp grass, swamp foliage, and water biome palettes at default--but also supports custom user-defined biome palettes through color.properties. Now even assuming you could consolidate all these into a single file per biome, you still have 61 files you have to create. If you didn't consolidate all those individual categories (as it would be difficult to do without running into limitation issues), then a pack like mine would have to make something like 1,281 new files.
The file structure is already cluttered enough as it is with all the format revisions made by Mojang. The KISS principal must be pretty strictly adhered to when designing new features.
Any biome mod that's using Mojang's default palettes is probably not a very well-made mod to begin with (they should be adding their own resources instead of recycling those from Mojang).
I won't dispute what should be.
But a quick check shows that the latest releases of ExtraBiomesXl and Biomes O Plenty don't provide their own color maps.
To my knowledge, biome altitude is what Mojang is using to calculate this. They just apply a noise filter calculated by the worldgen's seed so the snowfall layer on their altitude scale doesn't always land at the same block height--this prevents having "bowl cut" snow caps. Essentially it is a combination of biome altitude data with block height that determines snowfall and we'll likely just be using their system for this. 'Relative height' is just the term I'm using for the Y since it's what it'll most generally correspond to. If this works as expected, you should have no problem having dead grass under all naturally-occuring snowfall everywhere in the game.
In snapshot 13w37a (and the previous ones i think) the altitude at which rain turns to snow varies greatly. It seems to be the same in a regular and AMPLIFIED world. For instance it is about Y 400 over forest, Y 130 over Taiga, but Y 100 over X Hills.
But a quick check shows that the latest releases of ExtraBiomesXl and Biomes O Plenty don't provide their own color maps.
This mod is only intended to affect the official biome ID's implemented by Mojang with room for expansion within their own currently visible system. It's likely any mod that references these resources will still be able to use Mojang's two palettes. If they're cutting into Mojang's biome ID expansion space, then they may have a problem. But it's really on them to ensure their mod as conflict-free as possible by keeping it self-contained with their own resources.
In snapshot 13w37a (and the previous ones i think) the altitude at which rain turns to snow varies greatly. It seems to be the same in a regular and AMPLIFIED world. For instance it is about Y 400 over forest, Y 130 over Taiga, but Y 100 over X Hills.
Hence the reason for this thread and my statement about providing a template for the new format. The snow level varies based on a combination of 'relative height' (again for lack of a better term) and the biome's temperature. On that template I'll mark the levels of snowcover. It's not like this new palette will be changing Mojang's coding for this, it just changes how the 'line ranges' (See khanador's post.) are read from the resource file. If Mojang's amplified worlds do not break their palette color levels for snowfall, then neither will this new palette. All it does is take those 'line ranges' on their current palette and does the following:
Orients them vertically for easier for easier gradient assignments
Increases the range of colors that are blended over a larger range
Separates and organizes every single biome into its own individual column to allow finer control of variety.
Maintains a small filecount and filesize while still maintaining compatibility with the custom palettes of CustomColors.
Your issue of concern should not be affected in any way by the new palette format. It's just a different and more intuitive way of doing the same thing Mojang's already does.
I love your work Misa and I thought you might find information about new biome palette I discovered useful.
I post my observation in the other thread about biome colors.
That's actually almost spot on to the calculations I made for the template I was planning. I've unfortunately had very little time to actually assemble any graphics lately due to my computer being somewhat broken, and the fact that I'm busy with renovations on my house to sell it, and preparations for a large move across the country. I'm glad someone beat me to posting some detailed info on that whole 'line range' thing they've got going on.
So making one big PNG wich covers all biomes, in the way Taaine mentions, is not a viable idea?
You would have one file, wich could be expanded with every new biome or something like that...
He's not suggesting making one big png which covers all biomes--I am. He's suggesting combining just Mojang's grass and foliage palettes into one file, but separating the biomes into 61 different files. And that is not viable because it doesn't account for MCPatcher's CustomColors palettes (which is what this new system will be implemented through). Even if it did combine all those, you still have 61 new palettes, plus 61 more for each and every custom palette created by the texture pack author. Given that the number of biomes is greater than the number of palettes in the average texture pack, it makes more sense to combine the biomes into single files instead of the other way around to reduce clutter.
For those who like to have everything change color as time progresses.
( for let's say an LSD or MUSHROOM mod ) could be very trippy
Time is not a factor of biome palettes and probably shouldn't be for the sake of simplicity. This new palette idea's goal is just to allow finer control of existing features, not create new ones. Besides the sky color changing feature based on time would be more complicated to implement than you think given how sunrise and sunset are coded. HOWEVER, altitude will be able to be affected by custom sky color. Meaning you could have a mushroom biome sky that changes colors as you jump or climb or descend hills--or more practically, haze in forests that only kicks in at forest-level relative altitudes.
Sorry i know Taaine ( who is a she btw ) mentioned separate rows, my thought was to combine them. Wich is what your suggesting.... how stupid of me. I just feel guilty for using alot of tutorials you guys make, without contributing something And believe me i don't underestimate anything as far as coding goes. I tried tutorials about making a mod, just got a generic item done.... And it was even a simple copy paste tut also, so i didn't actually do any coding myself. I shall refrain from making dumb comments and just let you guys do your thang! The part you mention about the hazey forest though... I might give that a try, if i can ever figure it out that is Anyway i'm following this along with the other biome threads that popped up. Seeing how you guys unfold this is pretty interesting really. I just got home from a late shift and immediatly jumped behind the laptop to see how it's going
Because this format, being an MCPatcher-specific feature of Custom Colors needs to be compatible with MCPatcher's custom palettes feature. This method would also greatly increase the file count and size--making the file structure far more complicated than it needs to be to still have much greater control over biome colorings than the default Mojang method. Remember that MCPatcher supports birch, pine, sky, fog, swamp grass, swamp foliage, and water biome palettes at default--but also supports custom user-defined biome palettes through color.properties. Now even assuming you could consolidate all these into a single file per biome, you still have 61 files you have to create. If you didn't consolidate all those individual categories (as it would be difficult to do without running into limitation issues), then a pack like mine would have to make something like 1,281 new files. The file structure is already cluttered enough as it is with all the format revisions made by Mojang. The KISS principal must be pretty strictly adhered to when designing new features.
One methood in biomes I wouldn't mind seeing is instead of using one colormap, why not a strip of color per biome all in their own files? A 6 pixel high (or more for random color shuffleing) by X wide strip file for each biome where one ends the default color and the other end is max height, top half can be for leaves, bottom for grass. Something like that.. each biome gets their own strip. Mods that add biomes just need to add their own. Be better then trying to pinpoint exact locations on one colormap.. or wasting a large colormap for one biome.
The big problem with single strips (or one png with column or row for each biome) is that blending would be very difficult. Also seeing that biomes are split into 4 groups:
Biomes have been put into four main categories[13]
Snow-covered
Cold
Medium
Dry/warm
I believe newer looking biome colors will arise, as you will not have to worry about blending near a desert and taiga anymore, which should simplify things some way, but strips create hardpoints where two biomes can't blend and will not flow continuously. Also with 1.7 around the corner, Mojang has been taking ideas like CTM and shaders, which I think is a huge step to solving mistakes and errors present. Also on the topic of colors, how should people go about sugar cane being biome specific? Will it blend too much, create new variety? The new biome colors png may be split into the 4 biome sections, and since like 5 biomes have been added its going to be more cluttered with less room for noise and blending. I hope it won't be too hard of a switch.
Also about finding the new coordinates of biomes, I've been trying to do one strip at a time with 256 colors and running Minecraft to identify the coordinates using the colors as reference points, time consuming(256x256 times) but it should get it done until someone finds them an easier way.
Does this work for the snapshots? It works fine in 1.6.2. But I never tried it in the snapshots.
Read the thread title. A new template is in the works for the snapshots. The existing one will get you really close, though, but there are some pronounced changes that you'll want to take into account.
The big problem with single strips (or one png with column or row for each biome) is that blending would be very difficult. Also seeing that biomes are split into 4 groups:
Biomes have been put into four main categories[13]
Snow-covered
Cold
Medium
Dry/warm
But that's not how blending between biomes works. It just looks at the two biome colors, and creates an in-between color on the edges of a biome. For instance if a red colored biome was next to a yellow biome the border would be orange-- even if there was no orange anywhere on any of your colormaps.
Biomes are categorized, yes, but as described it simply makes it unlikely for biomes of different categories to be near each other, not impossible. As i understand the categories, i've seen biomes from different ones next to each other.
Misa, do we have a time frame in regards to you and Kahr getting this new template of a 256-striped png published?
I see that he's updated his patcher for 13w39b, but there's no new information under the "Info for texture artists" section.
No pressure, as I understand you're busy. Just curious.
I've been away since 1.4, but was drawn back in with the terrain generation update. I'd like to finally finish my texture pack. Thanks for everyone's contributions. These threads on the new biome coloring scheme have been great reads.
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. 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 with 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.
I think I understand the basic shape of how this works, but is there a template image anywhere showing it visually? Also, does anyone know if the filename for the image was decided? Kahr said he started experimenting with it in the newest beta release of MCPatcher. I assume the image would go in the ~\colormap folder, but what to name it?
Thanks so much for your efforts, Misa! The combination of the new update and this new biome palette are going to make Minecraft so much more interesting to play!
I assume the image would go in the ~\colormap folder, but what to name it?
I gather that the names are the same as the existing files. For example "grass.png". That's why you have to have a "grass.properties" file with "format=2" in it to let MCPatcher know that it's supposed to be using the Misa-style format rather than the Minecraft-style format.
I could be wrong since I haven't tried it out, however. If someone tries it this way, please let me know. I'll try to check it out myself later today or tomorrow.
Apparently I'm wrong. I just tried it and I can't figure it out. Anyone know what these files are supposed to be called and in what folder they're supposed to be placed?
It won't use the vertical method for biomes, what am i doing wrong?
That's what I'd like to know. I have no idea what MCPatcher wants the files to be named. Unfortunately the only people who seem to know are Misa and Kahr... and neither has said.
I think I understand the basic shape of how this works, but is there a template image anywhere showing it visually? Also, does anyone know if the filename for the image was decided? Kahr said he started experimenting with it in the newest beta release of MCPatcher. I assume the image would go in the ~\colormap folder, but what to name it?
That's what I'd like to know. I have no idea what MCPatcher wants the files to be named. Unfortunately the only people who seem to know are Misa and Kahr... and neither has said.
HELP!
Here's the sample biome reference .png that Misa posted about a month ago to my request for an example of what she was proposing:
I downloaded it back then to better understand her explanation of how it would fit with all the new biomes. The perpendicular lines exactly match all the biomes listed here:
The color change from bottom to top of each line goes from bedrock to the highest point in a world and simulates altitude effect on block color, as far as I understand (kahr just recently mentioned it was now possible to specify variable blend points on each line...again, if I understood him correctly!).
I tried to get this to work using the .properties convention kahr first mentioned he'd implemented in one of the snapshots about 3 weeks ago and tried every which way to get it to work, but couldn't see any effect in game. I'm assuming you'd need one of these biome 'charts' for each block you wanted biome and height to effect (such as grass, foliage, stone, etc.).
Of course I might have completely misunderstood Misa's original explanation and things could well have changed since then.
I haven't had time to experiment further, due to all the extra work Mojang landed us with, but you guys are better at this sort of thing for sure. Hope this helps in some way. At least you've got the graphic that Misa originally posted, which since completely disappeared off the forum (this might indicate that Misa and kahr have changed the method by which biome coloring would be implemented).
Hey! I put a lot of time into this and recently updated it and I'm just gonna put it here where hopefully it can provide some more help!
It's a PIXEL-PERFECT map of the biomes used in the biome colormap, after looking at a couple of references for where the biomes approximately start and, through painstaking trial and error (special thanks to Jeb for adding F3+T to reload textures in-game), tracking down the each pixel used in each biome for two solid days (now that I understand how it works, I can update it in much less time).
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.
Some thoughts:
The advantage of the old colormap that this looses is easy extensibility. If you make a sensible colormap, than a mod that adds biomes can say add a biome that's half-way between forest and jungle, and choose a spot on the old colormap between those two points. It should get a sensible, but new color, if the texture artist filled in the whole thing.
How does this system work for biome mods-- especially with large numbers of biomes?
Seems to me we can have the best of both worlds, by using a full square, positioning the origin points of biomes by temperature and moisture-- but moving in a straight (not diagonal) line towards the cold side. That way as long as you didn't have origin points on the same line biomes wouldn't cross.
It seems to me that height isn't exactly the relevant property, but whatever they use to calculate the level at which snow falls. I don't know how that is calculated, but i wouldn't want to see lush green grass under the snow, just because the world height was increased over the vanilla (assuming the snow level stayed the same).
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
That's not really the best of both worlds, as it's lacking the huge key bonus of this new system. As it is, certain biomes share the same coordinates or clamped coordinates and cannot be currently split, and Mojang's concept of biome color schemes don't necessarily translate well to actual temperature/humidity graphs. For instance we could not have a custom Nether biome and a desert biome next to each other with drastically different appearances (remember, this will also affect custom colors skies/fog). The new palette format allows you to edit every single biome in the game, not just the coordinates several biomes happened to be grouped to. This greatly increases the amount of variety by a factor larger than 4x that could not be obtained with a temperature/humidity graph of any kind using Mojang's current values.
To my knowledge, biome altitude is what Mojang is using to calculate this. They just apply a noise filter calculated by the worldgen's seed so the snowfall layer on their altitude scale doesn't always land at the same block height--this prevents having "bowl cut" snow caps. Essentially it is a combination of biome altitude data with block height that determines snowfall and we'll likely just be using their system for this. 'Relative height' is just the term I'm using for the Y since it's what it'll most generally correspond to. If this works as expected, you should have no problem having dead grass under all naturally-occuring snowfall everywhere in the game.
A 6 pixel high (or more for random color shuffleing) by X wide strip file for each biome where one ends the default color and the other end is max height, top half can be for leaves, bottom for grass.
Something like that.. each biome gets their own strip. Mods that add biomes just need to add their own.
Be better then trying to pinpoint exact locations on one colormap.. or wasting a large colormap for one biome.
The file structure is already cluttered enough as it is with all the format revisions made by Mojang. The KISS principal must be pretty strictly adhered to when designing new features.
I won't dispute what should be.
But a quick check shows that the latest releases of ExtraBiomesXl and Biomes O Plenty don't provide their own color maps.
In snapshot 13w37a (and the previous ones i think) the altitude at which rain turns to snow varies greatly. It seems to be the same in a regular and AMPLIFIED world. For instance it is about Y 400 over forest, Y 130 over Taiga, but Y 100 over X Hills.
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
Hence the reason for this thread and my statement about providing a template for the new format. The snow level varies based on a combination of 'relative height' (again for lack of a better term) and the biome's temperature. On that template I'll mark the levels of snowcover. It's not like this new palette will be changing Mojang's coding for this, it just changes how the 'line ranges' (See khanador's post.) are read from the resource file. If Mojang's amplified worlds do not break their palette color levels for snowfall, then neither will this new palette. All it does is take those 'line ranges' on their current palette and does the following:
That's actually almost spot on to the calculations I made for the template I was planning. I've unfortunately had very little time to actually assemble any graphics lately due to my computer being somewhat broken, and the fact that I'm busy with renovations on my house to sell it, and preparations for a large move across the country. I'm glad someone beat me to posting some detailed info on that whole 'line range' thing they've got going on.
He's not suggesting making one big png which covers all biomes--I am. He's suggesting combining just Mojang's grass and foliage palettes into one file, but separating the biomes into 61 different files. And that is not viable because it doesn't account for MCPatcher's CustomColors palettes (which is what this new system will be implemented through). Even if it did combine all those, you still have 61 new palettes, plus 61 more for each and every custom palette created by the texture pack author. Given that the number of biomes is greater than the number of palettes in the average texture pack, it makes more sense to combine the biomes into single files instead of the other way around to reduce clutter.
Time is not a factor of biome palettes and probably shouldn't be for the sake of simplicity. This new palette idea's goal is just to allow finer control of existing features, not create new ones. Besides the sky color changing feature based on time would be more complicated to implement than you think given how sunrise and sunset are coded. HOWEVER, altitude will be able to be affected by custom sky color. Meaning you could have a mushroom biome sky that changes colors as you jump or climb or descend hills--or more practically, haze in forests that only kicks in at forest-level relative altitudes.
The big problem with single strips (or one png with column or row for each biome) is that blending would be very difficult. Also seeing that biomes are split into 4 groups:
I believe newer looking biome colors will arise, as you will not have to worry about blending near a desert and taiga anymore, which should simplify things some way, but strips create hardpoints where two biomes can't blend and will not flow continuously. Also with 1.7 around the corner, Mojang has been taking ideas like CTM and shaders, which I think is a huge step to solving mistakes and errors present. Also on the topic of colors, how should people go about sugar cane being biome specific? Will it blend too much, create new variety? The new biome colors png may be split into the 4 biome sections, and since like 5 biomes have been added its going to be more cluttered with less room for noise and blending. I hope it won't be too hard of a switch.
Also about finding the new coordinates of biomes, I've been trying to do one strip at a time with 256 colors and running Minecraft to identify the coordinates using the colors as reference points, time consuming(256x256 times) but it should get it done until someone finds them an easier way.
Servers Rules|Support Forum Rules|Show Your Creation Rules|Off Topic Rules
But that's not how blending between biomes works. It just looks at the two biome colors, and creates an in-between color on the edges of a biome. For instance if a red colored biome was next to a yellow biome the border would be orange-- even if there was no orange anywhere on any of your colormaps.
Biomes are categorized, yes, but as described it simply makes it unlikely for biomes of different categories to be near each other, not impossible. As i understand the categories, i've seen biomes from different ones next to each other.
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
I see that he's updated his patcher for 13w39b, but there's no new information under the "Info for texture artists" section.
No pressure, as I understand you're busy. Just curious.
I've been away since 1.4, but was drawn back in with the terrain generation update. I'd like to finally finish my texture pack. Thanks for everyone's contributions. These threads on the new biome coloring scheme have been great reads.
Servers Rules|Support Forum Rules|Show Your Creation Rules|Off Topic Rules
What are you talking about? 1.7 Is the same in this regard as the previous snapshots discussed in this and other threads.
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
I think I understand the basic shape of how this works, but is there a template image anywhere showing it visually? Also, does anyone know if the filename for the image was decided? Kahr said he started experimenting with it in the newest beta release of MCPatcher. I assume the image would go in the ~\colormap folder, but what to name it?
Thanks so much for your efforts, Misa! The combination of the new update and this new biome palette are going to make Minecraft so much more interesting to play!
I gather that the names are the same as the existing files. For example "grass.png". That's why you have to have a "grass.properties" file with "format=2" in it to let MCPatcher know that it's supposed to be using the Misa-style format rather than the Minecraft-style format.
I could be wrong since I haven't tried it out, however. If someone tries it this way, please let me know. I'll try to check it out myself later today or tomorrow.
Apparently I'm wrong. I just tried it and I can't figure it out. Anyone know what these files are supposed to be called and in what folder they're supposed to be placed?
HELP!
Here's the sample biome reference .png that Misa posted about a month ago to my request for an example of what she was proposing:
I downloaded it back then to better understand her explanation of how it would fit with all the new biomes. The perpendicular lines exactly match all the biomes listed here:
http://minecraft.gamepedia.com/index.php?title=Data_values&oldid#Biome_IDs
The color change from bottom to top of each line goes from bedrock to the highest point in a world and simulates altitude effect on block color, as far as I understand (kahr just recently mentioned it was now possible to specify variable blend points on each line...again, if I understood him correctly!).
I tried to get this to work using the .properties convention kahr first mentioned he'd implemented in one of the snapshots about 3 weeks ago and tried every which way to get it to work, but couldn't see any effect in game. I'm assuming you'd need one of these biome 'charts' for each block you wanted biome and height to effect (such as grass, foliage, stone, etc.).
Of course I might have completely misunderstood Misa's original explanation and things could well have changed since then.
I haven't had time to experiment further, due to all the extra work Mojang landed us with, but you guys are better at this sort of thing for sure. Hope this helps in some way. At least you've got the graphic that Misa originally posted, which since completely disappeared off the forum (this might indicate that Misa and kahr have changed the method by which biome coloring would be implemented).
Best of luck.
http://www.youtube.com/user/Ninghum?feature=mhee
Hey! I put a lot of time into this and recently updated it and I'm just gonna put it here where hopefully it can provide some more help!
It's a PIXEL-PERFECT map of the biomes used in the biome colormap, after looking at a couple of references for where the biomes approximately start and, through painstaking trial and error (special thanks to Jeb for adding F3+T to reload textures in-game), tracking down the each pixel used in each biome for two solid days (now that I understand how it works, I can update it in much less time).
(image updates can be found here: http://minecraft.gamepedia.com/File:Biomes1.7.2.png# )