Unity实现无缝大世界--地形

最新推荐文章于 2024-09-27 06:56:30 发布

UWA

最新推荐文章于 2024-09-27 06:56:30 发布

阅读量2.4k

点赞数

分类专栏：厚积薄发| Unity优化文章标签： unity 游戏引擎贴图图形图像游戏开发

原文链接：https://www.zhihu.com/people/yang-yang-90-83

版权

厚积薄发| Unity优化专栏收录该内容

517 篇文章 95 订阅

订阅专栏

大世界最重要的毫无疑问是地形了，地形也是一项比较古老，且一直在迭代更新的图形学技术。地形系统主体技术要点，一般围绕着LOD来展开。最近一些年，随着DrawInstance和GPU Pipeline的流行，地形系统又在这两个方向做了进一步发展，这俩技术非常契合地形系统，简直就是为地形而生。

Unity的整套地形系统（包括植被），在有DrawInstance功能前，几乎不能在移动上使用，大家一般采用转成Mesh的方式在游戏中使用。转成Mesh始终不是长久之策，发挥不了地形极致LOD的优势。要想做大世界，自己写一套高效的地形系统是必不可少的。

大概思路依然是合理的材质和模型LOD，结合DrawInstance，在性能和效果之间进行平衡。我这里提供一个在移动平台验证过的可行解决方案，可以参考，也可完全按照这个方案来，至少在几万到几十万的量级不会出问题。

通过模型，可以分两部分，GPU地形和远景四叉树，以下图每个格子是512的大地图为例，灰色部分为远景四叉树，蓝色部分为GPU地形。

GPU地形

这里先主要讲一下配置和注意事项。

GPU地形整体大小是2048x2048，更新粒度是512，也可以是256，但若是256，资源文件可能就太多，Unity在资源文件爆炸后，Import的速度会变得很慢。实际测下来，512的粒度没有明显问题。LOD分5级就足够了，因为我们整体大小才2048，LOD0的Mesh对应密度比例是1:1，LOD4已经是16x16了。

跟模型有关的数据建议用保存成二进制文件，因为如果保存成Unity文件，如Asset或者贴图，需要把这些资源放到Asset目录下，而二进制的数据文件是可以放到目录外的，打包的时候进入Bundle就ok，在Editor模式下，可以直接通过文件访问，一切为了节省Import耗时。二进制还有好处是，可以整合各种数据，如每个块各个LOD等级的一些配置信息（坐标，高度差等）、挖洞信息等。一个2Wx2W的大世界数据能控制在500MB左右。

在实际使用过程中，如果用Hiz来剔除会有一帧延迟，不太适合做地形的剔除，所以最好还是采用PVS，并且地形的排布比较整齐，比较好做PVS，天然省去了PVS里字典映射的部分。

这里说一句，DXR用来烘焙PVS是个不错的框架，很适合做一些离线自动化工具。

接着来着重说一下，PVS的数据组织和加载使用。

众所周知GPU地形只显示2048x2048的地形，那么全量的PVS数据是多少呢？LOD0是一个4x4的Mesh，显示的实际空间是4x4，那么LOD0的内存数据就是(2048/4)x(2048/4)/1024 = 256KB，所有LOD加起来不超过512KB。数据结构可以直接用一维数组来表示，因为是个全量均匀排布，那么Offset = (Pow(4，level) - 1)/3，这里level=0表示最低的即2048x2048，这里需要有个换算，还有就是可能低等级没有到0，只要再减去无用Index就可以得到正确结果。其实从一个地块的数据量，就能大概推算出整个大世界地形的PVS数据有多少，实际还能进行压缩，这些对于包体的大小是完全能接受的。

为了省去索引烦恼需要将硬盘数据全量存放，这是一棵完整的树，但是这里的内存还能压缩，因为LOD0是最多的，而离中心点较远的位置其实是不需要的，可以在LOD0只加载64米以内的数据，LOD1则是124米，以此类推。这样能把数据压缩到非常小。就索引来说，需要做进一步换算，拿个纸笔应该能很快推算出来。

