MineGraph Docs Help

光线追踪相关误区

光线追踪不是着色器？

有不少人喜欢强行区分两者，而事实上他们从未熟知真正的概念：

  • 光线追踪：一种应用广泛的算法 ，在下方有更多细节说明；

  • 着色器：承载算法的载体。

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

官方光线追踪秒天秒地？

下称 BERTX

有一部分玩家会对 微软 与 英伟达 合作出品的 BERTX 持过于乐观的态度，而对民间开发者编写的 Java 版光追光影缺乏关注甚至认为它们并非光追而抱有抵触态度。

经部分破译微软宣传的渲染龙引擎，已知 BERTX 调用了 37 个着色器，均属于 计算着色器 ，同时，BERTX 在光照处理中没有采用任何光栅化流程。

从结果分析看，我们认为 BERTX 依仗的基础优于软件光追光影（采用完全光线追踪渲染方案，使用 DirectX RayTracing API ），这也是大多数乐观玩家的理由。但由于该光影编写组的水平问题， 代码中含有非常多不合理甚至自相矛盾的部分 。这也导致部分效果奇怪，整体呈现的画风诡异 ，也不被大部分光影爱好者认同。
对此，国外已推出基于官方版修改的第三方社区 BetterRTX 光影。感兴趣的玩家可前往 图形站 了解详情。

光影的喜好由个人决定 ，我们不在此强求别人改变观点，但是希望大家对待不同光影有一个正确的态度。

延迟渲染是光线追踪？

参阅： 渲染方法的发展

顾名思义，在延迟渲染中，渲染将延迟至所有物体绘制到屏幕空间的缓冲中。在最后逐光源着色，计算阴影，生成最终图像。

  • 该技术于 Java 版光影中应用已久，存在于市面上几乎所有已发布的 Java 版光影。

    • 事实上，OptiFine 管线就基于延迟渲染。

  • 该技术与光线追踪无任何关联 ，但由于混淆概念的玩家过多，我们在此强调。

  • 有关它的更多技术科普，参阅： 知乎 - 延迟渲染（deferred shading）是什么？

“伪光追”的臆想合集

我们需要在最前面强调的是： 伪光追这个概念在图形学专业领域中实际上是不存在的 ，它主要源于民间社区中的以谣传遥 。而英伟达在商业营销宣传中对光线追踪技术的命名和解释不恰当，导致定义模糊，也是这一错误概念广泛流传的可能原因。
因此，我们希望大家能够正视社区中的光线追踪光影，不要被错误概念所迷惑，在发现这一概念被误用时，积极进行科普解释，维护社区和圈子的环境， 不要让 伪光追 成为下一个 材质包。

伪光追 或称 假光追、 拟光追、 类光追 ，是光线追踪相关误区的重灾区。

  • 本文仅解释 Minecraft 中的 伪光追 说法，其他游戏尚对其有不同解释。

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

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

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

伪光追 的起源：

  • 该概念其最早用于国内某技术成果的包装宣传 ，遂成一种没有实际意义 ，但具有宣传效果的营销手段。

  • 于 2019 年左右被一些名气较高的 UP 错误宣传，流毒无穷，至今未消。

首先我们应明确一个概念： 伪光追 不存在，也不能用来指代光线追踪以外的所有渲染技术 。我们调查了所有原因，然而它们的本质都是错误应用二极管思维， 强行将原本有其它命名的技术归类为伪光追。

以下是我们记载的各种各样将技术称为 伪光追 原因及反驳：

将使用光栅化效果称为伪光追

参阅： 既然有伪 3D，为什么不能将光栅化称为伪光追？

光线追踪主要是模拟物理光学的部分过程，从而产生物理正确的 全局光照 效果（包括直接光照、间接光照、体积光、焦散等）。

而使用光栅化实现光照本质上是使用数学方法拟合部分光学效果的视觉现象并叠加，从而避开昂贵的求交算法 （特别是早期 GPU 性能不够强）。

也可以说，光栅化实现的光照效果在流程上和光线追踪并不沾边，只是在数学上近似物理光学结果 。比如现在光线追踪还无法模拟波动性 ，但是你可以用算法强行写一个模拟波动性干涉结果的光栅算法，它只是在拟合物理，而不是光线追踪。

各种光栅化技术对光照的贡献并不好界定，比如我们通常将天空颜色乘以一个小值来模拟天空环境光照，并将其乘到场景上：

