LambDynamicLights: making a torch in your hand actually light the room

Dynamic light is a rendering problem, not an inventory one

The mod starts from a specific frustration: it is dark outside, you cannot see much, and you wish you had a torch or a lantern to hold so you could see in the light. Vanilla Minecraft lets you carry a torch, but the torch in your hand does not emit light into the world, so the fantasy the item implies is not delivered.

LambDynamicLights adds dynamic lights to the game, and the definition it gives is precise: dynamic lights are lights created by an entity holding an item which makes light as a block, or created by an entity on fire. That definition matters because it describes a rendering behaviour rather than a gameplay one. The light is computed on the client, from the state of the world as that client sees it, and the environment badge in the README states that this is a client mod.

The feature list expands the idea in a few directions. Any entity holding an item which emits light will emit light, so a fox holding glowberries lights the ground around it. Burning entities emit light, so an arrow on fire or an Aurora on fire lights its surroundings. Dropped items which already emit light as a block also dynamically emit light, which is the case the README shows first with a dropped lantern.

The setting that governs all of this is update smoothness, and the mod exposes a choice of how smoothly the dynamic lighting updates. That is the knob a player will actually touch.

Light sources are discovered from items, entities and resource packs

The interesting engineering is in where the light values come from, and the answer is that they are not hard coded in the mod.

Item lighting is customised through resource packs, and it works with modded items. That is the extension point: a pack author can declare that a modded item emits a certain light level, and the mod honours it. There is a separate api/ directory in the repository and the README points to in depth documentation for developers and resource pack makers, described as a quick and simple API. So a pack author has two routes, a resource pack declaration or the API, and the same information has to reach the renderer either way.

Native entities are handled explicitly. Allays, blazes, fireballs, glow squids, magma cubes and spectral arrows all emit light naturally. Glow squids in particular finally glow in your world. Guardian lasers emit light too, and the README frames that with some enthusiasm, noting that they do pack a punch.

There are two special cases worth knowing. Creeper explosions are made more apparent through a progressive emission of light before the blast, so the warning arrives visually rather than only as a sound. And some items, torches and soul torches among them, will not light up in water, which is a deliberate exception rather than a bug.

The fireflies particle emits light as it flies. That is the smallest unit the mod handles, and its presence says something about the granularity of the lighting model: the effect works at the level of individual moving things, not just blocks.

Installing on Fabric and NeoForge, and building from source

The installation steps are short because a Minecraft mod is a jar file in a folder. The README states the two paths:

On Fabric, install it in your mods folder along with [Fabric API] and [ModMenu], (and [Sodium] if wanted for better performances).  
On NeoForge, install it in your mods folder (and along with [Sodium] if wanted for better performances).

On Fabric you also need Fabric API and ModMenu, since ModMenu is what exposes the configuration screen through the mods list. On NeoForge only the mod jar is required. Both loaders are supported by the same project, and the mod badge in the README shows both.

It works as is once dropped in. Configuration is optional and lives in the video settings screen or in the mods list, and a configuration GUI has existed since v4.0.0, with separate screens for the main settings and for entity configuration. The entity screen is where you turn individual light emitting entities on or off.

Builds are published rather than only built from source, with a Modrinth page and a CurseForge page for downloads, and a project page at lambdaurora.dev under projects/lambdynamiclights. For anyone who wants to compile it, the build section of the README says the whole thing is a single Gradle invocation, ./gradlew build, and the repository has the expected Gradle layout with build.gradle.kts, settings.gradle.kts, a build_logic directory, gradle.properties and gradlew wrappers for both platforms.

The README also links a curated list of alternatives to OptiFine, which matters because dynamic lighting used to arrive as one feature inside a large performance mod. Here it is separated out.

A client side mod means every player sees their own lighting

The environment badge says Client, and that single word shapes the experience. Lighting is added by your client, so the light a torch in your hand casts is a local rendering decision. Two players in the same world can see different lighting around the same torch, and a server that wants uniform light has no mechanism here to enforce it.

