Crafted from a normal redstone lamp and any dye, this would make the lamp and produced light the color of the dye. I think it would help with redstone systems, as part identifiers, for one thing.
Crafted from a normal redstone lamp and any dye, this would make the lamp and produced light the color of the dye. I think it would help with redstone systems, as part identifiers, for one thing.
Not possible with the current system.
The way that the current system works is explained is essentially like this. Blocks have two values, a light value and a light opacity the value, the light value is how much light the given block emits and the light opacity value is how much like the block, well, blocks, or "absorbs" as light passes through it. Air has a light value of 0 and a light opacity of 1, meaning it emits no light but deducts 1 from the light intensity at that given point. Light passes itself around to adjacent blocks if the existing light intensity is less than the potential new one. So glowstone emits a light value of 15 to it's neighbouring blocks, at which point the neighbouring blocks subtract their respective opacity values and those block's light intensity is set to the outcome. Apply this to a system globally and you have a basic light propagation system. A similar method is used for sky lighting, or light the sky emits, but rather than blocks emitting it, the sky does. Sky lighting is stored as it's own value in the block.
Then, these values are combined into a 32-bit signed integer value, where the upper 16 bits represent the sky lighting value multiplied by 16, and the lower 16 bits represent the block lighting value multiplied by 16, so where 's' equals sky and 'b' equals block, it's basically "ssssssssssssssssbbbbbbbbbbbbbbbb". Lighting information is bounced around the renderer in this fashion, called the "mixed brightness value". Coming from this "mixed brightness value", the renderer (specifically the Tessellator) then uses the block and sky lighting values and uses them as 16-bit UV coordinates. When the game renders a given block side, the game goes to a special texture called the light map (see the Light Map spoiler for the image) and uses the two coordinates given (block and sky lighting values) as look-up coordinates to dictate the colour of light. The brightness of both the light coming from blocks and the light coming from the sky control the colour of said light. And here lies the problem.
Because the colour of light is directly tied to the light intensity of both block and sky lighting, you can't have a system like you're describing work. Mojang could do this if the colour was controlled in code rather than a texture, but the problem is it's a texture so you won't get a proper representation of the colour light the block is supposed to be emitting. If a given block is meant to emit pure red light (so the RGB colours are red = 1.0, green = 0.0, blue = 0.0), you'd only ever see that pure red light during the day time when the lighting values return white from the light map. Otherwise, you're multiplying two different colours together meaning you will be getting a completely different colour than you expect. To add this, Mojang would need to completely redesign the lighting system and do away with how it currently works, which is a feat in itself when the code for lighting is so encrusted into the game that it'd break virtually everything.
Because of this, no support. It'd break way too much for just coloured light, Mojang would be better off investing in standardised lighting solutions that games and game engines already use, which provides dynamic shadowing along with coloured light, and point lighting where even the torch in your hand or that zombie on fire can emit light. The problem is these methods typically are GPU-bound, which means they'd have to think up a clever but hacky solution to tie mob spawning to light again.
Rollback Post to RevisionRollBack
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
As much as I'd love colored lighting... *points to post #2* Though I do support the different lamps.
Rollback Post to RevisionRollBack
Yeah, that guy in the avatar is me. I'm *that* strange. It happens. Sometimes people act like that. Just go with it. I can offer help with suggestions even before you post them - NOT make your suggestions - but help you with them.
Personally, I think colored light is well worth the effort even though it would indeed require a significant redesign.
Even without coloured light a refactor and redesign of how lighting works would be well worth it. Point-based, per-pixel, dynamic shadows using cascading shadow maps (configurable), potentially accurate inverse square falloff (or just linear attenuation if they wanted), much better performance, directional lighting. All these are incredible upsides even without coloured light. Modern shaders give Mojang the ability to do this, the question is will they. Coloured light can go on the CPU similar to how light works now, but I'd much rather shader-based lighting.
Rollback Post to RevisionRollBack
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
I'm fully up for this, aesthetic-wise. But as jcm2606 stated, this would be impossible, at least without causing major lag. Sadly, No Support.
Lag wouldn't be the limiting factor, the inability to actually accurately colour the light while retaining the intended colour is the main limiting factor. Mojang could in all likelihood just add a new bit of data (bit as in piece, not binary digit) that represents a given block's lighting RGB value and multiply the light map result by that then multiply the block's texture by the outcome, voila, simple coloured light and I'm fairly certain there's no game-breaking lag, but it's inaccurate, by my calculations wouldn't blend (so red and blue would not result in purple where the lights overlap, I don't think at least, whatever is the most intense at a given block wins, you could change it to instead multiply the colours together to blend them, but still), and as I said, the light map would pollute the RGB value and give an inaccurate colour. You'd only see the desired colour when the light map returns pure white, or 1.0 across all three channels. Otherwise it's the light map RGB value multiplied by the colour, so if the light map returns say (1.0, 0.5, 0) and your light has a colour of (0.0, 1.0, 1.0) (so cyan), the outcome would effectively be (0.0, 0.5, 0.0) because 0*1=0, 1*0.5=0.5, 1*0=0. That's the problem.
Where is everyone getting lag from? This wouldn't cause game-breaking lag any more than the current lighting system does, just that instead it takes up a bit more room on disk and bounces more data around the game's innards. In theory at least, but still, I'm fairly certain this would barely result in 1 FPS drop.
Rollback Post to RevisionRollBack
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
Crafted from a normal redstone lamp and any dye, this would make the lamp and produced light the color of the dye. I think it would help with redstone systems, as part identifiers, for one thing.
ERROR unknown file type
Not possible with the current system.
The way that the current system works is explained is essentially like this. Blocks have two values, a light value and a light opacity the value, the light value is how much light the given block emits and the light opacity value is how much like the block, well, blocks, or "absorbs" as light passes through it. Air has a light value of 0 and a light opacity of 1, meaning it emits no light but deducts 1 from the light intensity at that given point. Light passes itself around to adjacent blocks if the existing light intensity is less than the potential new one. So glowstone emits a light value of 15 to it's neighbouring blocks, at which point the neighbouring blocks subtract their respective opacity values and those block's light intensity is set to the outcome. Apply this to a system globally and you have a basic light propagation system. A similar method is used for sky lighting, or light the sky emits, but rather than blocks emitting it, the sky does. Sky lighting is stored as it's own value in the block.
Then, these values are combined into a 32-bit signed integer value, where the upper 16 bits represent the sky lighting value multiplied by 16, and the lower 16 bits represent the block lighting value multiplied by 16, so where 's' equals sky and 'b' equals block, it's basically "ssssssssssssssssbbbbbbbbbbbbbbbb". Lighting information is bounced around the renderer in this fashion, called the "mixed brightness value". Coming from this "mixed brightness value", the renderer (specifically the Tessellator) then uses the block and sky lighting values and uses them as 16-bit UV coordinates. When the game renders a given block side, the game goes to a special texture called the light map (see the Light Map spoiler for the image) and uses the two coordinates given (block and sky lighting values) as look-up coordinates to dictate the colour of light. The brightness of both the light coming from blocks and the light coming from the sky control the colour of said light. And here lies the problem.
Because the colour of light is directly tied to the light intensity of both block and sky lighting, you can't have a system like you're describing work. Mojang could do this if the colour was controlled in code rather than a texture, but the problem is it's a texture so you won't get a proper representation of the colour light the block is supposed to be emitting. If a given block is meant to emit pure red light (so the RGB colours are red = 1.0, green = 0.0, blue = 0.0), you'd only ever see that pure red light during the day time when the lighting values return white from the light map. Otherwise, you're multiplying two different colours together meaning you will be getting a completely different colour than you expect. To add this, Mojang would need to completely redesign the lighting system and do away with how it currently works, which is a feat in itself when the code for lighting is so encrusted into the game that it'd break virtually everything.
Because of this, no support. It'd break way too much for just coloured light, Mojang would be better off investing in standardised lighting solutions that games and game engines already use, which provides dynamic shadowing along with coloured light, and point lighting where even the torch in your hand or that zombie on fire can emit light. The problem is these methods typically are GPU-bound, which means they'd have to think up a clever but hacky solution to tie mob spawning to light again.
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!
Well your not explaining why this is needed in minecraft but I think colored lamps will be cool.
As much as I'd love colored lighting... *points to post #2* Though I do support the different lamps.
Yeah, that guy in the avatar is me. I'm *that* strange. It happens. Sometimes people act like that. Just go with it. I can offer help with suggestions even before you post them - NOT make your suggestions - but help you with them.
Unofficial Suggestions Guide (2.0) - by Theriasis
Unofficial Critics Guide - by yoshi9048
Personally, I think colored light is well worth the effort even though it would indeed require a significant redesign.
Even without coloured light a refactor and redesign of how lighting works would be well worth it. Point-based, per-pixel, dynamic shadows using cascading shadow maps (configurable), potentially accurate inverse square falloff (or just linear attenuation if they wanted), much better performance, directional lighting. All these are incredible upsides even without coloured light. Modern shaders give Mojang the ability to do this, the question is will they. Coloured light can go on the CPU similar to how light works now, but I'd much rather shader-based lighting.
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!
I'm fully up for this, aesthetic-wise. But as jcm2606 stated, this would be impossible, at least without causing major lag. Sadly, No Support.
Lag wouldn't be the limiting factor, the inability to actually accurately colour the light while retaining the intended colour is the main limiting factor. Mojang could in all likelihood just add a new bit of data (bit as in piece, not binary digit) that represents a given block's lighting RGB value and multiply the light map result by that then multiply the block's texture by the outcome, voila, simple coloured light and I'm fairly certain there's no game-breaking lag, but it's inaccurate, by my calculations wouldn't blend (so red and blue would not result in purple where the lights overlap, I don't think at least, whatever is the most intense at a given block wins, you could change it to instead multiply the colours together to blend them, but still), and as I said, the light map would pollute the RGB value and give an inaccurate colour. You'd only see the desired colour when the light map returns pure white, or 1.0 across all three channels. Otherwise it's the light map RGB value multiplied by the colour, so if the light map returns say (1.0, 0.5, 0) and your light has a colour of (0.0, 1.0, 1.0) (so cyan), the outcome would effectively be (0.0, 0.5, 0.0) because 0*1=0, 1*0.5=0.5, 1*0=0. That's the problem.
Where is everyone getting lag from? This wouldn't cause game-breaking lag any more than the current lighting system does, just that instead it takes up a bit more room on disk and bounces more data around the game's innards. In theory at least, but still, I'm fairly certain this would barely result in 1 FPS drop.
Author of the Clarity, Serenity, Sapphire & Halcyon shader packs for Minecraft: Java Edition.
My Github page.
The entire Minecraft shader development community now has its own Discord server! Feel free to join and chat with all the developers!