GameLook报道/8月14日至8月17日，由腾讯游戏学堂举办的2022腾讯游戏开发者大会（Tencent Game Developers Conference，以下简称TGDC）将正式举行。
大会以Inspire Six Senses为主题，汇聚国内外顶尖游戏从业者以及学界专家学者，以激发游戏的创意力、想象力、洞察力、科技力、影响力和凝聚力，共同拓宽游戏产业的边界与可能性。
在8月14日的技术专场论坛上，腾讯互娱START云游戏引擎技术负责人邵岳伟进行了题为《原生云游戏引擎———一种能创造超世代体验的技术》的分享。
以下是分享实录
邵岳伟：各位游戏业界的同仁们，大家晚上好！今天我来给大家介绍一下原生云游戏引擎技术，主要是想同分享一下我们对原生云游戏的一些理解，还有我们在这一块一些技术进展。
今天的 talk 主要分为三个部分，第一部分是原生云游戏技术的一些概念，这个技术能给游戏开发业界一些什么好的改变。第二部分就是从植被渲染的技术细节说起，来谈谈在新的硬件环境下，我们能做到更多的技术特性。最后一部分是进行展望，原生云游戏这个领域还处于探索阶段，还有大量的工作要往前推进， 但是我们也认为他还是具有美好的前景。
我们先从云游戏开始，云游戏这个概念很早就有了，但是直到近些年图形硬件，网络等的发展，这几年云游戏才开始大规模的发展起来。简单说来，云游戏就是从客户端接受用户的操作指令，然后在云端完成所有的游戏模拟以及渲染，最后把渲染结果编码之后发送给远端用户。
因此云游戏本身具有很多优点，对于游戏玩家来说，他不需要下载游戏本体，他可以通过云游戏的平台、网页、小程序等很便利的方式体验游戏，这对于现如今日益庞大的游戏客户端包体大小是一个很好的解法。
而对于游戏开发者来说，在云端的游戏，硬件环境相对比较简单，比如都是A10的GPU，那这个硬件适配的工作就变得非常简单，不用去考虑适配各家厂商的硬件，这些适配工作还是相当花时间的，特别是使用一些新的GPU 特性来作为开发支撑的时候。
而对于游戏的发行来说，近些年的用户买量成本也越来越高，用户转化率也不容易提高，而正如刚才所说的，因为玩家可以不用下载就可以快速体验，这对于用户转换也是一个很大的帮助。
这些都是云游戏能看到的优点，可目前云游戏也存在一些比较困难的挑战。
首先是网络环境要求高，云游戏需要从云端传输实时的游戏视频到客户端，因此需要高带宽、低延时的网络环境。
再者因为需要云端来进行游戏模拟和渲染，一个客户端就需要一个云端对应的算力，因此硬件特别是GPU的成本成为云游戏运营的高昂的成本。
其三，目前的云游戏也还处于游戏上云的阶段，并没有能够体现出云游戏体验优势的游戏，在说服更多的游戏玩家为云游戏来买单还会有一些困难。
最后，如果想开发出更好的云游戏体验（或者不局限云游戏体验），那我们现有的游戏开发管线还需要进行升级。举一个例子来说，大家也看到了最近一些游戏或者引擎当中，超高细节的几何体渲染，模糊了游戏和影视的边界，但是问题也来了，这庞大的几何体数据在运行时刻是一个很大的挑战，而在游戏制作阶段，这么大量的数据的处理对于硬件的要求是更加苛刻。
如果要想为一下代的游戏体验进行研发，升级整个工具制作链也是势在必行的，或者我们可以考虑的一种新的可能性，游戏开发环节就是在远端的服务器上进行的，而不是必须依赖本地的硬件升级。
带着这些挑战，我们来看看原生云游戏技术。
原生云游戏这个概念也一直有人在提，我这里想抛砖引玉的：原生云游戏是在云端利用多个GPU，而这些GPU可能跨越多个服务器，利用这些GPU来模拟、渲染一个更为复杂的游戏世界，并且要为多个用户来提供游戏体验。
这里有几个概念或者目标是特别重要的：第一，优于当前世代的游戏体验，我们都了解游戏的体验是跟随着硬件、显卡的计算能力一起进步的。通过联合众多显卡，就相当于获得超出当世代的GPU算力。因此，能够模拟更加复杂的游戏世界，能够渲染更加真实的游戏体验。
第二，能有获得足够好的游戏体验之后，硬件成本问题也是需要考虑解决的。如果都是7、8张显卡来服务一个玩家，那这个运营成本是很难持续的，因此必须通过各种技术实现来共享这个计算力，达到等价于一个GPU服务好几个在线玩家的过程，这就摊低了硬件成本。
第三，前面提到更加复杂的游戏世界和体验，那将会出现这样一种情况，游戏世界过于复杂，本地的硬件开发环境无法承载，这可能倒逼我们把游戏开发环境放到云上去。
谈了这么多大费周章的原生云游戏，那这个东西都给我们带来什么呢？
对于游戏艺术家，这个意味着前所未有的自由度，基本需要限制建模的面数、贴图的大小、材质的复杂程度，以前游戏中很多约束被打破，可以尝试更多以前游戏中未实现艺术效果。
对于gameplay的开发者，由于原生云游戏天然就具备多人联网的特性，不需要再考虑游戏同步的问题，这对于一些小团队来说是一个很好的福音，他们只需要去打磨好多人游戏的玩法本身，省去了多人同步的开发成本。
对于游戏引擎开发者呢，在这个全新的硬件环境下，拥有了更多可以运用的算力，可以去探索游戏图形广袤的空间，这一点我们也会在第二部分的技术talk里面所谈到。
对于游戏设计师来说，终于也不用天天被告知，这也实现不了那也实现不了，很多特性都可以实现了，而限制他们的是自己在游戏设计方面的想象力。
说了这么多，下面看一下我们目前实现一个原生云游戏的demo。
为什么是植被技术呢，一方面是UE5出来以后，对于像以石头、建筑为主的场景已经有了比较好的解决方案，UE5对于这类型的场景解决得非常好，但对于植被这类的场景还解决得不是太好。另外植被这个技术的解决过程也能体现出我们在基于云端多 GPU 的环境下，有了很多的新的技术工具了。
先来看问题，这是一片使用nanite渲染的树林场景，我们看到远处树叶已经被消失掉了。当然我们可以通过调整参数的方式避免这种情况，但是这个性能的消耗是巨大的。
Nanite会根据视点距离逐渐拉远，mesh cluster逐渐变得稀疏，小三角形逐渐合并成大的三角形，而这个三角形的合并，也因为视点距离变远不会被观察到，也就不会对最终的图像有所影响。但是我们注意到像树叶，草这样的几何体，他是大量的而且离散的，按原有的方式无法把逐渐的合并三角形。
因此，我们看到当使用类似 nanite 这样的方式来处理树叶，草这种情况，会出现如图所示的问题，当视点拉远之后，因为树的三角形面，都变得特别小，因此这些三角形都被剔除掉，最后所显示的结果就是树变得特别小了。
这其实也产生了一个问题，如果我们的艺术家在制作一个非常精细的场景时候，其他资产都非常精细，都是影视级别的资产，但是植被因为有所限制，没办法达到同样精度的话，整体表现就会形成一个比较奇怪的情况，很容易形成一个短板。
另外一个比较痛苦的事情是，复杂植被的场景，通常会出现比较严重的overdraw，也会给光栅化单元（rop）带来非常大的压力。常用的prez的方式，也因为植被渲染多使用alphatest的情况，变得不太高效。
而像树这样物体，大量充满着空洞缝隙，很多时候针对于一棵树的遮挡剔除，很难有效的剔除，反而增加剔除的成本。
对于植被的 lod 的生成也必须要谨慎的处理，处理不好很容易出现lod 的跳变。
以前世代的游戏图像画面，可能对于这个跳变比较能容忍，但是如果我们追求影视级的画面体验，这个跳变属于很糟糕的体验。像大家之前玩游戏，玩家在一片草地中行走，不远处有草突然冒出来，大家也都习以为常了，但是你如果玩家提供影视级别的游戏画面体验这些问题就是不能够被接受的。
另外对于影视级别的树木资产，其几何体存储数据也是非常惊人， 以图示这棵树为例，mesh数据达到了约500MB，面数达到了3000w。而且对于树林这类的场景，streaming也不太好起到很大的作用。
我们简单的计算一下，20种这样的树，显存的占用达到了将近10G， 这对于显存是一个巨大的负担，如果不是很好处理这快的问题，很容易导致显存不足，显存不足导致一堆画面上的问题。
正如上面的展示所看到的，大规模、影视级别的植被渲染，是补齐游戏渲染和影视渲染画面差距重要的一个环节。因此这个问题再一开始就成我们要解决的一个重点问题。
所以我们先梳理一下，针对于这个问题我们会有哪些设计目标；
首先，我们还在云端的硬件平台上来解决问题，目前看，在移动GPU上，都是很难满足我们的要解决这个问题所需的硬件门槛，而对于比较老一点的PC GPU，要去兼容也会有其他很多问题，甚至是分散掉问题的焦点，需要把大量的精力在处理兼容方面。
其次，我们面向的场景是大规模的、影视级别的植被场景，这类场景本身渲染复杂很高，一些之前的渲染方式都不能很好的解决，而只能是通过限制植被资产本身的规格来达到一个实时性，当然这个规格的限制是会牺牲掉影视级别的画面表现。
这些主要需要解决的性能瓶颈，是大规模植被渲染的overdraw。再有我们也要保证一定的渲染品质，主要是避免视点移动时，树的lod切换不能被肉眼所发掘，避免lod跳变所产生的画面瑕疵。还有就是我们尽量自动生成 lod，减少艺术家处理资产的时间成本，让他们把精力都集中场景搭建本身。
我们还是从nanite这种hold出发，生成一组具有层次lod的树状加速结构，用这种加速结构来实现高效率lod的无缝切换，而且还要实现高效率的裁剪。
另外我们也要考虑数据结构的压缩，一棵树的mesh如果是500MB的显存占用，对于显存是一个极大的负担，一些常规的压缩方式，也不能太好处理问题。这一块，通过研究speedtree中树的原始资产，可以发现整颗树由约十几种类型树叶组成，因此通过提取树叶mesh 的实例数据，可以很高的压缩比例。
因此我们设计了一种高压缩存储树模型的格式，首先我们提取所有的基本的叶子mesh，通常有十几种类型（每种类型的 mesh 尺寸在几十KB，texture尺寸在几MB的范围）。
对于整颗树，我们只需要存储基本的叶子模型，还有实例数据，实例数据就是由这样一个结构组成，一个float3的translation，一个float4 的rotation，一个float的scale。
整体的数据就被控制大约10MB左右，相较于原始的模型尺寸，我们压缩了近50倍，这样的压缩存储能够满足我们显存占用的情况。另外我们还测试了用这个压缩结构生成硬件光线追踪的BVH结构，也是获得同样的压缩比例，这样也为以后要用到硬件光线追踪做准备。解决这个压缩的问题之后，我们还需要在运行时快速渲染这样的数据结构。
刚才我们提到树这种的模型，如果用普通hlod，三角形是不太合并的。因此我们考虑用带有alpha贴图的quad来逐级优化优化，当然这每一级的简化是有损失的，当时同样只要视点距离足够远的时候进行lod的切换，这个突变的效果就不会很明显。
因此我们的lod生成策略是这样的，从一片原始树叶蜕化到一个quad， 三四个quad合并成一个大quad，这样依次进行下去，最终蜕化成一个imposter。
对于一个quad来说，我们也是用压缩结构来存储，只存储一个float3 的中心位置，一个half3的切线位置，一个half3的副法线位置，中心的uv坐标，以及uv延展。在运行时，我们用meshshader来把这个 quad解算回来，这样也减少geometry data访问的带宽。
另外还要考虑的问题是我们切换lod的时候不能整体的去切换lod， 这样要不然切换会产生lod明显的跳变，要不然晚切换，会导致性能出问题。
因此我们切换的粒度，最后以单个quadnode为单位，这样逐渐变换，能够保证所见细节不变的同时，也能保证兼顾到性能。
由于生成很多自动的lod，也需要给这些lod生成生成对应的texture。最早我们尝试过用differentialable rendering的方式，来自动生成贴图，但是由于收敛速度比较慢，是的预处理时间变得太长了，这个也不符合我们一开始的设计目标。后面我们改用的是直接把quad lod上一级的texture投影，生成新一级的texture。
另外我们刚才提到我们压缩存储树叶的时候，需要从speedtree中输出树叶的索引信息。但有一大批树的资产他已经没有这些树叶索引信息，因此我们还需要从数目资产估计出树叶索引信息。
这里我们想了一个比较巧妙的方法，第一步我们使用ligigl的库，对树叶模型进行一个划分，生成很多submesh，这里面的submesh就是我们的树叶。
第二步，需要从这些树叶里面找到相同的树叶，我们先把顶点索引数目相同的submesh来进行比较，用他们UV坐标来算一个 hash值，只要hash值相同，我们再整体比较一下submesh的UV，如果所有UV相同，我们再把变换到一个局部空间坐标下，大致的比较一下树叶的包围盒，包围盒如果相同，我们就认为这是同一种树叶，找到基础的树叶类型，我们就不难生成出所有的索引信息。
目前来看，原生云游戏还是很有能力，或者说很有潜力给玩家来提供有足够的竞争力的游戏画面体验，并且能够有办法控制住运营成本。
另外想说的是，在云端游戏内容制作工具方面我们也在大力投入， 这一块确实是希望能够通过这样的工具，扫除一些原来游戏内容制作 中的一些痛点。
例如，我们在云端blender上面的投入，目前有很多美术大佬都开始去用blender来制作一些个人作品。我们正在尝试对这些软件进行云端改造，这个改造并不是说，只是上个云串流一下，而是要去对软件的制作环节进行改造，释放出更大的能力，相信明年如果还有机会来这里，这些新的技术和管线会和大家见面。
对于原生云游戏，我们也更多的期待，我们期待能够游戏开发者带来更大的便利，让他们更加容易setup一个新游戏，快速顺利的通过游戏早起设计阶段，而不用针扎与各种优化，适配的繁琐的细节里面。
跳出行业来看，也希望这项技术领域也能创造正面的社会价值，云游戏本身对于网络，边缘计算服务器的要求，也能促进这些云基础建设的开展。对于影视等传统行业，也可以进行赋能。
那我今天的讲座就到这里，谢谢大家。
如若转载，请注明出处：http://www.gamelook.com.cn/2022/08/493607
