移动平台实时动态多点光源方案：Cluster Light

Jaihk662

已于 2024-03-29 18:49:38 修改

阅读量1.1k

点赞数 20

分类专栏： # Unity3D 文章标签： Unity3D

于 2024-03-29 18:46:14 首次发布

本文链接：https://blog.csdn.net/Jaihk662/article/details/137153400

版权

Unity3D 专栏收录该内容

66 篇文章 62 订阅

订阅专栏

一、什么是 Cluster Light，它具体如何实现多点光源效果？

对于移动设备，如何支持场景中大量的实时点光源一直以来都是比较棘手的问题，因此对于过去，往往有如下两种常规方案：

静态点光源直接烘焙，光源本身依靠自发光 + Bloom 出效果
动态点光源标记最重要的 1~4 盏，shader 中只计算这些标记为 Important 的点光源的贡献

但如果场景中有大量的点光源，又或者说点光源的数量、位置无法预知，那么前两种方案就会完全不可行，除此之外对于方案②，场景中不同位置的点光源也很难分辨出哪个是 “Important” 的，毕竟这个标签若要跟着场景走，你很难说哪个光源重要或者不重要

因此，基于空间划分后分块计算光照的思路就应运而生，其可以在保证效果的同时减少 PixelShader 的计算量，大体思路也很简单，看一张图就多多少少有所理解

此图来源：GDC2015：Thomas Gareth Advancements in Tile-Based

有兴趣可以翻看当年的 PPT，这里直接上重点，一个简单的多点光源 ClusterLight 思路如下：

ViewSpace，即摄像机可见区域，分块（GPU ComputeShader）
计算每个块（Cluster）会受到哪些点光源影响
在着色时，根据像素获取对应的 Cluster，并拿到光照列表
正常计算点光源着色

1.1 简单 ClusterLight 实现

可参考链接：这些都是知乎上个人实现的 ClusterLight Demo，除此之外，URP12 之后的版本也支持 PC 下的 ClusterLight，大部分情况，ClusterLight 方案都不包含阴影，关于阴影的问题后面也会提到

Unity SRP学习笔记（二）：Cluster Based Light Culling
Unity SRP 实战（四）Cluster Based Lighting
实时动态多光源渲染-Cluster Forward Shading
Cluster Based Deferred Lighting-MaxwellGeng

1.1.1 第一步：按照 ViewSpace 切割 Cluster

摄像机的可见区域，即摄像机的视锥体，按照 X, Y, Z 等距切割成多个 Cluster，这里没有复杂的数学公式，加上其没有前后依赖计算，因此可以并行，交给 ComputeShader 非常的合适

X, Y 轴的切割没啥好说的，直接等距切割就 OK，传统的 Frustum Light 方式 Z 方向不切割，Frustum 截锥体如下图，如果继续按 Z 轴切割就是本文的 Cluster 了：

图片来源自：https://www.3dgep.com/forward-plus/

考虑到离摄像机越远的位置，相同距离的 $\Delta Z$ 对于屏幕 pixel 的贡献就可能越小，因此 Z 轴可以按照距离指数分割，即离摄像机越远，Z 方向上 Cluster 分的块就越大，反之越小，不过这个对于 Deferred Lighting，或是在屏幕空间进行的光照计算优化明显，目前测试下来 Forward 物体着色时计算光照优化不明显，因此依然可以仅等距划分 Z

1.1.2 第二步：收集光照信息，再次计算每个 Cluster 包含哪些光源

到此 GPU 需要获取两个 StructuredBuffer：一个是 ClusterBox 对应的 List：每个 Cluster 数据包含八个 Vector3，对应锥体的每个顶点

另一个则是场景中所有点光源列表：

protected struct PointLight
{
    public Vector4 color;
    public Vector4 position;
};

其中 Color 的第四维为光源强度，position 第四维存储光源半径

一样可以并行计算：对于每个 Cluster 做一个几何判断，即当前 Cluster 与球体是否相交，计算方案有很多，这里提供两个正确的经典思路：

一是求出 Cluster 对应的 AABB 方形包围盒，之后判断这个包围盒是否与球体相交：这个方案相对后者计算量没那么大，缺点就是可能会有浪费，可能 Cluster 不会受到某个光源影响，但仍然会统计这个光源

