最近总算是等来起源 2 的 CS2 beta了，随之而来的最大变化，图形肯定算一个。作为快被 s&box（不算 HLA）的起源 2 开发工具 hang detected 了快 100 小时的人，并且爱好还是计算机图形，于是出来对这次的 CS2 图形发表下看法。

为了能写得让玩家们和入门起源开发萌新能看懂，就不搞一些很难啃的专业概念（因为我也啃不明白）但简单的是有的，就不把什么 渲染方程，双向反射分布函数 这类东西搬上来吹水了，虽然这样可能会在描述时出现一些偏差，但作为普通 CS2 / 起源 2 爱好者了解这些已经非常够了。

这里也插句题外话，起源 2 的资源管理系统和起源1相比有长足进步。从游戏加载时间这一点就能看出来，我的三星 980 (PCIe 3.0) 基本上 5 秒读完 de_dust 2 的条。（主要是印象有点深刻就写下来了）

·更加现代化的图形 API

起源 2 原生支持 DirectX 11 和 Vulkan API，意味着支持的着色特性比以往多得多。众所周知，起源 1 的着色器模型标准还停留在 SM 3.0 时代 (DirectX 9.0c)。并且由于 DirectX 11 支持多线程队列的调度，Vulkan 具有更接近硬件抽象层的特性等，它们都能够让游戏绘制指令的处理相较于起源 1 得到大幅优化，对于今天吞吐量极高的 CPU, 显卡 来说无疑是很好的。

这次图形 API 的改进，更多体现出来的是帧数上的提升。（谁叫起源1这么拉呢）

目前 CS 2 可通过 -vulkan 直接启用 Vulkan 渲染。

·基于物理的渲染 (PBR)

起源 2 引擎原生支持基于物理的渲染 (PBR)，这使得材质观感上升了多个层次。起源 1 因为年代久远并不默认支持 PBR，除非魔改底层。（如 Apex）

起源 2 的全 PBR 流程带来的直接好处就是画质观感的提升。起源1仅支持简单的凹凸贴图，只能让纹理看上去更有立体感，但是质感不能体现出来。而起源2完美解决了这个问题。

实际体现在游戏里就是 金属看上去更像金属，泥巴看上去更像泥巴了。而不是起源1那样 金属 和 泥巴 的光泽看起来像一个东西。当然目前CS2的很多地图并没有大量使用 PBR 材质（以后也不一定会），起源 2 该方面的优势并不能体现。

关于起源 2 引擎该特性更完美的体现，可参考 半条命：爱丽克斯 的最高画质渲染。

·更好的全局光照(GI)效果

这里指的是 静态 的全局光照，因为 V 社游戏绝大多数都无需实时的大规模光照变换，于是起源的全局光照就干脆全部靠离线烘焙来实现。起源引擎一直有一个叫做 “VRAD” 的光照编译器，负责利用辐射度 (Radiosity) 算法计算漫反射的传递，以此来预计算全局光照。

详见：VRAD - Valve Developer Community (valvesoftware.com) 

起源 2 使用的是最新的 VRAD 3，对算法进行进一步优化，且采样率非常高，效果优异。

起源 2 的烘焙效果和起源 1 相比有很大提升，反映到 CS2 上则是光影观感的巨大提升。

但是注意：它没有任何一点实时的元素，所以一动起来就会露馅。

这里补充：

全局光照 = 直接光照 + 间接光照 (衍生光线反弹)

游戏的层次感，氛围感（例如傍晚的太阳光充满整个房间，显得十分温暖，柔和），多来自系统计算间接光照的多次反弹到终点的颜色。

V 社在起源 2 的光照编译方面的算法做出了部分优化，压低计算过程中产生的一些artifact.

现在很多大厂的游戏都拿 实时光线追踪 来做 间接光照 了，这也是一种趋势。但是V社不跟进显然也是有原因的，因为他们家的游戏完全不需要。并且还能把这方面的压力转移到开发者而不是玩家身上，毕竟不是谁都拥有一块 RTX 显卡。

但是 VRAD 一直到起源 2 以来都仅支持 CPU 编译，个人认为这是非常脑瘫的。

从 V 社曾在 SIGGRAPH 2007 发表的一篇技术论文里可知 ，他们其实在起源 1 时期就实现了一种高效的多线程 SIMD 硬件跑离线光追的系统。但是就是不用在 VRAD 上。

GPU 计算单元的本质是一种 SIMD（单指令多数据流）硬件，软件上大多以 SIMT（单指令多线程）的模式来运行。

但好在有泄露代码表示，VRAD 3 可能今后将支持硬件光线追踪求交加速。对于以后 CS2 的地图制作者们来说无疑是件大好事。

·新瓶装老酒——基于前向管线的渲染

没错，V社还是那么地热衷于前向渲染 (Forward Rendering) 

其实起源 2 已经提供了对 延迟渲染 (Deferred Rendering) 的支持，但是基本上没有人用，所以鲜有人知。

但是前向渲染某种意义上来说也确实对 CS2 来说是件好事。因为开启 MSAA 的开销比延迟管道的小得多。