That is a deliberate consequence of how the mod works, not an oversight, and the README does explain the internals in a separate document, HOW_DOES_IT_WORK.md, linked from a section asking how it works internally. The presence of that document, plus the api/ directory and the resource pack path, tells you the author treats this as an engineering project rather than a patch.

The performance story is where the honest caveat sits. The README recommends Sodium for better performances, on both loaders, and repeats the recommendation in the integrations section. A dynamic lighting mod computes extra lights every frame, and Sodium is the rendering optimisation the project points at for absorbing that cost. The word the README uses is recommended rather than required, which means the mod works without it, at an unspecified cost to frame time.

That places the project in a specific spot in the mod ecosystem. It is a feature mod that assumes an optimisation mod is present, and it is the kind of mod that has to keep pace with the game's rendering changes, which is the next constraint.

Version numbers are coupled to Minecraft releases

The release tags make the coupling explicit. The recent versions are v4.13.0+26.3, v4.12.4+26.2 and v4.11.2+26.1, and the default branch is 26.3. The trailing number is the Minecraft version, so the mod version and the game version advance together. v4.13.0 for 26.3 was published on 2026-09-15, and the two preceding builds, 4.12.4 for 26.2 and 4.11.2 for 26.1, both landed on 2026-08-31.

The last push was on 2026-09-15, and the repository is not archived, so the project is still shipping. The pace is what you would expect from a mod that has to be recompiled and revalidated whenever the game updates, with two builds on one day and a third two weeks later.

For an ordinary player this is invisible, because the distribution pages hand you the build for your game version. For a pack author or a server operator it is not, since a resource pack that targets an item set has to be checked against the matching mod build, and a new Minecraft release means a new jar before anything else works.

The licence deserves attention too. The repository badge names the Lambda License, and the licence is classified as custom because GitHub cannot map it to a known category. The repository carries both a LICENSE file and a LICENSE.OLD file, which is the trace of a licence change, so anyone shipping a resource pack or a server bundle alongside the mod should read the current LICENSE file rather than assume the terms match what they saw earlier. This article does not interpret those terms.

Where the alternatives sit

The closest alternative is the one the project itself points away from. Dynamic lighting was historically a feature of OptiFine, and the README links a curated alternatives list for people searching for a replacement for OptiFine. The difference in approach is that OptiFine bundled lighting with frame rate control, shaders, entity culling and a long list of rendering toggles, while LambDynamicLights does lighting only. That is a narrower tool with a smaller surface, but it also means you still need a separate mod for the frame rate and rendering work, which is why Sodium appears in the install instructions twice.

Inside the Fabric ecosystem the adjacent tools are integrations rather than competitors. Illuminated is a flashlight mod that uses LambDynamicLights, and Beltborne Lanterns equips a lantern on a belt so you have a light source on yourself at all times. Both are built on the assumption that this mod provides the lighting substrate. A mod that does its own lighting, such as a shader pack with a full dynamic lighting model, takes a different route entirely: it re-renders the scene from scratch rather than adding lights to the game's own lighting pipeline, which is a different trade-off between fidelity and compatibility.

So the choice comes down to what you are missing. If it is a torch that lights the room, this mod is the focused answer. If it is a full shader lighting model with reflections and shadows, a shader pack is the different tool, and it will not be a drop in swap.

Editorial conclusion

LambDynamicLights fits a player who wants dynamic light without rebuilding their shader setup, and a resource pack author who needs item light levels to be discoverable rather than hard coded. It does not fit a server operator who wants every client to see the same lighting, because the mod is client side and the lighting a player sees is their own rendering, and it does not fit a player who wants a version independent setup, since each build targets one Minecraft release. Verify first by installing the build that matches your game version from Modrinth or CurseForge, enabling the entity configuration screen, and checking whether Sodium is present, because the README recommends it for performance and the interaction between the two mods is where the tuning lives.

Frequently asked questions

Official sources

1. Issues
2. LambdAurora/LambDynamicLights on GitHub
3. Project website
4. README
5. Releases