bool TestSphereVsAABB(float4 s, AABB aabb)
{
    float3 center = (aabb.max1.xyz + aabb.min1.xyz) * 0.5f;
    float3 extents = (aabb.max1.xyz - aabb.min1.xyz) * 0.5f;
    
    float3 vDelta = max(0, abs(center - s.xyz) - extents);
    float fDistSq = dot(vDelta, vDelta);
    return fDistSq <= s.w * s.w;
}

二是对于 Cluster 的每个面判断面交，6个面计算六次，优点就是精准，但是要额外考虑光源球体完全在 Cluster 内部的情况，因此还要计算下空间相对位置，比较麻烦

同样，这一部分也交给 GPU Compute 计算，最后可以得到一张光源分配查找表，即每个 Cluster，对应一个 LightList，即该 Cluster 会接收到的点光源的列表，不过考虑到每个列表的大小必然不会一样，GPU 没法申请动态大小的 List，因此为了避免空间浪费，可以多加一个 LightIndexList 用于存储光源索引，此时光源查找表可以只记录每个 Cluster 对应的 LightIndexList 的起点和数量，最后通过 LightIndexList 查询对应连续的一段内存来获取 LightList 的实际索引：

[numthreads(32, 32, 1)]
void LightAssign(uint3 tid : SV_GroupThreadID, uint3 id : SV_GroupID)
{
    // cluster ID 
    uint i = tid.x, j = tid.y, k = id.x;
    uint3 clusterId_3D = uint3(i, j, k);
    uint clusterId_1D = Index3DTo1D(clusterId_3D);

    ClusterBox box = _clusterBuffer[clusterId_1D];
    uint startIndex = clusterId_1D * _maxNumLightsPerCluster;
    uint endIndex = startIndex;

    for(int lid = 0; lid < _numLights; lid++)
    {
        PointLight pl = _lightBuffer[lid];
        if(!ClusterLightIntersect(box, pl))
            continue;
        _lightAssignBuffer[endIndex++] = uint(lid);
    }

    LightIndex idx;
    idx.count = endIndex - startIndex;
    idx.start = startIndex;
    _assignTable[clusterId_1D] = idx;
}

需要注意的是，这个数据量还是不小的，假设 ViewSpace X, Y, Z 分别按照 32, 32, 64 的大小切割，限制每个 Cluster 最多受到 8 盏点光源影响，这样就需要至少 32 * 32 * 64 * 8 = 524288 的 lightAssignID 大小

后续会介绍这一部分怎么优化，或者是否有其它的存储方式

1.1.3 第三步：光照计算

这一部分就比较简单了，着色时判断当前 pixel 在哪个 cluster 中，获取其光照索引表，拿到其光照之后就是标准的遍历点光源计算光照，出于性能考虑的话可以直接用最简单的兰伯特光照模型

#if defined(VIEW_CLUSTER_LIGHT)
    float2 scrPos = i.scrPos.xy / i.scrPos.w;
    float depth = LinearEyeDepth(i.pos.z, _ZBufferParams);
    float A = LinearEyeDepth(0, _ZBufferParams);
    float B = LinearEyeDepth(1, _ZBufferParams);
    // 计算 Cluster Based Lighting
    uint x = floor(scrPos.x * _numClusterX);
    uint y = floor(scrPos.y * _numClusterY);
    #if UNITY_REVERSED_Z
        uint z = (_numClusterZ - 1) - floor(((depth - B) / A) * _numClusterZ);
    #else
        uint z = floor(((depth - A) / B) * _numClusterZ);
    #endif
#endif

不过考虑到 DirectX 和 GL 的平台差异，还要处理一下 Reserve-Z 问题，在计算 Cluster 的 Z 索引时，对于 Reversed-Z 的平台要把 Z 部分的计算反过来那分割数量减去它，这和你 ComputeShader 中的计算逻辑也有一定关系，在 ComputerShader 中考虑好 Reserve-Z 应该也是可行的

光照计算部分代码就不贴了，可以根据实际情况选择使用任意光照模型

还需要注意的是，点光源的阴影计算并不包含其中，依旧需要额外处理阴影的问题，并且对于 foward 管线这部分没有高性能的方案，一个简单地思路就是对于每个点光源求出其 CubeShadowmap，对于多个点光源可以得到一个 TexCubeArray，着色时通过 index 读取采样 shadowmap

