Will you please stop posting this mod here? Not only did we hear you the first time, but it's completely different: instead of adding colored glass that allows for colored lights, it just has colored lights.
I don't know what mod that guy refers to that keeps annoying you, but the idea to color light by passing it through colored glass is ridiculous. As bad as the overhead involved in colored glass and good transparancy is, colored light in general would be worse. But adding the additional requirement that light moving through a colored glass block changes the color of the light would really be the last nail in the coffin. Would you ray trace light from each torch through to every block it lights, look for intersections with colored glass, then do the color calculations? I suppose you could try and speed it up by limiting the radius to the 16 blocks around the torch, then searching that space for colored glass blocks, then only ray tracing through those blocks. However, if you built a wall of colored glass in front of a wall of torches, you still have a ton of calculations to perform. If you want to combine colored glass blocks to further control the color of the light, you'd need to an additional layer of ray tracing from each glass block to all the glass blocks around it, making the problem exponential.
These calculations could be server side or client side, but either way would cause serious reductions in FPS. The colored light data would most likely have to be stored in the map files, and if you want 256 shades each of red, green, and blue, that's 3 bytes (24 bits) per block on top of the 2 bits per block already used to determine light level (I suppose you could store intensity in the 3 bytes for color, since I can't imagine you'd have intense black light, darker colors would mean lower light levels, but you're still talking 24 bits for light instead of 2)
Calculating light levels server side would allow griefers to lag down servers with tons of torches and colored glass, and slow down chunk loading for players because of the increased memory per block. You could prevent this by doing lighting calculations client side, because you'd only have to tell the client that torches and colored glass exists, but the client would have to do the same lighting calculations, and wouldn't be able to store the data once calculated, it would have to calculate it every time the client loads the chunk or updates a block (at a minimum) where if the server did it it would need to calculate light on block updates, which probably doesn't improve much ( I have nightmares of giant colored glass and torch machines with pistons on fast clocks opening and closing windows and melting my server's CPU )
As fun as colered glass would be, the sheer amount of work it would take to implement renders it completly pointless. Almost every modder who has ever tried this has given up after a few updates because of the amount of time it takes. You also have the FPS problem, the amount of calculations it would take would melt the average minecraft players computer. I'm currently getting 30-40 FPS currently and with this change I would almost certaintly drop to 15-20. You're basically asking mojang to spend months implementing something that around forty-percent of minecraft users would have to turn off anyway.
Rollback Post to RevisionRollBack
Warning: reading the above post has been known to cause the following side effects: Uncontrollable rage, urge to smash your computer, screaming like an angry gorilla, desire to hire a gang of monkeys to hurl banana peels at Jdman1699.
As fun as colered glass would be, the sheer amount of work it would take to implement renders it completly pointless. Almost every modder who has ever tried this has given up after a few updates because of the amount of time it takes. You also have the FPS problem, the amount of calculations it would take would melt the average minecraft players computer. I'm currently getting 30-40 FPS currently and with this change I would almost certaintly drop to 15-20. You're basically asking mojang to spend months implementing something that around forty-percent of minecraft users would have to turn off anyway.
First issue: What? I mean, what are you even going on about here? It has already been implemented once, in the fake-update. Maybe the colored light MAY cause lag, yet you decide to hate on the EASY part of the suggestion.
Secondly: This thread would not have survived thus far if this would have been a well acknowledged issue. How can you say for sure it would lag so much? The fake-update didn't lag more than any other update, and if you get such framedrops why not try out optifine? It's a great way to enhance your comp-performance?
First issue: What? I mean, what are you even going on about here? It has already been implemented once, in the fake-update. Maybe the colored light MAY cause lag, yet you decide to hate on the EASY part of the suggestion.
Secondly: This thread would not have survived thus far if this would have been a well acknowledged issue. How can you say for sure it would lag so much? The fake-update didn't lag more than any other update, and if you get such framedrops why not try out optifine? It's a great way to enhance your comp-performance?
It is a well known issue. Anyone who has ever done 3D graphics programming knows that transparency is a complicated problem. Look up Z buffers. In order to do transparency the z buffer must keep track of more pixels and sort those pixels by depth. The more layers of transparent pixels you have means the z buffer must do more work. While there are tricks to simplify this and get a few layers of transparency with relatively little impact on performance, minecraft is a game where the terrain is totally customizable and you can circumvent the tricks by placing many many layers of colored glass. More advanced methods such as order independent transparency can solve some the speed problems, but most players graphics cards can't do that yet.
In summary: Colored glass is not impossible, but impractible. To do it right would require major changes to minecraft's graphics pipeline which would harm performance for most of the playerbase, and probably keep many people from playing because they have weaker graphics cards. Mojang does not like to do that, it took them until the new 1.6 update to move to new JLWGE because it means that powerPC users can no longer play, even though most players will see improved FPS and controls. It's simply not worth the work needed to properly implement such a minor feature that would harm many aspects of the game. You could always implement the cheap and easy colored glass and get crappy looking transparency problems.
While there are tricks to simplify this and get a few layers of transparency with relatively little impact on performance, minecraft is a game where the terrain is totally customizable and you can circumvent the tricks by placing many many layers of colored glass.
The view would probably be totally opaque after just a few layers. No need to calculate beyond that.
In summary: Colored glass is not impossible, but impractible. To do it right would require major changes to minecraft's graphics pipeline which would harm performance for most of the playerbase, and probably keep many people from playing because they have weaker graphics cards. Mojang does not like to do that, it took them until the new 1.6 update to move to new JLWGE because it means that powerPC users can no longer play, even though most players will see improved FPS and controls. It's simply not worth the work needed to properly implement such a minor feature that would harm many aspects of the game. You could always implement the cheap and easy colored glass and get crappy looking transparency problems.
Dinnerbone has said that transparency needs an overhaul, which is the only actual issue with this. However, it would not cause such a dramatic drop in FPS, the main issue is just getting it to work properly.
I think you're just overestimating performance issues and underestimating the power of player CPUs.
Also, PowerPC is considered obsolete anyway, it's not even supported by Apple anymore, so Mojang is at least predicting that the change will affect a small minority of the fanbase.
Assuming the kinks in the transparency rendering could be fixed, this would provide an enormous benefit to a great deal of mapmakers. It would most certainly be worth the coding.
Rollback Post to RevisionRollBack
[quote=Badgerz]You have to keep in mind that people are stupid.
[quote=Catelite]Just because you don't understand how something works, doesn't make it broken or pointless. >_<
The view would probably be totally opaque after just a few layers. No need to calculate beyond that.
Lets say we stop it at 5 blocks deep. Then lets say we have a griefer who takes advantage of this and builds this:
The orange dot in the middle is a torch, the squares around are colored glass blocks. The red dot is a glass block immediatly exposed to the torch. The blue dots are the paths traced out from the red, the green are from the blue. That one block that get's lit up by the torch affects at least the 37 blocks I show here. You'll notice that some blocks are hit more than once, I didn't draw all the interactions, but my guess is that some blocks will be hit many times, each hit is another light calculation. I only considered 1 of the 8 glass blocks around the torch, but each of those blocks will have its own tree of calculations. And the exterior blocks will be affected by light on the outside of the of the box coming in. And this diagram is only 1 layer thick, in reality, this would be built as a cube, greatly increasing the number of interactions. These interactions remind me of leaf decay, and I remember when notch tried to "improve" leaf decay a couple years ago and it got so slow that my laptop couldn't run minecraft until it got fixed, it didn't crash, it just slowed to a stop once I got near a forest. And leaf decay didn't have a light calculation at every step. You could alleviate some of the calculation problems by reducing the limit from 5 to 4 or 3 or 2 layers, but then you're almost at opaque glass and what's the point? (opaque glass would be fine for the Z buffer by the way, so I might like that)
First issue: What? I mean, what are you even going on about here? It has already been implemented once, in the fake-update. Maybe the colored light MAY cause lag, yet you decide to hate on the EASY part of the suggestion.
Secondly: This thread would not have survived thus far if this would have been a well acknowledged issue. How can you say for sure it would lag so much? The fake-update didn't lag more than any other update, and if you get such framedrops why not try out optifine? It's a great way to enhance your comp-performance?
Optifine shouldn't be mandatory just to play the game
I should start using that ;3
~Epic Space Milk Muffin
Hello.
I don't know what mod that guy refers to that keeps annoying you, but the idea to color light by passing it through colored glass is ridiculous. As bad as the overhead involved in colored glass and good transparancy is, colored light in general would be worse. But adding the additional requirement that light moving through a colored glass block changes the color of the light would really be the last nail in the coffin. Would you ray trace light from each torch through to every block it lights, look for intersections with colored glass, then do the color calculations? I suppose you could try and speed it up by limiting the radius to the 16 blocks around the torch, then searching that space for colored glass blocks, then only ray tracing through those blocks. However, if you built a wall of colored glass in front of a wall of torches, you still have a ton of calculations to perform. If you want to combine colored glass blocks to further control the color of the light, you'd need to an additional layer of ray tracing from each glass block to all the glass blocks around it, making the problem exponential.
These calculations could be server side or client side, but either way would cause serious reductions in FPS. The colored light data would most likely have to be stored in the map files, and if you want 256 shades each of red, green, and blue, that's 3 bytes (24 bits) per block on top of the 2 bits per block already used to determine light level (I suppose you could store intensity in the 3 bytes for color, since I can't imagine you'd have intense black light, darker colors would mean lower light levels, but you're still talking 24 bits for light instead of 2)
Calculating light levels server side would allow griefers to lag down servers with tons of torches and colored glass, and slow down chunk loading for players because of the increased memory per block. You could prevent this by doing lighting calculations client side, because you'd only have to tell the client that torches and colored glass exists, but the client would have to do the same lighting calculations, and wouldn't be able to store the data once calculated, it would have to calculate it every time the client loads the chunk or updates a block (at a minimum) where if the server did it it would need to calculate light on block updates, which probably doesn't improve much ( I have nightmares of giant colored glass and torch machines with pistons on fast clocks opening and closing windows and melting my server's CPU )
yeah, it's a good term
Secondly: This thread would not have survived thus far if this would have been a well acknowledged issue. How can you say for sure it would lag so much? The fake-update didn't lag more than any other update, and if you get such framedrops why not try out optifine? It's a great way to enhance your comp-performance?
It is a well known issue. Anyone who has ever done 3D graphics programming knows that transparency is a complicated problem. Look up Z buffers. In order to do transparency the z buffer must keep track of more pixels and sort those pixels by depth. The more layers of transparent pixels you have means the z buffer must do more work. While there are tricks to simplify this and get a few layers of transparency with relatively little impact on performance, minecraft is a game where the terrain is totally customizable and you can circumvent the tricks by placing many many layers of colored glass. More advanced methods such as order independent transparency can solve some the speed problems, but most players graphics cards can't do that yet.
In summary: Colored glass is not impossible, but impractible. To do it right would require major changes to minecraft's graphics pipeline which would harm performance for most of the playerbase, and probably keep many people from playing because they have weaker graphics cards. Mojang does not like to do that, it took them until the new 1.6 update to move to new JLWGE because it means that powerPC users can no longer play, even though most players will see improved FPS and controls. It's simply not worth the work needed to properly implement such a minor feature that would harm many aspects of the game. You could always implement the cheap and easy colored glass and get crappy looking transparency problems.
Mostly moved on. May check back a few times a year.
Agreed.
Dinnerbone has said that transparency needs an overhaul, which is the only actual issue with this. However, it would not cause such a dramatic drop in FPS, the main issue is just getting it to work properly.
I think you're just overestimating performance issues and underestimating the power of player CPUs.
Also, PowerPC is considered obsolete anyway, it's not even supported by Apple anymore, so Mojang is at least predicting that the change will affect a small minority of the fanbase.
Assuming the kinks in the transparency rendering could be fixed, this would provide an enormous benefit to a great deal of mapmakers. It would most certainly be worth the coding.
[quote=Badgerz]You have to keep in mind that people are stupid.
[quote=Catelite]Just because you don't understand how something works, doesn't make it broken or pointless. >_<
Lets say we stop it at 5 blocks deep. Then lets say we have a griefer who takes advantage of this and builds this:
The orange dot in the middle is a torch, the squares around are colored glass blocks. The red dot is a glass block immediatly exposed to the torch. The blue dots are the paths traced out from the red, the green are from the blue. That one block that get's lit up by the torch affects at least the 37 blocks I show here. You'll notice that some blocks are hit more than once, I didn't draw all the interactions, but my guess is that some blocks will be hit many times, each hit is another light calculation. I only considered 1 of the 8 glass blocks around the torch, but each of those blocks will have its own tree of calculations. And the exterior blocks will be affected by light on the outside of the of the box coming in. And this diagram is only 1 layer thick, in reality, this would be built as a cube, greatly increasing the number of interactions. These interactions remind me of leaf decay, and I remember when notch tried to "improve" leaf decay a couple years ago and it got so slow that my laptop couldn't run minecraft until it got fixed, it didn't crash, it just slowed to a stop once I got near a forest. And leaf decay didn't have a light calculation at every step. You could alleviate some of the calculation problems by reducing the limit from 5 to 4 or 3 or 2 layers, but then you're almost at opaque glass and what's the point? (opaque glass would be fine for the Z buffer by the way, so I might like that)
Mostly moved on. May check back a few times a year.
Optifine shouldn't be mandatory just to play the game