如果你做过一段时间的 Vulkan 渲染器大概会有这种感觉引擎跑起来之后最难受的不是某个渲染效果做不出来而是 CPU 和 GPU 之间那条细细的传导线。场景一复杂几千个 DrawCall 往提交队列里怼几何数据跟着一大堆状态切换LOD 切层距离近了跳变距离远了白fill。我这次在自研 Vulkan 渲染器里实现的连续集群 LODContinuous Cluster LoD就是想把这套传统流程换成另一种思路把可见性判断、LOD 决策和几何输出全部下沉到 GPU 侧以 cluster三角形簇为最小处理粒度让几何管线的关注点从一个模型变成一组三角形。本文是这次实验从方案设计、管线搭建到踩坑排错的完整记录适合正在搞 Vulkan 几何管线、或者对 Nanite 类方案有兴趣但不想一上来就啃源码的人参考。先声明一下我不是在做 UE5也没有复刻几百倍的压缩率而是从更传统的 GPU-Driven Render 路径出发把连续集群 LOD这件事从原理到落地走了一遍中间的取舍和教训我都写下来。1. 为什么传统几何管线在 Vulkan 里也开始力不从心1.1 顶点量不是瓶颈调度与状态切换才是旧式几何管线的标准路径是VBO/IBO 进 Vertex Shader再走 Primitive Assembly、Rasterization。这套流程在几百个物体的小场景里完全没问题但一旦场景达到一万个可视对象以上问题就变了。现代 GPU 每秒处理几十亿三角形的理论算力并不缺缺的是 CPU 端提交几何数据、切换管线状态、更新描述符的能力。我这边有个中等密度的室外场景光静态网格就有 1.2 万个传统做法每帧 CPU 要花掉 4 到 6 毫秒去做粗粒度剔除和 Draw 组装这还只是可见性计算没算提交本身。Vulkan 跟 OpenGL 不一样的地方在于它把一个 DrawCall 的隐藏成本亮出来了Pipeline Bind、Descriptor Bind、Vertex Input 状态、间接参数缓冲每一样都是显式的。理论上你可以把一万个物体打包进一个 IndirectDraw但问题来了——管线状态不同怎么办纹理绑定不同怎么办物体被遮挡了怎么避免它继续占资源这些在传统管线里都绕不开按物体逐次提交的宿命。另一个被忽略的瓶颈是剔除粒度。CPU 侧做视锥剔除通常以整个物体包围盒为单位。一个大型建筑只露了一个角你仍然要把它的完整 VBO 送进去顶点着色器里大部分顶点根本不会产生可见像素。GPU 驱动的剔除GPU-Driven Culling可以把这个负担卸掉但如果你还是用传统的顶点级管线剔除粒度也最多到一个 Draw 范围内是否可见。1.2 离散 LOD 的跳变问题出在粒度太粗传统 LOD 的做法大家都很熟模型离线烘焙出 LOD0、LOD1、LOD2 几档运行时按距离选择。问题在于切换是按整个模型实施的切换瞬间模型顶点数量少了一个量级投影边长突变再叠加法线、纹理密度、阴影贴图的变化结果就是玩家能明显看到pop跳变。如果切层阈值离得远一点、保守一点又会在中距离浪费大量三角形画质和性能两头不讨好。为什么会这样因为离散 LOD 的开关粒度是模型级。一个模型内部各部分的可见度差异极大远处的一个塔尖可能只需要几十个三角形而近处的一个门拱可能需要几千个。用整体距离来决定全模型的简化程度本质上是在用一个平均值替所有局部做决策。连续集群 LOD 的核心就是把这个决策单元从模型缩小到cluster——一组几十到一百来个三角形的集合。每个 cluster 独立计算屏幕空间误差、独立决定自己用哪一档精度这样切换成本被分散到人眼难以察觉的尺度上。1.3 Vulkan 把问题放大了也给了机会在 OpenGL 时代驱动还会替你做状态排序、一些简单的裁剪优化。到了 Vulkan所有底层控制权都交给你了代价就是没有兜底任何低效都得自己承担。这听起来像是坏事但对于连续集群 LOD 这种需要深度自定义几何管线的方案反而是好事你可以用计算着色器做全 GPU 的可见性提取用 Bindless 资源跳过每物体描述符切换用间接调度把 CPU 从渲染主循环里几乎摘出去最后再用 Task/Mesh Shader 从底层改变三角形生成的方式。当然机会背后是兼容性和工程量的代价。VK_EXT_mesh_shader不是所有平台都支持Bindless 的descriptor indexing在一些移动 GPU 上也有限制。所以在搭这套管线之前我给自己定的目标是Mesh Shader 路径是主路径但必须保留一条能跑在旧设备上的降级路径。这个降级方案我在第 5 章会专门讲。2. 连续集群 LOD 的底层逻辑粒度、误差与接缝2.1 Meshlet一个能在 GPU 上独立处理的几何单元集群 LOD 离不开 cluster在 Vulkan/DX12 语境里这个东西也常叫 meshlet。它本质上是把一个大模型切成一堆小的三角形集合每个集合包含几十个顶点、几十到一百来个三角形。为什么用这个量级因为 GPU 的执行粒度跟它强相关NVIDIA 的 wavefront 规模是 32 线程AMD 是 64 线程Mesh Shader 一个 workgroup 通常对应 128 线程左右。如果一个 cluster 的三角形数跟一个 workgroup 能处理的线程数对齐就不会出现大量线程空转。我这边用 MeshOptimizer 库做划分参数是max_vertices64、max_triangles124。这是一个在实践中比较常见的组合顶点数不要太高保证局部性三角形数接近 124 是为了让 128 线程的 workgroup 里有少量余量处理溢出。meshlet 生成时会尽量保证三角形之间共享顶点这样在 Mesh Shader 阶段我们可以直接用局部索引输出三角形缓存命中率也高。每个 meshlet 除了几何数据还需要附带一个包围球或包围盒。这个包围体是 GPU 做 cluster 级剔除的基础——一个 cluster 如果整个在视锥外、或者被深度缓冲遮挡那它里面所有三角形都不用执行这就是比按物体剔除更细一档的裁剪粒度。2.2 连续到底指什么两条技术路线要先澄清一个容易混淆的点连续集群 LOD 里的连续不是指几何数据每帧动态变化流式细分而是指LOD 选择的误差曲线是连续的切换过程在人眼感知上不可察觉。它本质上是把一组离散的 LOD 层级做得足够细、足够局部让它们的误差在任何距离上都不会超过一个像素阈值。落地时有两条路线。第一条是**边界锁定boundary-locked**方案思路来自早期 Rabbit 那类连续集群算法离线把模型的 cluster 边界顶点锁定简化器可以任意坍缩 cluster 内部的顶点但边界顶点不能被移动或删除。因为相邻 cluster 共享同一组边界顶点它们的三角形在交界处天然对齐无论两个 cluster 各自处于哪一档 LOD缝合处都不会出现裂缝。这个方案的最大优点是拓扑稳定、容易实现。代价是简化率被边界顶点限制住了我实测一个大建筑模型只能压到原始三角形的 10% 到 15%再往下边界区域就开始成为瓶颈。第二条是自由简化 过渡区方案Nanite 大致走的是这个方向。cluster 内部和边界都可以被简化压缩率高得多但解决 cluster 之间的裂缝就要靠额外的过渡几何、双面渲染或者某种裙边机制。我这次实验先选了边界锁定路线因为它的结果可控调试时不容易被一闪一闪的裂缝干扰自由简化路线对资产管线的要求更高适合后续版本再引入。2.3 屏幕空间误差用像素决定切哪一层连续 LOD 的选层不是简单按距离切而是按屏幕空间误差。一个 cluster 有多个 LOD 版本每个版本有一个离线计算好的世界空间误差e它表示这个版本相对原始高模的最大偏差。运行时把e投影到屏幕上换算成像素值如果小于阈值比如 1 像素就认为这一档足够精细可以切换。投影公式可以用一个非常简化的模型来理解p ≈ e × (H / 2) / (d × tan(fov / 2))其中H是视口像素高度d是观察距离fov是垂直视场角。举个例子一个 cluster 的 LOD1 版本世界空间最大误差是 1 厘米视口高 1080垂直 FOV 60 度观察距离 20 米那它造成的屏幕误差大约是 0.01 × 540 / (20 × 0.577) ≈ 0.47 像素。这种情况下切到 LOD1 肉眼基本察觉不到。但如果距离拉到 5 米同样误差就变成接近 1.9 像素这时候就该换回更精细的 LOD0。在 GPU 上算这个东西非常便宜就是一次 view-space 距离计算加一次乘除。我把它放在 Compute Shader 里每个线程处理一个 cluster遍历该 cluster 的 LOD 列表选出误差刚好小于阈值且三角形最少的那一档。因为每个 cluster 都是独立的所以同一帧里远处墙面用 LOD2、近处窗框用 LOD0 是很正常的事这也是连续感知的关键。2.4 接缝难题和常见处理手法只要 cluster 之间 LOD 选层不同接缝问题就绕不开。边界锁定方案下由于边界顶点在所有 LOD 版本中保持一致几何上不会出现裂缝但这不代表万事大吉——法线、UV、切线这些顶点属性如果在简化过程中被改写过簇与簇交界处仍然会出现着色跳变。这个坑我放到第 5 章详细讲。如果你选择自由简化路线接缝处理通常有三种手法一是给 cluster 外圈生成一条极薄的裙边skirt把缝隙盖住二是让相邻 cluster 共享一条固定边带的顶点去焊接三是在两个 LOD 版本之间做一段过渡区让边界处的三角形从旧精度渐变到新精度。这三种方案各有代价裙边会引入很细碎的三角形焊接会降低压缩率过渡区则要额外存储双倍几何数据。所以在工程上边界锁定其实是性价比很高的起点。3. Vulkan 管线落地从离线资产到 GPU 驱动渲染3.1 离线预处理链路先把资产侧捋顺。我这边流程是原始高模来自雕刻软件或建模软件进入一个离线工具链经过四步处理输出为自定义的.clod格式。自动减面用带象限误差度量的边坍缩算法逐步简化生成多个精度层级。如果做边界锁定简化器需要知道哪些顶点是边界顶点把这些顶点从坍缩候选中排除。Cluster 划分对每一层 LOD 分别跑 MeshOptimizer生成 meshlet 集合。注意不同 LOD 层的划分结果是独立的但边界顶点集合要在所有 LOD 层之间保持一致。包围体计算为每个 cluster 计算精确的包围球误差信息写进 LOD 元数据。打包把所有 cluster 的顶点、索引、材质 ID、LOD 元数据合并成大缓冲区按 Vulkan 的 SSBO 内存布局打包转成二进制资产。这一步的产物大致是下面这种结构MeshletDesc包围球、顶点偏移、顶点数量、三角形偏移、三角形数量、材质索引、LOD 层号ClusterVertexBufferpositionvec4、normalvec4、uvvec2、tangentvec4ClusterIndexBuffer每三个索引一个三角形局部索引 u32LODMetaBuffer每层误差、可切换的阈值CPU 加载时直接把这些 Buffer 上传到VK_BUFFER_USAGE_STORAGE_BUFFER_BIT | VK_BUFFER_USAGE_INDIRECT_BUFFER_BIT后面渲染阶段就完全不再碰这些几何数据。3.2 Compute 阶段可见性提取与 LOD 决策渲染循环里我先把整个场景的所有 cluster 信息扔给 Compute Shader每个 thread 处理一个 cluster做三件事视锥剔除、遮挡剔除可选、LOD 选层。伪代码大致长这样// compute: 每个线程处理一个 cluster #version 460 layout(local_size_x 128) in; struct Cluster { vec4 boundingSphere; // xyz 中心w 半径 uint lodIndex; // 当前 LOD 层内 cluster 索引 float worldError; // 该 cluster 在当前 LOD 层相对高模的误差 uint triangleCount; }; layout(std430, binding 0) readonly buffer Clusters { Cluster clusters[]; }; layout(std430, binding 1) buffer VisibleList { uint visibleClusters[]; }; layout(std430, binding 2) buffer DrawCounter { uint counter; }; uniform mat4 viewProj; uniform vec4 frustumPlanes[6]; uniform float viewportHeight; uniform float tanHalfFov; void main() { uint id gl_GlobalInvocationID.x; if (id clusters.length()) return; Cluster c clusters[id]; // 1. 视锥剔除 vec4 sphere c.boundingSphere; for (int i 0; i 6; i) { float dist dot(frustumPlanes[i].xyz, sphere.xyz) frustumPlanes[i].w; if (dist -sphere.w) return; } // 2. 计算屏幕空间误差并选 LOD简化版实际选层逻辑在离线工具里确定 float dist length(sphere.xyz - viewPos.xyz); float errPx c.worldError * (viewportHeight * 0.5) / max(dist * tanHalfFov, 1e-3); if (errPx pixelErrorThreshold) { // 需要更精细的一层这里通过二次查询找更细 LOD } // 3. 输出为可见 cluster uint idx atomicAdd(counter, 1u); visibleClusters[idx] id; }实际工程里我会把选层做成一个预先烘焙好的误差表运行时用distance或view-space z直接查表避免复杂的循环判断。Compute 阶段会维护一个全局可见 cluster 列表以及一个按 LOD 层分类的间接调度参数。最后把counter写回一个VkDispatchIndirectCommand用于触发后面的 Task/Mesh 阶段。3.3 Task/Mesh Shader让几何管线的粒度变成 Cluster这是整条链路里最关键的一段。VK_EXT_mesh_shader引入了两级新着色器Task Shader可选和 Mesh Shader。Task Shader 的每个 workgroup 可以发射若干个 Mesh Shader 的 workgroup而 Mesh Shader 的每个 workgroup 对应一个 meshlet它直接输出顶点和三角形。我的做法是Compute 阶段已经得到一个紧凑的visibleCluster列表Task Shader 每个线程负责一个可见 cluster做最后一层细节剔除比如更精细的遮挡后把通过的 cluster ID 放进 payload然后用EmitMeshTasksEXT发射对应数量的 Mesh Shader workgroup。// task shader 片段 #version 460 #extension GL_EXT_mesh_shader : require layout(local_size_x 128) in; struct Cluster { vec4 boundingSphere; uint meshletOffset; uint vertexCount; uint triangleCount; uint materialIndex; }; layout(std430, binding 0) readonly buffer Clusters { Cluster clusters[]; }; layout(std430, binding 1) readonly buffer VisibleList { uint visibleClusters[]; }; layout(std430, binding 2) readonly buffer DrawCounter { uint counter; }; taskPayloadSharedEXT TaskPayload { uint meshletIDs[128]; uint materialIDs[128]; } payload; void main() { uint i gl_GlobalInvocationID.x; if (i counter) return; uint clusterID visibleClusters[i]; Cluster c clusters[clusterID]; // 可再做一次更精细的遮挡剔除这里略 payload.meshletIDs[gl_LocalInvocationID.x] clusterID; payload.materialIDs[gl_LocalInvocationID.x] c.materialIndex; } // 之后通过 subgroup ballot 或共享内存统计可见数量 // 再调用 EmitMeshTasksEXT(visibleCount, 1, 1);Mesh Shader 端则根据 payload 里的 cluster ID 读取对应的顶点和三角形索引写入gl_MeshVerticesEXT和gl_PrimitiveTriangleEXT// mesh shader 片段 #version 460 #extension GL_EXT_mesh_shader : require layout(local_size_x 128) in; taskPayloadSharedEXT TaskPayload { uint meshletIDs[128]; uint materialIDs[128]; } payload; // 省略绑定、缓冲声明 void main() { uint clusterID payload.meshletIDs[gl_LocalInvocationID.x]; Cluster c clusters[clusterID]; SetMeshOutputsEXT(c.vertexCount, c.triangleCount); // 写顶点 for (uint i gl_LocalInvocationID.x; i c.vertexCount; i gl_WorkGroupSize.x) { VertexData v readClusterVertex(c.meshletOffset, i); gl_MeshVerticesEXT[i].gl_Position viewProj * vec4(v.position, 1.0); // 同时输出法线、UV 等到 per-vertex 自定义可变变量 } // 写三角形索引 for (uint i gl_LocalInvocationID.x; i c.triangleCount; i gl_WorkGroupSize.x) { uvec3 tri readClusterTriangle(c.meshletOffset, i); gl_PrimitiveTriangleEXT[i].gl_PrimitiveIndicesEXT uvec3(tri.x, tri.y, tri.z); } }到这一步几何管线的粒度就彻底变成 cluster 了。一个 Task Shader dispatch 可以覆盖上万个 clusterMesh Shader 并行输出它们的三角形光栅化单元照常工作。对 CPU 来说一帧只需要提交一个 dispatch 命令剩下的全部由 GPU 内部决策。3.4 Bindless 与 Indirect为什么这套方案更适合 Vulkan这套链路里有两个特性是我明确依赖的一个是Bindless / Descriptor Indexing另一个是Indirect Dispatch。传统绑定方式下每个物体需要一组描述符状态切换开销跟 draw call 数量成正比。但在 cluster 渲染里cluster 数量可以轻松到十万级别不可能为每个 cluster 绑描述符。用 Bindless 后所有 cluster 数据、材质纹理、材质参数全部放在几组大描述符数组里Mesh Shader 里直接用materialIndex去采样对应纹理这一步省掉了整个渲染 loop 里一半的状态切换开销。Indirect 的意义在于让 GPU 自己决定接下来该画多少。Compute 阶段写好的counter会被 CPU 用vkCmdDispatchIndirect引用GPU 调度器看到的是动态的任务数而 CPU 只是提交了一条固定命令。实测下来CPU 提交时间从几毫秒降到了几十微秒而且场景越复杂收益越大——因为 CPU 侧的可见性计算成本几乎被压到零。4. 实测数据集群 LOD 究竟省了什么4.1 测试环境与对比基线先交代测试环境AMD Ryzen 9 5900X、NVIDIA RTX 3060、Linux Vulkan 1.3。场景是我自建的一个中世纪小镇包含约 1.2 万个静态网格物体原始三角形总数约 2.3 亿。注意这是一个精度非常高的资产库不是实时游戏里常见的几百万三角形场景所以数据更偏压力测试。对比基线是同一渲染器里用传统管线实现的版本每个物体一个 DrawCall带 4 档离散 LODCPU 做视锥剔除和距离选层。两者使用相同的相机路径、相同的视口和阴影设置。4.2 数据结果Draw、三角形、帧时间指标传统离散 LOD集群 LODMesh Shader变化CPU 提交时间4.6 ms0.12 ms约 -97%DrawCall / Dispatch约 8400 draw2 个 dispatch数量级下降渲染三角形量约 4200 万约 760 万约 -82%几何 Pass GPU 时间3.1 ms1.4 ms约 -55%可见 pop3-4 处明显跳变基本不可见视觉大幅改善关键点不在三角形从 4200 万降到 760 万这个数字本身而在于这是 GPU 自己基于屏幕空间误差算出来的结果。在传统管线里如果我把距离阈值调高中远景会被简化得非常狠弹跳肉眼可见现在我只需要把像素误差阈值从 1.0 调到 0.8远处细节自然多保留一点几乎不用调整任何距离参数。4.3 瓶颈转移带来的连锁变化几何成本降下来之后最直接的连锁反应是帧时间预算的重新分配。之前几何 Pass 占掉一大块阴影 Pass 又占一块光照、后处理都得靠边站。现在几何和阴影加起来省出 2 毫秒以上我把它给了 SSAO 质量和更激进的反射探针更新整体画面观感好了不少。另一个容易被忽略的点是带宽。传统管线里LOD0 的顶点数据从显存读到 L2 是一次大流量切换 LOD 时又得多读一份新数据。集群 LOD 下GPU 一次只读取被选中的 cluster 的那一小段顶点和索引而且和三角形数量成正比显存带宽压力显著下降。RTX 3060 的 PCIe 带宽和显存带宽在场景大转移时曾经到过 80% 以上现在基本稳定在 40% 左右。5. 实战踩坑记录接缝、法线、阴影和兼容性5.1 集群交界处的裂缝与闪烁第一次跑通完整管线我直接盯着屏幕找 pop。大部分距离上没有跳变但某些墙角、门框边缘会出现细小的闪烁像是三角形在来回切换。排查后发现问题出在离线简化的数值稳定性上边界顶点虽然没被删除但简化算法在计算边坍缩代价时会把边界顶点所属的三角形也纳入误差度量导致内部顶点被压缩后边界三角形贴得不够紧光栅化时出现一两个像素的缝隙。解决方法分两步。第一在简化过程中给边界三角形更高的权重让简化器优先坍缩远离边界的边。第二在 Mesh Shader 输出的顶点位置上加一个极小的裙边偏移不裙边会带来阴影瑕疵。更稳的做法是给边界顶点绑定一个可选的位置校正表把跨 cluster 的重复顶点位置强制统一。我最后选择的是边界锁定 顶点位置快照所有 LOD 层共享同一份边界顶点位置不参与任何坍缩和合并。5.2 法线和切线属性在简化后的失真几何裂缝解决了新问题又来了法线在 cluster 交界处会出现明显的明暗断裂尤其在有法线贴图的墙体上。原因很简单法线贴图采样的是切线空间法线而切线空间的基底来自顶点切线。当 cluster 内部顶点被简化后UV 分布变了切线也随之改变同一个 UV 位置在两套切线基底里可能差出好几度。断裂最容易发生在法线贴图高频区域比如砖墙、石板路面。我的处理方案是把切线也纳入边界保持逻辑离边界一定距离内的顶点切线信息在 LOD 切换时都保持不变。另外法线贴图本身在低 LOD 层可能需要加大 blur防止屏幕误差已经很小的时候纹理频率过高产生摩尔纹。这里我踩过的坑是直接在 Fragment Shader 里按 LOD 层切换 mip 偏移结果导致交接处变糊。正确做法是让 UV 导数自然驱动 mip而不是手动指定层。5.3 阴影与 Alpha Test 的额外要求阴影 Pass 一开始我偷懒用的是最简单的传统深度渲染把整个场景的 LOD0 数据按原样送进去。结果阴影边缘出现严重的自阴影粉刺因为这些高模 cluster 的三角形密度在近距离超过了深度贴图的采样精度。后来把阴影 Pass 也切换到了同一套集群 LOD 管线问题基本解决。注意阴影 Pass 的像素误差阈值要比 Color Pass 更保守因为阴影贴图的分辨率远低于常规渲染目标。我把阴影 Pass 的阈值设为 0.5 像素处理的是屏幕空间误差但实际由光源视锥主导因此要额外对靠近光源的 cluster 扩大精度选择。Alpha Test 是另一个暗坑。传统管线里alpha 测试发生在像素着色后一个三角形可能只有 30% 的像素通过。但在 meshlet 语义下cluster 是独立剔除的单位你没法在三角形级做裁剪一半的退化剔除。如果场景里有大量树叶、铁丝网这种 alpha 剪裁几何meshlet 的剔除效率会骤降。我的建议是植被和剪裁几何单独走传统管线不要硬塞进集群 LOD。5.4 没有 Mesh Shader 的机器怎么办Mesh Shader 扩展的支持面在桌面端已经不错但移动端和旧核显依然不友好。我做一个降级路径Compute Shader 照常做 cluster 剔除和选层但输出的不再是间接 dispatch 参数而是一个紧凑的顶点索引重映射表。随后用一个普通的 Vertex Shader 从 cluster 缓冲区中读取并变换顶点gl_VertexIndex通过重映射表找到对应的全局顶点。这个降级方案可以把 90% 的收益保留下来——GPU 驱动的剔除和连续 LOD 决策照常工作只是几何管线的输出方式回到传统 vertex pipeline。它的代价是在 Mesh Shader 路径里可以省掉的重复顶点 fetch在这里会多花一点带宽但至少保证老设备能跑不至于一套新特性只能服务高端卡。6. 后续演进动画、物理与硬件趋势6.1 蒙皮网格与集群 LOD 的摩擦连续集群 LOD 在静态场景里表现很好但一碰到蒙皮骨骼动画问题就来了。蒙皮顶点需要每帧由骨骼矩阵驱动而集群 LOD 的顶点数据是静态烘焙过的。如果对蒙皮网格套用同样的 cluster 减面边界锁定依然有效但蒙皮权重必须作为不可压缩属性保留结果就是简化率上不去。更麻烦的是动画过程中 cluster 包围球也需要动态更新否则视锥剔除会提前把可见 cluster 剪掉。一种常见做法是只对距镜头一定距离以上的角色启用集群 LOD近距离用传统骨骼渲染保证质量。我更倾向的路线是后续引入cluster 级蒙皮并行化蒙皮计算放到 Compute 中输出结果直接被 Mesh Shader 读取这样就不需要额外同步但在资产计算和调试上要比静态场景复杂不少。6.2 渲染与物理几何的一致性跨界到物理系统是另一个角度的挑战。连续集群 LOD 里的几何是高度动态选择的物理引擎不可能拿这些三角形做碰撞。如果玩家碰撞体用的是低模代理而渲染用了高模 cluster两者在细节丰富的地方会出现明显的穿模。目前主流做法还是为物理预备独立的代理几何包括凸分解体、粗糙碰撞壳。这不算缺陷但如果你原本想用同一份几何既做渲染又做物理连续集群 LOD 会明确告诉你不行。6.3 硬件与 API 生态的下一步从硬件趋势看NVIDIA Turing 之后、AMD RDNA2 之后都加入了 Mesh Shader 相关的硬件支持Intel Arc 也在跟进这一代几何管线显然是要往GPU 自主决定几何的方向走。Vulkan 的VK_EXT_mesh_shader作为跨厂商扩展生态上比 DX12 的 Mesh Shader 更开放未来实现跨平台路径时有明显优势。我比较期待的是硬件侧对任务级粒度的进一步优化比如更宽松的 Mesh Shader payload、更大的输出顶点上限这会直接拉升 cluster 的可用复杂度。另一个值得关注的方向是几何与光追的融合。硬件光追加速结构仍然依赖传统 BVH但底层的三角形数据如果来自 cluster LOD 的动态选择加速结构更新就变成了哪部分 cluster 换 LOD就更新哪段 BVH。这个思路可以把光追的三角形量也降下来让实时光影和几何复杂度同步降载。目前没有看到非常成熟的通用解决方案但这条路我觉得是接下来一两年最有意思的技术点。最后再分享一个小技巧连续 LOD 的调参别一上来就追求像素误差最小化。先把阈值放到 1.5 像素跑一圈确认没有接缝问题再把阈值往下压。因为像素误差只是表面因素法线连续性、纹理频率、阴影抖动都会影响最终观感而这些是纯距离公式描述不了的。先保证视觉稳定再去追指标能省掉一半调参的头发。