vec3 color = albedo.rgb * skyColor * 0.01;

它和后处理中提升画面亮度的代码没有本质区别，

vec3 finalColor = color * 2.0;

本质上都是画面颜色乘以一个值。同时也说明，光栅化不仅仅是为了拟合光学结果，它还能胜任其他处理工作 。因此将前者称为伪光追是极其鲁莽的。

用真／假区分软／硬件光线追踪

这种说法一般认为 BERTX 才是真光追。

如之前内容所述， 光线追踪由是否采用光线求交算法决定，与所用 GPU 无关，甚至与是否使用 GPU 无关，区别的只是性能表现。

  • 基岩版限制 GPU 型号的原因更多与市场有关，在游戏中主要的原因则为没有加速核心的显卡难以流畅运行游戏。

  • 所谓硬件光线追踪是指使用硬件内的相应核心对光线求交过程进行加速 ，而非独有算法和技术 ，因此该说法是错误的。

将手机能运行的光线追踪称为伪光追

如今，手机芯片厂商也陆续推出了支持光线追踪的手机芯片，尽管实现方案可能有所差异，但这并不影响光线追踪能够在手机上运行的事实：光线追踪本质上是一种通用算法，仍属于数学计算，甚至在 CPU 上运行也是可行的， 且 极客湾 甚至已经演示过。

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

光线追踪最初的目的就是在计算机上模拟光路的传播。无论是使用了光追加速核心的硬件实时光线追踪技术，还是最初应用于电影的离线渲染技术，都依靠着色器完成。

直接将代码模拟光线追踪定为伪光追，这种说法自相矛盾。

将“贴图光追”视为为伪光追

这里所谓的 贴图光追 在一部分笃定者眼里指的是 Java 版的光线追踪光影所产生的光照；另一部分笃定者则认为 PBR 资源包让光影在纹理表面产生了真实的光线交互，创造出不同的质感，所以这些资源包产生了贴图光追。

尽管它们已经自相矛盾，但我们还是需要在这里解释一下：

  • PBR 无论在光栅化流程还是光线追踪流程中，都是计算机图形学对物理现象的 近似 ，其核心是 渲染方程。

    • 唯一不同的是，纯光栅化流程中，我们忽略了那些需要积分的部分，也就是说无法反射场景 （除了同样用算法描述的大气和云，以及固定位置的光源高光）。

      • 当然，你也可以积分屏幕中的信息，这样就形成了屏幕空间光线追踪。

    • 而光线追踪流程中，光线追踪这个过程本身充当了蒙特卡洛积分的部分，让表面得以反射场景。

  • 而 PBR 资源包只是定义了方块表面的材质属性，从而让支持 PBR 的光影允许将这些参数导入渲染方程。

    • 事实上，没有 PBR 资源包时，支持 PBR 的光影通常默认表面材质为完全粗糙的非金属。

    • 部分光影还硬编码了一部分方块的材质属性（如金块、铁块等）。

真正的“贴图光追”见 下文。

认为构建 Minecraft 所用的语言无法实现光线追踪

MC 使用的图形接口为 OpenGL JE 、OpenGL ES BE(安卓/iOS) 、DirectX BE(Windows/XBox) ，与构建游戏本体时使用的编程语言无关。

将一些 Java 版光影提供的 RTX 预设 视为拟光追

这些类似的预设只是尝试模拟了基岩版 BERTX 的色彩风格 。而此说法可能造成歧义，使用户认为该光影使用了 RTX 技术。

我们也不提倡不进行任何解释就直接使用此类宣传语。

将基岩版最新引入的延迟渲染技术视为伪光追

参考 前文 ，若将其视为 伪光追 ，则所有光影无一幸免。

将屏幕空间追踪视为伪光追

屏幕空间追踪 在一些光影中也被称为屏幕空间路径追踪（SSPT），在本文中统一使用屏幕空间追踪（SST）。

SST 是受限于 屏幕空间 ，效果不及其它 世界空间 光线追踪解决方案，有说法由此认为 SST 并非光线追踪技术。

虽然 SST 仅在屏幕空间进行，且使用帧缓冲上的几何信息，无法获取屏幕外信息，但其流程与光线追踪无异。

有贴图光追这种东西？

该说法来源已不可考 ，笃信者的理由是 Java 版光追光影不使用也不能使用光追单元，因此只能是利用贴图进行渲染。

