I've tested. Roofed forest obeys the colormap. You are right about the grass on top of the mesa plateaus-- it totally ignores the colormap.
I've been testing the colors today and I found out that the roofed forest does, in fact, OVERLAY its own separate color onto the grass. It doesn't totally ignore the color map like the mesa and swamp do. Btw, my colormap has 0 green on it.
It's a lot more subtle than the swamp and mesa biomes, but I guess the overlay is there to simulate a darker forest floor.
Why don't you use the more pinpoint biome locations like the template shows? Unless you want most the biomes to be the same color. You have a lot of nuce hues going with what you have, but a lot of those hues are lost being in spots not used by the game.
Hardcoding colors has to stop. Does Mojang realize people make resource packs in order to change the game's appearance? Sometimes it looks like they don't, or maybe they're just laughing at us right now.
The masa and swamp not using the biome sheet may be a bug, just like theres a semi bug with the colormaps still. They've been giving us more and more control over the colors.
The new system isn't really an 'altitude problem' once you have it sorted out it works and looks very stunning in game. I've been going though my last sheet I showed and seeing what heights the colors start changing and editing the gradient to get the colors to start changing where I like and at what height. Easy when you plop down a rainbow like I showed and go 'okay blocks at ___ height are this color on the sheet at this spot."
But yeah MCPtatcher wont be updating until 1.7 comes out in full. With these snaps the code can very well change from snap to snap, and you wouldn't want tp spend hours working on support only to have to throw everything you just did away for the next snap due to code changes.
What program are you using that just lets you "plop down" a gradient with multiple stops in the shape you want just like that? It would be useful to know as I screw around with biome colors.
And on a related note, maybe someone could help me with this problem I'm having? My resource pack crashes the game every time I look at a savanna biome. Found the problem, terrain.png was one pixel too short. Interesting bug though, because the game worked fine until I looked at the biome. Seems like it could be exploited in some way for an adventure map or something. Keep up the good work guys!
Why don't you use the more pinpoint biome locations like the template shows? Unless you want most the biomes to be the same color. You have a lot of nuce hues going with what you have, but a lot of those hues are lost being in spots not used by the game.
What program are you using that just lets you "plop down" a gradient with multiple stops in the shape you want just like that? It would be useful to know as I screw around with biome colors.
Most programs have a gradient tool that lets you slect two colors (or more) and just click and drag from two points places it in that area, auto mixing the colors.
Or you can use a brush with a soft edge and make your own.
I would go through what you have already and eyedrop some colors from good spots, colors that would fit well with each biome then use the pierces spots for the colors and the new 'temp lines'. I bet it would look so mice more diverse! Plus you could have some 'temps' be that rusty hue you'd like!
The pinpoint Pixel for the default biome is the base color, purly shown at height 62 and below, the rest takes color from the 'temp line'. the colors pick wobble a bit, so you could have one side of the line a more rusty hue, and the other a more cooler metal and it'll show a nice devercity! EXPEREMENT!
een testing the colors today and I found out that the roofed forest does, in fact, OVERLAY its own separate color onto the grass...
I guess you are right, it multiplies a light green-grey to the colormap. I couldn't tell before because my grass block has a very similar tint before adding the colormap.
That's true, if the roofed forest were really as dark and menacing as they say they wouldn't need to create the illusion of darkness by making the grass darker. The lighting engine should take care of that, and if the canopy doesn't fully cover everything, make the trees taller and the canopies closer together.
The lighting engine should take care of that. Besides there's no guarantee it will stay shaded. You can chop down the trees.
Yeah, that or, I don't know, THE BIOME COLOR MAP?
Why should there be ANY color overlays when we have a whole 256x256 image dedicated to just biome colors? With 256x256, doing around what, 12-32 different biomes with no derivatives or overlays shouldn't be an issue. I think this is just proving that biome coloring is still in major need of an overhaul.
I might be crazy for saying it, but I think using an MCMETA (caps for emphasis) file to do biomes might be better for biome colors! .....err, provided we get one of those doohickeys someone at Mojang always makes to convert things, this time you input a color map and it outputs an .mcmeta file with all of the biomes and comments to-OH WAIT, I FORGOT, MCMETA FILES DON'T HAVE COMMENTS
Moving on, basically define biome colors with hex color codes, define a min and max color (with medians sort of like doing a gradient?) values (with custom block values defined, if lower/higher, just keeps the last value), random colors with frequency/attraction/attenuation. Transitions (as well as biomes that use derivatives now) could also be defined, but otherwise they would behave like they do now.
"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
I might be crazy for saying it, but I think using an MCMETA (caps for emphasis) file to do biomes might be better for biome colors! .....
Moving on, basically define biome colors with hex color codes, define a min and max color (with medians sort of like doing a gradient?) values (with custom block values defined, if lower/higher, just keeps the last value), random colors with frequency/spread/attraction/attenuation. Transitions (as well as biomes that use derivatives now) could also be defined, but otherwise they would behave like they do now.
Um, some of us can deal with both worlds, but i dare say the vast majority of decent pack artists are much more comfortable messing with a colormap than typing in hex codes.
Unfortunately Jeb and Dinnerbone are more comfortable typing in hex values and thus we get this hardcoded stuff.
IMHO what Mojang should do is make the colormap a square. As elevation increases, it samples further to the right in a straight line. Biomes wouldn't overlap, as long as the origin point have different Y values.
Or each biome could get an 256 x 8 pix color map. 8 pixels of color randomly chosen for any of the 256 elevation levels. More files, but each one straight-forward.
Um, some of us can deal with both worlds, but i dare say the vast majority of decent pack artists are much more comfortable messing with a colormap than typing in hex codes.
Unfortunately Jeb and Dinnerbone are more comfortable typing in hex values and thus we get this hardcoded stuff.
IMHO what Mojang should do is make the colormap a square. As elevation increases, it samples further to the right in a straight line. Biomes wouldn't overlap, as long as the origin point have different Y values.
Or each biome could get an 256 x 8 pix color map. 8 pixels of color randomly chosen for any of the 256 elevation levels. More files, but each one straight-forward.
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
Mojang could have made a template for us, or I don't know, made default to be a pixel-perfect biome colormap instead of well, the one they've been using for a majority of the game that's just a basic gradient?
It used to use 11 points, they could have changed it to use an entire 128x128 image with a square grid instead of a 256x256 image with a triangular grid using only half of it.
They could have told us ahead of time saying, "hey, biome coloring is about to get a bit more complex, make sure your color maps don't have funky colors near the old points".
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
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
Also, I made my gradient using Photoshop and a large, soft brush.
Good point. Thanks!
oh, I meant foliage and grass pngs. oops.
And thanks for the help about the gradients, I figured it out and produced something that I think turned out well (or at least will with some refinement).
Hardcoding colors has to stop. Does Mojang realize people make resource packs in order to change the game's appearance? Sometimes it looks like they don't, or maybe they're just laughing at us right now.
I don't think they really think outside the box much when it comes to the art. Doesn't seem to occur to them that grass isn't always green.
I might be crazy for saying it, but I think using an MCMETA (caps for emphasis) file to do biomes might be better for biome colors! .....err, provided we get one of those doohickeys someone at Mojang always makes to convert things, this time you input a color map and it outputs an .mcmeta file with all of the biomes and comments to-OH WAIT, I FORGOT, MCMETA FILES DON'T HAVE COMMENTS
Yea putting ALL of the currently hard coded colors into the pack.mcmeta would be the obvious answer I think. Dunno why mojang never put any comments in the file since it supports having them just fine. (It's javascript basically.)
In regards to the color shifting with height. I don't think it's directly using height. I think what is happening is that the temperature now gets colder with elevation and it's still just using the old temp/wetness lookup. (I also suspect the shifting around of the color is due to humidity variations within a biome but I've not done enough poking to be entirely sure of that.) You can see the temperature change with elevation quite clearly when it's raining. Fly straight up and the rain will turn into snow. (Biomes with snow capped hills are the best for seeing this in action.)
Yea putting ALL of the currently hard coded colors into the pack.mcmeta would be the obvious answer I think. Dunno why mojang never put any comments in the file since it supports having them just fine. (It's javascript basically.)
In regards to the color shifting with height. I don't think it's directly using height. I think what is happening is that the temperature now gets colder with elevation and it's still just using the old temp/wetness lookup. (I also suspect the shifting around of the color is due to humidity variations within a biome but I've not done enough poking to be entirely sure of that.) You can see the temperature change with elevation quite clearly when it's raining. Fly straight up and the rain will turn into snow. (Biomes with snow capped hills are the best for seeing this in action.)
I've read that for the most part, JSON doesn't support comments. You CAN do comments, but you have to format like data, and then have it ignored. Example in Dinnerbone's sample:
"//comment":"All metainfo files will be ORIGINAL_FILE.mcmeta. For example, textures/blocks/portal.png.mcmeta. The format is, of course, JSON.",
So, not as easy as plopping a # at the start of the line, or a // a the beginning or /* at start and */ at end.
I know it's based on temperature getting cooler, I'm basically saying breaking that connection and allowing each biome to have an individual color map that is used based on height. I guess it could still be done with temperature if you just swapped out "height" with "local temperature", and then X was global temperature (biome ordering) and y was local temperature (temperature in that biome, elevation, still *basically* height).
"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
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?
IMHO what Mojang should do is make the colormap a square. As elevation increases, it samples further to the right in a straight line. Biomes wouldn't overlap, as long as the origin point have different Y values.
I've read that for the most part, JSON doesn't support comments. You CAN do comments, but you have to format like data, and then have it ignored. Example in Dinnerbone's sample:
"//comment":"All metainfo files will be ORIGINAL_FILE.mcmeta. For example, textures/blocks/portal.png.mcmeta. The format is, of course, JSON.",
So, not as easy as plopping a # at the start of the line, or a // a the beginning or /* at start and */ at end.
I know it's based on temperature getting cooler, I'm basically saying breaking that connection and allowing each biome to have an individual color map that is used based on height. I guess it could still be done with temperature if you just swapped out "height" with "local temperature", and then X was global temperature (biome ordering) and y was local temperature (temperature in that biome, elevation, still *basically* height).
I've put // comments in my mcmeta files and not had any problems with them. Haven't tried the multiline ones though. (/* */)
Oh yea, If I was going to redo it myself I'd toss out the whole temp/humdity thing and just have it strictly based on height and an arbitrary random 'wobble'. Re-orient the map so that the lowest elevation is at the bottom, each biome gets it's own location along the X axis and have the 'wobble' noise map shift the point +- on the X. Then put all of the biome starting positions into the mcmeta file. I never liked the fact that Notch over-complicated the mapping by trying to make it 'realistic' rather than just keeping it simple and picking a color gradient that gave the same result.
Rollback Post to RevisionRollBack
Tis far better to be a witty fool than a foolish wit.
I've been testing the colors today and I found out that the roofed forest does, in fact, OVERLAY its own separate color onto the grass. It doesn't totally ignore the color map like the mesa and swamp do. Btw, my colormap has 0 green on it.
It's a lot more subtle than the swamp and mesa biomes, but I guess the overlay is there to simulate a darker forest floor.
What program are you using that just lets you "plop down" a gradient with multiple stops in the shape you want just like that? It would be useful to know as I screw around with biome colors.
And on a related note, maybe someone could help me with this problem I'm having? My resource pack crashes the game every time I look at a savanna biome.Found the problem, terrain.png was one pixel too short. Interesting bug though, because the game worked fine until I looked at the biome. Seems like it could be exploited in some way for an adventure map or something. Keep up the good work guys!Also, I made my gradient using Photoshop and a large, soft brush.
Good point. Thanks!
Most programs have a gradient tool that lets you slect two colors (or more) and just click and drag from two points places it in that area, auto mixing the colors.
Or you can use a brush with a soft edge and make your own.
I would go through what you have already and eyedrop some colors from good spots, colors that would fit well with each biome then use the pierces spots for the colors and the new 'temp lines'. I bet it would look so mice more diverse! Plus you could have some 'temps' be that rusty hue you'd like!
The pinpoint Pixel for the default biome is the base color, purly shown at height 62 and below, the rest takes color from the 'temp line'. the colors pick wobble a bit, so you could have one side of the line a more rusty hue, and the other a more cooler metal and it'll show a nice devercity! EXPEREMENT!
I guess you are right, it multiplies a light green-grey to the colormap. I couldn't tell before because my grass block has a very similar tint before adding the colormap.
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
The lighting engine should take care of that. Besides there's no guarantee it will stay shaded. You can chop down the trees.
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
Yeah, that or, I don't know, THE BIOME COLOR MAP?
Why should there be ANY color overlays when we have a whole 256x256 image dedicated to just biome colors? With 256x256, doing around what, 12-32 different biomes with no derivatives or overlays shouldn't be an issue. I think this is just proving that biome coloring is still in major need of an overhaul.
I might be crazy for saying it, but I think using an MCMETA (caps for emphasis) file to do biomes might be better for biome colors! .....err, provided we get one of those doohickeys someone at Mojang always makes to convert things, this time you input a color map and it outputs an .mcmeta file with all of the biomes and comments to-OH WAIT, I FORGOT, MCMETA FILES DON'T HAVE COMMENTS
Moving on, basically define biome colors with hex color codes, define a min and max color (with medians sort of like doing a gradient?) values (with custom block values defined, if lower/higher, just keeps the last value), random colors with frequency/attraction/attenuation. Transitions (as well as biomes that use derivatives now) could also be defined, but otherwise they would behave like they do now.
"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
Um, some of us can deal with both worlds, but i dare say the vast majority of decent pack artists are much more comfortable messing with a colormap than typing in hex codes.
Unfortunately Jeb and Dinnerbone are more comfortable typing in hex values and thus we get this hardcoded stuff.
IMHO what Mojang should do is make the colormap a square. As elevation increases, it samples further to the right in a straight line. Biomes wouldn't overlap, as long as the origin point have different Y values.
Or each biome could get an 256 x 8 pix color map. 8 pixels of color randomly chosen for any of the 256 elevation levels. More files, but each one straight-forward.
• Follow Lithos on Twitter for release announcments
* Join the Lithos Discord for previews and to help
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'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
oh, I meant foliage and grass pngs. oops.
And thanks for the help about the gradients, I figured it out and produced something that I think turned out well (or at least will with some refinement).
Voted and added some images from my Mooncraft pack which suffers horribly from the hard coded colors.
I don't think they really think outside the box much when it comes to the art. Doesn't seem to occur to them that grass isn't always green.
Yea putting ALL of the currently hard coded colors into the pack.mcmeta would be the obvious answer I think. Dunno why mojang never put any comments in the file since it supports having them just fine. (It's javascript basically.)
In regards to the color shifting with height. I don't think it's directly using height. I think what is happening is that the temperature now gets colder with elevation and it's still just using the old temp/wetness lookup. (I also suspect the shifting around of the color is due to humidity variations within a biome but I've not done enough poking to be entirely sure of that.) You can see the temperature change with elevation quite clearly when it's raining. Fly straight up and the rain will turn into snow. (Biomes with snow capped hills are the best for seeing this in action.)
I've read that for the most part, JSON doesn't support comments. You CAN do comments, but you have to format like data, and then have it ignored. Example in Dinnerbone's sample:
"//comment":"All metainfo files will be ORIGINAL_FILE.mcmeta. For example, textures/blocks/portal.png.mcmeta. The format is, of course, JSON.",
So, not as easy as plopping a # at the start of the line, or a // a the beginning or /* at start and */ at end.
I know it's based on temperature getting cooler, I'm basically saying breaking that connection and allowing each biome to have an individual color map that is used based on height. I guess it could still be done with temperature if you just swapped out "height" with "local temperature", and then X was global temperature (biome ordering) and y was local temperature (temperature in that biome, elevation, still *basically* height).
"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
Excellent idea. Like this?
Oh yea, If I was going to redo it myself I'd toss out the whole temp/humdity thing and just have it strictly based on height and an arbitrary random 'wobble'. Re-orient the map so that the lowest elevation is at the bottom, each biome gets it's own location along the X axis and have the 'wobble' noise map shift the point +- on the X. Then put all of the biome starting positions into the mcmeta file. I never liked the fact that Notch over-complicated the mapping by trying to make it 'realistic' rather than just keeping it simple and picking a color gradient that gave the same result.