【Unity】移动端草海解决方案

草海是开放大世界渲染的必不可少的因素，Unity 原生的 Terrain 草海效率较低，而且无法与 RVT 结合起来，无法在移动端上实现。因此我们自己搓出来一套草海系统，使用 C# 多线程辅助运算，并能支持割草、烧草等进阶玩法。草的位置、密度、类型还需要根据美术和地形的信息进行自适应。

最终效果可以看这个演示视频（虽然这个视频美术表现力不行，但是已经可以看到 GpuTerrain基础下的实时运算的草海效果了。对于游戏开发者而言，显然能明白这个演示已经实现了既定目标）：

GpuTerrain+草海_哔哩哔哩_bilibili地形用GpuTerrain渲染；草海是自定义实时生成运算+Gpu渲染。, 视频播放量 103、弹幕量 0、点赞数 0、投硬币枚数 0、收藏人数 0、转发人数 0, 视频作者魔术师dix, 作者简介我们这么努力，不是为了改变世界，而是为了不让世界改变我们。，相关视频：Island_G效果演示（8月版本），原型工程1.0演示视频，玲珑岛12贴图版本_1.0，Unity3D 战斗系统核心技术: 高度可扩展的技能与多Buff系统(收藏级)，【中配】A*寻路算法：算法解释 - Sebastian Lague，很多3a游戏的马还不如塞尔达的真实生动，新动作又被虐了，Skyrim Special Edition-定海神针-金箍棒，【Unity3D/资产发布】拟真向URP海面渲染系统——HigWaterSystem，游戏，还是现实？https://www.bilibili.com/video/BV1nj411D7tm

方案设计

这里我按照 1*1 的范围将地图进行分块，每一块视为一整片草，进行整体剔除和计算。

如上图的示例，将草分块之后，进行AOI剔除，最后得到所有可能在视野中的草（注意：这里没有进行视锥体剔除），之后再使用生成式算法得到最终的草数据（精确到每一株草的实体）。然后再直接将数据打包传入 GPU，使用之前提到过的 GPU 驱动的渲染上屏，完成草海渲染。

这里就涉及到之前的一些实现过的架构了：

需要得到地面的高度和法线，与开放大世界的 GpuTerrain + RVT-CSDN博客共用一张高度法线图。
上屏方案： GPU驱动的大规模静态物件渲染-CSDN博客

除此之外，草海还需要一张密度图（表示每个格子的草的密度和类型），和 GpuTerrain 的高度法线图每个像素一一对应。

有了上述数据之后，草海就能正常运转了。在项目前期，我们是将草海的生成式算法放到C#多线程中的，目的是为了方便调试和交互。后续功能稳定了，可以将这个算法移动到 ComputeShader 中，效率可以更高（这也是最终成型方案）。

框架与数据管理

制作地图时，生成棋盘格，每个格子 1*1 米，每512 *512 个棋盘生成视为一个地块。统一棋盘格的尺寸，对应高度图、植被密度图的数据。

一般来讲，对于视野远端的地块，不需要生成格子，也不需要计算。对于近处的地块，才需要生成草海，当然距离越近性能越好。按照一些文章的说法，80米的视野范围就能满足需求，如果加上视锥体剔除，视角设置为60度，那么算下来大概需要 3696 个格子参与生成计算（后面按照4000个格子计算）。

4000 个格子，每个格子生成 64 棵草（密度最大），每颗草的数据（Transfrom数据）大约为 30 byte，算下来总共占用约 7.5 MB 内存，即便是移动端也可以接受。（为了减少对GPU的数据传输，我们其实使用了4个80*80的区域，内存占用更多，原因下文有解释）

对于 Patch 而言，最高运算的部分在生成（以及根据玩法对数据的修改部分），因此在运行时并没有复杂逻辑，就只是在原地不动。生成之后最大的性能瓶颈就是在玩法（例如割草）上对实体的遍历。但因为能实现限制 Patch 进行刷新，所以遍历的量并不会很大。