GPU地形可以再拆分两种材质：

绿色为RVT材质，黄色为中景离线烘焙贴图材质

近景RVT材质

在这里由于使用GPU地形的原由，粒度会下降到4x4，这样我们可以把尺寸缩到512，RVT在把尺寸缩到512后，即使VT的size控制到2048，也能达到一个比较清晰的画面，不仅能节约很大的内存，而且地表的精细度也能得到很大的提升。

中景离线烘焙贴图材质

我们为每一块512地形，生成混合完成的Albedo和Normal，这里有三点需要注意。

1.烘焙的时候注意把投射RVT的模型也渲染到上面，比如路面、贴花这些，直接烘焙到中景贴图上。

2.Normal直接取地形的顶点法线即可，无需把Layer上Tangent转到世界空间。相隔太远、太碎的Normal反而会造成噪点，起反作用，我们只保留顶点法线的结果就ok。

3.烘焙时，地形的Layer可以适当放大，远处的纹理可以通过放大Tile，让纹理的细节显现出来，具体放多大，取决于RVT远处纹理的缩放比。

在材质准备好后，由于是512位单位的，我们需要显示2048x2048（中间扣掉一块512为RVT材质），我们在运行时，可以采用TextureArray或者动态合并VT的方式。以合并VT的方式为例，我们可以忽略中间RVT那个块，直接生成2048x2048的完整贴图，直接平铺上去就OK，要处理的是，我们应当尽可能复用之前的数据。如：

我们只需把右下一圈，填到左上即可。如下图，将蓝色区域填在灰色区域，然后存一个偏移即可。

这种处理方法在整个大世界的资源加载非常常见，一定要有这个意识。

由于整个GPU地形使用两种材质，那么在GPU地形生成Mesh的IndirectDraw就要分开生成，分两个DrawCall提交。

远景四叉树模型

2048以外的地方，其实也可以用GPU地形，只是资源的形式要分两级，2048以外的数据粒度更大一点，保证IO友好，甚至可以做四叉树的IO，不把各个等级的数据放在一起，从技术上讲是能完全可行的，关键问题在于，出来的模型质量很差，因为需要把LOD等级提到很高，基本至少要128x128来表示一个数据，疏密调节的灵活度在这里远远不如模型。

在确定生成远景模型后，最理想的情况是，全地图生成一个静态模型直接渲染，一个2Wx2W的大地图，做完极致优化，1~2W面就能达到预期效果。这里建议用Houdini自动生成，可以把山脊那部分的面加多，海拔低的盆地和平原面数可以砍得狠一点。但是我们面临了几个问题。第一，我们要能灵活抠掉中间2048x2048的空隙，粒度是512。第二，远景模型跟GPU地形之间存在接缝问题。

第一个问题，难的不是抠出中间部分（VS输出SV_Position为无穷大或者蜕化顶点到边上），难的是2048的矩形边，要求抠出来是一个四四方方的，那么就需要在每个512上都要卡一条直线，卡线会使模型顶点数直接翻倍。

第二个问题，可以把模型往下降降，根据视角特性，能解决大部分问题，但是恰恰地形接缝问题太过突兀（漏出天空盒，有人考虑把天空盒的底面用地形颜色图，依然没法解决所有问题），必须得保证100%没问题。那么经典的解决接缝问题就是蜕化边和加裙子，由于GPU地形和远景地形不在一个系统，不好蜕化边，只剩加裙子了，加裙子又需要很多顶点。

为了解决这两个问题，最简单的一个办法是，切成每个512x512的地块，且生成裙边，然后控制地块的显隐，再通过Static Batch渲染。这里引申出了两个新问题，一个是面数过多，切块加裙边，面数基本翻3倍以上，另一个是虽然是Static Batch，但是实际DrawCall数偏高。实际裙边仅仅在2048的那个矩形需要，其他地方造成很大的浪费，能缓解第一个问题，但是还是由于切边导致面数翻番。

我们引出一种新的解决办法，四叉树生成各个等级LOD的模型，然后显示矩形，如图所示：