Unity中Gaussian Splatting性能优化：从10FPS到147FPS的实战方案

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来渲染Splats，CPU仍然有大量工作要做。最致命的就是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是渲染的主战场，瓶颈也最为复杂。

1. 顶点/几何着色器过载：一种常见的实现方式是，将每个Splat作为一个顶点，在顶点着色器中计算其对应的屏幕空间四边形（两个三角形）。对于610万个Splats，顶点着色器就要执行610万次。这其中有大量计算是重复或可以简化的，比如视图矩阵的变换、投影计算等。
2. 片元着色器过载与Overdraw：每个Splat在屏幕上覆盖一个区域，这个区域内的每个像素（片元）都可能被多个Splat重叠覆盖。由于渲染顺序（通常按深度从后往前）的需要，一个像素可能被计算几十次甚至上百次（深度复杂度高），这就是恐怖的Overdraw。片元着色器中的混合操作（Blend）和深度测试虽然由硬件处理，但计算量依然巨大。
3. 内存带宽瓶颈：这是最隐蔽也最关键的瓶颈。每个Splat的属性（位置、颜色、旋转、缩放等）需要作为数据传递给Shader。如果这些数据组织不当（例如，没有使用GPU友好的数据布局，或者频繁在CPU和GPU间拷贝），访问这些数据的延迟会成为主要性能杀手。GPU的算力很强，但如果数据喂不饱它，算力就闲置了。

2.3 优化策略总览

针对上述瓶颈，我们的优化路线图是分层、递进的：

1. 数据层面优化：重新组织Splat数据，使其对GPU缓存友好，并减少不必要的数据传输。
2. 渲染管线重构：抛弃传统的GameObject渲染路径，采用基于Compute Shader的完全自定义渲染管线，将排序、剔除等逻辑也搬到GPU上。
3. 算法级优化：实现视锥体剔除（Frustum Culling）、细节层次（LOD）和基于屏幕空间误差的Splat简化，从根本上减少需要处理的Splat数量。
4. Shader微优化：优化着色器代码，减少寄存器压力，利用GPU的SIMD特性，合并计算步骤。

我们的优化目标很明确：将CPU从繁重的数据组织和命令提交中解放出来，使其只负责最轻量的调度；将绝大部分计算，包括剔除、排序、渲染，都压到GPU上，并确保GPU的计算单元和内存带宽被高效利用。

3. 数据预处理与高效存储结构

优化第一步，从源头——数据开始。原始的.ply文件是一种通用格式，并未为实时渲染优化。我们需要将其转换为Unity（或者说GPU）更“爱吃”的格式。

3.1 原始数据解析与问题

一个典型的Splat数据包含：

• x, y, z: 位置（3个float）
• nx, ny, nz: 法线（在Gaussian Splatting中通常不使用，可忽略）
• f_dc_0, f_dc_1, f_dc_2: 球谐函数的0阶系数，代表基础颜色（3个float）
• f_rest_*: 球谐函数高阶系数（通常是45个float，用于表示视角相关的颜色变化）
• opacity: 不透明度（1个float）
• scale_0, scale_1, scale_2: 缩放（3个float），通常经过exp运算得到实际缩放值。
• rot_0, rot_1, rot_2, rot_3: 表示旋转的四元数（4个float），需要被归一化。

直接将这些数据作为一个大的StructuredBuffer传给Shader会有几个问题：

1. 数据不对齐：GPU访问内存时，有特定的对齐要求（例如，128位或256位边界）。混合了不同大小的数据（如float和float3）可能导致低效的内存访问。
2. 缓存不友好：着色器可能只需要访问部分属性（如位置用于剔除），但不得不加载整个结构体，浪费了带宽。
3. 球谐系数庞大：45个高阶系数数据量很大，但在很多情况下，特别是性能优先时，可以牺牲一些视觉效果，仅使用0阶系数（基础颜色）来大幅减少数据量。

3.2 定制GPU数据结构

我们的策略是将数据按用途拆分到不同的Buffer中，并确保每个Buffer内的数据紧密排列（Array of Structures 转为 Structure of Arrays 的变体）。

我们创建了以下ComputeBuffer：

1. SplatPositionBuffer(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);

2. 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: 编码旋转和缩放。将四元数（单位向量）编码成SNORM16（4个16位有符号整数）。缩放（经过log后的scale_0, scale_1, scale_2）也可以量化后打包进剩余的位数，或者单独一个Buffer。这里我们选择将log缩放值（float3）量化为UNORM16，和旋转一起打包进另一个uint。为了简化，我们可以将旋转四元数存储在另一个Buffer<float4>，但为了极致紧凑，编码是值得的。

3. 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字节（45+3+1+3+4个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主要做两件事：

1. 视锥体剔除：利用预计算好的边界球半径（存储在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）算法来生成紧凑列表，效率更高。

2. 深度排序：Gaussian Splatting需要从后往前渲染才能正确混合。我们得到可见Splat索引列表后，需要根据每个Splat到相机的深度进行排序。在GPU上做全排序（如快速排序）并不高效。我们采用一种近似但非常适合GPU的方法：

   • 计算每个可见Splat的深度值（相机空间Z）。
   • 使用基数排序（Radix Sort）。基数排序是稳定的、数据并行的排序算法，非常适合在Compute Shader中实现。我们可以利用HLSL的Wave操作或直接实现一个高效的GPU基数排序内核。
   • 排序的输出是一个新的、按深度从大到小排列的索引列表。

