Counter-Strike 2 图形渲染浅析

最近总算是等来起源 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)

from VDC

起源 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 上则是光影观感的巨大提升。

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

这里补充:

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

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

烘焙全局光照 0

烘焙全局光照 1

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%+ 

起源 2 的图形后端感觉一直都成问题,HLA 和 s&box 都一样

在日常游戏环节,吞吐高的单元也是集中在一级/二级缓存, 显存以及 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.