然而如 用真／假区分软／硬件光线追踪 所述，是否为光线追踪和是否使用光追单元没有关系，所谓光追单元只能加速求交，而不是独占算法。核显能运行光影也并不能推论出该光影是否含有光追算法。

所谓 贴图光追 在渲染技术上的真正学名应为贴图光照 ，更准确地说是预烘焙 。它能够将事先渲染好的场景光照信息以纹理形式“贴”到场景中（更准确的说是将一张三维纹理扩散到场景中），被广泛应用于一些场景固定的游戏。但在地形随机、场景复杂的 Minecraft 中，这种技术的效果并不理想，也从未被光影或资源包开发者使用过 1。

[1] 唯一有记载的是早年间有一张 镜之边缘跑酷地图 试图使用了地图资源包模拟光照效果（将阴影绘制到纹理上然后按需布置方块）。

光追和光栅的关系

既然有伪 3D，为什么不能将光栅化称为伪光追？

首先我们要理清伪 3D 和真 3D 的区别：

伪 3D

在二维空间中变换 二维顶点（图像） 从而达成视觉 3D。

结果导向：将二维图像根据现实生活中的经验 （近大远小，近物遮挡远物等）直接变换（乃至前期绘制各种图块时就形成了空间关系），从而产生直觉近似的空间观感。

二维图像经验变换近似空间观感的二维图像
真 3D

在三维空间中变换三维顶点组成的二维平面从而达成视觉 3D。

过程导向：将三维空间中的二维平面根据数学公式 （矩阵变换、透视除法等）投影到视平面上，从而产生数学准确的空间观感。

三维顶点组合二维平面三维空间数学变换准确空间观感的二维图像

不难看出，伪 3D 和真 3D 的主要区别是看原始数据是否来源于三维空间，而次要区别则是计算过程和结果是直觉近似还是数学正确。

那么从这个结论出发，我们来看光栅化和光线追踪的定义：

光栅化

拟合光线传播的结果形成的各种视觉效果。

结果导向：将三维场景根据现实生活中的经验 （大多，向光面更亮、近光源物体会投影、没有直接光源也能照亮一些区域等） 或 物理公式 （少数，屏幕空间追踪等）进行色彩处理（采样几何数据进行计算， 屏幕空间追踪 也在光栅化之后进行），从而产生直觉近似的光照观感。

在 向前渲染 中： 场景几何信息精确　经验公式或物理公式近似现实观感的场景
在 延迟渲染 中： 场景几何信息缓冲区经验公式或物理公式近似现实观感的场景

光线追踪

模拟光线传播的过程并最终产生各种视觉效果。

过程导向：将三维场景根据光学物理公式 （光线的反射、折射、散射等）进行色彩处理（根据几何数据进行求交、计算和积分，算法表现出来的就是在“追踪”每一条光线与场景的交互结果并求和），从而产生物理准确的光照观感。

在 几何光线追踪 中： 场景几何信息精确　物理公式准确现实观感的场景
在 屏幕光线追踪 中： 场景几何信息缓冲区物理公式近似现实观感的场景

可以知道，光栅化和光线追踪的原始数据都是场景几何信息 ，只是计算的过程不同：前者直觉近似，后者物理准确，而屏幕空间追踪更是同时脚踏光线追踪和光栅化两只船。

相比真 3D 和伪 3D，光栅化之于光线追踪更像是经典力学之于相对论和量子力学：

  • 经典力学在宏观低速（日常生活）下符合直觉且基本准确、公式也相对更简单；

    • 光栅化在常规场景中可以保持直觉真实的观感，算法对 GPU 负载也较小；

  • 高速和微观需要更加精确的相对论和量子力学，且公式较为复杂；

    • 光线追踪才能在光学复杂场景中保持光照的准确性，确保场景不失真，算法对 GPU 负载较大。

我相信应该没人将经典力学称为伪物理吧？

那要如何区分光栅化和光线追踪光影？

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

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

若想通过自己的能力检测，除了死磕选项外，从光的粒子性质入手是一个很好的检验手段。

间接光照

间接光照的特征较为明显，通过一些简单的观察即可区分。

  • 在设置中通常称为光线追踪全局光照；

  • 观察光影是否有小孔成像；

  • 研究光线是否存在二次以上的反弹；

    • 一些光影不会直接让光子进行多次反弹，而是使用 辐照传播体积 进行辅助；

    • 一些光影使用 反射阴影贴图 ，不过它们无法自然产生环境光遮蔽，你可以据此判断是否为光线追踪；

  • 遮挡间接光源的遮蔽物能否投射出准确的遮蔽阴影；

  • 观察方块光源能否投射出清晰的阴影（虽然方块光源在一定程度上属于直接光照，但是在 Minecraft 中，大多数时候都将其当作间接光照处理，有例外是 Rethinking Voxels）。

