The third piece of the 26.3 server performance stack is in place. ScalableLux built for Wilderness Bound on 15 and 16 September, which means Lithium, C2ME and ScalableLux are all available on the same version for the first time since the drop.
It is also the least understood of the three, partly because the thing it fixes is invisible until it is not.
What ScalableLux is
A fork of Starlight, which replaced Minecraft’s lighting engine and stopped being maintained as a mod in March 2024. ScalableLux picked it up, kept the performance work, added bug fixes, and added something Starlight did not have: optional parallel light updates.
The reason a fork was needed is stated plainly on the project page – vanilla’s lighting engine is still a bottleneck for high-speed chunk generation. You can make chunk generation as parallel as you like, and lighting will still serialise it.
Starlight’s own measured advantage over vanilla lighting was roughly 100 percent, and its stateless design is what makes parallel light updates possible at all. ScalableLux exists to keep that available and push it further.
Why it matters more on a server than a client
Lighting cost scales with how much new world is being lit. On a client walking through already-generated chunks, there is almost nothing to do. On a server where several players are exploring outward simultaneously, lighting is being recalculated constantly and it is competing with everything else on the tick.
The project is explicit that this matters for dedicated servers with more players stressing chunk generation. That is the use case. A single-player world will see a smaller effect, and a fully explored world will see close to none.
Client and server are both listed as optional, which is accurate – it will run on either – but the value is concentrated server-side.
The stack, now complete on 26.3
The three mods divide the work cleanly and are designed to be run together:
- Lithium – general tick optimisation across game logic.
- C2ME – chunk generation, loading and I/O, spread across cores.
- ScalableLux – the lighting engine, with optional parallel updates.
C2ME’s own page recommends the other two by name. That is not marketing – the benchmark numbers C2ME publishes were measured with them installed, and removing the lighting piece puts the bottleneck back.
Installing C2ME alone and wondering why generation did not speed up as much as advertised is the common version of this mistake.
The alpha label
The 26.3 builds are versioned 0.3.0-alpha and tagged alpha, the same release channel the project has used throughout. The Fabric 26.3 build has picked up over 17,000 downloads, the NeoForge one a few hundred.
The changelog is automated and says what you want it to say: build 26.3, plus an archivesName fix. No behaviour changes in the port.
Parallel light updates are the option to be careful with. It is the part that is genuinely new relative to Starlight, it is where any threading bug would live, and it is worth enabling as a separate step after the mod itself has been stable for a few days rather than at the same time. Backing up first is the standard discipline for any server-side change of this kind.
Loader availability
Fabric and NeoForge both have 26.3 builds, unlike C2ME where NeoForge is a separate project on its own schedule. Licence is LGPL-3.0, so modpack distribution is unrestricted.
The mod sits at about 13.8 million downloads with 2,205 followers, which is modest next to Lithium and reflects how many people know what a lighting engine is rather than how many would benefit.
Who should install it
Install if you run a multiplayer server where players explore, if you are about to pre-generate a world, or if you already run C2ME and want the numbers it promises. Those three overlap heavily.
Skip it if your server is a stable, fully explored map with tick lag – that is a different bottleneck and the fix is elsewhere in the tuning stack. Skip it on a single-player client unless you are specifically generating a lot of new terrain.
The order to install the whole set, and what to measure afterwards, is in our server performance stack write-up.
How to tell lighting is your bottleneck
Lighting rarely announces itself. The symptom is not a lighting problem – it is chunks arriving slowly while the server’s tick time looks acceptable, or generation throughput that refuses to improve no matter how many threads you give it.
Three situations where it is worth suspecting:
- You installed C2ME, gave the server more cores, and generation speed barely moved.
- A pre-generation run is taking far longer than the chunk count suggests it should.
- Players report that newly explored areas take a noticeable moment to light up after the terrain appears.
The third one is the most visible version and the easiest to dismiss as normal, because on vanilla it is normal.
A note on relighting
Because Starlight and its forks replace the lighting engine rather than tune it, a world that has been run on one and then run on vanilla can end up with lighting data the other engine did not write the same way. In practice this shows up as dark patches that correct themselves once chunks are relit.
It is not destructive and it is not common, but it is a reason to decide once rather than toggling the mod on and off across sessions. Install it, leave it installed, and take the backup before the first launch rather than after.
Images: Tectonic project gallery.