1. 项目概述当Gaussian Splatting遇见Unity最近在社区里看到不少朋友在尝试把Gaussian Splatting高斯泼溅这套炫酷的3D重建技术搬到Unity里结果一跑起来帧率直接掉到个位数尤其是当Splat数量Splats一多比如达到几百万甚至上千万级别时项目基本就卡成幻灯片了。这太正常了因为Gaussian Splatting本质上是一种基于点的、需要大量并行计算的渲染技术它和Unity传统的基于三角形网格的渲染管线完全是两回事。我最近刚啃下来一个硬骨头把一个包含610万个Splats的场景在Unity里从最初的不到10 FPS优化到了稳定147 FPS。这中间踩过的坑、试过的方案足够写一本小册子。今天我就把这次性能优化的完整心路历程和具体操作拆解出来希望能帮到正在和性能搏斗的你。简单来说Gaussian Splatting是一种从多视角图片重建出3D场景的新方法它不像传统方法输出网格而是输出一大堆带有颜色、不透明度、旋转和缩放的3D高斯椭球这就是Splats。渲染时这些椭球会被投影到2D屏幕并按深度排序然后通过类似体素渲染的方式混合形成最终图像。它的优势是重建质量极高特别是对复杂细节和半透明材质的还原。但问题也来了每个Splat都是一个独立的渲染单元计算量巨大。在Unity里如果不做任何优化直接用一个Shader去遍历渲染几百万个点GPU根本吃不消。这个优化过程绝不仅仅是调几个参数那么简单。它涉及到从数据预处理、渲染管线定制、计算着色器Compute Shader的深度运用到CPU-GPU通信、内存管理、乃至引擎底层Draw Call的彻底重构。我们最终的目标是让这套“外来”的渲染技术能高效、稳定地跑在Unity的生态里无论是在PC、移动端还是未来可能的XR设备上。2. 核心瓶颈分析与优化总览在动手优化之前我们必须像医生一样先给项目做个全面的“体检”找到真正的性能瓶颈。盲目优化只会事倍功半。对于Unity中的Gaussian Splatting瓶颈通常分布在以下几个层面。2.1 CPU端瓶颈数据准备与Draw Call在Unity的默认渲染流程中即使我们使用GPU Instancing或Compute Shader来渲染SplatsCPU仍然有大量工作要做。最致命的就是Draw Call。如果你为每个Splat或每批Splat生成一个GameObject或一个Graphics.DrawProcedural调用当Splat数量达到百万级时Draw Call数量会爆炸CPU时间会全部消耗在准备和提交渲染命令上GPU却在一旁“饿着肚子”等待。另一个CPU瓶颈在于数据准备。原始的Gaussian Splatting数据通常是.ply文件包含每个Splat的位置、颜色球谐系数、缩放、旋转四元数和不透明度。这些数据需要被组织、上传到GPU。如果每一帧都从C#端重新组织这些数据并调用SetBuffer或SetData会产生巨大的CPU开销和内存分配GC Alloc导致卡顿。2.2 GPU端瓶颈着色器计算与带宽GPU是渲染的主战场瓶颈也最为复杂。顶点/几何着色器过载一种常见的实现方式是将每个Splat作为一个顶点在顶点着色器中计算其对应的屏幕空间四边形两个三角形。对于610万个Splats顶点着色器就要执行610万次。这其中有大量计算是重复或可以简化的比如视图矩阵的变换、投影计算等。片元着色器过载与Overdraw每个Splat在屏幕上覆盖一个区域这个区域内的每个像素片元都可能被多个Splat重叠覆盖。由于渲染顺序通常按深度从后往前的需要一个像素可能被计算几十次甚至上百次深度复杂度高这就是恐怖的Overdraw。片元着色器中的混合操作Blend和深度测试虽然由硬件处理但计算量依然巨大。内存带宽瓶颈这是最隐蔽也最关键的瓶颈。每个Splat的属性位置、颜色、旋转、缩放等需要作为数据传递给Shader。如果这些数据组织不当例如没有使用GPU友好的数据布局或者频繁在CPU和GPU间拷贝访问这些数据的延迟会成为主要性能杀手。GPU的算力很强但如果数据喂不饱它算力就闲置了。2.3 优化策略总览针对上述瓶颈我们的优化路线图是分层、递进的数据层面优化重新组织Splat数据使其对GPU缓存友好并减少不必要的数据传输。渲染管线重构抛弃传统的GameObject渲染路径采用基于Compute Shader的完全自定义渲染管线将排序、剔除等逻辑也搬到GPU上。算法级优化实现视锥体剔除Frustum Culling、细节层次LOD和基于屏幕空间误差的Splat简化从根本上减少需要处理的Splat数量。Shader微优化优化着色器代码减少寄存器压力利用GPU的SIMD特性合并计算步骤。我们的优化目标很明确将CPU从繁重的数据组织和命令提交中解放出来使其只负责最轻量的调度将绝大部分计算包括剔除、排序、渲染都压到GPU上并确保GPU的计算单元和内存带宽被高效利用。3. 数据预处理与高效存储结构优化第一步从源头——数据开始。原始的.ply文件是一种通用格式并未为实时渲染优化。我们需要将其转换为Unity或者说GPU更“爱吃”的格式。3.1 原始数据解析与问题一个典型的Splat数据包含x, y, z: 位置3个floatnx, ny, nz: 法线在Gaussian Splatting中通常不使用可忽略f_dc_0, f_dc_1, f_dc_2: 球谐函数的0阶系数代表基础颜色3个floatf_rest_*: 球谐函数高阶系数通常是45个float用于表示视角相关的颜色变化opacity: 不透明度1个floatscale_0, scale_1, scale_2: 缩放3个float通常经过exp运算得到实际缩放值。rot_0, rot_1, rot_2, rot_3: 表示旋转的四元数4个float需要被归一化。直接将这些数据作为一个大的StructuredBuffer传给Shader会有几个问题数据不对齐GPU访问内存时有特定的对齐要求例如128位或256位边界。混合了不同大小的数据如float和float3可能导致低效的内存访问。缓存不友好着色器可能只需要访问部分属性如位置用于剔除但不得不加载整个结构体浪费了带宽。球谐系数庞大45个高阶系数数据量很大但在很多情况下特别是性能优先时可以牺牲一些视觉效果仅使用0阶系数基础颜色来大幅减少数据量。3.2 定制GPU数据结构我们的策略是将数据按用途拆分到不同的Buffer中并确保每个Buffer内的数据紧密排列Array of Structures 转为 Structure of Arrays 的变体。我们创建了以下ComputeBufferSplatPositionBuffer(StructuredBuffer ):存储位置x, y, z和一个预计算的边界球半径w。这个半径是根据缩放和一个保守估计计算出来的用于后续的视锥体剔除。将位置和半径打包在一个float4中GPU可以一次性加载非常高效。// 预计算示例 (C#端预处理时完成) Vector3 scale new Vector3(exp(scale_0), exp(scale_1), exp(scale_2)); float boundingSphereRadius scale.MaxComponent() * 1.732f; // 近似对角线长度 positions[i] new Vector4(x, y, z, boundingSphereRadius);SplatAttributeBuffer(StructuredBuffer ):这是一个关键优化。我们将颜色、旋转、缩放等属性编码到更紧凑的格式中。uint2.x: 编码颜色和不透明度。将RGB颜色每个通道0-1量化到R8G8B8A8格式每个通道8位共32位其中A存储不透明度也量化到8位。在Shader中再解码。byte r (byte)(color.r * 255); byte g (byte)(color.g * 255); byte b (byte)(color.b * 255); byte a (byte)(opacity * 255); uint packedColor (uint)((a 24) | (b 16) | (g 8) | r);uint2.y: 编码旋转和缩放。将四元数单位向量编码成SNORM164个16位有符号整数。缩放经过log后的scale_0, scale_1, scale_2也可以量化后打包进剩余的位数或者单独一个Buffer。这里我们选择将log缩放值float3量化为UNORM16和旋转一起打包进另一个uint。为了简化我们可以将旋转四元数存储在另一个Bufferfloat4但为了极致紧凑编码是值得的。SplatRotationBuffer与SplatScaleBuffer(可选StructuredBuffer ):如果对编码解码带来的轻微精度损失和性能开销有顾虑或者需要完整的球谐系数可以保留单独的Buffer。但务必确保它们是float4对齐的。对于610万Splats每个float4是16字节两个Buffer就是约186MB。加上位置Buffer约93MB显存占用已经不小。因此编码压缩对移动端或大场景至关重要。注意数据量化如将float颜色转为byte会带来精度损失可能导致渲染出现色带。但在实践中对于大多数场景8位颜色加上正确的Gamma解码视觉差异极小而带来的带宽收益和缓存命中率提升是巨大的。这是一个典型的用极小视觉代价换取巨大性能提升的权衡。3.3 数据上传与更新策略这些Buffer在场景加载时一次性创建并上传数据。在运行时绝对避免每帧更新整个Buffer。只有当场景中的Splats发生动态变化这在Gaussian Splatting中很少见时才更新局部数据。通过这样的数据预处理我们将每个Splat的GPU内存占用从原始的约240字节453134个float压缩到了约32-48字节取决于编码方案数据量减少了5-8倍。这直接缓解了GPU内存带宽压力是后续所有GPU优化生效的基础。4. 基于Compute Shader的GPU驱动渲染管线这是性能提升最核心的一环。我们要彻底告别由CPU驱动、通过Graphics API逐对象提交的渲染方式构建一个由Compute Shader发起和控制的GPU端渲染管线。4.1 传统渲染路径的缺陷传统做法可能是使用Graphics.DrawProcedural在C#端循环为每一批Splats设置属性并调用绘制。这仍然会产生大量的CPU到GPU的命令提交开销。我们的目标是让CPU只发一次令剩下的全由GPU自己搞定。4.2 核心Compute Shader剔除与排序我们创建一个核心的Compute Shader它每个线程处理一个Splat。这个Shader主要做两件事视锥体剔除利用预计算好的边界球半径存储在SplatPositionBuffer的w分量快速判断Splat是否在相机视锥体内。剔除计算本身很简单但关键在于剔除后我们需要一个紧凑的列表来存储可见的Splat索引。// 在Compute Shader中 [numthreads(256, 1, 1)] void FrustumCullAndPrefixSum (uint3 id : SV_DispatchThreadID) { uint splatIndex id.x; if(splatIndex totalSplats) return; float4 posAndRadius SplatPositionBuffer[splatIndex]; float3 worldPos posAndRadius.xyz; float radius posAndRadius.w; bool isVisible // ... 视锥体相交测试逻辑 ... // 将可见性结果写入一个AppendBuffer或使用原子操作计数 if(isVisible){ uint dstIndex 0; InterlockedAdd(visibleCountBuffer[0], 1, dstIndex); // 原子计数获取写入位置 visibleIndexBuffer[dstIndex] splatIndex; // 存储可见Splat的原始索引 } }这里用到了InterlockedAdd原子操作虽然有一定开销但对于百万级数据在GPU上并行执行仍然比在CPU上做快几个数量级。更高级的优化可以使用GPU上的并行前缀和Prefix Sum算法来生成紧凑列表效率更高。深度排序Gaussian Splatting需要从后往前渲染才能正确混合。我们得到可见Splat索引列表后需要根据每个Splat到相机的深度进行排序。在GPU上做全排序如快速排序并不高效。我们采用一种近似但非常适合GPU的方法计算每个可见Splat的深度值相机空间Z。使用基数排序Radix Sort。基数排序是稳定的、数据并行的排序算法非常适合在Compute Shader中实现。我们可以利用HLSL的Wave操作或直接实现一个高效的GPU基数排序内核。排序的输出是一个新的、按深度从大到小排列的索引列表。4.3 间接绘制Indirect Draw这是连接Compute Shader和渲染管线的桥梁。我们不再直接调用DrawProcedural而是使用Graphics.DrawProceduralIndirect。创建间接参数缓冲区这是一个ComputeBuffer类型为DrawIndirectArgs包含实例数量等参数。在Compute Shader中填充参数在剔除和排序完成后最后一个Compute Shader内核将可见Splat的数量写入DrawIndirectArgs缓冲区的相应位置。发起绘制在C#端每帧只需调用一次Graphics.DrawProceduralIndirect(material, bounds, MeshTopology.Points, argsBuffer, 0, null, null, UnityEngine.Rendering.ShadowCastingMode.Off, false);MeshTopology.Points我们告诉Unity我们将绘制点。实际上在顶点着色器中我们会将每个点扩展为一个四边形。argsBuffer包含了本次绘制需要绘制多少个“点”即经过剔除和排序后的Splat数量。这样CPU的职责就变成了每帧分发几个Compute Shader剔除、排序、准备参数然后发起一次间接绘制调用。CPU开销变得极低且恒定。4.4 顶点着色器与片元着色器优化现在渲染由GPU间接参数触发。我们的顶点着色器将接收可见Splat的索引列表。顶点着色器输入不再是Splat属性而是SV_VertexID它代表当前是第几个可见Splat。通过SV_VertexID从排序后的索引列表中获取原始Splat索引。用原始索引从SplatPositionBuffer和SplatAttributeBuffer中读取数据。进行解码从uint中解出颜色、不透明度、旋转四元数、缩放。核心计算根据相机参数、Splat的位置、旋转、缩放计算该Splat在屏幕空间对应的四边形4个顶点的位置。这里可以利用实例化技巧一个Splat索引生成4个顶点通过SV_InstanceID区分0,1,2,3分别对应四边形的四个角。将计算好的顶点位置、Splat索引、颜色等传递给片元着色器。片元着色器接收来自顶点着色器的Splat颜色、不透明度。关键操作深度测试与混合。由于我们是按深度从后往前渲染的所以可以使用Blend SrcAlpha OneMinusSrcAlpha进行标准的Alpha混合。深度写入ZWrite必须关闭。因为多个Splat需要在同一像素深度上混合。我们依赖的是排序顺序而不是深度缓冲来保证正确性。一个重要的优化是提前深度测试Early-Z。虽然我们关闭了深度写入但可以开启深度测试ZTest Less或LEqual。如果片元被更近的、不透明的物体可能是场景中的传统网格物体遮挡它会被提前剔除避免执行昂贵的片元着色器计算。这需要与场景中其他渲染器妥善管理深度缓冲区。实操心得在实现GPU排序时不要一开始就追求完美的全局排序。可以先尝试按Tile屏幕分块排序或者使用近似排序如根据深度值放入不同的桶。对于610万Splats一个完整的基数排序可能需要多轮Dispatch有开销。实测中发现对于许多场景不排序或粗略排序带来的视觉错误混合顺序错误在高速运动或高复杂度场景中并不明显但性能提升显著。这是一个需要根据项目需求权衡的“黑科技”。5. 高级优化技巧LOD与动态简化即使经过了GPU剔除当相机靠近一个复杂区域时仍然可能有数十万甚至百万个Splats是可见的。这时我们可以引入细节层次LOD和动态简化。5.1 屏幕空间误差度量LOD的核心思想是根据Splat在屏幕上的投影大小决定其渲染的细节程度。如果一个Splat在屏幕上只覆盖1个像素那么用高精度的球谐系数渲染它和用简单的颜色渲染它视觉上几乎没有区别。我们为每个Splat预计算一个“重要性”或“误差”值。一个简单有效的度量是屏幕空间大小 (世界空间半径 / 到相机的距离) * 屏幕常数。屏幕空间大小小于某个阈值如0.5像素的Splat可以被简化或剔除。5.2 分层数据结构与简化构建层次结构在预处理阶段使用八叉树Octree或KD树对Splats进行空间划分。树结构的每个节点存储该区域内Splats的包围盒和聚合信息如平均颜色、总不透明度。运行时动态选择在渲染时从根节点开始遍历空间加速结构。对于每个节点计算其包围盒在屏幕上的投影大小。如果投影大小小于阈值则不再遍历其子节点而是渲染该节点的代理Splat。这个代理Splat可以使用节点的聚合属性例如平均颜色和合并后的不透明度来渲染用一个或少数几个Splat来代表该区域内成百上千个原始Splat。如果投影大小大于阈值则继续遍历其子节点。GPU驱动LOD上述遍历过程也可以实现在Compute Shader中输出最终需要渲染的Splat列表可能是原始Splat也可能是代理Splat。这进一步将计算负担转移到了GPU。通过LOD在远景和快速移动时实际参与渲染的Splat数量可以下降1-2个数量级从而极大地提升帧率。对于我们的610万场景在远景视角下通过LOD可能只需要渲染几十万个代理Splat帧率提升立竿见影。6. 性能数据对比与问题排查经过上述一系列优化后我们来对比一下关键数据。测试环境RTX 4070 Ti GPU Intel i7-13700K CPU 1080p分辨率。优化阶段平均FPSGPU耗时 (ms)CPU耗时 (ms)显存占用 (MB)关键改动初始状态910535~1500原始.ply数据简单Shader循环渲染数据压缩后156832~350应用第3节数据编码减少带宽占用GPU剔除与间接绘制62151~360实现第4节核心管线CPU开销骤降引入LOD后1476.81~380应用第5节LOD远景Splat数量大幅减少6.1 常见问题与排查技巧即使按照指南操作你可能还是会遇到问题。这里记录一些我踩过的坑画面闪烁或Splat缺失可能原因GPU剔除或排序算法有竞态条件Race Condition。例如在生成可见索引列表时原子操作的顺序问题。排查在Compute Shader中使用GroupMemoryBarrierWithGroupSync()确保线程组内的同步。或者使用更稳定的并行前缀和算法代替原子操作生成列表。工具使用Unity Frame Debugger或RenderDoc查看每一帧实际提交的Draw Call和顶点数量是否稳定。渲染顺序错误导致透明混合异常可能原因GPU排序不彻底或不稳定。基数排序的某一位排序不稳定或者深度计算有精度问题。排查可以暂时在片元着色器中输出深度值作为颜色观察梯度是否平滑、正确。简化场景用少量Splat测试排序逻辑。备选方案如果GPU排序开销太大可以退回使用每Tile排序。将屏幕划分为多个Tile如32x32像素只保证每个Tile内的Splat按深度排序Tile之间不排序。这在很多情况下视觉上可接受。移动端性能极差可能原因移动GPU的ALU算术逻辑单元强大但带宽有限且对分支和复杂Shader支持不如桌面GPU。优化进一步压缩数据考虑使用ASTC或ETC2格式的纹理来存储Splat颜色属性而不是Buffer。简化Shader移除所有分支语句使用lerp或step函数替代。避免在片元着色器中进行复杂的数学运算如sin,pow。降低精度在移动端大量使用half或fixed精度代替float。分帧处理如果一帧内完成所有剔除、排序、渲染压力太大可以考虑将剔除和排序分摊到多帧中进行渲染总是使用上一帧准备好的数据会引入一帧延迟但对静态或慢速移动的场景影响不大。与URP/HDRP管线集成问题现象自定义的DrawProceduralIndirect渲染的物体不参与后处理、不受光照、不投射阴影。解决在URP中你需要编写一个自定义的ScriptableRenderPass。在这个Pass中设置好渲染目标可能是相机颜色目标绑定你的Compute Buffer和Material然后调用CommandBuffer.DrawProceduralIndirect。这样你的Splat渲染才能被正确地嵌入到URP的渲染流程中参与后续的后处理。光照和阴影则需要更复杂的方案可能需要将Splats转换为某种形式的体积数据或延迟渲染路径这属于进阶课题。这次从6.1M Splats到147FPS的优化之旅本质上是一场针对GPU计算特性的深度适配。它让我重新审视了在Unity中进行高性能渲染的思维方式减少CPU干预信任并压榨GPU精心设计数据布局敢于在算法层面做取舍。最终得到的不仅是一个高性能的Gaussian Splatting渲染器更是一套应对海量数据实时渲染的方法论。如果你在实现过程中遇到了上面没提到的问题欢迎在评论区交流很可能那也是我曾经熬夜调试过的坎。