光线追踪

未经优化的文档

这篇文档的格式较为不规范。

误区介绍

此部分用于提升大众对光线追踪该技术的理解，同时记录了多种反例并逐一纠正。
阅读这些内容，可以避免被光线追踪这个噱头迷惑认知、蒙蔽双眼，在充斥着错误说法的角落里仍能保持清醒。

概念普及

光线追踪与光影（着色器）

有不少人喜欢在对话中强行区分两者，这里我们作出简单概念解释。

  • 光线追踪：一种应用广泛的算法，在下方有更多细节说明；
  • 光影（着色器）：承载算法的载体，即程序。

实际上两者并非对立概念，只是一些人喜欢将后者贴上“非光线追踪”的标签，概念理解错误而不自知。

光线追踪

  • 在三维计算机图形学中，光线追踪是一种对光线传输进行建模的技术，用于生成数字图像的各种渲染算法。
  • 在计算成本和视觉保真度方面，基于光线追踪的渲染技术，如光线投射、递归光线追踪、分布光线追踪、光子映射和路径追踪，通常比扫描线渲染方法更慢，保真度更高。 因此，光线追踪首先被部署在可以花费相对较长的时间进行渲染的应用中，如静态渲染的计算机图像，以及电影和电视视觉效果（VFX），但不太适合实时应用，如视频游戏，因为在渲染每一帧时，速度是至关重要的。
  • 然而，自2018年以来，实时光线追踪的硬件加速已成为新的商业显卡的标准，图形API也紧随其后，允许开发人员在游戏和其他实时应用中使用混合光线追踪和基于光栅化的渲染，对帧渲染时间的冲击较小。
  • 光线追踪能够模拟各种光学效果，如反射、折射、软阴影、散射、景深、运动模糊、黄昏、环境遮蔽和色散现象（如色差）。它还可以用来追踪声波的路径，其方式与光波类似，通过渲染逼真的混响和回声，使其成为视频游戏中更具沉浸感的声音设计的可行选择。事实上，任何具有近似线性运动的物理波或粒子现象都可以用光线追踪来模拟。
  • 基于光线追踪的渲染技术，涉及到在一个领域内对光线进行采样，会产生图像噪音伪影，可以通过追踪大量的光线或使用去噪技术来解决。
  • —— 维基百科 · Ray Tracingopen in new window

混合光线追踪

  • 也叫 部分光线追踪。
    • 现阶段的 实时光线追踪技术 处于 初步开发阶段，
    • 而 传统的屏幕空间技术 已达到 炉火纯青 的境界。
  • 实际上，大部分 支持实时光线追踪的 3A 游戏 都 未采用 完全光线追踪 的渲染方案，
  • 而是 采用 传统 + 光追互补 的 思路 构成画面：
    • 这样既能有 光追的效果，
    • 也不至于因为 效率太低 导致 帧数 过于不合理。
  • PTGI 的思路也与此类似：
    • 将 整个着色器 的 部分渲染方案 用 光线追踪技术 替代 传统反射，
    • 做到 兼顾足够流畅 的 帧率 与 画质 的 提升。

完全光线追踪

  • 与 混合光线追踪技术 不同，完全光线追踪技术 只使用 Compute Shader （计算着色器） 渲染画面，抛弃 传统的光栅化 流程。
  • 目前该技术的 主要意义 在于 开创新的 图形开发思路。

路径追踪

  • 路径追踪算法是基于蒙特卡洛采样算法的光线渲染方法，其核心思想与逆向光线追踪一致。
  • Kajiya 于 1986 年提出了路径追踪算法的理念，开创了基于蒙特卡洛采样算法的全局光照这一领域。路径追踪的基本思想是经过逆向光线追踪的一系列计算，撞击到光源后，用蒙特卡洛的方法，计算其贡献，作为像素的颜色值。
  • 简单来说，路径追踪 = 光线追踪+ 蒙特卡洛采样算法。

屏幕空间路径跟踪

  • 屏幕空间路径跟踪即 SSPT ，是在路径跟踪技术的基础上加以限制，使其只计算屏幕中的三角面以达到减轻性能负载的目的，是一种廉价的实时光线追踪解决方案。

  • SSPT 表现出来的效果酷似屏幕空间反射（SSR）。因为两者在算法与最终效果上都有许多相似之处。

误区与解释

Windows RTX

