<iframe allowfullscreen="true" data-mediaembed="youku" frameborder="0" id="9IP9ZShK-1720920898707" src="https://player.youku.com/embed/XNjQxMDY0MTAxMg=="></iframe>
Unity引擎制作万人同屏效果
大家好，我是阿赵。
经常在各种渠道看到游戏的广告，会经常看到一些很宏大的场景，比如什么万人国战、千人同屏之类的说法。多人同屏是某些游戏的卖点，比如经典的割草游戏无双系列，或者是末日类主题的丧尸围城游戏。
说出来很失败，阿赵我虽然做过很多类型的游戏，但对于多人同屏，是一直都没有成功过的。之前做MMOARPG游戏，只要同屏玩家多起来，就要做过滤显示，把某些玩家的模型给隐藏起来。
多人同屏战斗，性能的压力不止是来自于渲染，还有CPU的逻辑。我们这里暂时先抛开业务逻辑对性能的影响，单纯只讨论渲染。
为什么多人同屏的时候，渲染的压力会大呢？我个人认为是来自于几个方面的：
1、同屏的面数会很高
假设一个角色的面数是1000左右，如果要10000人同屏一起显示，那么实际显示的面数就是一千万。千万级的同屏渲染，无论如何都可以算是比较高的渲染消耗了。
2、骨骼动画的计算
骨骼动画有很多优点，但也有一个比较明显的缺点。
骨骼动画由于是使用父子相对位置的关系来计算最终骨骼的坐标的，所以需要打的关键帧数据不多，哪个节点有变化就打哪个节点的关键帧就行。但在播放的时候，骨骼需要计算回它真正所在的位置，需要通过一层一层的父子矩阵去计算。
然后顶点的位置是通过蒙皮信息的权重值来计算的，所以每帧都需要确认一个顶点受多少根骨骼影响，再逐个骨骼读取位置乘以权重值，最后加起来，得到顶点的最终坐标。
这两部的计算，如果是我自己写引擎，是会放在GPU里面计算的。但Unity这部分其实是在CPU算好的。所以当骨骼父子连接越复杂，骨骼数量越多，模型顶点数量越多，每个顶点支持蒙皮权重影响的骨骼越多的情况下，消耗CPU的计算也就越多。
3、渲染内容的差异
如果是整个场景里面只有一种模型需要渲染， 那么可能优化的方法很多。比如直接用GPU Instance之类的方法，让引擎自动帮忙合并渲染。
但实际的情况可能没有那么简单，可能会遇到需要渲染的模型并不只单一一种的情况，里面的模型会用到了多种的网格模型和多种的材质球。这样可能引擎就不能合并渲染了。
为了解决这些问题，所以我们不能直接把模型扔到引擎里面，然后完全的依靠引擎的功能来渲染，而需要做出一些特殊的处理。
1、面数问题
面数这个问题比较难处理，所以我觉得只能是让建模师提高技艺，用更少的面数表达出更好的效果。
不过这估计才是整个流程最难的地方。现在从事游戏行业的美术工作者数量很多，建模师也很多。但真正会用少面数表达复杂效果的并不多。我自己项目里面的建模师，用两三万面建出来的模型，看起来和两三千面的模型差别都不是很大。所以我自己知道，我自己的渲染技术，是不可能用在公司的项目里面的。
从这个问题能看出，实际上想要提升性能，并不是几个TA和前端程序在埋头苦干就能解决的。如果缺少了传统美术人员的支持，这个事情从开始就不用想了。
2、骨骼问题
在出现骨骼动画之前，实际上游戏里面最早的3d动画都是顶点动画。骨骼动画渐渐替代顶点动画，甚至在很多商用的游戏引擎里面，默认都是骨骼动画了。但顶点动画并不是没有任何优点的。
顶点动画由于每一帧的顶点都已经固定了位置了，所以根本不需要计算，只需要每一帧读取对应的坐标并且赋予给顶点，就可以渲染出来了。
所以，在这个大批量渲染的情况下，我觉得首先是需要把骨骼动画转换成顶点动画，这样渲染性能才可能比较大的提升。
之前我介绍过一个Unity的插件，叫做GPUSkinning。实际上阿赵我有一个习惯，是基本上拒绝用第三方插件的。因为使用插件，假如插件有bug，很大程度上就要等原作者去修改，除非是有公布源码的开源工具。所以如果能自己实现的功能，我更愿意相信我自己的能力。GPUSkinning这个插件，我自己并没有使用过，只是看过它的实现原理而已，所以有些朋友问我关于它的使用时出现的问题，我是没法回答的。相同的功能，我自己其实已经实现过了，所以对于我来说并不是问题。
3、合批渲染问题
如果我们已经得到了顶点动画的运行方案，那么剩下来的事情就是要解决合并的问题了。
Unity引擎的合并方式有很多种，自带的静态合并一般是用于合并那些不会动的场景物体，而动态合并时合并一些效果一样的少面数物体。这两个合并方式，对我们在讨论的多人同屏问题，基本上是没什么帮助的。
接下来，可以看看GPU Instance的问题。GPU Instance的使用条件是，渲染的物体使用的网格和材质球都是完全一样的，才可以合并。上面讨论过了，在实际应用中，应该是不存在的。假如一个兵种的一个动作作为一个材质球来合并，也不是不可以。但这样的结果是，有多少种兵种，有多少种动作，最终的合批次数就是兵种数量乘以动作数量。然后，同一个批次的动作，将会是每个用到相同动作的角色都一样的。比如多个相同角色在走路，将会是这些角色的动作会整齐划一。如果想做差异动作，那么就需要更多的合批次数，最后就和没有合批没太大区别了。
所以GPU Instance我认为并不适合解决这个问题。我解决这个问题的方法是SRPBatcher。
SRPBatcher的使用条件比较简单，只要是同一种Shader变体就可以合并，可以不同网格，可以不同材质球。不过使用SRPBatcher就不能用内置渲染管线了，我是改成了URP来使用的。
于是问题就渐渐有了答案了。接下来要做的事情，是搭建一个URP项目，然后做一套可以生成VAT顶点动画的工具，然后做一套支持VAT播放的角色渲染控制。
4、关于BatchRendererGroup
对于超多物体的渲染，其实Unity还给了另外一个解决方案：BatchRendererGroup。这又是另外一个值得研究的技术点了。不过BatchRendererGroup的实现难度比较高，我这个例子使用的VAT顶点动画的实现难度是比较低的，所以如果感觉够用，也就可以了。