要是 CS2 搞个延迟渲染，如果 TAA 的 Neighbouring clamp 没做好的话，真不敢想象习惯低分辨率 CSGO 玩家开 TAA 时那种 ghosting 糊得到处乱飞的感人场面。对于 CS 这样画面对竞技性必须影响较小的游戏来说，MSAA 抗锯齿一定是一种最优解。而前向渲染很容易处理 MSAA.

当然 V 社也设置了 FSR 2 的支持，也是一种时域上的算法，但是比 TAA 锐利。

其次，就是 V 社一直以来引以为傲的着色器渲染。前向管道因为场景物体是一个个画出来的，很容易针对多个对象设置多个 shader，以此堆砌真实感。（不过这个对 CS2 应该没啥用，主要是 HLA）

起源 2 的前向管道实际上是一种 Tile-Based Forward 的管道，支持的光源数上去了，算是对时代的一种妥协吧。这种模式既不前向也不延迟，本人对它的评价其实不怎么样，有时不如直接用 Deferred，而且这个特性还造成了一些性能问题，后面会做出分析。

·基于体积像素的渲染

这里主要指的是烟雾的渲染，从 V 社放的视频也很容易辨认出这就是体素化的烟雾。宣传片里也吹了这烟多么多么厉害，在这里不做赘述。

早在 s&box 早期，体素在起源 2 里就已经实用化了。只不过 Facepunch 没有把它用在烟雾上，当时的演示只是一个简单的实时固体生成。

过渡：优化分析（NVIDIA）

从 NVIDIA Nsight GPU 的分析结果来看，烟雾还对 GPU 缓存有更多需求。因为体素化数据是存在 SRAM 里的，计算烟的数据需要频繁访问。实际上这个是可以优化的，根据 GPU Trace 数据分析，优化好 L2 吞吐的帧数有待提升的空间大概在 3-6%

并且在烟雾场景下，也存在着其它大量需要优化的元素，在此不作过多解释。如果一并优化到位，烟雾场景总体性能提升保守估计有 25%-30%+ 

在日常游戏环节，吞吐高的单元也是集中在一级/二级缓存, 显存以及 misc，而不是计算单元（SM）。

并且 CS2 的 L1 访存相关问题也是可以进行优化的，能提升的性能还不少。

对于 SM 负载较低的问题，个人分析这和 V 社在起源 2 的设定有关，起源 2 本身不是特别注意实时渲染，通过开发机离线算好了的数据很多（比如前文介绍的全局光照），所以计算单元吞吐较少是正常的，捕获到的几个 SM 空闲时刻也情有可原。

所以还是希望 V 社能适当添加点新图形技术，让 CS2 更加次世代，因为目前 GPU 的 SIMD 单元运算还不是 CS2 帧数的瓶颈所在。

对于管道延迟, L1 的问题，个人分析可能和起源 2 使用的 Tile-Based Forward 渲染模式有关。

s&box 在去年就在起源 2 上应用了 Tile-Based 的前向管道，如今 CS2 和 s&box 为同一版起源 2 引擎，这里也相当于在回答 s&box 的一些问题。

因为 Tile-Based 模式的渲染需要等待生成 Tile 表才能进行进一步光栅化操作，这会造成整个管线的一些延迟；并且 Tile 表存放在 SRAM 里，对内存吞吐量也有明显的推动，这可能也是几组数据显示内存子系统吞吐量占比很高的原因。

简而言之，有些副作用是 CS2 本身附带的。

“环境光遮蔽（AO）”

这里打了引号，所以不难理解要表达什么。CS2 画面设置里的“环境光遮蔽”并不是大家所熟知的 SSAO 这类，只是起源 2 的一个针对动态物件的阴影叠加功能，性能影响其实不高。不过鉴于起源引擎一直以来都没有自带过真正意义上的 AO，我一直都非常期待 V 社哪天也把这类技术应用上。（不过还有一种最大的可能，就是目前只有 V 社才了解细节的起源 2 完整版）

一般地，环境光遮蔽背后的基本思想是：如果预处理一个模型，去计算每个点可以探测到多少的外部环境，以及有多少的外部环境会被模型的其他部分遮挡；那么就可以在渲染时使用这些信息来计算漫反射阴影项的值，最后结果就是模型的缝隙等很逼真地变暗，模型的暴露部分接收到更多的光线，因此更亮。

总的来说，CS2 的图形方面，其实惊喜不大。不能说和 s&box / HLA 的一模一样，只能说完全一致。但是和 CSGO 一对比，你会发现惊喜确实是有的。

最后也祝愿我们 CS2 和起源 2 引擎越来越好！

Reference

[1] Green C . Efficient self-shadowed radiosity normal mapping. ACM, 2007.

[1] Antochi I ,  Juurlink B H H ,  Vassiliadis S , et al. Memory Bandwidth Requirements of Tile-Based Rendering[J]. DBLP, 2004.

[1] Pharr M ,  Green S . Ambient occlusion[J]. gpu gems, 2004.