有一部分玩家会对 Microsoft 与 NVIDIA 合作出品的 Windows 10 Bedrock 版 RTX 光影 持 过于乐观 的态度，而对民间开发者编写的 Java Edition 光追光影 缺乏关注甚至认为它们 并非 真光追 而抱有抵触态度，我们对此观点阐述如下。

  • 对于 真伪光追 说法，我们在下方 伪光追 中有说明。对于 RTX 光影，我们有以下研究结果：

    • 经部分破译微软宣传的 渲染龙（ Render Dragon ）引擎，已知 Windows 10 版 RTX 光影 调用了 37 个 着色器，均属于 Compute Shader （计算着色器），

    • 这也意味着 Windows 10 版 RTX 光影 完全使用 了 RTX 显卡 的 光追核心 计算渲染 所有 的画面效果，没有采用 任何光栅化 流程。

    • 从结果分析看，我们认为 Win10 版 RTX 光影 使用的 基础技术 优于 软件光追光影（采用完全光线追踪渲染方案），这也是大多数乐观玩家的理由。

    • 但由于该光影编写组的 水平问题，代码中含有 非常多 的 不合理 的甚至 自相矛盾 的部分。

    • 这也导致部分渲染 效果不合理，整体呈现的 画风诡异，也不被大部分光影爱好者认同。

  • 对此，国外已推出基于官方 RTX 修改的第三方社区 BetterRTX 光影。感兴趣的玩家可在 BetterRTX 了解详情。

  • 光影的喜好 由个人决定，我们不在此强求别人改变观点。毕竟，提升现今着色器的图形技术 才是我们的追求目标。

伪光追

  1. 伪光追 或称 假光追、拟光追、类光追：

  • 该词条仅解释 Minecraft 中的 “伪光追” 说法，其他游戏尚对其有不同解释。

  • 是在国内光影界流行的涉及光线追踪技术所谓 真伪问题 的多种 错误说法 的总称。

  • 该词语在 图形学术语 中 尚无明确的 定义与解释；

  • 多数认为 伪光追 存在的玩家认为该词代指下方第一个说法，但 至今未有任何成果能够佐证该说法。

  1. 伪光追 的来源：
  • 该概念其最早用于国内某技术成果的 包装宣传，遂成一种 没有实际意义 ，但 具有宣传效果 的营销手段。
  • 于 2019 年左右被一些名气较高的 UP 错误宣传，流毒无穷，至今未消。
  1. 首先我们应明确一个概念：伪光追 ≠ 光线追踪以外的所有技术。我们调查了所有原因，然而它们的本质都是错误应用二极管思维，强行将原本有其它命名的技术归类为伪光追。以下是我们记载的各种各样的原因：

  • 认为可以 使用非光追手段（光栅化）实现光线追踪效果：

    • 光线追踪技术可作为实现 全局光照 或一些其它效果（如焦散、丁达尔效应（体积光），阴影）的一种手段，这些效果使用传统光栅化也能实现。
    • 但按照这种定义走下去，光栅化理应实现一些后者 独有 的现象，如小孔成像、光的色散等，但实际上并不能。
    • 因此只能够说 光栅化同样能够渲染出光线追踪能实现的部分效果 ，而非急着盖棺定论，认为实现光线追踪技术能够做到的部分效果=伪光追。

  • 认为可以 用真假区分软/硬件光线追踪：

    • 这种说法一般认为 基岩版 RTX 才是真光追，其他的都是假的。
    • 如之前内容所述，光线追踪 由 是否采用算法 决定，与所用 GPU 无关，甚至与是否使用GPU无关，区别的只是性能表现。
    • NVIDIA 限制 GPU 型号的原因更多与市场有关，在游戏中主要的原因则为 未支持 DLSS 与 RTX 的显卡难以流畅运行游戏。
    • 硬件光线追踪的 优势 在于 效率更高，而非 独有技术，因此该说法是错误的。

  • 将 使用代码模拟光线追踪 定为伪光追：

    • 目前光线追踪技术的实现方法只有一种：通过 在着色器内编写代码 实现。
    • 无论是使用了光追加速核心的硬件实时光线追踪技术，还是最初应用于电影的离线渲染技术，都依靠了该方法。
    • 直接将代码模拟光线追踪定为伪光追，这种说法自相矛盾。

  • 将 贴图光追（预烘焙） 认定为伪光追：

    • 关于贴图光追，下文有一份关于它的记载。
    • 在这里只需要知道它们两个概念不等同即可。

  • 认为构建 MC 所用的编程语言（如Java 、 C++）无法实现光线追踪效果：

    • MC 使用的图形渲染引擎为 OpenGL（Java 版与携带版）、 DirectX（基岩版），与构建游戏本体时使用的编程语言无关。

  • 将一些光影（如 Complementary Shader）提供的 Bedrock RTX 光影预设视为拟光追：

    • 该预设尝试模拟了基岩版 RTX 官方光影的色调。
    • 而此说法可能造成歧义，使听众认为该光影使用了 RTX 技术。
    • 因此我们不提倡一些宣传品的标题直接使用此语句作为宣传语，而不进行任何解释。

  • 将基岩版最新引入的延迟渲染（Deferred Render）技术视为伪光追：

    • 通俗来说，延迟渲染的原理只是将渲染的步骤延迟至绘制好屏幕内所有物体形状后进行。
    • 该技术与光线追踪没有任何冲突，只是基岩版并未使用。
    • 该技术比实时光线追踪更早出现，被用于 Java 版的绝大多数光影。
    • 若将其与伪光追捆绑，即承认包括 Java 版“真”光线追踪光影在内的着色器都使用了伪光追技术，两者理论说法相悖。（注意，光线追踪技术并没有真与伪的概念，此处的真仅用于与伪的对立）
    • 故此观点错误。

  • 其他更多的错误说法。

  • 如果你想要从更深层的角度去了解“伪光追”这个说法，可以观看下面的有关视频。

