行业活动

日前，在FBEC 2019大会举办的“Unity制作人专场”，Unity技术专家刘伟贤带来关于“Unity的超大开放世界解决方案”的主题分享。

针对超大开放世界游戏开发，刘伟贤详细介绍了相关的解决方案，分析了HLOD System与 LOD的差异，以及阐述了如何进行超大场景管理、如何处理场景里道路、树木、桥、石头等技术性干货。

以下为游戏陀螺整理的演讲分享：

大家下午好！很高兴有这么多人在场聆听，现场有很多认识我的朋友，当然还有很多比较新鲜的面孔，我首先简单介绍一下我自己。

我叫刘伟贤，是Unity China在广州的技术人员，主要是做企业级技术支持的工作，服务过这边很多的客户。

今天我给大家带来的是《Unity的超大开放世界解决方案》，今天我着重讲移动端，相信大家很多都是做手游的。

首先跟大家介绍一下这个项目立项时候的一些情况。当时立项目标是用2019.1这个比较新的版本，当然现在不是一个新的版本了，类型是长射距、开放世界的，锁定第三视角等等，其他类型的我们在有需要的时候也会尝试做一些实践。

目标帧率是30帧，对于移动端来说，我们使用的是HDRP，但是实际上演示的时候，我也可以给大家看一下我们近期做的一个技术Demo，是基于HPRP的，所以目前整个大世界的解决方案，主要就是这样。为了保证客户可以更好的接入这个方案，所以绝大部分的实现都是基于C# sourcepackage方便接入。

世界大小方面，目前我们是以4K×4K的世界大小，跟表现相关的话，我们觉得风格化的也可以，但是还没有做更多关于照片级的真实渲染，我们也借助了一些外部的工具来完善整体的流程，等会儿会给大家介绍。

总体来讲，整个超大世界的方案里面，我们有下面的这些Feature，首先一个是HLOD System + Terrain HLOD System，主要是可以替代很多静态的东西，进行合拼，进行见面，达到一个在长射距的时候能够有比较好的内存和性能的指标。

下面是关于我们内部一个新的Voxelized Shadow Maps，基于算法转换高分辨率的Shadow Maps。在美术和设计方面我们采用了第三方的插件，来配合Unity做一个超大世界的Terrain的生成，比如关于树的生成、桥梁的生成、石头的生成等等，这些都是比较方便的。至于Streaming的话，它是基于我们的HLOD system，里面会涵盖到我们的prefabs/textures/meshes。

我们当时选用较新的2019.1这个版本的时候，也是考虑了这些引擎后面提供的Feature。 还有一个就是Occlusion Culling Streaming，因为对于一个超大世界来讲，如果想要提高效率的话，可以利用Occlusion Culling Streaming提前进行跟遮挡相关的技术，对于大世界来看，数据量比较大，所以我们提供了Streaming的方式去做游戏加载。

接下来是Light Probe Layout Tool和 Light Probe Streaming，这个其实是跟我们Light Occlusion相关的，主要为了能够自动化的去排布Light Probe并且在做超大世界的时候我们对Light Probe做了一个Streaming的工具。然后是Indirect Draw，简单来说就是充分利用CPU的资源去做Instancing之类的操作。

以上这个图的左边跟上一页是一样的，希望大家可以了解一下右边的，这是兼容性方面的内容，在2019.1之前的版本里面有HLODSystem是可以兼容的。

对于整体的Solution item，我们会按开发的流程去讲。首先是如何得到这个场景，得到这个场景之后，如何把这个超大场景管理起来，场景管理起来以后， Lighting solution是怎么样，如何处理光照和引擎等等，还要处理场景里面很多地表上细节的东西，接下来我会详细讲一下。

首先是Houdini+Unity Workflow，我也是技术人员出身，在开发大世界的时候，很难有很多人员去做超大世界的搭建，我们都是基于Houdini这样一个系统、一个插件，让它去生成Terrain，能够有路、有河、有桥等等。生成完之后可以导入到Unity里面，就可以很方便的在Unity里面对这些参数进行调整。

当我们把这些东西都调整好了得到一个超大场景的时候，就可以进到HLOD System，进行预处理的状态。当到HLOD System预处理完了之后，就可以得到观看的时候可以真正去跑的状态了，我们在借助Houdini的时候，是可以快速在Demo验证阶段，比较方便的得到一个模型。

HLOD System主要是为了减少drawcall，其次是为了了减少面数和纹理，当这些东西减少了以后，我们把面数贴图进行了减法以后，就相应的得到了内存，加载时间也得到了提升。

目前HLOD System只针对当前所在的这一个level进行加载，加载Mesh和Texture，在后台下面进行异步的操作。

大家可能会问，HLOD System跟原来使用的LOD有什么差别？这里有一个对比图，共性都是大家都可以做一些减面的减法数据，当我们把面数减下来之后，LOD不能减少DrawCall、Memory Usage，不能减少内存，也不能提升CPU，特别是在LOD的计算上，HLOD为了弥补这些方面，所以我们做了全新的系统来弥补以前的不足，这张图可以比较直观的展示到底LOD System和HLOD System这两者之间的差别。

这是我们当时做HLOD System时候的一个测试场景，这个原来有5642个DrawCallS，用了HLOD System后就变成了952个，基本上这是性能上的对比，占比达到了原来的16.87%。Tris也从原来的8.0M降低到3.9M。