4.3 间接绘制（Indirect Draw）

这是连接Compute Shader和渲染管线的桥梁。我们不再直接调用DrawProcedural，而是使用Graphics.DrawProceduralIndirect。

1. 创建间接参数缓冲区：这是一个ComputeBuffer，类型为DrawIndirectArgs，包含实例数量等参数。
2. 在Compute Shader中填充参数：在剔除和排序完成后，最后一个Compute Shader内核将可见Splat的数量写入DrawIndirectArgs缓冲区的相应位置。
3. 发起绘制：在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的索引列表。

1. 顶点着色器：

   • 输入不再是Splat属性，而是SV_VertexID，它代表当前是第几个可见Splat。
   • 通过SV_VertexID从排序后的索引列表中获取原始Splat索引。
   • 用原始索引从SplatPositionBuffer和SplatAttributeBuffer中读取数据。
   • 进行解码：从uint中解出颜色、不透明度、旋转四元数、缩放。
   • 核心计算：根据相机参数、Splat的位置、旋转、缩放，计算该Splat在屏幕空间对应的四边形（4个顶点）的位置。这里可以利用实例化技巧，一个Splat索引生成4个顶点（通过SV_InstanceID区分0,1,2,3），分别对应四边形的四个角。
   • 将计算好的顶点位置、Splat索引、颜色等传递给片元着色器。

2. 片元着色器：

   • 接收来自顶点着色器的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 分层数据结构与简化

1. 构建层次结构：在预处理阶段，使用八叉树（Octree）或KD树对Splats进行空间划分。树结构的每个节点存储该区域内Splats的包围盒和聚合信息（如平均颜色、总不透明度）。
2. 运行时动态选择：在渲染时，从根节点开始遍历空间加速结构。对于每个节点，计算其包围盒在屏幕上的投影大小。
   • 如果投影大小小于阈值，则不再遍历其子节点，而是渲染该节点的代理Splat。这个代理Splat可以使用节点的聚合属性（例如，平均颜色和合并后的不透明度）来渲染，用一个或少数几个Splat来代表该区域内成百上千个原始Splat。
   • 如果投影大小大于阈值，则继续遍历其子节点。
3. 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分辨率。

6.1 常见问题与排查技巧

即使按照指南操作，你可能还是会遇到问题。这里记录一些我踩过的坑：

1. 画面闪烁或Splat缺失：

   • 可能原因：GPU剔除或排序算法有竞态条件（Race Condition）。例如，在生成可见索引列表时，原子操作的顺序问题。
   • 排查：在Compute Shader中使用GroupMemoryBarrierWithGroupSync()确保线程组内的同步。或者，使用更稳定的并行前缀和算法代替原子操作生成列表。
   • 工具：使用Unity Frame Debugger或RenderDoc，查看每一帧实际提交的Draw Call和顶点数量是否稳定。

2. 渲染顺序错误导致透明混合异常：

   • 可能原因：GPU排序不彻底或不稳定。基数排序的某一位排序不稳定，或者深度计算有精度问题。
   • 排查：可以暂时在片元着色器中输出深度值作为颜色，观察梯度是否平滑、正确。简化场景，用少量Splat测试排序逻辑。
   • 备选方案：如果GPU排序开销太大，可以退回使用每Tile排序。将屏幕划分为多个Tile（如32x32像素），只保证每个Tile内的Splat按深度排序，Tile之间不排序。这在很多情况下视觉上可接受。

3. 移动端性能极差：

   • 可能原因：移动GPU的ALU（算术逻辑单元）强大但带宽有限，且对分支和复杂Shader支持不如桌面GPU。
   • 优化：
     • 进一步压缩数据：考虑使用ASTC或ETC2格式的纹理来存储Splat颜色属性，而不是Buffer。
     • 简化Shader：移除所有分支语句，使用lerp或step函数替代。避免在片元着色器中进行复杂的数学运算（如sin,pow）。
     • 降低精度：在移动端，大量使用half或fixed精度代替float。
     • 分帧处理：如果一帧内完成所有剔除、排序、渲染压力太大，可以考虑将剔除和排序分摊到多帧中进行，渲染总是使用上一帧准备好的数据，会引入一帧延迟，但对静态或慢速移动的场景影响不大。

4. 与URP/HDRP管线集成问题：

   • 现象：自定义的DrawProceduralIndirect渲染的物体不参与后处理、不受光照、不投射阴影。
   • 解决：在URP中，你需要编写一个自定义的ScriptableRenderPass。在这个Pass中，设置好渲染目标（可能是相机颜色目标），绑定你的Compute Buffer和Material，然后调用CommandBuffer.DrawProceduralIndirect。这样你的Splat渲染才能被正确地嵌入到URP的渲染流程中，参与后续的后处理。光照和阴影则需要更复杂的方案，可能需要将Splats转换为某种形式的体积数据或延迟渲染路径，这属于进阶课题。

这次从6.1M Splats到147FPS的优化之旅，本质上是一场针对GPU计算特性的深度适配。它让我重新审视了在Unity中进行高性能渲染的思维方式：减少CPU干预，信任并压榨GPU，精心设计数据布局，敢于在算法层面做取舍。最终得到的不仅是一个高性能的Gaussian Splatting渲染器，更是一套应对海量数据实时渲染的方法论。如果你在实现过程中遇到了上面没提到的问题，欢迎在评论区交流，很可能那也是我曾经熬夜调试过的坎。