【BSL到底是不是光追？光追为mc带来了什么？【素影之下 #2】×【光影实验室 #3】】open in new window

屏幕空间路径跟踪（SSPT）

  • SSPT 的效果不及其它光线追踪解决方案，有说法由此认为 “ SSPT 并非光线追踪技术”。

  • 然而，SSPT 的目的是 在节省性能的前提下做到光线追踪渲染，而非实现一些更好的效果。

  • 而且，判定与光线追踪技术有关的标准应是 是否使用光线追踪相关算法 ，仅仅通过最终效果简单粗暴地断言是非常不严谨的。

延迟渲染（Deferred Render）

  • 顾名思义，在延迟渲染中，渲染将延迟至所有物体绘制到屏幕空间的缓冲中。在最后逐光源着色，计算阴影，生成最终图像。
  • 该技术于 Java 版光影中应用已久，存在于市面上几乎所有已发布的 Java 版光影。
  • 该技术与光线追踪 无任何关联，但由于混淆概念的玩家过多，我们在此强调。
  • 有关它的更多技术科普，可参考：知乎-延迟渲染（deferred shading）是什么？open in new window

贴图光追（预烘焙）

  • 该说法来源已不可考， 笃信者的理由是：

    • Java 版光追光影可以不使用 RTX 系列 或 RX6000 系列以上 显卡。

    • 然而，实时光线追踪技术的本质是算法，与 是否调用硬件进行光追加速 没有关系，核显能运行光影也并不能推论出该光影是否含有光追算法。

    • 贴图光追 的真正学名应为 预烘焙 。它能够将事先渲染好的场景以图片形式“贴”到场景中，被广泛应用于一些 场景固定 的游戏。

    • 但在 地形随机、场景复杂 的 Minecraft 中，这种技术的效果并不理想，也从未被光影或资源包开发者使用过。

区分是否存在光追

  • 如果你身边有一些研究 Minecraft 图形学 的（最好是自己做过光影包/纹理包的）朋友，你可以拿着 光影包名称 去询问他们。

  • 如果你身边没有这类朋友，你可以 直接在社区提问，了解的人自然会来解答。

  • 若想通过自己的能力检测，从 光的性质 入手是一个很好的检验手段。

  • 观察光影是否有 小孔成像，或是研究光线是否存在 二次以上的反弹 。

  • 但注意，由于当前技术水平限制，我们所谓的 光线追踪 技术并不能模拟出光的 所有物理性质（例如不能模拟出 双缝干涉 现象）。

Java 版的那些事

  • 累计下来，有几个光影发生了一些有趣的事，在此整理一下：

    • Sildurs Vibrant Shaders - 田园光追级光影

      • 该光影由国外作者 Sildur 编写，效果不输于很多高端光影，帧数十分舒服，属于 传统光影。

      • 但在某论坛中被打上了 田园光追级光影 的标签，理由是 体验达到了光追光影的水准，至今仍存在。

    • BSL - （伪）光追光影

      • 该光影作者为 CaptTatsu ，同样也属于 传统光影。

      • 但在B站某宣传视频中被强行扣上 最棒的室内伪光追光影 的帽子，在评论区快变成光追普及区后，去掉了 伪 字。

    • BSL_Edit_Pasquale - 伪光追光影

      • BSL 早期的一个魔改版本，作者 Pasquale 。

      • 2019 年 7 月 13 日，Pasquale 在推特宣布已获取到 BSL 作者的的 魔改授权 。

      • 同年 9 月 23 日，Pasquale 在自己的 Discord 上 正式发布 该光影。

      • 从发布至今，这位作者都并未提及自己的光影与光线追踪技术有任何关联。而国外也并不流行“伪光追”这种说法。

    • SEUS_PTGI_E13

      • 这个光影出现的原因大部分人都不清楚，它并 不存在 于作者发布的 任何帖子 上，但又好像有着一定的信服力。

      • 其实它来自一个国外翻版网站（现已被关闭）。

      • 最明显的标志是：这个网站出来的文件名往往是以下划线_为分隔，而 Patreon 那边获取到的都是空格分隔。

      • 据分析，它应该是 E11 版本 的轻度修改，并未有很大变动。

    • Complementary Shaders

      • 由 BSL 魔改而来，属于中规中矩的一个光影，在 CurseForge 上有发布。

      • 然而在某论坛的搬运帖里再次被打上 光追 标签，原因在于：该光影宣传时 提到 它的场景色调是 模仿 Windows10 Bedrock 版 RTX 光影，被 误以为 引入了光线追踪渲染技术。

      • 现该帖子已修改内容，避免了进一步的误导。