ProjectS中的地形系统-Terrian Rendering
地形系统思路来自 ProjectS中的GPU Driven
架构
首先明确ProjectS的世界大小,目前暂定整个世界面积为 20.48km * 20.48km
,实际上可以再大很多,但考虑到资源量级以及对于世界内容的填充需要颇费心思,暂定这么大了
既然地形分了LOD,那么纹理自然也要根据LOD进行区分
- LOD0的Node对应的纹理信息(高度纹理,Material Id纹理等)分辨率为
128*128
,覆盖区域为64m*64m
即一个纹素对应0.5m,已经很可以了,再高点画质就要比原神好了 - LOD1的Node纹理分辨率为
128*128
,但覆盖区域为128m*128m
- LOD2的Node纹理分辨率为
128*128
,覆盖区域为256m*256m
- LOD3的Node纹理分辨率为
128*128
,覆盖区域为512m*512m
- LOD4的Node纹理分辨率为
128*128
,覆盖区域为1024m*1024m
- LOD5的Node纹理分辨率为
128*128
,覆盖区域为2048m*2048m
这也就意味着我们需要对整个世界做六种不同覆盖区域的纹理,可以理解为Mipmap,不同的LOD Node采样不同覆盖区域面积的纹理
,如图所示
不同颜色代表不同LOD等级,但每个LOD都是使用的128*128
分辨率的高度图纹理进行渲染的,这里以原分辨率8192纹理为例,需要额外再导出4096,2048,1024,512,256的贴图,才能满足所有LOD层级的渲染需求。
需要注意的是,由于我们所有纹理都是分块流式加载的,每张纹理仅仅是128*128的,没有全分辨率的纹理,所以类似SampleLevel这种指定mip等级的API是用不了的,只能自己将相应的LOD对应纹理加载进来,由于纹理数量较多,且分辨率相同,使用Unity的TextureArray作为管理器是一个很好的选择,可以有效减少bind消耗
明确了基础的世界组成架构,接下来需要确定整个地形渲染系统的运作流程
CPU
四叉树构造
值得注意的是,如果没有流式加载的需求,其实是不需要标准化的四叉树的,只需要将所有需要细分的节点进行4次细分即可,完全可以将四叉树的构建和剔除放在GPU加速
而如果需要流式加载,则需要构建标准四叉树,并借助四叉树的快速区域查找特性来进行卸载和加载节点,因为涉及相对复杂的数据结构和数据异步交互,放在CPU中进行
四叉树基础知识
由于我们无法保证四叉树一定是一颗完全树,所以没法用数组的形式来保存节点信息,另外我们需要动态更新四叉树,所以采用指针引用的形式进行节点存储
四叉树节点中包含的数据就是我们地形渲染中的Node:
1 | public class QuadTreeNode : IReference |
可能有些抽象,画张图解释一下
然后就是老生常谈的四叉树构造,地形节点的填入了,由于四叉树算法网上已经有很多讲解和实现,此处不再表述,可以参考:Quadtree and Collision Detection
这里只说几个注意点:
- 每个节点都可以存储对象,不论是否是叶子节点,可以加速查找
- 当一个对象不被将要被细分的四叉树节点中的四个象限中的任意一个完全包含时,将不会进行细分
- 当一个对象不被四叉树节点完全包含的时候,需要分配到父节点
- 当一个对象不被四叉树节点的四个象限中的任意一个完全包含时,需要分配到四叉树节点本身
- 四叉树需要有动态更新的能力
动态演示如下:
超大世界下的区域性四叉树
因为我们的世界是20.48km * 20.48km
,且Sector为64*64m,那么如果在整个世界范围内构建四叉树的话,至少需要将四叉树的深度拉伸到9以上(即2^n >= (20480/64 = 320),n > 8 => n = 9)
才能保证获取到每个Sector的LOD级数,由于四叉树深度过深,效率已经比较糟糕了
所以我们需要构建一个区域性的四叉树,尽量把四叉树深度保持在6以内,范围就是 (2^6 = 64) * 64 = 4096
,即我们的四叉树覆盖范围为4096m*4096m
,区域外的部分一律采用LOD5进行渲染
这个区域性四叉树优点如下:
- 较小的深度,保证查询效率
- 通过对比当前帧与前一帧的四叉树覆盖区域快速获得需要流式加载,卸载的节点
- LOD0大小完全匹配Sector,便于后续数据准备收集工作
- 为后续的RVT提供数据支持
- 兼容任意大小的世界地形,同时可通过坐标偏移避免大世界浮点精度问题
当然对于这个区域性的四叉树,我们需要保证其中心落点一直位于64的整数倍上,不然每个Sector就对不准我们离线切分的纹理大小了
示例如下:
区域性四叉树移动触发流式
当玩家进行移动时,四叉树会跟随更新,如果移动连续(即不进行传送操作),则可以求出这次移动需要加载和卸载的节点
示例如下:棕色部分为待卸载部分,绿色为复用部分,蓝色为待加载部分
具体步骤为:
- 设当前四叉树为X
- 当玩家移动距离相比上一次记录累计超过LOD0(64m)阈值时触发流式
- 计算出需要加载的范围A,卸载的范围B,以及重合的范围C
- 由于我们LOD层级较多,基本上每次移动都会触发大部分节点的重建,所以直接重建整颗四叉树得到Y
- 将需要加载的范围A和Y做相交测试,得到覆盖的节点,以及对应的待加载资源列表a
- 将需要卸载的范围B和Y做相交测试,得到覆盖的节点,以及对应的待卸载资源列表b
- 将重合的范围C和X,Y做相交测试,得到相对的覆盖节点,对节点进行一一对比,如果节点的位置和四叉树层级(LOD等级)均相同,则认为此节点无需加载资源,否则此节点需要卸载引用资源,并重新加载新的对应资源,得到待加载的资源列表c,以及待卸载的资源d
- 对a,c资源列表进行加载,对b,d资源列表进行卸载
- PS:当然如果项目的资源管理模块做的比较吊的话,可以忽略上述复杂的加载卸载步骤,只需要无脑卸载上一帧残余资源,加载这一帧所有资源即可,由资源管理模块进行处理
区域性四叉树跟随移动表现如下:
当然,仅仅是这样是有问题的,因为我们是依据LOD0的阈值来重建整颗四叉树,这样会导致其余LOD等级的对应资源无法被正确加载,例如LOD1覆盖区域为128x128m,在离线切分纹理的时候每个tile是固定的,即x轴间隔0,128,256三张纹理,那么x为64的时候,是没有对应纹理的,只能继续复用x为0时的纹理。
综上,我们只有在四叉树中最高等级的LOD发生变动的时候才会移动整颗四叉树,否则以各个LOD等级贴图切分规格进行流式加载和卸载,示例如下:
世界原点与Node布局
为了最大限度利用浮点精度范围,我们把世界中心点设置在世界坐标原点处
为了和四叉树统一排列算法,世界左下角为tile0,从左到右,从下到上进行排列,就像这样:
Node内容
对于地形高度渲染,每个Node至少需要有以下数据
1 | public class TerrianNode : IReference |
资源准备
Patch
首先是最基础的Patch,直接在houdini拉一个8x8m,分辨率为16的grid导出fbx即可,记得在fbx的rop节点恢复原生比例(勾选Convert Units),不然导入到unity还得放大100倍
四叉树剔除
借助四叉树的结构特性,可以实现较为高效的剔除
1 | /// <summary> |
碰撞检测基于相机的视锥体进行,剔除代码和debug代码如下:
1 | Camera cam = Camera.main; |
效果如下:
TODO
流式传输
TODO