I know Mojang has said they aren't adding dynamic light sources to Minecraft. But I don't care. In fact, I think Mojang should reevaluate everything on that list, but that's for other posts.
Mechanics
When you are holding a lantern in your hand, offhand or helmet slot, the air or water block that you are standing in becomes a new temporary light block that emits a light of 15. If you move a block, the light despawns and respawns. If you take the lantern out of your hand, the light block despawns.
That's pretty much it. I was previously thinking of a new helmet with a lantern built in (which, even though Mojang explicitly rejected for being too modern, would still fit the the game's style), but that would add one unnecessary item. Yes, wearing a lantern on your head is silly, but so is wearing a pumpkin on your head to not aggravate endermen, or strapping wings to your back. This is Minecraft, it doesn't have to be completely reasonable, so long as it is consistent and makes some kind of sense.
I know Mojang has said they aren't adding dynamic light sources to Minecraft. But I don't care. In fact, I think Mojang should reevaluate everything on that list, but that's for other posts.
Mechanics
When you are holding a lantern in your hand, offhand or helmet slot, the air or water block that you are standing in becomes a new temporary light block that emits a light of 15. If you move a block, the light despawns and respawns. If you take the lantern out of your hand, the light block despawns.
That's pretty much it. I was previously thinking of a new helmet with a lantern built in (which, even though Mojang explicitly rejected for being too modern, would still fit the the game's style), but that would add one unnecessary item. Yes, wearing a lantern on your head is silly, but so is wearing a pumpkin on your head to not aggravate endermen, or strapping wings to your back. This is Minecraft, it doesn't have to be completely reasonable, so long as it is consistent and makes some kind of sense.
I don't know the codes from modifications which add dynamic lightning, but i can promise you:
That is the base concept for most of them.
Mojang would have added it by now, if they wanted to.
Rollback Post to RevisionRollBack
My projects:
-are abandoned for now. I might pick 'em up in the future.
For now i'm working on a private modpack that suit's my own playstyle.
I am gonna stay in modded 1.12.2 untill my potato dies. No mercy! :Q
No, what I meant to say is that I personally had ample chance to play with dynamic lighting, and I found that it does more harm than good. I have it switched off in Optifine settings. If I am in an area that's dark enough to spawn mobs (and thus needs a torch placed), I want it clearly visible. If a carried torch always places a pool of light around me, it makes the process a lot less intuitive.
Once I stuck a glowstone block to a fast-moving slimeblock flying machine
This lagged my poor laptop so badly...
I think quickly changing light levels will cause too much lag to be worth the effort, especially after Mojang declared miner hats as too modern and unfitting.
Rollback Post to RevisionRollBack
Dwarf gamer found:
Buildings - square, not round
Materials - from rubble mound
Dark caves - lit 'n' cleaned out
Settlements - deep underground
Farmability - to grinder bound
Shields - made creepers but sound
Axes and crossbows - taking mobs out
Once I stuck a glowstone block to a fast-moving slimeblock flying machine
This lagged my poor laptop so badly...
I think quickly changing light levels will cause too much lag to be worth the effort, especially after Mojang declared miner hats as too modern and unfitting.
Since 1.14 lighting has been multithreaded so (at least in theory) this should no longer be an issue.
Of course, just because it is threaded doesn't mean it couldn't cause lighting updates to lag (e.g. you place a torch and the light doesn't appear until the lighting thread is able to process it, much as e.g. mob movement can lag while FPS is fine), which is why actually optimizing the lighting engine is still the best solution (e.g. while I did not multithread lighting I made it much faster; a piston rapidly moving a block back and forth over a hole in a high ceiling (the scenario described in MC-11571) only causes minor stuttering while vanilla 1.6.4 has crippling lag to single digit FPS. World generation also massively benefited from this change, with a "Mega Forest" Superflat Overworld generating within a few seconds instead of over half a minute (this is probably one reason why Mojang hasn't added any very large trees; other mods make compromises like making leaves completely transparent to minimize lighting updates).
There is also lag from chunk updates, independent of lighting updates (i.e. any block change will cause the entire chunk section it is in to be re-rendered), which may be a bigger issue in current versions, and the main bottleneck, at least for more complex geometry, is OpenGL itself (in the case of a 16x16x16 section filled with Fancy leaves 90% of the total time was spent on uploading the vertex data to OpenGL, as opposed to constructing it in Java code, and the uploads can't be multithreaded, at least not without knowing if the driver properly supports it, and this is why modern versions still have lag spikes despite multithreaded chunk rendering, and it is actually worse since they render blocks using triangles instead of "quads" (deprecated since OpenGL 3, but I tried this myself; 1.6.4 has code that renders using triangles if a flag is enabled (by default it isn't and can only be changed with a mod); and I saw a huge slowdown due to a 50% increase in the amount of vertex data being sent to the driver, even as the driver has to translate quads into triangles anyway):
In any case, I never noticed lag spikes when placing or removing torches, even on an ancient computer from the mid-2000s, completely hopeless by today's standards (it still met the system requirements for 1.6) and without any optimizations other than Optifine, which only optimizes chunk rendering; the code in modern versions is much slower and only thanks to multithreading is the game playable at all (most of my optimizations to the lighting engine focused on making chunk data access as fast as possible, including using a chunk cache and eliminating most bounds-checking as it is known that light can't propagate more than 14 blocks horizontally from a source, likewise, the y-coordinate only needs to be checked when propagating light up/down).
This is well thought out and simple, buuuuut I'd rather not have it. I can't imagine what it would be like on a server of like 100 people holding lanterns. We don't really need lanterns that bad anyway, torches not only do the job just fine, but they act as a "you've already been here" marker in caves and such.
Of course, just because it is threaded doesn't mean it couldn't cause lighting updates to lag (e.g. you place a torch and the light doesn't appear until the lighting thread is able to process it, much as e.g. mob movement can lag while FPS is fine), which is why actually optimizing the lighting engine is still the best solution (e.g. while I did not multithread lighting I made it much faster; a piston rapidly moving a block back and forth over a hole in a high ceiling (the scenario described in MC-11571) only causes minor stuttering while vanilla 1.6.4 has crippling lag to single digit FPS. World generation also massively benefited from this change, with a "Mega Forest" Superflat Overworld generating within a few seconds instead of over half a minute (this is probably one reason why Mojang hasn't added any very large trees; other mods make compromises like making leaves completely transparent to minimize lighting updates).
There is also lag from chunk updates, independent of lighting updates (i.e. any block change will cause the entire chunk section it is in to be re-rendered), which may be a bigger issue in current versions, and the main bottleneck, at least for more complex geometry, is OpenGL itself (in the case of a 16x16x16 section filled with Fancy leaves 90% of the total time was spent on uploading the vertex data to OpenGL, as opposed to constructing it in Java code, and the uploads can't be multithreaded, at least not without knowing if the driver properly supports it, and this is why modern versions still have lag spikes despite multithreaded chunk rendering, and it is actually worse since they render blocks using triangles instead of "quads" (deprecated since OpenGL 3, but I tried this myself; 1.6.4 has code that renders using triangles if a flag is enabled (by default it isn't and can only be changed with a mod); and I saw a huge slowdown due to a 50% increase in the amount of vertex data being sent to the driver, even as the driver has to translate quads into triangles anyway):
In any case, I never noticed lag spikes when placing or removing torches, even on an ancient computer from the mid-2000s, completely hopeless by today's standards (it still met the system requirements for 1.6) and without any optimizations other than Optifine, which only optimizes chunk rendering; the code in modern versions is much slower and only thanks to multithreading is the game playable at all (most of my optimizations to the lighting engine focused on making chunk data access as fast as possible, including using a chunk cache and eliminating most bounds-checking as it is known that light can't propagate more than 14 blocks horizontally from a source, likewise, the y-coordinate only needs to be checked when propagating light up/down).
Huh, good to know, thanks
The answer didn't have to be so elaborate though
Rollback Post to RevisionRollBack
Dwarf gamer found:
Buildings - square, not round
Materials - from rubble mound
Dark caves - lit 'n' cleaned out
Settlements - deep underground
Farmability - to grinder bound
Shields - made creepers but sound
Axes and crossbows - taking mobs out
Honestly, they would need to fix spawners so that they would still work in light, perhaps only disabling when a light source is placed on them instead of spawing based on the light level. But yeah I totally agree, they should add it to the game, but they can definitely do it way more effectively than just changing the light level of blocks around you.
In addition, it would be nice to have light source blocks glow when on the ground.
So to put it in simple terms - Minecraft's code is so bad that it can't handle a simple function that exists in literally every other single modern game.
So to put it in simple terms - Minecraft's code is so bad that it can't handle a simple function that exists in literally every other single modern game.
I wouldn't put it that way. One of the major issues is that minecraft worlds generate random while you are playing. That's why the lighting is such a mess.
Lighting something like that is by no means a simple funtion imo. Take a look into this video, at 10:45. This is where you find the difference between minecraft and other 3d games lightning solutions.
Rollback Post to RevisionRollBack
My projects:
-are abandoned for now. I might pick 'em up in the future.
For now i'm working on a private modpack that suit's my own playstyle.
I am gonna stay in modded 1.12.2 untill my potato dies. No mercy! :Q
I wouldn't put it that way. One of the major issues is that minecraft worlds generate random while you are playing. That's why the lighting is such a mess.
The lighting code is actually quite simple; here are the main methods involved in propagating light (sky light is handled separately and has special methods to compute lighting over an entire chunk and in columns below a block but the only real difference is that blocks with direct sky exposure are set to 15):
while (index2 < index1)
{
int lightData = this.lightUpdateQueue[index2++];
int x = (lightData & 31) + posX_16;
int y = (lightData >> 5 & 31) + posY_16;
int z = (lightData >> 10 & 31) + posZ_16;
int x15 = x & 15;
int z15 = z & 15;
Chunk chunk = this.getChunk(x, z);
int newLightLevel = this.computeBlockLightValue(x, y, z, chunk);
int index = y << 8 | z15 << 4 | x15;
if (newLightLevel > chunk.getBlockLightValueByIndex(index))
{
chunk.setBlockLightValueByIndex(index, newLightLevel);
this.worldObj.markBlockForRenderUpdate(x, y, z);
// 14 reduced from 17 (actual max range of light from source is 14 blocks)
if (Math.abs(x - posX) + Math.abs(y - posY) + Math.abs(z - posZ) < 14 && index1 < QUEUE_LIMIT)
{
int i = x - posX_16 | y - posY_16 << 5 | z - posZ_16 << 10;
if ((x15 > 0 ? chunk.getBlockLightValueByIndex(index - 1) : this.getBlockLightValue(x - 1, y, z)) < newLightLevel) this.lightUpdateQueue[index1++] = i - 1;
if ((x15 < 15 ? chunk.getBlockLightValueByIndex(index + 1) : this.getBlockLightValue(x + 1, y, z)) < newLightLevel) this.lightUpdateQueue[index1++] = i + 1;
if (y > 0 && chunk.getBlockLightValueByIndex(index - 256) < newLightLevel) this.lightUpdateQueue[index1++] = i - 32;
if (y < 255 && chunk.getBlockLightValueByIndex(index + 256) < newLightLevel) this.lightUpdateQueue[index1++] = i + 32;
if ((z15 > 0 ? chunk.getBlockLightValueByIndex(index - 16) : this.getBlockLightValue(x, y, z - 1)) < newLightLevel) this.lightUpdateQueue[index1++] = i - 1024;
if ((z15 < 15 ? chunk.getBlockLightValueByIndex(index + 16) : this.getBlockLightValue(x, y, z + 1)) < newLightLevel) this.lightUpdateQueue[index1++] = i + 1024;
}
}
}
private final int computeBlockLightValue(int x, int y, int z)
{
int block = this.getBlockState(x, y, z);
int lightValue;
int opacity;
if (!BlockStates.isAirBlock(block))
{
// Enables data values to affect light value (e.g. empty mob spawners)
lightValue = Block.blocksList[BlockStates.getBlockId(block)].getLightValue(BlockStates.getBlockMetadata(block));
if (lightValue >= 14) return lightValue;
opacity = clampedLightOpacity[BlockStates.getBlockId(block)];
// Prevents solid blocks like glowing redstone ore from passing a higher light level through
if (opacity >= 15) return lightValue;
}
else
{
lightValue = 0;
opacity = 1;
}
int savedLight = this.getBlockLightValue(x - 1, y, z) - opacity;
if (savedLight > lightValue) lightValue = savedLight;
savedLight = this.getBlockLightValue(x + 1, y, z) - opacity;
if (savedLight > lightValue) lightValue = savedLight;
if (y > 0)
{
savedLight = this.getBlockLightValue(x, y - 1, z) - opacity;
if (savedLight > lightValue) lightValue = savedLight;
}
if (y < 255)
{
savedLight = this.getBlockLightValue(x, y + 1, z) - opacity;
if (savedLight > lightValue) lightValue = savedLight;
}
savedLight = this.getBlockLightValue(x, y, z - 1) - opacity;
if (savedLight > lightValue) lightValue = savedLight;
savedLight = this.getBlockLightValue(x, y, z + 1) - opacity;
return (savedLight > lightValue ? savedLight : lightValue);
}
The actual application of lighting to blocks when they are rendered is a simple matter of setting the "brightness" of the vertices to a value derived from the light level adjacent to it (smooth lighting averages the brightness of a 2x2 block area around each vertex). In fact, the game actually appears to combine a lightmap "texture" with the block texture; for example, prior to rendering an entity it sets it brightness with the following methods:
As mentioned before, the biggest issue with lighting, and the game in general, is chunk updates - it is extremely expensive to upload vertex data to the GPU, especially in more complex scenes - even though I can get a steady 1000 FPS, even in a "Mega Forest" biome, a single chunk update may take as much as 20 milliseconds, and average FPS drops down to less than 50 - this is partly why I set leaves to Fast as otherwise my "Mega Forest" biomes kill the smoothness of the game when chunk updates are occurring, especially when Vsync is enabled (it amplifies framerate drops because it drops to a submultiple of the maximum; e.g. 60, 30, 20, 15, etc):
16x16x16 Fancy leaves in vanilla:
Chunk update took 35652 us (render: 16481, draw: 19170)
TMCW:
Chunk update took 20927 us (render: 1971, draw: 18955)
(render = time spent in Java code; draw = time spent to upload the data to OpenGL)
Even the multithreaded chunk rendering in 1.8+ only applies to the Java code; OpenGL itself still bottlenecks the upload process, so the end result may as well be the same as making the Java code faster like I did (you'd need 8 threads with perfect load balancing to get the same performance, and not even considering the code inefficiencies in 1.8+):
The real technological feat of Minecraft is that it can effortlessly render millions of blocks, but this is mainly because the world is mostly static with only actively updating chunks (more accurately, 16x16x16 sections) requiring mesh rebuilds. Why do entities kill FPS so badly (see this example, where 100 chickens dropped FPS from 2700 to 380)? Because they must be re-rendered from scratch every frame, with many separate draw calls, one for each movable piece; e.g. body, head, legs, wings - that's the true cost of a truly dynamic world, and the best way to implement dynamic lighting is to use a shader to render a spherical area as if it were lit up, without actually affecting the world, and this is how the many such mods actually work; if you watch a video you can see that the light smoothly follows the player, instead of jumping from block to block:
This would also solve GBoiHere's concern about spawners being affected, while not having any impact on general mob spawning because they can't spawn within 24 blocks of a player anyway.
I wouldn't put it that way. One of the major issues is that minecraft worlds generate random while you are playing. That's why the lighting is such a mess.
Lighting something like that is by no means a simple funtion imo. Take a look into this video, at 10:45. This is where you find the difference between minecraft and other 3d games lightning solutions.
Lighting is an issue when you're dealing with animation, because this tends to be very taxing on hardware, the proof is that you need powerful hardware to make use of advanced shaders in the game, otherwise the frame rate will be like a slideshow and it doesn't make for a good gaming experience. It depends on what type of lighting you're dealing with and how many objects in the game it affects. Sometimes mods for old games can stress modern hardware if they too change how the graphics work in your game.
I know Mojang has said they aren't adding dynamic light sources to Minecraft. But I don't care. In fact, I think Mojang should reevaluate everything on that list, but that's for other posts.
Mechanics
When you are holding a lantern in your hand, offhand or helmet slot, the air or water block that you are standing in becomes a new temporary light block that emits a light of 15. If you move a block, the light despawns and respawns. If you take the lantern out of your hand, the light block despawns.
That's pretty much it. I was previously thinking of a new helmet with a lantern built in (which, even though Mojang explicitly rejected for being too modern, would still fit the the game's style), but that would add one unnecessary item. Yes, wearing a lantern on your head is silly, but so is wearing a pumpkin on your head to not aggravate endermen, or strapping wings to your back. This is Minecraft, it doesn't have to be completely reasonable, so long as it is consistent and makes some kind of sense.
My suggestions: Enhancements - Throwable Fire Charges - On Phantoms and Elytra. Also check out The Minecraftian Language. This signature is not here to waste your space.
I don't know the codes from modifications which add dynamic lightning, but i can promise you:
That is the base concept for most of them.
Mojang would have added it by now, if they wanted to.
My projects:
-are abandoned for now. I might pick 'em up in the future.
For now i'm working on a private modpack that suit's my own playstyle.
I am gonna stay in modded 1.12.2 untill my potato dies. No mercy! :Q
I think the Miners helmet mod works just like that.
https://www.curseforge.com/minecraft/mc-mods/miners-helmet
Optifine already offers dynamic lighting option. And I generally find it detrimental cause it messes with lighting places up.
Not everyone has or can get Optifine. Further, this wouldn't be always on. I assumed that would be obvious.
My suggestions: Enhancements - Throwable Fire Charges - On Phantoms and Elytra. Also check out The Minecraftian Language. This signature is not here to waste your space.
No, what I meant to say is that I personally had ample chance to play with dynamic lighting, and I found that it does more harm than good. I have it switched off in Optifine settings. If I am in an area that's dark enough to spawn mobs (and thus needs a torch placed), I want it clearly visible. If a carried torch always places a pool of light around me, it makes the process a lot less intuitive.
Once I stuck a glowstone block to a fast-moving slimeblock flying machine
This lagged my poor laptop so badly...
I think quickly changing light levels will cause too much lag to be worth the effort, especially after Mojang declared miner hats as too modern and unfitting.
Dwarf gamer found:
Buildings - square, not round
Materials - from rubble mound
Dark caves - lit 'n' cleaned out
Settlements - deep underground
Farmability - to grinder bound
Shields - made creepers but sound
Axes and crossbows - taking mobs out
Since 1.14 lighting has been multithreaded so (at least in theory) this should no longer be an issue.
https://www.reddit.com/r/admincraft/comments/bgty5t/in_114_light_computation_got_moved_off_the_main/ (note the first reply about lag from flying machines; this also applies to singleplayer, which if it is anything like 1.6.4 computes lighting on both the server and client sides; the server only sends lighting data when a chunk is first sent, not for subsequent updates)
MC-11571 Huge lighting updates lag the game. (marked as fixed in 18w43a, a snapshot for 1.14)
Of course, just because it is threaded doesn't mean it couldn't cause lighting updates to lag (e.g. you place a torch and the light doesn't appear until the lighting thread is able to process it, much as e.g. mob movement can lag while FPS is fine), which is why actually optimizing the lighting engine is still the best solution (e.g. while I did not multithread lighting I made it much faster; a piston rapidly moving a block back and forth over a hole in a high ceiling (the scenario described in MC-11571) only causes minor stuttering while vanilla 1.6.4 has crippling lag to single digit FPS. World generation also massively benefited from this change, with a "Mega Forest" Superflat Overworld generating within a few seconds instead of over half a minute (this is probably one reason why Mojang hasn't added any very large trees; other mods make compromises like making leaves completely transparent to minimize lighting updates).
There is also lag from chunk updates, independent of lighting updates (i.e. any block change will cause the entire chunk section it is in to be re-rendered), which may be a bigger issue in current versions, and the main bottleneck, at least for more complex geometry, is OpenGL itself (in the case of a 16x16x16 section filled with Fancy leaves 90% of the total time was spent on uploading the vertex data to OpenGL, as opposed to constructing it in Java code, and the uploads can't be multithreaded, at least not without knowing if the driver properly supports it, and this is why modern versions still have lag spikes despite multithreaded chunk rendering, and it is actually worse since they render blocks using triangles instead of "quads" (deprecated since OpenGL 3, but I tried this myself; 1.6.4 has code that renders using triangles if a flag is enabled (by default it isn't and can only be changed with a mod); and I saw a huge slowdown due to a 50% increase in the amount of vertex data being sent to the driver, even as the driver has to translate quads into triangles anyway):
MC-123584 Updating blocks creates lag spikes proportional to geometry in chunk section (this is why setting leaves to Fast can make such a big difference, more than any other graphical setting, even render distance, although this does not work in current versions)
In any case, I never noticed lag spikes when placing or removing torches, even on an ancient computer from the mid-2000s, completely hopeless by today's standards (it still met the system requirements for 1.6) and without any optimizations other than Optifine, which only optimizes chunk rendering; the code in modern versions is much slower and only thanks to multithreading is the game playable at all (most of my optimizations to the lighting engine focused on making chunk data access as fast as possible, including using a chunk cache and eliminating most bounds-checking as it is known that light can't propagate more than 14 blocks horizontally from a source, likewise, the y-coordinate only needs to be checked when propagating light up/down).
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
This is well thought out and simple, buuuuut I'd rather not have it. I can't imagine what it would be like on a server of like 100 people holding lanterns. We don't really need lanterns that bad anyway, torches not only do the job just fine, but they act as a "you've already been here" marker in caves and such.
Huh, good to know, thanks
The answer didn't have to be so elaborate though
Dwarf gamer found:
Buildings - square, not round
Materials - from rubble mound
Dark caves - lit 'n' cleaned out
Settlements - deep underground
Farmability - to grinder bound
Shields - made creepers but sound
Axes and crossbows - taking mobs out
Honestly, they would need to fix spawners so that they would still work in light, perhaps only disabling when a light source is placed on them instead of spawing based on the light level. But yeah I totally agree, they should add it to the game, but they can definitely do it way more effectively than just changing the light level of blocks around you.
In addition, it would be nice to have light source blocks glow when on the ground.
So to put it in simple terms - Minecraft's code is so bad that it can't handle a simple function that exists in literally every other single modern game.
I wouldn't put it that way. One of the major issues is that minecraft worlds generate random while you are playing. That's why the lighting is such a mess.
Lighting something like that is by no means a simple funtion imo. Take a look into this video, at 10:45. This is where you find the difference between minecraft and other 3d games lightning solutions.
My projects:
-are abandoned for now. I might pick 'em up in the future.
For now i'm working on a private modpack that suit's my own playstyle.
I am gonna stay in modded 1.12.2 untill my potato dies. No mercy! :Q
The lighting code is actually quite simple; here are the main methods involved in propagating light (sky light is handled separately and has special methods to compute lighting over an entire chunk and in columns below a block but the only real difference is that blocks with direct sky exposure are set to 15):
As mentioned before, the biggest issue with lighting, and the game in general, is chunk updates - it is extremely expensive to upload vertex data to the GPU, especially in more complex scenes - even though I can get a steady 1000 FPS, even in a "Mega Forest" biome, a single chunk update may take as much as 20 milliseconds, and average FPS drops down to less than 50 - this is partly why I set leaves to Fast as otherwise my "Mega Forest" biomes kill the smoothness of the game when chunk updates are occurring, especially when Vsync is enabled (it amplifies framerate drops because it drops to a submultiple of the maximum; e.g. 60, 30, 20, 15, etc):
Even the multithreaded chunk rendering in 1.8+ only applies to the Java code; OpenGL itself still bottlenecks the upload process, so the end result may as well be the same as making the Java code faster like I did (you'd need 8 threads with perfect load balancing to get the same performance, and not even considering the code inefficiencies in 1.8+):
https://www.reddit.com/user/sliced_lime/comments/e00ohm/a_word_or_two_about_performance_in_minecraft/f8bai01/
The real technological feat of Minecraft is that it can effortlessly render millions of blocks, but this is mainly because the world is mostly static with only actively updating chunks (more accurately, 16x16x16 sections) requiring mesh rebuilds. Why do entities kill FPS so badly (see this example, where 100 chickens dropped FPS from 2700 to 380)? Because they must be re-rendered from scratch every frame, with many separate draw calls, one for each movable piece; e.g. body, head, legs, wings - that's the true cost of a truly dynamic world, and the best way to implement dynamic lighting is to use a shader to render a spherical area as if it were lit up, without actually affecting the world, and this is how the many such mods actually work; if you watch a video you can see that the light smoothly follows the player, instead of jumping from block to block:
https://www.reddit.com/r/Minecraft/comments/4lv4ld/smooth_dynamic_lights_optifine/
This would also solve GBoiHere's concern about spawners being affected, while not having any impact on general mob spawning because they can't spawn within 24 blocks of a player anyway.
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
Lighting is an issue when you're dealing with animation, because this tends to be very taxing on hardware, the proof is that you need powerful hardware to make use of advanced shaders in the game, otherwise the frame rate will be like a slideshow and it doesn't make for a good gaming experience. It depends on what type of lighting you're dealing with and how many objects in the game it affects. Sometimes mods for old games can stress modern hardware if they too change how the graphics work in your game.