1.2 世界空间 ClusterLight 分割

前面介绍的就是经典的 ViewSpace 分割方案，但是，技术一定是要依赖需求去动态调整的，生搬硬套没有意义，考虑到大多数手机游戏，点光源往往都是静态烘焙的做法，根本没有必要上动态的多光源

而需要动态点光源的，可能是一些特殊的场景，又或者是点光源位置不能确定的场景，例如家园，玩家可以任意摆放建筑和摆饰，而部分摆饰会有光源，又或者说是空间小室内场景。对于这些需求的特点就是：我们没有必要将点光源和大世界绑定在一起，对于如上情况而言，可以布置或者说会出现动态点光源的空间是有限的，此时按照世界空间分 Cluster 就成了一种可行的选择，并且相对于 ViewSpace 的分块，后者无需在摄像机改变视角时实时更新，性能也会更好

既然是世界空间的分割，那么分割范围大小就要有严格限制：可以通过放置 Box 来确定其光源生效范围，后续只对这个 Box 内的空间进行分割及光照计算

而后续计算 Cluster 对应光照数据的流程，和前者 View-Space 的计算流程没有差异，甚至可以共用一个 ComputeShader，最后在着色时，也无须考虑平台差异

#if defined(VIEW_CLUSTER_LIGHT)
    …… ViewSpace Cluster
#else
    float3 dir = maxBound - minBound;
    float X = (worldPos.x - minBound.x) / dir.x;
    float Y = (worldPos.y - minBound.y) / dir.y;
    float Z = (worldPos.z - minBound.z) / dir.z;
    uint x = floor(X * _numClusterX);
    uint z = floor(Y * _numClusterZ);
    uint y = floor(Z * _numClusterY);
#endif

二、移动平台性能优化及兼容

很可惜，如果是无脑上 ClusterLight 的话，无论是自己的方案，或者是 URP UE 自带的方案，在大部分中配机型上都很难跑的动，甚至是不兼容，抛开阴影不谈，经过测试原因主要如下：

部分手机理论应该支持 ComputeShader，但是仍旧会出现进游戏闪退等问题
对于①深度了解主要又分两种情况：手机驱动尽管是 OpenGL3.1 以上版本，但仍不支持
支持 ComputeShader，但是不支持 StructuredBuffer（SSBO）
可以进入游戏，但是有很明显的掉帧，主要原因出在 StructuredBuffer pixelShader 访问上

2.1 StructuredBuffer pixelShader 优化

StructuredBuffer 测试报告.md

对于 ClusterLight 的数据，往往都通过 StructuredBuffer 存储，这样是非常常见的操作：

RWStructuredBuffer<ClusterBox> _clusterBuffer;
RWStructuredBuffer<PointLight> _lightBuffer;
RWTexture3D<float4> _assignTable;

但是在 pixelShader 中，读取 StructuredBuffer 对于部分手机而言会出现非常离谱的帧数下降：

以 Mi6（骁龙835为例），正常使用 StructuredBuffer 未优化的性能如下：

整体稳定在 30FPS，但是运行一段时间后手机会降频（735MHz - 515MHz），此时无法稳定 30FPS

之前存储灯光是使用 StructuredBuffer 的，一般情况下场景中的灯光都会有最大数量限制，如果最大数量限制 128 个，那么实际操作上就可以使用一个长度为 64 的 Matrix[] 来存储至多 128 盏光源信息

Matrix[64] 必然可以定义在 ConstantBuffer 中而非 StructuredBuffer，前者读写性能远好于后者

float4x4 _lightBuffer[64];
float4x4 lit = _lightBuffer[lightId / 2]; // 根据 id 查灯光表
float4 litPosition = lit[(lightId % 2) * 2 + 1];
float4 litColor = lit[(lightId % 2) * 2];

在仅做了这步优化后，实机测试性能就有了肉眼可见的提升：

可以看到，原先 30FPS 提升到了 50FPS，这也证明了这个优化路线是正确的

关于 StructuredBuffer 在移动设备上出现严重性能下降的原因推测：