草海编辑工具

因为草海已经脱离了 Unity 的Terrain，所以需要一编辑工具。

根据 GpuTerrain + RVT 数据直接还原地形的工具，方便美术开发。
类似于 Terrain 的刷子工具，可以绘制草海密度图。
草海类型配置：配置不同类型的草，以及其出现频率，可以实时预览。
运行时调试工具，方便运行时查找问题。

其他细节问题

这里记录一些细节问题，可以帮助大家实现时做参考。

面片草还是网格草？

面片草顶点数少，但是依赖 AlphaTest，这一步在很多移动设备上非常昂贵。
网格草顶点数高，但因为是实体渲染，性能表现远远优于 AlphaTest。

此外，对于某些表现效果（例如高光、碰撞弯曲）上，面片制作起来困难；在视角上，面片草存在穿帮死角，大致上只适合固定视角。所以还是建议使用网格草。

草海密度图存的什么数据？

草海密度图我这里将每个像素的 rgba 各设置为一种类型的草的密度，每一个草的密度取值从 0~256表示其密度。在生成草海数据时，查询到某个位置有颜色，则根据通道（例如 R通道表示杂草，G表示花、B表示地衣、小石头）密度算出需要生成特定类型、特定数量的实体。生成完成之后，将数据收集起来统一传给 GPU。

实际上，每一个通道的256的值对于密度还是太多了，本来一个地块最多64个实体，精度肯定超标了。后续如果要优化，完全可以将密度的精度降低到8，再将其他位记录其他地图数据。

生成式算法

成式算法其实是根据项目相关，所以不必去网上特意查找。一般来讲，只需要设置一个随机方式（噪声图、或者固定随机种子），根据算法进行随机。只要满足一个要求就行：每一次生成的位置、旋转、缩放都是相同的结果。

同时，在生成时可能需要根据地形信息有所变化，这点也需要考虑到。

草海实时重建的频率

在计算哪些草块（Pitch）需要计算时，为了减少对 GPU 交互的频率，改为周围 80m 的棋盘格都计算了一起扔给 GPU。因此这样占用的内存大了4倍，但数据交互频率显著降低，就不用每帧都生成一次数据了。否则，一旦加上视锥体剔除，那么一旦相机旋转了，每帧都要实时计算一次、传值，数据大了还是很不划算的（实际上，视锥体剔除我们也试过，数据量少了很多，但传输数据的频率就大幅提升了）。

当然这是妥协，如果在 GPU 里计算草海就没这个问题了。所以，最终的完整版本还是要在 ComputeShader 里生成草海。

图片数据读取

GPU端直接通过 Texture.GetPixel 也太蠢了，效率还低。这里我们的做法是将图片转换成 NativeArray 然后再在多线程读取。这里需要注意的时，如果是多线程读取 NativeArray ，需要一点点操作：

NativeArray<Color32> HeightMap = texture.GetPixelData<Color32>(0);//获取图片的原始数据

//根据已有的数据生成不安全的只读 NativeArray，否则多线程无法使用。
NativeArray<Color32> ConvertedHeightMap= NativeArrayUnsafeUtility.ConvertExistingDataToNativeArray<Color32>(HeightMap.GetUnsafeReadOnlyPtr(), HeightMap.Length, Allocator.Invalid);

#if ENABLE_UNITY_COLLECTIONS_CHECKS 
//只有编辑器下才存在 SetAtomicSafetyHandle 
NativeArrayUnsafeUtility.SetAtomicSafetyHandle(ref ConvertedHeightMap, AtomicSafetyHandle.Create());
#endif

按照上图示例，就可以在多线程中使用 Unity 的 NativeArray 了。要注意的是，SetAtomicSafetyHandle 只在编辑器下使用，在真机上是会报错的。参考：NativeArrayUnsafeUtility seems to not work in builds - Unity Engine - Unity Discussions