Minecraft 1.20 光照引擎的变化

在 Minecraft 1.20 中，Mojang 重新编写了一个光照引擎，详细请看星光作者的文章。

简而言之，Mojang 对光照引擎的两大核心优化措施：

• 传递光照等级，而不进行方块更新；

• 使用单独、简化的逻辑确定区块内光照分布；

与星光的优化思路高度相似。虽然 Mojang 的优化力度仍不及星光（比如在传递光照等级方面仍然只达到了星光的一半速度），但是对客户端来说，足够快了。

因此，作者将不再更新 1.20 以后的模组版本。

星光仍会在 Paper 等服务端中存在，因为星光的性能仍然受到原版区块引擎的掣肘，这样可以运用到这些服务端提供的区块引擎，进而为大型服务器提供处理巨量区块更新/生成的能力。

星光（Starlight）

由 Tuinity 作者 Leaf 开发的光照优化 Mod，对 Minecraft 的光照引擎进行了完整的重写。星光原本是独属于 Tuinity 服务端的光照优化方案，后被转制成 Fabric & Forge Mod。

光照引擎（Light Engine）和光影（Shader）是完全不同的概念，星光对光照引擎的重写不会妨碍你开光影！

单从性能相比，星光远优于原版的光照引擎，也远优于 磷(Phosphor) 或是其分支，但重写的性质会使其破坏任何与光照引擎直接交互的模组（大部分情况下只有诸如磷等优化模组才会直接挂钩光照引擎），因此请自行斟酌是否使用星光。详见“模组兼容性及相关结论”部分及作者提供的技术性文档。

星光还修复了 MC-162253 等特定情境才会出现的性能问题。

注：Tuinity 是 Paper Spigot 服务端的分支，旨在提升世界相关操作的性能。

开发目的

原版光照引擎的性能简直糟透了。现有的修改，例如 磷(Phosphor) 或 Paper 光照引擎（Paper 的光照引擎继承自磷），虽有尝试但终究无力回天。

       磷对现有光照引擎的优化相当出色，但遗憾的是，它的优化将近碰到了原版代码的天花板，现如今几乎没有进一步优化的空间了。

 Paper 的光照引擎继承自磷，因而也遇到了同样的问题——改无可改，所以它选择使用更加激进的手段，然而，Paper 所作出的修改有着技术上的困难，在实际应用中，光照显得颇为间断、不连续。如图：

而下图则展示了比较合理的光照样貌（使用了星光）：

• 这些问题有机会得到解决吗？

  或许可以，但没人知道究竟是什么导致了这个问题，并且针对于原版光照引擎的调试过于复杂，简直就是一团乱麻，以至于所有尝试勇攀高峰的勇士最后都不得不感叹这屎山之高，最后选择放弃。更有甚者，例如 Paper 所做的更改，压根没有针对那些由原版光照引擎造成的显而易见的问题进行修复，只是放任自流，估计也是心有余而力不足了。

实际上，在原版代码的基础上优化光照引擎就是天方夜谭——不如推倒重写。

性能测试

伊始与注意事项

数据胜于雄辩。我们将性能指标分为三种测试。[世界生成/大平台光照更新/荧石]

无论在下面哪种测试中，得益于由星光完全重写的光照引擎，区块生成速度都难以置信地快，远远超出 磷(Phosphor) 所能达到的范围。

请注意，作者认为您可能无法在此模组上看到客户端一侧的 FPS 显着提升。这主要是因为由于光照引擎得到了质的飞跃，客户端每帧能渲染更多区块，而区块更新速度的提高也会对 FPS 产生负面影响。而在一些对光照引擎要求颇高的情景中，比如在不太理想的硬件上生成放大化世界时，我们还是能够看到非常显着的区块生成速度提升和 FPS 飞跃。

由于天空光照的控制方式不同，星光将重新点亮原版光照引擎点亮的区块，并且新的天空光照数据与原版光照格式不兼容。而重新加载区块总是比直接加载它们更耗时，因此，在您正式对星光的性能做出测评时，应先让区块重载一遍以适应新光照引擎的格式。

光照生成测试

• 地图种子: vanillakekw。

• CPU: Intel i7-8750H @ 2.20GHz (已关闭睿频加速)。

• 从 (0, 0) 开始同步生成 101x101 个区块，以 (-10000, -10000) 为中心预渲染 101x101 个区块。
  

• 强制让光照执行线程运行在单个线程上，通过工具 visualvm 度量 CPU 线程时间，以此测量 CPU 在光照上的性能表现。

星光大约需要 7 秒才能产生光，而原版的光引擎大约需要 220 秒，磷(Phosphor) 耗时约 170 秒。星光在为区块生成光照时，与磷相比快约 25 倍，比原版快约 35 倍。

大平台光照更新测试