当前设备并不能很好的支持在 pixel 中访问 StructuredBuffer 或者本质上不支持 StructuredBuffer，因此在使用 StructuredBuffer 时，为了避免更坏情况（直接闪退 or 不执行），对应的逻辑会退化，从而在读写上出现了不可预料的时间消耗

2.1.1 使用 Texture3D

除此之外，每个 ClusterBox 存储光源信息，也可不使用 StructuredBuffer 而是用 Texture3D 替代，其 Texture3D 的每个 pixel 正好和切割后的每个 Cluster 一一对应

private int numClusterX = 32;
private int numClusterY = 32;                          
private int numClusterZ = 32;
public JClusterCPUGenerate(int Z, BoxCollider collider)
{
    numClusterZ = Z;
    worldBox = collider.bounds;
    assignTable = new Texture3D(numClusterX, numClusterY, numClusterZ, TextureFormat.RGBAFloat, true);
    Color[] colors = new Color[numClusterX * numClusterY * numClusterZ];
    for (int i = 0; i < colors.Length; i++)
    {
        colors[i] = Color.black;
    }
    assignTable.SetPixels(colors);
}

Texture3D 只能支持4通道，也就是最大 ARGBFloat，这就意味着没有特殊操作的话每个 Cluster 只能存储最多4盏灯，这样的话还是需要像前面 1.1.2 的操作一样，这里只存储两个 Int 数据，对应 lightBuffer 的起始 Index 和灯光数量，在着色计算时最终从 LightBuffer 里获取灯光，这样就没有灯光数量限制了

此时 Texture3D 也可以使用 RGInt 格式足够，使用 Texture3D 而非 StructuredBuffer 性能可以得到进一步提升：

可以看到，目前设备已经能够稳定 60FPS，尽管运行一段时间后手机仍会降频

2.2.2 灯光数据位存储

前面提到过：Texture3D 只能支持4通道，也就是最大 ARGBFloat，这就意味着没有特殊操作的话每个 Cluster 只能存储最多4盏灯，但是真的只能存储4盏灯嘛？考虑到场景中的灯光数量必然有一个上限，以128的上限为例，其灯光 Index 必然是在 0~127 的范围内，此时对于 RGBAFloat 或 RGBAInt 格式，一个通道就可以存储4盏灯光

例如一个 Cluster 受到第2，4，16，36这四盏灯光影响，那么其第一个通道的数据存储值就为：

00000001 00000010 00001000 00100100 = 526337

在实际获取数据时，再通过位运算就可以解算其灯光索引，考虑到位运算效率很高，因此不会带来太大的性能问题，除此之外，一张 Texture3D 单通道也可以存储至多16盏灯光

如果设置了16盏灯光为单个 pixel 可接受的点光源数量上限，那么就无需在申请 LightBuffer 或 lightIndex 这样的额外的 StructuredBuffer 了

[numthreads(32, 32, 1)]
void LightAssign(uint3 tid : SV_GroupThreadID, uint3 id : SV_GroupID)
{
    // cluster ID 
    uint i = tid.x, j = tid.y, k = id.x;
    uint3 clusterId_3D = uint3(i, j, k);
    uint clusterId_1D = Index3DTo1D(clusterId_3D);

    ClusterBox box = _clusterBuffer[clusterId_1D];
    uint startIndex = 0, endIndex = 0;
    int lightAssignID[16] = {0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0};
    for(int lid = 0; lid < _numLights && endIndex < 16; lid++)
    {
        PointLight pl = _lightBuffer[lid];
        if(!ClusterLightIntersect(box, pl))
            continue;
        lightAssignID[endIndex++] = int(lid) + 1;
    }

    int A = (lightAssignID[0] << 16) + lightAssignID[1];
    int B = (lightAssignID[2] << 16) + lightAssignID[3];
    int C = (lightAssignID[4] << 16) + lightAssignID[5];
    int D = (lightAssignID[6] << 16) + lightAssignID[7];
    _assignTable[clusterId_3D] = float4(A, B, C, D);
}

以上代码为16位存储，即每个 int 存储两盏灯光，此时最多支持的单个 pixel 灯光上限为8盏，事实上，手机上也不太好布置太密的点光源，一个 pixel 接受8盏光源已足矣，否则计算量其实也优化不下来

到此就成功完全弃用了 StructuredBuffer，以避免其读写慢带来的致命性能损耗：

