A single mcmeta file that uses hex values as colours for each biome would be soooooooooooooooooo much easier to use that what we have got now. I imagine it would be easier to read in-game as well?
There are potentially a thousand different color samples in one biome's path up to max elevation. I don't see anyone trilled to type a fraction of those numbers in.
There are potentially a thousand different color samples in one biome's path up to max elevation. I don't see anyone trilled to type a fraction of those numbers in.
Yeah.
Or turned so the cold/high end is at the top, as other's have suggested. That makes sense, though it breaks tradition more.
You could have it so that you set two numbers, one for max height, one for base height and it just auto scales between them. Then there wouldn't be too many numbers. Mind you though, I had forgotten about the whole elevation thing when I said it would be easier... If it was still the pinpoint biome map like before it would probably be easier though.
You could have it so that you set two numbers, one for max height, one for base height and it just auto scales between them.
A good artist can make a better and much more attractive color range than something auto-generated between two color values.
And anyway, most 2-point color gradients between dissimilar colors have a middle section of grey or brown.
For instance Savanah will (once i get it working) probably go from dull gold/green, to a darker olive to a lighter, more saturated green, to a very pale green-grey at the snow line. Plus the random variations, which are generated from noise initially, but tweaked with more care than a simple +/- 5% random luminosity fluctuation.
I don't like the idea of entirely specifying colors as a start and end value in the mcmeta because that then forces you into having a flat gradient. I'd rather be able to specifically set the color at a given elevation with a colormap image that is as high in pixels as the game world is in blocks.
As for McPatcher and Optifine. We should not need to dig into the jar file just to change a color. If MC was designed properly from the start, all of the model data, all of the textures, and all of the color data would have been in external data files from the beginning. (Course this was started as some guys personal project with no intention that it ever would become what it has. So I can forgive Notch some of his poor design decisions. Doesn't make them any less frustrating to deal with though.)
If it's not too hard I'd love to see if we could get some biome maps for things like birch leaves, spruce leaves, reeds, etc. in vanilla. I'm just so sick of hardcoded colours...
If it's not too hard I'd love to see if we could get some biome maps for things like birch leaves, spruce leaves, reeds, etc. in vanilla. I'm just so sick of hardcoded colours...
It should be pretty easy. The system works, they just need to apply it to other blocks using other colormaps.
Does anyone have the points for the new biomes yet? I'm having a rough time locating them myself.
Have you verified that they actually have new points?
I haven't been systematic, but except for birch forest and jungle edge (if that is new?) everything i've checked reuses existing biome points. Though i really hope future snapshots will change that.
I had another idea for a new colormap system... why not give each biome it's own file that could vary in size and dimension (up to 256x256, presumably), where the color moves further along the X-axis as the block's height increases, and the value is randomized along the Y-axis?
That way, you could have detailed colors like the square colormap suggested earlier, or stick to the original un-varying coloring system with a 1x1 image for each biome, or have varying amounts of height detail and randomization by using various rectangular shapes... Just an idea.
I would also imagine that the X-axis would have to have an even number of pixels to be divided along the required 256 block world height properly.
On an unrelated note: This is my first hot topic on the forums... Yay! :P. Didn't think there would be so much discussion revolving around the new biome coloring... I was quite wrong.
On an unrelated note: This is my first hot topic on the forums... Yay! :P. Didn't think there would be so much discussion revolving around the new biome coloring... I was quite wrong.
Something affects texturing, you can bet that the regulars here will bounce it around until we've learned every last one of its secrets and discussed at least a dozen interesting ideas for how to use it in various situations. Minimum.
Your idea isn't bad, btw. It would make things functionally similar to how biome coloring worked in beta, but with an added height dimension. I doubt they'd ever implement it, though.
Yeah from the way it looks, it's just safer to paint the whole sheet and blend colors so we don't have to worry about stuff in the future or for other mods.
This reminds me... we will have to add the lines to the bottom right for each color AND blend them together to get rid of the black so that future biome mods will hopefully look halfway decent... ew. I hated that already the last time.
That's an unnecessarily painful workflow.
I recommend starting with big gradients over the whole triangle. Then smaller, less opaque circular gradients to push different areas to the color you want. Thus any mod biome should work reasonably. There is not a good reason to have any black in the color map.
There are potentially a thousand different color samples in one biome's path up to max elevation. I don't see anyone trilled to type a fraction of those numbers in.
Yeah.
Or turned so the cold/high end is at the top, as other's have suggested. That makes sense, though it breaks tradition more.
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
You could have it so that you set two numbers, one for max height, one for base height and it just auto scales between them. Then there wouldn't be too many numbers. Mind you though, I had forgotten about the whole elevation thing when I said it would be easier... If it was still the pinpoint biome map like before it would probably be easier though.
A good artist can make a better and much more attractive color range than something auto-generated between two color values.
And anyway, most 2-point color gradients between dissimilar colors have a middle section of grey or brown.
For instance Savanah will (once i get it working) probably go from dull gold/green, to a darker olive to a lighter, more saturated green, to a very pale green-grey at the snow line. Plus the random variations, which are generated from noise initially, but tweaked with more care than a simple +/- 5% random luminosity fluctuation.
Things like what?
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
As for McPatcher and Optifine. We should not need to dig into the jar file just to change a color. If MC was designed properly from the start, all of the model data, all of the textures, and all of the color data would have been in external data files from the beginning. (Course this was started as some guys personal project with no intention that it ever would become what it has. So I can forgive Notch some of his poor design decisions. Doesn't make them any less frustrating to deal with though.)
If it's not too hard I'd love to see if we could get some biome maps for things like birch leaves, spruce leaves, reeds, etc. in vanilla. I'm just so sick of hardcoded colours...
It should be pretty easy. The system works, they just need to apply it to other blocks using other colormaps.
Have you verified that they actually have new points?
I haven't been systematic, but except for birch forest and jungle edge (if that is new?) everything i've checked reuses existing biome points. Though i really hope future snapshots will change that.
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
I spent some time this morning and found the following colormap coords for each biome.
Awesome!
Just think how great it would be if we had a file where you could edit those values... we could do whatever the frack we wanted!
God I hate them removing colors from the colormap. Have I made that very clear?
That way, you could have detailed colors like the square colormap suggested earlier, or stick to the original un-varying coloring system with a 1x1 image for each biome, or have varying amounts of height detail and randomization by using various rectangular shapes... Just an idea.
I would also imagine that the X-axis would have to have an even number of pixels to be divided along the required 256 block world height properly.
On an unrelated note: This is my first hot topic on the forums... Yay! :P. Didn't think there would be so much discussion revolving around the new biome coloring... I was quite wrong.
Your idea isn't bad, btw. It would make things functionally similar to how biome coloring worked in beta, but with an added height dimension. I doubt they'd ever implement it, though.
Tell me if there is something wrong, I have yet to actually test it.
That's an unnecessarily painful workflow.
I recommend starting with big gradients over the whole triangle. Then smaller, less opaque circular gradients to push different areas to the color you want. Thus any mod biome should work reasonably. There is not a good reason to have any black in the color map.
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
Glad you folks are experimenting the new stuff for us who are a bit wary of dealing with the snapshots.
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
For example, heres my test colormap.
Yet when I reached max height in a planes biome..
So maybe need to rethink this, that looks to be stopping shy of where my ocean color is.