直接光照

一些光影引入了光线追踪平行光（太阳／月亮光照），由于目前阴影贴图优化技术繁多，判断比较麻烦，因此这里给出更多判据。

  • 在设置中通常称为光线追踪阴影、光线追踪接触阴影（注意不要和屏幕空间阴影混淆）；

  • 你可以通过观察实体和不规则方块与地面的接触边缘是否会产生浮空、阴影是否锐利无锯齿来初步判断；

    • 你需要刚好将接触点放到屏幕外，以排除屏幕空间阴影的干扰；

    • 实体通常无法写入数据存储，因此有实体阴影的光影可以判断使用了阴影贴图，但是无法判断是否使用光线追踪阴影；

    • 一些光影针对光线追踪直接光照也生成了软阴影，或者当光线追踪阴影脱离投影物一定距离后逐渐消隐，因此当远离接触面时会影响判断；

    • 一些光影引入了 RTW 阴影来根据玩家能观察到的区域扭曲阴影贴图。其可以最大化地利用阴影贴图，从而使低分辨率阴影贴图也能产生高精度的阴影。这种情况下我们就不要钻牛角尖了；

  • 通过半影判断较为简单，你可以直接在光影设置中检查是否有 PCSS 软阴影或者可变半影的选项。除此之外阴影贴图的半影混合通常会有一些问题：

    • 由于其需要事先查找遮挡的缘故，当半影查找区域过大，投影物距离投影面很远时，你会发现你自己的影子在经过远处投影物投下的软阴影之前就开始模糊并和其混在一起难以区分了；

    • 若你的影子和方块没有混合在一起（一定要是大半影区域），两个区域都清晰可分的话，那么光影大概率使用了光线追踪直接光照，并辅以阴影贴图用于处理实体。

反射

反射特征最为明显，可以直接观察能否反射镜头外或被遮挡的物体。

  • 对于 Java 版，体素光追中的实体和未编码物体无法反射；

  • 一些光影存在反射捕获功能，即可以将你看到过的场景记录下来并将其作为环境贴图进行反射；

  • 对于这类光影，你可以尝试重载光影来刷新缓存，或在场景远处建一面镜墙，再在近处建立一面镜墙，然后观察它们反射的被遮挡物是否随着位置而变化，若反射内容有差异，则是光线追踪反射。

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

此外，你可以在 这里 查找一些我们目前收集到的光影的光线追踪特性信息。

那些年被误会的光影

受伪光追的荼毒至今，我们收集了很多光影和光线追踪相关的趣事，遂在此记录：

Sildur's Vibrant Shaders

《田园光追级光影》

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

  • 但在某论坛中被打上了 田园光追级光影 的标签，理由是 体验达到了光追光影的水准 ，随着论坛关停，这篇帖子也终于沉入互联网的大海。

BSL

《（伪）光追光影》

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

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

BSL_Edit_Pasquale

《伪光追光影》

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

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

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

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

SEUS_PTGI_ E13

《Cody 的秘密发布》

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

  • 其实它来自一个国外的 Patreon 翻版网站，在上面其他用户可以分享对应 Patreon 创作者的付费解锁资源，当然也可以分享一些毫无关系的东西。

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

  • 据分析，它应该是 E11 版本的轻度修改 ，并未有很大变动。因此很可能是某个人在该网站上传的整蛊文件。

  • 该网站在几年前就已经被关停， Cody Darr 也公开了自己所有的 Patreon 内容，这个玩笑性质的魔改也就石沉大海了。

Complementary Shaders

《光线追踪预设》

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

  • 然而在某论坛的搬运帖里再次被打上光追标签，原因在于：该光影宣传时提到它的场景色调中包含模仿 BERTX 画面风格的预设 ，被误以为引入了光线追踪渲染技术。

  • 在论坛关闭之前该帖子已修改内容，避免了进一步的误导。

  • 新版本的 Complementary 引入了一个极简的 辐照传播体积 用以渲染彩色光照，这算不算是一种一语成谶呢？

08 四月 2025
误区纠正问答