下图展示了在 Y = 254 的大平台上破坏方块以及在 Y = 0 的大平台上放置方块的光照更新用时（越低越好）：

• 测试使用 LightBench。

• 世界是一个超平坦世界，y = 0处有基岩 (Bedrock)，y = 254处有草 (Grass)。

• CPU: Ryzen 9 5950X。

荧石更新测试

下图说明了一个简单的荧石放置/破坏后的光照更新时间（越低越好）：

• 测试使用 LightBench。

• 世界是一个超平坦世界，y = 0 处有基岩，y = 254 处有 草 (Grass)。

• CPU: Ryzen 9 5950X。

• 在基岩层放置并破坏荧石，这意味着天空光照不太可能影响测试结果。

模组兼容性及相关结论

不兼容模组列表

不出所料，最初为基于 Bukkit 的服务器设计的前沿技术在 Forge 和 Fabric 等平台上存在模组兼容性问题。任何依赖于直接连接到光照引擎的模组——比如 飞轮 (Flywheel) ——都会被星光破坏，需要额外的手段实现兼容。您可以在右边链接找到被破坏的模组的列表：不兼容模组列表

上面的列表当然不是 100% 完整的，因为它依赖于在那里报告这些问题的人。并且鉴于作者不太可能逐个修复这些兼容性问题，不要指望很多人会费心于提交这些问题。

另外，关于飞轮，作为 机械动力 (Create) 这个著名模组的前置，其与星光的兼容问题被许多人询问，这里特别做些说明。官方发布的星光在 1.16 下与飞轮是不兼容的，后来有人提供了兼容性补丁，但那时星光已经放弃了对 1.16 的维护转向 1.17+，于是 1.16 下与飞轮（也即机械动力，因为飞轮是其前置）兼容的星光版本另外发布在了 Starlight x Create 页面。而在 1.16 后，1.20 前，星光与飞轮都是兼容的。1.20 以及以后的版本中，由于原版新编写了一个光照引擎，星光对客户端的支持力度减少，这时星光与飞轮的兼容性又难以保证了。

区块引擎

星光与 井字棋 (tic-tacs) 区块优化提供官方兼容，还专程做了重构，Tic-tacs 方也对星光做出了特异性的修改，因此您可以放心地同时使用这两个模组，且出于双方优化方向的互补关系，Leaf 甚至提倡您那么干。

不过 Tic-tacs 现已停更，出于稳定性考虑，[C2ME] C^2M 引擎 (C^2M-Engine) 是不错的选择。

其他光照引擎

必然不兼容。

如果你一同安装了星光和磷，并成功进入了游戏没有崩溃，请不要认为星光和磷兼容。因为星光设法会将原版的光照引擎完全推倒，替换为自己的光照引擎。在较好的情况下，被磷优化过的原版光照引擎也被星光给推倒，磷在星光的环境下不会发挥任何作用。而在较坏的情况下，星光和磷的代码会互相混杂覆盖，此时光照引擎的行为就难以预料了，任何后果都有可能。

以上结论不仅适用于磷，也适用于磷的各类非官方重制版（比如氡、硫），或是其他更改原版光照引擎的模组。

结论

星光是目前 Minecraft 中最快的光照引擎。然而，这并非没有代价。它会破坏一些模组，并使客户端的一些光照延迟问题成为性能瓶颈（因为服务端的光照引擎由星光负责，速度远胜以往）。

• 那么您应该使用哪种光照引擎？

对个人游玩而言，作者建议，至少不要使用原版的光照引擎，因为 磷(Phosphor) 是一个经过社区验证的光照引擎优化，修复了像 MC-162253 这样的性能问题。所以您的选择范围至少应该缩减为磷或星光。在模组兼容性方面，磷会更好，因为它只是修改了光照引擎而不是重写。不过，根据您的计算机配置和世界地形，星光也可能更具有优势。综上所述，作者建议测试这两者对您使用情境的影响，并根据需要选择您所钟爱的那个。

但是，对于更大规模（有大量区块加载）的服务器，建议又会大相径庭。如果您意识到了光照引擎的性能问题，就会发现大型服务器中的很多问题都可以归因于光照。例如因光照引擎而引发持续不断的卡顿，或是服务器因卡顿而重启，挂起的光照更新因此丢失，导致光照中断。星光解决了这些问题，首先是它本身的速度很快，不太可能造成卡顿，其次是在有待处理的光照更新时阻止保存区块。更大规模的服务器也会有更多的人在探索，这会给区块生成带来更大的压力，而星光将对此提供帮助。

所以作者认为，如果您追求高性能的 Minecraft 体验，星光将更好地处理大型服务器上的光照更新，并且取决于各种因素（见本小节第一段）Phosphor 可能更适合小型和单人游戏。如果您想添加新模组，请仔细确认您已有的模组是否兼容。