稳定 60FPS 的同时，测试机在一段时间内也没有降频现象

2.2 CPU 实现 ClusterLight

ComputeShader 手机兼容性报告

很可惜，并非所有手机都能很好的支持 ComputeShader，在引用中所有测试的 Android 手机中，OpenGL ES 3.1以上的手机均使用的是 Shader Model 4.5 或 Shader Model 5.0，在使用 unity 提供的 API：SystemInfo.supportsComputeShaders 在上述手机显示为 true，但通过运行一段 ComputeShader 程序，在 Shader Model4.5 上运行结果却不符合预期

因此，如果想要不兼容 CS 的手机也能实现 ClusterLight 动态点光源，就需要考虑备选方案，也就是使用 CPU 计算原先 CS 计算的部分

不过如果这部分任务交给 CPU，CPU 要不考虑使用 JobSystem 来并行计算，要不就考虑分帧，不然如此大的计算量，尽管 WorldSpace 的 ClusterLight 仅需一次计算，但仍然会出现卡帧问题

下面给出一个分帧的实现：分帧分什么？当然是光源 —— 即每帧只处理一盏光源

思路也很简单，对于每个当前 Add 的光源，以其光源为中心开启 BFS，搜索所有受到该光源影响到的 Cluster，此时复杂度为线性：

private void BFSCluster(PointLight light, bool isAdd)
{
    int clusterNum = numClusterY * numClusterZ;

    Queue<Cluster> queue = new Queue<Cluster>();
    uint[] flag = new uint[clusterNum];

    Vector3 pos = new Vector3(light.position.x, light.position.y, light.position.z);
    Cluster lightCluster = Locate(light, pos);
    queue.Enqueue(lightCluster);
    flag[lightCluster.y * numClusterY + lightCluster.z] |= (uint)1 << lightCluster.x;

    Vector3 perCusterlen = new Vector3((worldBox.max.x - worldBox.min.x) / numClusterX, (worldBox.max.y - worldBox.min.y) / numClusterZ,
            (worldBox.max.z - worldBox.min.z) / numClusterY);
    while (queue.Count != 0)
    {
        Cluster s = queue.Dequeue();
        ChangeLightState(s, light, isAdd);
        int[,] dirS = { { 1, 0, 0 }, { -1, 0, 0 }, { 0, 1, 0 }, { 0, -1, 0 }, { 0, 0, 1 }, { 0, 0, -1 } };
        for (int i = 0; i < 6; i++)
        {
            Cluster n = s;
            n.x += dirS[i, 0];
            n.y += dirS[i, 1];
            n.z += dirS[i, 2];
            if (n.x >= numClusterX || n.y >= numClusterZ || n.z >= numClusterY || n.x < 0 || n.y < 0 || n.z < 0)
                continue;
            if ((flag[n.y * numClusterY + n.z] & (uint)1 << n.x) != 0)
                continue;

            if (n.deep++ > 0)
            {
                if (!CheckLightDir(n, lightCluster, perCusterlen, light.position.w))
                    continue;
            }
            queue.Enqueue(n);
            flag[n.y * numClusterY + n.z] |= (uint)1 << n.x;
        }
    }
}

2.2.1 基于 BFS 的光源 Add 方案

关于 BFS（代码中为队列实现的广度优先搜索），默认看到这里的人都是了解的，因此不会介绍这部分算法，重点提一下搜索时的标记数组 Flag[]，因为该 BFS 为避免重复搜索采用的是记忆化搜索的思路

Flag[] 的大小理论上应该和 Cluster 的数量一致，但是如果每帧都申请并清空这样大小的 Flag[]，必然也会浪费资源，因为 Cluster 的数量可能会过万，因此这部分需要做点处理：

清空标记处理：如果是分帧操作，则没必要每帧都重新 new 一个数组，也没必要像 memset 一样重置 flag[] 的值，可以直接给 flag[] 填上当前的灯光 ID 作为标记
此方案和①不兼容，不过可以省掉大量的 flag[] 空间，一样是利用位运算，申请 flag 时只需要申请 X Y 两轴的大小，Z 存储到对应的位中，不过此方案也要求 Z 不能超过位数（uint=32），上面的代码样例采用的就是这个方案