最近把火星全球地形渲染这个练手项目重新收拾了一遍从四叉树细分到LOD切换从球面投影到瓦片调度前前后后踩了不少坑。之所以选火星当试验场是因为它有一套完整的全球高程数据不像地球那样被各种投影分带折腾得头疼拿来做地形引擎的“小白鼠”再合适不过。这篇笔记把整个方案拆开讲四叉树怎么设计、LOD怎么卡阈值、火星全球地形数据怎么做成金字塔、渲染时又该怎么处理裂缝和精度问题。内容比较偏向实际操作适合正在做地形渲染、三维地球、或者想入门大规模场景组织的朋友参考。1. 先想清楚方案四叉树、LOD、火星数据三者怎么配合1.1 为什么是四叉树而不是八叉树很多人一上来就问三维场景不是应该用八叉树吗这里要分清概念。火星全球地形本质上是一个“球面二维曲面”每个节点代表地表上的一块区域本质上仍然是二维平面上的空间划分。四叉树每次把一个区域等分成四块天然匹配经纬度网格或纹理瓦片的组织方式递归清晰、索引简单GPU 渲染时也能高效地按节点粒度批次合批。八叉树当然也能用但它的优势体现在真三维数据上比如点云、体素、空间遮挡剔除。对地形来说额外增加一个高度维度进去并不会带来查找效率的质变反而会让瓦片遍历、显存管理、父子节点同步复杂好几倍。项目里没必要给自己加戏二维问题就用二维结构这是我一直坚持的原则。1.2 LOD 到底在优化什么LOD 全称 Level of Detail核心就一句话远处少画近处多画。对地形渲染来说G 缓冲区带宽、顶点处理量和纹理采样带宽是三大瓶颈。假如整个火星表面都以最高精度铺网格每个像素的三角形规模会直接让 GPU 崩溃而且火星直径约 6800 公里即使只渲染视野内一小块区域顶点数量也极其恐怖。LOD 的优化本质是“用距离换精度”在渲染质量和渲染代价之间找一个动态平衡点。我建议你把它理解成“按需分配”把精细网格资源集中在相机附近远处用粗糙网格撑住轮廓过渡处再把相邻层级的差异抹平。只要这个逻辑跑通了全球尺度漫游的性能问题就解决了一大半。1.3 火星数据特征对方案选型的影响火星全球高程数据通常是一个覆盖整个星球的经纬度网格分辨率大概在几百米量级。这个分辨率相比地球商业地形数据要低不少好处是数据量可控坏处是贴地飞行时细节不足必须配合颜色影像或程序化细节纹理来补充视觉信息。因为数据本身是等距经纬网格我直接采用了等距圆柱投影的方式切瓦片。把整个火星映射成一个长宽固定的大图再按金字塔层级切块每个四叉树节点对应一块瓦片。这么做的最大好处是和数据格式天然对齐切片、采样、纹理坐标换算都不带额外步骤。如果做的是游戏场景或者追求极点附近更好的视觉表现可以换成六面体投影但这里我为了省事选择了最直接的路线。2. 数据预处理把火星全球地形变成可以喂给四叉树的瓦片2.1 数据源与精度认知做火星项目前我先把全球高程数据拿全格式是标准的经纬度网格。火星全球地形一般以 CSV 或 GeoTIFF 形式发布覆盖范围是经度 -180 到 180、纬度 -90 到 90每个采样点记录海拔高度。这里有个关键认知全球低分辨率数据只能保证“从轨道上看得像火星”一旦把相机压到距离地面几十千米会发现地形细节仍不够丰富。实际项目中我从两个方向补充一是引入更高分辨率的局部区域数据做混合二是对高度场做平滑插值并且用噪声扰动微地形让近地面镜头不至于一片光秃。数据源的最终形态我整理成了一张大高度图后续所有瓦片都从这张图上重采样。2.2 全球金字塔切片的参数逻辑金字塔是四叉树的基础。我定的参数如下第 0 层全球 1 张瓦片覆盖 360 度经度、180 度纬度。第 1 层2 x 2 张瓦片每块覆盖 180 度经度、90 度纬度。第 n 层2^n x 2^n 张瓦片每块覆盖 360/2^n 度经度、180/2^n 度纬度。每张瓦片内部固定为 256 x 256 个采样点。这样一个像素对应的实际尺度可以估算赤道上 1 度经度约为 59 公里第 8 层每块覆盖约 1.4 度经度256 个像素去采样单像素大约 0.005 度也就是三百米左右已经接近激光测高数据的原始分辨率。继续细分下去数据都是插值出来的视觉提升有限但渲染压力会指数上升所以最大层级我设到了 14再深基本没有意义。切片时我用的是通用栅格处理工具GDAL 这类把全球高度图裁剪成各级瓦片输出为 16 位灰度 PNG。选择 16 位是因为火星海拔范围很大从低于基准面数千米到最高点两万多米都有8 位会完全丢失细节。每张瓦片在保存时保留一定的边界重叠像素可以有效避免后续采样时相邻瓦片出现沟槽。2.3 高度图转成高度场的注意点拿到瓦片后GPU 侧不能直接采样 PNG需要把高度范围归一化到 0 到 1精度尽量保留。我在 CPU 侧建了一张查找表把实际海拔米数映射到 0 到 1 区间传入着色器的 Uniform运行时再用反向映射还原海拔。实际项目中遇到一个坑直接用 PNG 像素值除以 65535 得到的是相对高度但不同瓦片之间的基准面必须统一。火星全球地形大家通常以某个参考椭球面为海拔基准我处理时统一减掉基准面半径再归一化避免了相邻瓦片在接缝处高度不一致的问题。同时每个瓦片在加载时做一遍 min/max 统计存进节点对象LOD 切换时能用这个值做更准确的包围球和误差预判。3. 四叉树节点与 LOD 判定这是整套系统的心脏3.1 节点对象里到底该存什么四叉树节点不是一个简单的“格子”它必须承载渲染和调度所需的所有信息。我项目里的节点结构大概是这样的struct QuadNode { int depth; int tileX, tileY; int status; // Unloaded / Loading / Ready / Eliminated float minHeight, maxHeight; double centerLat, centerLon; BoundingSphere sphere; QuadNode* children[4]; Mesh* mesh; Texture* heightTex; Texture* colorTex; float lastAccessTime; };depth、tileX、tileY 三件套确定了节点对应哪一层哪块瓦片status 是状态机的基础minHeight / maxHeight 用于误差裁剪和包围球计算。sphere 用于视锥剔除应该不用多说但要注意它的半径必须把最大海拔也算进去否则相机贴近高山时节点还没进入视野就被剔除了偏远山体边缘会出现“突然出现一堵墙”的问题。children 指针的维护是整个四叉树实现最容易乱的地方。我的经验是创建子节点时必须保证父节点状态为 Ready否则子节点加载完却没有网格可用逻辑会乱。统一的状态流是父节点 Ready 后才能继续拆分拆分和合并都只针对叶子节点操作。3.2 屏幕误差模型与细分阈值LOD 判定不是简单看距离而是看“这个节点在屏幕上占多少像素”。如果节点在屏幕上面积已经很小又何必继续细分我用的屏幕误差估算公式是screenSize (worldSize / distance) * (viewportHeight / (2.0f * tan(fov / 2.0f)));worldSize 可以是节点覆盖的球面大圆弧长distance 是相机到节点包围球中心的距离。算出 screenSize 之后如果大于某个阈值就继续细分否则保留当前节点。阈值的选择直接影响画质和性能。我把视图高度调成 1080p、FOV 设为 60 度后阈值取 8 到 12 像素表现最好。小于 8 像素时远处山体细分过于积极每帧请求大量瓦片卡顿明显大于 12 像素时远处细节丢失太严重山脊边缘会出现明显的多边形感。这个模型有一个简化假设就是相机正对节点。斜视情况下远处地形在屏幕上会被压缩误差会比估算值小但实际跑起来问题不大再加上一节要说的迟滞逻辑视觉上不会出现大面积抖动。3.3 请求调度与内存回收不让加载拖垮渲染瓦片加载是异步的网络、磁盘 IO 都可能在几毫秒到几十毫秒之间波动。直接无脑把所有满足 LOD 条件的节点全部入队会让纹理上传和网格重建在某一帧集中爆发卡到没法看。我引入了优先级队列相机视野内的节点优先级最高越靠近视野中心、屏幕误差越大排得越前。每帧最多处理 4 到 8 个请求加载太少会跑到哪哪儿秃加载太多会吃掉主线程时间。已经加载完成但暂时不在视野内的节点标记为 Cache不立刻释放留给相邻区域快速使用。内存回收我用了一种类似 LRU 的策略。每帧记录节点访问时间当总内存超过上限比如 512 MB时从最久未访问的叶子节点开始回收。这种做法对原地旋转、快速平移这类操作很友好刚去过的地方缓存在内存里再移回去时瞬间就绪。我特别强调一点不要每帧把所有节点重新遍历一遍并重建网格索引。节点的细分状态没变时索引缓存必须复用只更新高度数据这样才能把每帧 CPU 开销控制住。这一点做到位帧率就能稳定不少。4. 渲染流程与核心实现从坐标换算到裂缝处理4.1 球面坐标换算与顶点生成把经纬度瓦片放到球面上标准的换算是lat (tileY v / size) * latSpan - 90; lon (tileX u / size) * lonSpan - 180; x (R h) * cos(lat) * cos(lon); y (R h) * sin(lat); z (R h) * cos(lat) * sin(lon);R 是火星参考半径我取约 3390 公里h 是该点海拔。从瓦片高度图采样出 h 之后用 double 计算 x、y、z存成局部坐标。这里必须提醒火星全球坐标的数值范围很大用 float 直接存会出现肉眼可见的抖动尤其相机贴近地面时地形像被风吹的纸片一样飘。我最后是 CPU 侧用 double 存世界坐标传 GPU 之前减去相机位置把坐标转换到相机附近的局部坐标系再转 float完美解决精度问题。等距圆柱投影在极区会有网格收敛问题纬度接近 90 度时同一经度跨度对应的空间距离越来越小。好在我这个项目主要在空中视角巡游极少贴着极点飞行所以没有进一步处理。如果你要做极地穿越场景建议换六面体投影方案把球面分成六个面片每个面单独跑四叉树极区畸变会小得多。4.2 索引生成与 T 型裂缝根治地形裂缝是四叉树渲染最让人头疼的问题。它的来源很简单相邻两个节点的细分层级不同边缘顶点数量不一致。高层级节点边缘有 33 个顶点低层级节点边缘只有 9 个顶点两者的三角形顶点对不齐接缝处就会出现缝隙。我的方案分两步。第一步限制相邻节点的层级差不能超过 1。这是四叉树裁剪的经典做法任何节点细分前都要检查四邻域节点的层级如果差超过 1先强制细分邻居再细分子节点。这一步能避免大跨度的 T 型裂缝。第二步在节点边缘做裙边。即使层级差不超过 1相邻节点边缘顶点位置仍不同单纯用索引把边缘连起来也会产生拉伸和共面闪烁。我用的裙边做法是在网格的最外圈把所有边缘顶点垂直向下压一段距离额外生成一圈三角形带。由于裙边嵌在星球内部正常角度看过去看不见接缝处的高度差就被这圈下陷三角形带遮住了。加上开启深度偏移双管齐下之后裂缝问题基本从视觉上消失。索引生成本身不复杂每个节点生成一个 (N-1) x (N-1) 的索引网格N 取 33三角形绕序固定为逆时针。注意不要每帧重新生成节点创建时生成一次随后反复使用。4.3 法线重建与纹理贴合高度图本身不直接提供法线。最简单的做法是用高度差分求梯度hL sampleHeight(u - 1, v); hR sampleHeight(u 1, v); hB sampleHeight(u, v - 1); hF sampleHeight(u, v 1); normal normalize(vec3(hL - hR, 2.0 * heightScale, hB - hF));中间那个 2.0 是一个经验权重用来调整法线强度。权重越大光照下地形立体感越强太小则地形显得扁平。你可以把这个值做成参数在“地形平滑”和“山体棱角感”之间切换。法线算出来是切线空间下的向量还需要变换到世界空间。这一步很多人忽略导致火星表面光照方向完全不对。使用 TBN 矩阵转换即可T 沿经度方向B 沿纬度方向N 由球面坐标推出。颜色纹理方面火星全球影像的原始分辨率并不高放大到近地面时会看到明显马赛克。我采用两套纹理混合近景时在高分辨率局部影像瓦片上叠加一层噪声细节用高度图作为混合因子远处则只上低分辨率全球影像节省显存。火星地表那种红褐色氧化铁肌理靠这层噪声补一补视觉上还是相当能骗过眼睛的。4.4 相机移动时的动态更新流程一帧内完整的调度流程我是这样组织的更新相机参数计算世界矩阵和视锥平面。从根节点开始递归遍历四叉树先做视锥剔除再做屏幕误差判定。不满足细分条件的节点加入渲染列表满足细分条件的节点检查子节点状态如果子节点已 Ready 则递归下去否则先处理加载请求。所有请求按优先级入队之后统一派发异步 IO。渲染排序完成之后按节点透明的顺序提交绘制调用。每帧结束后按 LUR 策略淘汰多余的缓存节点。这套流程里最需要小心的是异步加载导致的“父节点先渲染、子节点后补上”。我遇到过一种情况父节点已经细分某个子节点还在加载渲染循环里既看不到父节点、又没有子节点可画结果相机移动时前方地形突然出现一个大黑洞。解决办法是让状态机保证“子节点全部 Ready 才替换父节点”也就是说父节点在当前帧仍保留渲染权直到全部子节点加载完成的下一帧才把父节点从渲染列表里移出。5. 问题排查与参数调优把常见的坑都翻出来5.1 常见问题速查表现象可能原因处理方式瓦片接缝处地形撕裂、有缝隙相邻节点层级差过大、边缘顶点数量不一致启用裙边、限制邻居层级差不超过 1、深度偏移相机靠近地表时地形抖动、飘动float 精度不足double 存全局坐标渲染时转换到相机局部坐标部分地形黑洞加载完才有模型父节点已细分但子节点未 Ready子节点全部 Ready 后才能移出父节点渲染地形表面光照方向混乱法线仍在切线空间未转换到世界空间用 TBN 矩阵变换帧率突然下降十几帧每帧加载请求过多、网格索引重复生成请求限流、索引缓存复用远处细节直接消失像“面团”屏幕误差阈值设得太大调小 thresholdPx比如从 12 降到 8对同一区域反复细化和合并画面抖动LOD 判定没有迟滞细分和合并使用一档迟滞区间比如细分 10px、合并 14pxVRAM 爆炸几分钟后卡死纹理加载不释放或 LRU 失效设纹理内存上限淘汰时同步释放 GPU 纹理5.2 我踩过的几个坑第一个坑是瓦片边界像素不重叠。我最初切瓦片时采用严格不重叠的 256 像素采样高度图时直接按局部坐标索引结果相邻瓦片边缘的高度采样点不连续接缝处出现一条条高度沟槽。后来改成瓦片四周多留一圈像素或者干脆每次从瓦片对应的全局经纬度重新采样高度不再依赖瓦片边缘问题立刻消失。第二个坑是层级差限制和异步加载顺序发生冲突。我一开始只做“邻居层级差不超过 1”的静态限制但没考虑加载中的节点状态。结果高细节节点快速加载完成低细节邻居还没就绪画面里出现半边有地形半边形似悬崖的尴尬场景。后来把状态机改成“先临时用父节点网格过渡等兄弟节点全部就绪再一起切换”才算根治。第三个坑和相机近地面移动有关。当相机贴地高度几百米、视角倾斜到接近水平时屏幕误差估算值对误差非常敏感节点会反复进入细分和合并状态画面看起来像深呼吸一样一呼一吸。我加了迟滞逻辑细分阈值用 10px合并阈值用 14px中间用一段缓冲区间不再临界反复。5.3 一套可以直接抄的保守参数起点如果你的视口是 1080p、FOV 60 度我建议从这套参数起步瓦片大小256 x 256节点网格密度33 x 33 顶点最大层级14依据数据精度可下调到 12屏幕误差阈值10 px合并阈值 14 px每帧最多请求数4 到 8 个内存上限高度图和纹理合计 512 MB纹理过滤三线性 8 倍各向异性高度图格式16 位 PNG深度偏移开启偏移量根据近远裁剪面动态调整这套参数跑下来全球视角流畅飞到距地表几十公里高度时依然能保持较好的细节。真正进入低空漫游前把最大层级调高、提高请求频率效果会进一步改善但这也要求数据源本身有足够高的局部分辨率否则只是把插值放大视觉收益有限。6. 最后再分享一点实际体会这套四叉树加 LOD 的方案折腾完给我最大的感受是火星作为测试场真的省心。不需要处理乱七八糟的投影分带也不用担心数据版权问题全流程从数据切片到渲染调度可以完整走通。而这个四叉树加 LOD 的骨架换到地球、月球或者任何一个球体上都是通用的差别只在于数据精度和瓦片组织方式。我个人的经验是项目推进顺序不要乱先让四叉树在静态网格上跑通再做 LOD 判定之后才叠加颜色纹理和异步调度。一上来就啃调度优化通常只会被各种加载竞态问题劝退。希望这篇笔记能让你少走点弯路把更多精力放在真正有趣的地形细节上。
