Java 版光影问答

为什么 Java 版光影优化如此糟糕？

事实上 OpenGL 本身性能不差，但是光影选用的 GLSL 版本老旧或受限于其编写时代，一些新 GL 特性无法使用，导致老旧的着色器代码产生了很多不必要的开销。

除了 GPU 驱动程序，更多的性能缺陷是来自于 Java 版游戏的渲染线程本身：

• LWJGL 封装加上 Blaze3d 封装让代码效率打了折扣；

• 游戏渲染和主进程绑定在一起，也就意味着虽然 GPU 可能有空闲，但是由于主进程运算阻塞，导致 FPS 降低（新版本区块构建器的 线程化 模式一定程度上缓解了这个问题）；

• 由于其商业原因和历史包袱，Mojang 没能力做到 Sodium 或者 OF 那样的优化。

总的来说，问题是多方面的：

• 从最底层看：御三家的 OpenGL 实现做的参差不齐；

• 往上看：OpenGL 本身历史包袱重，而且 Mojang 仍然在用旧的 GL 版本；

• 看引擎： LWJGL 也就 Minecraft 在用了，小厂自研，优化一般，单线程运作也限制了过多东西；

• 看游戏架构：经典单核，渲染与其他操作绑定同步，只要别的地方出岔子，渲染就卡；

• 再看看渲染代码： It just works；

• 最后看总体：屎山堆积，一代不如一代。

什么光影最好？某某光影是高配还是低配？

光影不存在最好，只存在最适合自己 ，包括所谓光追，并不是带有先进技术的才是好的。你可能会想在光源复杂巨型建筑群上运行带有路径追踪光影，也有可能会想在自己的生存小屋里开上一个原版风味光影。

渲染是一个动态的过程 ，任何变量（游戏版本、地图地形、资源包、模组、数据包，甚至视野内的物体等等）都会对光影的帧数产生影响，从而使帧数变得不稳定。
而由于光影设置的存在，某些光影所需要的性能上下限也会大相径庭，因此光影不存在明确的高低配说法 。但是针对某些光影的默认配置进行客观存在的性能评估也是可能的，这种情况下，你应该将具体场景细化再提问。

最清楚这个答案的是你和你的设备，多亲自测试，而不是问其他人！

光影区分游戏版本吗？

一般来说，光影不区分游戏版本 ，而是取决于 OF 和 GLSL 。OF 偶尔会添加独特的新特性和变量，而 GLSL 版本决定了可以使用的特性。

有一个例外是，如果光影基于 JE 1.12 及以前的游戏版本，可能由于 扁平化 而使 block.properties 等配置文件失效。

排除例外情况之后，如果光影仍不兼容当前游戏的情况，请检查以下原因：

• 设备问题

  • 光影使用了你的设备不支持的 GLSL 版本 ，大多数现代 GPU 所支持的 OpenGL 版本都是 4.6.0，GLSL 使用 #version 语句声明，过旧的 GPU 可能不支持光影所声明的 GL 版本，若情况如此请更换光影。

    • 移动平台此问题最为严重，它们的兼容性不在大多数 Java 版光影的考虑范围之内，若情况如此请不要反馈给作者。

  • 使用了 AMD 系列显卡 。自 2022 年 7 月开始， AMD 大幅重写了显卡驱动，在提升了一定性能的同时，把原本就不佳的兼容性破坏到无以复加。如果想要体验较多的光影，请将显卡驱动回滚至 22.6.1 及以前。

  • 使用了英特尔系列显卡 。英特尔系列显卡对光影的支持一直很糟糕。如果你的电脑还有独立显卡，请尽量调用独显来运行游戏，若有需要可以查阅 通用问题。

• 光影加载器问题

  • 使用了 OF 的预览版 ，OF 的预览版可能存在未知问题，会导致一系列不兼容现象，有时候还会无法启用光影，若情况如此请更换 OF 版本，如有需要可以查阅 安装光影。

  • 使用了 Iris ，Iris 缺失一些 OF 功能并且存在未知的 BUG，导致各种不兼容情况，若情况如此请更换为 OF。

  • 光影依赖于 Iris ，某些光影的部分功能或整个光影依赖 Iris 的独占特性，若情况如此请更换为 Iris。

  • 光影依赖于 Canvas ，若情况如此请更换为 Canvas，并将光影拖入 resourcepacks。

  • 是原版光影 ，无需光影加载器，若情况如此请将光影拖入 resourcepacks ，并将图像品质改为 极佳！ ，如果你已安装其他光影加载器，则可能需要关闭它们的光影功能，才能切换为 极佳！。

  • 光影过于老旧 ，特别是基于 GLSL 光影核心 的光影，若情况如此请更换光影，若仍需使用请安装 JE 1.12 及以前的版本，并安装 GLSL 光影核心模组和不带有光影功能的 OF。