HLOD System整体的流程是怎样的呢？刚才我讲过，我们开始从Houdini导入了一个场景到Unity，得到Game Objects再到Prefabs，这个时候就会进入到HLOD System，HLOD System模块其实主要有四个阶段。

前期Splitter，把Nested Prefabs根据树型结构进行切分，切分之后Simplifier去做减面的操作，我们会根据不同的电子结点来判断这是一个比较高等级的结点，还是一个比较低等级的结点，来进行减面的操作。当我们根据不同的LOD等级进行减法之后，我们会进入Batcher，对低结根结点进行合批的操作。到达Streamer，转成Prefab通过Addressable asset进行Streaming的操作。

这也是为什么我们通过HLOD System以后，可以把DrawCall batch到一起的原因， 是因为对整个场景进行了树型结构的整理、检验和批合，通过Streamer进行了流速的加载。

在Runtime阶段，HLOD System要做的事情就比较简单了，我们大量的工作都在预处理阶段已经处理掉了，只要在Camera PreCull的时候进入HLOD System更新一下数据，再选择要显示的是低精度的结点，还是高精度的结点，还是隐藏掉，所以这也是跟原来LOD System很大的差别，很多根源上的问题就解决掉了，可以精准的把你所需要的东西渲染出来。

下面这个也是大世界很大的难题，就是Lighting Solution，关于光照方面的问题。

目前我们采取的是LightProbe baking + VSM(Voxelized Shadow Maps For Far distance)+ CSM(For near distance)的解决方案，给长距离的、大范围的进行使用，希望远近景可以达到比较协调的状态。

Voxelized Shadow Maps的工作也非常简单，可以在离线的时候做一些数据的处理，然后生成一些高精度的Shadow Maps，在运行时，跟原来没有太大的区别，但是中间Screen Space Shadow Compute Pass可以做一些跟计算相关的事情。

这是一个效果图，包含了静态物品和动态物品融合的状态，在这里的Voxelized可以看到在不同的分辨率下面构建的时间和占用内存的大小，这是展开的大小，因为对高体来讲的话还可以进行数据的压缩，这个16K指得是分辨率。

接下来这个是将VxShadows放到HDRP里面进行光照的展示。

刚才讲到了关于阴影的部分，除了阴影以外，还有其他的东西，主要就是靠LightProbe的贡献，大家如果用过LightProbe就知道，这里麻烦的事情就是要去布一些点，在光源变化比较大的一些地方，但是这样做的话很累，因为需要不停的布点和修改。

所以，我们提供了工具LightProbe Auto Layout Tool，可以用方便的方式生成大量的LightProbe，来替代人工方式的操作。我们也提供了LightProbe Streaming的功能，运行时进行streaming，确保不需要把大世界的LightProbe data都丢到大世界内存里面。

这个AutoLayout 工具是我做的，大家想了解的话可以跟我聊一聊。左边的图是其中一个样式，可以自动的点一下按纽，就可以自动LightProbe的排部。这是一个非常简单的工作流，是排部的规则，里面提供了五种排布的规则。

一种是基于格子，按照AABB一个一个点；第二种是对于一些没有LOD等级的mesh，对它进行包围的计算，有一定的精度的数字来控制Light Probe如何精准的包围这个产品的物件；第三种是基于LOD group mesh generator，我们到底基于哪一级的LOD来进行排部；第四种是比较好用的是light generator，它可以在光源变化进行Light Probe密集排布；第五种是terrain generator，在2019.2上我们已经可以支持静态物体和动态物体的同时受到Light Probe的影响。所以用Light Probe作这样的方案是没有问题的，而且这几个是可以组合使用，并不是只能单一使用。

当Light Probe布完之后，我们会提供一个Optimize Baker，在Baker的过程中我们不需要生成Lingt maps，我们只需要把像低精度信息Baker到Light Probe就可以了。Baker完了之后我们还会提供一个Optimizer，专门做优化的，毕竟这是自动化排布，而且是组合使用，所以难免会产生一些小问题，在这里，我们提供了一个方法来进行裁减，把Baker完一些差异较小的剔除掉，达到的效果是有一个比较合理的存在。就是做一个Streamer。

现在讲一下场景里面很细节的一些物体，在游戏里面，大家非常熟悉树、草、河、植被等等。对于Render System我们主要做的两件事情，一个是用GPU做视觉的感受，第二个用Indirect Instance把它画出来。听起来好像很简单，但是实际上在系统里面，我们也加入了自插数，在送进GPU之前还有一些简单裁减，后续还有调整的方案在里面。

对于未来，我们还在进行一些新的尝试，比如对超大场景进行支持，使其得到更高的精度，所以进行了一些折中的方案来提升精度。

下面给大家看一下目前我们基于HDRP的技术Demo，当然下面还有一些红色的报错，里面的素材可能看起来不是很炫酷，对于我们来说只是做一个技术的验证。

这是目前我们做的一个技术Demo，把整个大世界的方案放到HDRP里面，这些技术方案基本上全通了，目前我们用的版本是2019.1.7。

除此以外，其实我们也给其他行业做了一些跟大世界相关的事情，比如这是我们做的智慧城市，是比较技术Demo的一个东西，大家可以看一下，里面包括了建筑物、道路、树木等等。

目前，我们这一套大世界的方案，除了跟很多客户在合作以外，在其他一些行业和领域都有使用场景。

我今天的分享就到这里，谢谢大家。