Hi what if paint was available in minecraft. So instead of having the same old wood you can have a different color of wood. This way you dont have to use clay or wool if you dont want to. So i was thinking that it could be made in a cauldron with water and a dye and melted slime. Melted slime could be made in a furnace. Then you can scoop the new paint out of the cauldron with a bucket. If you dump it it will spread somewhat like water it will spread 3 blocks to the side and it will go down any number of blocks until it touches the ground. The paint will not appear on the ground. I also thought that this would be fun if you want to paint a flower pot or something like it. Or if you want to make your own murals on your house whether it be stripes or something else.
Paint Is FPS The Idea Was Tossed Around A Few Years Back But I Would Like It For Art/Graffiti ? Partial Support
As for the paint idea itself, I like the idea of paint. However, the way to paint here, by "splashing", basically limiting the player to paint only floors not walls and ceilings, that seems very unwieldly and imprecise. I'd rather have a real paintbrush tool or something.
Also, there are in-game considerations. The number of available block IDs is very limited and Mojang is near the upper limit of the base 256 block IDs available before reaching into "mod range" block IDs territory. There are only a handful of IDs left. A rehaul of the block ID system itself would be needed first. And there are currently only 4 bits for storing a block's data value. So how would you allow the 3-D world matrix to "store" the paint data on the block? Metadata can go over that 4 bits limitation, but that means using block entities instead of normal blocks. Which is hundreds (if not thousands) times slower than "plain" normal blocks, performance wise.
The only solution I see is changing the Chunk format (breaking backwards compatibility -- ouch!) so that normal blocks get more than 4 bits of data. Even then, I'd go with only 16 colors of paint, not the full leather-dye range. That would allow the 4 bits of block data to be extended by needing another 4 bits only instead of a lot more bits to store a full RGB value.
This would still definitely reduce performance tough: the more data that has to be moved around and processed, the slower the game. That really can't be avoided. Currently the Chunk format holds 24 bits per block. It could be reasonable to extend this to 32 bits instead (aligning on 4 bytes allows to keep some level of optimization which wouldn't exist as well with 28 bits -- basic CPU stuff here even if modern processors have less trouble with that aspect than before, aligning data to power-of-two bit boundaries remains a good idea to help cache hit efficiency and stuff like that). This means that Anvil region files would become 33% bigger on your drive (which means time spent on more file access overhead), also RAM used for the game also would similarly jump by nearly 33% (since most of the RAM is used to store loaded chunks), and CPU usage would be at least jumping by that much too. Then for the textures you'd have to have either applying a local-per-block-extra-step-of-shading (sloooow) or make almost *ALL* paintable textures now exist in at least 17 different textures instead (gah take some pity on texture pack makers!). And now you'd have different wood types looking almost exactly the same because they were painted in similar colors. Lots of work to get a quite redundant result anyway.
I have a nice PC, and I find that this game already slow enough as it is. So I'd rather have no paint at all, instead of greatly worsening the performance we have now for a single minor feature.
And if using block entities, a single player on a server paints his house that way and suddenly it would laaaag nearly as bad as if you filled a cow farm with 500 cows. Never, EVER turn any "building block" into a block entity for that very reason. Things go into big number really fast hwne making builds. Only for simple 1-thick straight walls and floors and ceiling, a simple two stories 20x20x10 house requires nearly *2000* blocks to build! Basically, don't even thunk about using block entities here. It has to be normal blocks. And planks ALREADY use 3 of the 4 block data value bits for the 6 wood types all sharing the same block ID.
So, yeah, nice idea, but, basically this: can you say laaaaaag? So, unfortunately, no support.
IMHO paint is't really needed. Personally, I'd rather we get new types of trees added instead, a la Biomes O Plenty mod, in order to get more colors for wood. That would boost the color choices wooden builds options AND make the world itself more interesting to explore. Same for stone builds: the game can simply add new types of differently colored stones, a la Underground Biomes Constructs mod. And the remaining main building blocks (wool, clay, glass) already exist in 16 colors.
Dyed water = good. However, once you right click a cauldron with dye and it colors the water, you should scoop it up with water bottles, and then right click blocks to color them. There should only be 8 colors; Blue, Red, Yellow, Green, Orange, Purple, Turquoise, and Brown. Unless I missed something
As for the paint idea itself, I like the idea of paint. However, the way to paint here, by "splashing", basically limiting the player to paint only floors not walls and ceilings, that seems very unwieldly and imprecise. I'd rather have a real paintbrush tool or something.
Also, there are in-game considerations. The number of available block IDs is very limited and Mojang is near the upper limit of the base 256 block IDs available before reaching into "mod range" block IDs territory. There are only a handful of IDs left. A rehaul of the block ID system itself would be needed first. And there are currently only 4 bits for storing a block's data value. So how would you allow the 3-D world matrix to "store" the paint data on the block? Metadata can go over that 4 bits limitation, but that means using block entities instead of normal blocks. Which is hundreds (if not thousands) times slower than "plain" normal blocks, performance wise.
The only solution I see is changing the Chunk format (breaking backwards compatibility -- ouch!) so that normal blocks get more than 4 bits of data. Even then, I'd go with only 16 colors of paint, not the full leather-dye range. That would allow the 4 bits of block data to be extended by needing another 4 bits only instead of a lot more bits to store a full RGB value.
This would still definitely reduce performance tough: the more data that has to be moved around and processed, the slower the game. That really can't be avoided. Currently the Chunk format holds 24 bits per block. It could be reasonable to extend this to 32 bits instead (aligning on 4 bytes allows to keep some level of optimization which wouldn't exist as well with 28 bits -- basic CPU stuff here even if modern processors have less trouble with that aspect than before, aligning data to power-of-two bit boundaries remains a good idea to help cache hit efficiency and stuff like that). This means that Anvil region files would become 33% bigger on your drive (which means time spent on more file access overhead), also RAM used for the game also would similarly jump by nearly 33% (since most of the RAM is used to store loaded chunks), and CPU usage would be at least jumping by that much too. Then for the textures you'd have to have either applying a local-per-block-extra-step-of-shading (sloooow) or make almost *ALL* paintable textures now exist in at least 17 different textures instead (gah take some pity on texture pack makers!). And now you'd have different wood types looking almost exactly the same because they were painted in similar colors. Lots of work to get a quite redundant result anyway.
I have a nice PC, and I find that this game already slow enough as it is. So I'd rather have no paint at all, instead of greatly worsening the performance we have now for a single minor feature.
And if using block entities, a single player on a server paints his house that way and suddenly it would laaaag nearly as bad as if you filled a cow farm with 500 cows. Never, EVER turn any "building block" into a block entity for that very reason. Things go into big number really fast hwne making builds. Only for simple 1-thick straight walls and floors and ceiling, a simple two stories 20x20x10 house requires nearly *2000* blocks to build! Basically, don't even thunk about using block entities here. It has to be normal blocks. And planks ALREADY use 3 of the 4 block data value bits for the 6 wood types all sharing the same block ID.
So, yeah, nice idea, but, basically this: can you say laaaaaag? So, unfortunately, no support.
IMHO paint is't really needed. Personally, I'd rather we get new types of trees added instead, a la Biomes O Plenty mod, in order to get more colors for wood. That would boost the color choices wooden builds options AND make the world itself more interesting to explore. Same for stone builds: the game can simply add new types of differently colored stones, a la Underground Biomes Constructs mod. And the remaining main building blocks (wool, clay, glass) already exist in 16 colors.
It doesn't have to be as complicated as adding a whole set of new ids or turning blocks into entities. They could add a modifier property to the block that is the tint of the texture, which corresponds to a hexadecimal color, applying the tint to the texture of that block. This circumvents the issue of block ids or the lag associated with entities. This is actually how grass/leaves/plants get their biome tints and how leather armor is colored. The textures for these objects are gray and are colored by the code.
It doesn't have to be as complicated as adding a whole set of new ids or turning blocks into entities. They could add a modifier property to the block that is the tint of the texture, which corresponds to a hexadecimal color, applying the tint to the texture of that block. This circumvents the issue of block ids or the lag associated with entities. This is actually how grass/leaves/plants get their biome tints and how leather armor is colored. The textures for these objects are gray and are colored by the code.
This would mean that all blocks would have to have default grey textures. I don't think it's worth it TBH.
I'm only an amateur programmer and I don't have intimate knowledge of the code, but from what I do know, it sounds like you are making a big deal out of some pretty small things.
As for the paint idea itself, I like the idea of paint. However, the way to paint here, by "splashing", basically limiting the player to paint only floors not walls and ceilings, that seems very unwieldly and imprecise. I'd rather have a real paintbrush tool or something.
I agree here, there's no point in adding more liquids for paint and making it difficult to use.
Also, there are in-game considerations. The number of available block IDs is very limited and Mojang is near the upper limit of the base 256 block IDs available before reaching into "mod range" block IDs territory. There are only a handful of IDs left. A rehaul of the block ID system itself would be needed first. And there are currently only 4 bits for storing a block's data value. So how would you allow the 3-D world matrix to "store" the paint data on the block? Metadata can go over that 4 bits limitation, but that means using block entities instead of normal blocks. Which is hundreds (if not thousands) times slower than "plain" normal blocks, performance wise.
The only solution I see is changing the Chunk format (breaking backwards compatibility -- ouch!) so that normal blocks get more than 4 bits of data. Even then, I'd go with only 16 colors of paint, not the full leather-dye range. That would allow the 4 bits of block data to be extended by
needing another 4 bits only instead of a lot more bits to store a full RGB value.
I don't see a problem with breaking backwards compatibility, as you already should never open a world in an older version from when you last played it to avoid corruption. I do agree with using indexed colors; while that is slower CPU-wise than using RGB colors, it will reduce file size greatly.
This would still definitely reduce performance tough: the more data that has to be moved around and processed, the slower the game. That really can't be avoided. Currently the Chunk format holds 24 bits per block. It could be reasonable to extend this to 32 bits instead (aligning on 4 bytes allows to keep some level of optimization which wouldn't exist as well with 28 bits -- basic CPU stuff here even if modern processors have less trouble with that aspect than before, aligning data to power-of-two bit boundaries remains a good idea to help cache hit efficiency and stuff like that). This means that Anvil region files would become 33% bigger on your drive (which means time spent on more file access overhead), also RAM used for the game also would similarly jump by nearly 33% (since most of the RAM is used to store loaded chunks), and CPU usage would be at least jumping by that much too. Then for the textures you'd have to have either applying a local-per-block-extra-step-of-shading (sloooow) or make almost *ALL* paintable textures now exist in at least 17 different textures instead (gah take some pity on texture pack makers!). And now you'd have different wood types looking almost exactly the same because they were painted in similar colors. Lots of work to get a quite redundant result anyway.
Larger file sizes could be a problem for some, but it's not too huge of an issue. That's more for the individual consumer to deal with than the developers (why are you playing a game if you don't have enough space on your drive to run it?). Most gamers should have enough space left over. File access speed is an issue, but I believe it's worth it. Increasing RAM isn't that big of a deal, as the game can already run on less than half a gigabyte of it, as theMasterCaver will tell you. CPU usage probably wouldn't be that big, as CPU isn't used that much for block rendering; it's used more for things like ticking and mob AI. Image tinting is also incredibly easy and is already done on hundreds of blocks at once (grass and leaves). Also, we can further optimize it by preventing the tinting code from even running if there is no paint in the chunk, thus only marginally reducing overall performance. As for whether it would be redundant; well, you can paint more than just wood.
I have a nice PC, and I find that this game already slow enough as it is. So I'd rather have no paint at all, instead of greatly worsening the performance we have now for a single minor feature.
A feature that would only minorly effect your performance if you didn't use it.
And if using block entities, a single player on a server paints his house that way and suddenly it would laaaag nearly as bad as if you filled a cow farm with 500 cows. Never, EVER turn any "building block" into a block entity for that very reason. Things go into big number really fast hwne making builds. Only for simple 1-thick straight walls and floors and ceiling, a simple two stories 20x20x10 house requires nearly *2000* blocks to build! Basically, don't even thunk about using block entities here. It has to be normal blocks. And planks ALREADY use 3 of the 4 block data value bits for the 6 wood types all sharing the same block ID.
I personally think people overestimate the performance hit that block entities produce. I once made a huge structure more than 65,000 blocks large out of furnaces and noticed a negligible fps decrease and RAM increase.
But, yeah, let's avoid unneccessarily increasing performance hit where possible.
So, yeah, nice idea, but, basically this: can you say laaaaaag? So, unfortunately, no support.
IMHO paint is't really needed. Personally, I'd rather we get new types of trees added instead, a la Biomes O Plenty mod, in order to get more colors for wood. That would boost the color choices wooden builds options AND make the world itself more interesting to explore. Same for stone builds: the game can simply add new types of differently colored stones, a la Underground Biomes Constructs mod. And the remaining main building blocks (wool, clay, glass) already exist in 16 colors.
So, you'd rather have a bunch of redundant blocks than an infinitely expandable paint system? Sure, it's easier in the short run, but in the long run, paint is the way to go.
It doesn't have to be as complicated as adding a whole set of new ids or turning blocks into entities. They could add a modifier property to the block that is the tint of the texture, which corresponds to a hexadecimal color, applying the tint to the texture of that block. This circumvents the issue of block ids or the lag associated with entities. This is actually how grass/leaves/plants get their biome tints and how leather armor is colored. The textures for these objects are gray and are colored by the code.
That is not how they did it for grass and such. Tint modifier for grass is not "contained" as block property data. It is extrapolated from the block's coordinates (which also determines which biome it falls in into and approximately how far that block coordinate is from the biome boundary). That "extrapolation trick" is also used to determine dandelions orientations and the flower-inside-block-XZ-pixel-offsets, for example. Basically, for a given XYZ coordinate, such "derived" values are "free" in terms of extra memory space required, but not free in terms of processing required (you have to extrapolate the data out of the XYZ coords values each time you load the chunk or place a new block of that type that needs such kind of derived data), and definitely not free in terms of flexibility (the block type will ALWAYS get exactly the same value of shading/orientation/offset no matter what the player does -- the only "control" he has over this is changing to an entirely different type of block).
Adding hexadecimal color tint to specific blocks based not on some secondary-value derived from coord, but on a player-based action instead, that would however require real extra data, either in the block structure or as NBT data.
From the perspective of block structure, even if you add only a choice of only 16 colors (not like leather dying which has something like 12 million possible colors), that is still +4 bits needed per block. Currently there are a total of 24 bits per block already used up in the Chunk format. So yes you'd have to adapt both the chunk and the Anvil formats anew. No way around it. While IMHO that would help open the door for tons of potentially better features and improvements for the game, with the performance of nowadays CPU, the performance hit penalty (both in terms of lag, RAM space, and file save space) would be too much, near linear with total data size i.e. scaling to 28 bits instead of 24 bits. If you want full RBG then it's adding 24 bits to an 24 bits data structure i.e. doubling the entire data management overhead. That just ain't going to happen with today's Minecraft level of "tech progress", both in terms of software (which Mojang can do something about, but only to such an extent that the central parts of the code are already quite optimized already), and, more importantly, in hardware (which has nothing to do with Mojang).
Large file size ain't a problem for mere ordinary players. It is however a big problem for servers. Their monthly costs are already high enough as they are, no need to jack that up by an extra 15% (which is what adding 4 bits to a 24 bits structure would do), just for a single uneeded and IMHO frankly a bit useless feature. The only reason we would "need" paint is because we currently really don't have a lot of "building design artistic choices" for wood colors and stone colors. In fact I agree it sometimes feel pretty limiting. Adding a few new wood types and stone types would mostly solve or at least palliate that problem without needing to "reinvent the wheel albeit at a high performance cost". The tradeoff is just not good enough here.
Adding those 4 (or whatever amount) of extra bits to the block structure would affect ALL the blocks wether players used painted blocks or not. It is important to distinguish how the '"raw 3d block data" and NBT data which are differently stored. NBT is "per special block" data. Meanwhile raw 3D-block bits are a fixed size vector for every block even empty air. The only exception is when an entire section (16x16x16 blocks) is fully empty in which case the chunk doesn't contain that section data block (a null section). Yup, add a single block of whatever high in the sky and pop a new 4096 block-data-size vector for that chunk comes out getting added in the region file. It's as simple as that.
I completely skipped over adding the extra color bits as NBT metadata instead of block data.In that case yes the data would exist only for the paintable blocks, not for the entire world, but that would mean turning a basic building block into a block entity. And that would be way worse, performance wise. Way worse. Like I said, with tile entities, the first player to build a "not-even-all-that-huge" painted house would suddenly cause any server to be brought down to its knees. Block entities are good for the "special" stuff, where there are very limited number of blocks. But they would be horrible if used for basic building blocks. Things like an entire wall of Furnaces work without causing lag because the special NBT data is NOT accessed to render the block. In fact, the "burning" furnace is a totally different block ID!
As you can see in the last video, going from over 300 FPS down to less than 150 FPS with chests. Even a relatively small painted house would top of that number of blocks. So having each planks block requiring to go check some NBT data to know which color it needs to be, that would mean the lag would be on par at least chests (which are the least laggy of the tile entities blocks). So it's just not something that should exist for basic building blocks, ever.
I'm notr making a huge deal out of this, I'm just describing in detail some simple facts. I would love to see some paint added, sure, but that just ain't in the cards right now. Anyway, you seem convinced, set so let's just agree to disagree here: you seem to think it would be a wonderful idea right now. I don't.
Hi what if paint was available in minecraft. So instead of having the same old wood you can have a different color of wood. This way you dont have to use clay or wool if you dont want to. So i was thinking that it could be made in a cauldron with water and a dye and melted slime. Melted slime could be made in a furnace. Then you can scoop the new paint out of the cauldron with a bucket. If you dump it it will spread somewhat like water it will spread 3 blocks to the side and it will go down any number of blocks until it touches the ground. The paint will not appear on the ground. I also thought that this would be fun if you want to paint a flower pot or something like it. Or if you want to make your own murals on your house whether it be stripes or something else.
I love that idea!
Moderator for the official Minecraft Discord servers (Minecraft, Dungeons, Legends, Live, Feedback)
Moderator for MoJIRA (Minecraft official bug tracker)
As for the paint idea itself, I like the idea of paint. However, the way to paint here, by "splashing", basically limiting the player to paint only floors not walls and ceilings, that seems very unwieldly and imprecise. I'd rather have a real paintbrush tool or something.
Also, there are in-game considerations. The number of available block IDs is very limited and Mojang is near the upper limit of the base 256 block IDs available before reaching into "mod range" block IDs territory. There are only a handful of IDs left. A rehaul of the block ID system itself would be needed first. And there are currently only 4 bits for storing a block's data value. So how would you allow the 3-D world matrix to "store" the paint data on the block? Metadata can go over that 4 bits limitation, but that means using block entities instead of normal blocks. Which is hundreds (if not thousands) times slower than "plain" normal blocks, performance wise.
The only solution I see is changing the Chunk format (breaking backwards compatibility -- ouch!) so that normal blocks get more than 4 bits of data. Even then, I'd go with only 16 colors of paint, not the full leather-dye range. That would allow the 4 bits of block data to be extended by needing another 4 bits only instead of a lot more bits to store a full RGB value.
This would still definitely reduce performance tough: the more data that has to be moved around and processed, the slower the game. That really can't be avoided. Currently the Chunk format holds 24 bits per block. It could be reasonable to extend this to 32 bits instead (aligning on 4 bytes allows to keep some level of optimization which wouldn't exist as well with 28 bits -- basic CPU stuff here even if modern processors have less trouble with that aspect than before, aligning data to power-of-two bit boundaries remains a good idea to help cache hit efficiency and stuff like that). This means that Anvil region files would become 33% bigger on your drive (which means time spent on more file access overhead), also RAM used for the game also would similarly jump by nearly 33% (since most of the RAM is used to store loaded chunks), and CPU usage would be at least jumping by that much too. Then for the textures you'd have to have either applying a local-per-block-extra-step-of-shading (sloooow) or make almost *ALL* paintable textures now exist in at least 17 different textures instead (gah take some pity on texture pack makers!). And now you'd have different wood types looking almost exactly the same because they were painted in similar colors. Lots of work to get a quite redundant result anyway.
I have a nice PC, and I find that this game already slow enough as it is. So I'd rather have no paint at all, instead of greatly worsening the performance we have now for a single minor feature.
And if using block entities, a single player on a server paints his house that way and suddenly it would laaaag nearly as bad as if you filled a cow farm with 500 cows. Never, EVER turn any "building block" into a block entity for that very reason. Things go into big number really fast hwne making builds. Only for simple 1-thick straight walls and floors and ceiling, a simple two stories 20x20x10 house requires nearly *2000* blocks to build! Basically, don't even thunk about using block entities here. It has to be normal blocks. And planks ALREADY use 3 of the 4 block data value bits for the 6 wood types all sharing the same block ID.
So, yeah, nice idea, but, basically this: can you say laaaaaag? So, unfortunately, no support.
IMHO paint is't really needed. Personally, I'd rather we get new types of trees added instead, a la Biomes O Plenty mod, in order to get more colors for wood. That would boost the color choices wooden builds options AND make the world itself more interesting to explore. Same for stone builds: the game can simply add new types of differently colored stones, a la Underground Biomes Constructs mod. And the remaining main building blocks (wool, clay, glass) already exist in 16 colors.
There's a paint mod, Shoot, I wish I could find the video of Captain Sparklez previewing it. It is for an older version, however
Go Cleveland Indians! 2018 WS Champs!
Follow me on my Twitter, even though I don't talk about MC all that much: Pufflefuzz
Dyed water = good. However, once you right click a cauldron with dye and it colors the water, you should scoop it up with water bottles, and then right click blocks to color them. There should only be 8 colors; Blue, Red, Yellow, Green, Orange, Purple, Turquoise, and Brown. Unless I missed something
It doesn't have to be as complicated as adding a whole set of new ids or turning blocks into entities. They could add a modifier property to the block that is the tint of the texture, which corresponds to a hexadecimal color, applying the tint to the texture of that block. This circumvents the issue of block ids or the lag associated with entities. This is actually how grass/leaves/plants get their biome tints and how leather armor is colored. The textures for these objects are gray and are colored by the code.
This would mean that all blocks would have to have default grey textures. I don't think it's worth it TBH.
I'm only an amateur programmer and I don't have intimate knowledge of the code, but from what I do know, it sounds like you are making a big deal out of some pretty small things.
I agree here, there's no point in adding more liquids for paint and making it difficult to use.
I don't see a problem with breaking backwards compatibility, as you already should never open a world in an older version from when you last played it to avoid corruption. I do agree with using indexed colors; while that is slower CPU-wise than using RGB colors, it will reduce file size greatly.
Larger file sizes could be a problem for some, but it's not too huge of an issue. That's more for the individual consumer to deal with than the developers (why are you playing a game if you don't have enough space on your drive to run it?). Most gamers should have enough space left over. File access speed is an issue, but I believe it's worth it. Increasing RAM isn't that big of a deal, as the game can already run on less than half a gigabyte of it, as theMasterCaver will tell you. CPU usage probably wouldn't be that big, as CPU isn't used that much for block rendering; it's used more for things like ticking and mob AI. Image tinting is also incredibly easy and is already done on hundreds of blocks at once (grass and leaves). Also, we can further optimize it by preventing the tinting code from even running if there is no paint in the chunk, thus only marginally reducing overall performance. As for whether it would be redundant; well, you can paint more than just wood.
A feature that would only minorly effect your performance if you didn't use it.
I personally think people overestimate the performance hit that block entities produce. I once made a huge structure more than 65,000 blocks large out of furnaces and noticed a negligible fps decrease and RAM increase.
But, yeah, let's avoid unneccessarily increasing performance hit where possible.
So, you'd rather have a bunch of redundant blocks than an infinitely expandable paint system? Sure, it's easier in the short run, but in the long run, paint is the way to go.
Want to see my suggestions? Here they are!
I am also known as GameWyrm or GameWyrm97. You can also find me at snapshotmc.com
That is not how they did it for grass and such. Tint modifier for grass is not "contained" as block property data. It is extrapolated from the block's coordinates (which also determines which biome it falls in into and approximately how far that block coordinate is from the biome boundary). That "extrapolation trick" is also used to determine dandelions orientations and the flower-inside-block-XZ-pixel-offsets, for example. Basically, for a given XYZ coordinate, such "derived" values are "free" in terms of extra memory space required, but not free in terms of processing required (you have to extrapolate the data out of the XYZ coords values each time you load the chunk or place a new block of that type that needs such kind of derived data), and definitely not free in terms of flexibility (the block type will ALWAYS get exactly the same value of shading/orientation/offset no matter what the player does -- the only "control" he has over this is changing to an entirely different type of block).
Adding hexadecimal color tint to specific blocks based not on some secondary-value derived from coord, but on a player-based action instead, that would however require real extra data, either in the block structure or as NBT data.
From the perspective of block structure, even if you add only a choice of only 16 colors (not like leather dying which has something like 12 million possible colors), that is still +4 bits needed per block. Currently there are a total of 24 bits per block already used up in the Chunk format. So yes you'd have to adapt both the chunk and the Anvil formats anew. No way around it. While IMHO that would help open the door for tons of potentially better features and improvements for the game, with the performance of nowadays CPU, the performance hit penalty (both in terms of lag, RAM space, and file save space) would be too much, near linear with total data size i.e. scaling to 28 bits instead of 24 bits. If you want full RBG then it's adding 24 bits to an 24 bits data structure i.e. doubling the entire data management overhead. That just ain't going to happen with today's Minecraft level of "tech progress", both in terms of software (which Mojang can do something about, but only to such an extent that the central parts of the code are already quite optimized already), and, more importantly, in hardware (which has nothing to do with Mojang).
Large file size ain't a problem for mere ordinary players. It is however a big problem for servers. Their monthly costs are already high enough as they are, no need to jack that up by an extra 15% (which is what adding 4 bits to a 24 bits structure would do), just for a single uneeded and IMHO frankly a bit useless feature. The only reason we would "need" paint is because we currently really don't have a lot of "building design artistic choices" for wood colors and stone colors. In fact I agree it sometimes feel pretty limiting. Adding a few new wood types and stone types would mostly solve or at least palliate that problem without needing to "reinvent the wheel albeit at a high performance cost". The tradeoff is just not good enough here.
Adding those 4 (or whatever amount) of extra bits to the block structure would affect ALL the blocks wether players used painted blocks or not. It is important to distinguish how the '"raw 3d block data" and NBT data which are differently stored. NBT is "per special block" data. Meanwhile raw 3D-block bits are a fixed size vector for every block even empty air. The only exception is when an entire section (16x16x16 blocks) is fully empty in which case the chunk doesn't contain that section data block (a null section). Yup, add a single block of whatever high in the sky and pop a new 4096 block-data-size vector for that chunk comes out getting added in the region file. It's as simple as that.
I completely skipped over adding the extra color bits as NBT metadata instead of block data.In that case yes the data would exist only for the paintable blocks, not for the entire world, but that would mean turning a basic building block into a block entity. And that would be way worse, performance wise. Way worse. Like I said, with tile entities, the first player to build a "not-even-all-that-huge" painted house would suddenly cause any server to be brought down to its knees. Block entities are good for the "special" stuff, where there are very limited number of blocks. But they would be horrible if used for basic building blocks. Things like an entire wall of Furnaces work without causing lag because the special NBT data is NOT accessed to render the block. In fact, the "burning" furnace is a totally different block ID!
http://minecraft.gamepedia.com/Chunk_format
As you can see in the last video, going from over 300 FPS down to less than 150 FPS with chests. Even a relatively small painted house would top of that number of blocks. So having each planks block requiring to go check some NBT data to know which color it needs to be, that would mean the lag would be on par at least chests (which are the least laggy of the tile entities blocks). So it's just not something that should exist for basic building blocks, ever.
I'm notr making a huge deal out of this, I'm just describing in detail some simple facts. I would love to see some paint added, sure, but that just ain't in the cards right now. Anyway, you seem convinced, set so let's just agree to disagree here: you seem to think it would be a wonderful idea right now. I don't.