• 模组兼容问题 ，请检查所用模组的简介页是否有不兼容 OF 的说明，包括但不限于：

  • 未声明与 OF 的兼容性 ，或声明了需要通过设置进行兼容的模组：

    • 视觉类模组（如： 更好的树叶）；

    • 自带渲染的模组（如： 植物魔法）；

    • 此类模组，请前往 光影和模组兼容性 寻找可能的解决方式。

  • 声明了不支持 OF 的模组 （如暮色森林），如有运行光影的硬性需求，可以尝试使用 Iris ^Fabric 或 Oculus ^Forge ，否则，请卸载任何光影加载器。

  • 声明了兼容 OF，但是不兼容其光影模块的模组 ，像 Distant Horizons 这样虽然兼容了 OF 却没有兼容其光影模块的模组，若情况如此，请更换为其他光影加载器，或者卸载任何光影加载器。

  • 需要光影进行主动兼容的模组 ，像 Distant Horizons 和 Physics 这样的模组要求光影进行主动兼容，若情况如此，请更换为声明已兼容这些模组的光影。

Java 版光影能否调用光追加速单元？

可能可以，但不是现在。

Java 版所使用的图形库为 OpenGL，它没有相关的接口来调用加速单元。

但是，一些 Java 版模组正在试图将图形库更换为 Vulkan：

• Vulkan Mod；

• Sodium 的 Vulkan 分支。

• 正在开发中的 Focal VK

理论上可实现调用硬件来加速光线追踪渲染。但以这些项目的开发速度来看，想要在短时间内实现对光影的支持，希望非常渺茫。

我喜欢 A 光影的水和 B 光影的云，我可以把两个包的文件相互替换来混合吗？

通常情况下，不能。

光影包没有标准的做事方式 ，不同的光影在同一个阶段（或者着色器程序）干的事不尽相同，它们向同一个 缓冲区 写入的内容大多数时候也不一致，甚至缓冲区的格式也五花八门。

不同的光影可能会用完全不同的方法干同一件事情，而每个效果的代码也可能与其他效果存在耦合 ，同时会针对光影的整体风格进行调整。

当然，如果你对自己的 GLSL 能力自信，可以试一试，但是不要试图通过简单的文件替换来获得两个包的效果。

• 你可以询问你想组合光影包的开发者，他们的效果是如何／在哪里实现的，这些问题对于结合光影效果是有必要的。

• 但是，不要指望让开发者无条件帮你修改光影，或者教你 GLSL， 这不是他们的义务！

• 当然，你也可以付费委托他人帮你制作。

但是请注意你所选的光影包中的许可协议，在未经授权的情况下发布修改后的光影可能涉嫌侵权！

OptiFine 能与 Iris、Sodium 一起运行吗？

不能。

• Iris 与其功能重复；

• Sodium 与其冲突 ，它们都对原版进行了大量修改优化。

Java 版光影能否搭配 DLSS / FSR / XeSS？

• FSR 理论上可行 ，也确实有光影这样做了（iterationT 3.2 实现了 FSR 1.0）；

• DLSS 目前不可行 ，理由和 前文 一致，无法调用张量核心；

• XeSS 的传统方法理论上可行 ，加速核心独占方法同 DLSS，目前不可行。

光线追踪光影与传统光影的最本质区别是什么？

是否使用了光追算法。

也就是说，只要光影文件里存在光追算法，那就属于光线追踪光影，与你所使用的 GPU 无关。

关于如何区分光追和光栅光影，参阅 那要如何区分光栅化和光线追踪光影？。

Java 版叫 光影 ，基岩版就只能叫 着色器 或 伪光影？

这里有一些有趣的历史渊源：

• 国内最早把 GLSL 光影核心所运行的光影包称为 光影水反 ，后来 OF 合并其功能之后，其功能选项卡 shaders 译名被确认为了 光影 ，但 shader 的标准译名是 着色器。

• 由于修改 shaders 的媒介是 shader packs ，而一个 shader pack 包含了多个 shaders ，因此我们常称呼的 光影 事实上是指代的 shader pack ，而每个光影中除配置文件外由 OF 直接读取并编译的程序则是 shader 。反过来也同理， shaders 再加上各种配置文件就组成了一个 shader pack。

• 也由此我们可以知道，光影和着色器本质上是同义词，光影只是着色器在国内的另一种好听的说法 ，就像你可以把 引力波 称作 时空涟漪。

• 我们则更倾向于将整个 shader pack 称为 光影 ，而其内部的每个 shader 则称为 着色器。

而基岩版由于接口先天的缺乏以及移动设备性能不足 ，无法像 Java 版一样做出效果相对完整的光影，但它仍然叫做光影。
还有一种说法是，基岩版光影没有实时阴影，不配叫光影。然而光影二字，从来都不是指代实时阴影，也不会有任何一位光影作者会提出没有实时阴影就不是光影这种观点！