Jacobi 和 Gauss–Seidel 的物理求解差异#

球球非穿透约束可以写成 Cij = |pi - pj| - (ri + rj) >= 0

当 Cij < 0 时，说明两个球发生穿透：

1
penetration = ri + rj - |pi - pj|

并且需要根据质量倒数 wi、wj 分配位置修正：

1
Δpi =  normal * penetration * wi / (wi + wj)
2
Δpj = -normal * penetration * wj / (wi + wj)

1
float3 pi = sPosRad[tid].xyz;
2

3
for (int j = 0; j < n; j++)
4
{
5
    float3 pj = sPosRad[j].xyz;
6
    // 计算当前粒子相对 j 的修正
7
    delta += correction;
8
}
9

10
sBallDelta[tid] = delta / cnt;

1
粒子0读取旧位置，计算 Δp0
2
粒子1读取旧位置，计算 Δp1
3
粒子2读取旧位置，计算 Δp2
4
...
5

6
所有线程计算完毕后GroupMemoryBarrierWithGroupSync();
7

8
所有粒子同时应用各自 Δp

1
for (int i = 0; i < n; i++)
2
{
3
    for (int j = i + 1; j < n; j++)
4
    {
5
        float3 pi = sPosRad[i].xyz;
6
        float3 pj = sPosRad[j].xyz;
7

8
        ...
9

10
        sPosRad[i].xyz = pi + corr * (wi / wsum);
11
        sPosRad[j].xyz = pj - corr * (wj / wsum);
12
    }
13
}

1
解 A-B，立即更新 A、B
2
解 A-C，读取更新后的 A
3
解 B-C，读取更新后的 B、C

sInvMass[] 很可能是“完全不碰撞”的核心修复#

旧代码把速度和质量倒数打包在一起：

1
groupshared float4 sVelInvMass[16];
2
// xyz = velocity
3
// w   = inverse mass

但它多次只写 .xyz：

1
sVelInvMass[tid].xyz = vel;

然后球碰撞又从 .w 读取质量：

1
float wi = sVelInvMass[tid].w;
2
float wj = sVelInvMass[j].w;
3

4
float wsum = wi + wj;
5
if (wsum < 1e-8)
6
    continue;

按标准 HLSL 语义，写 .xyz 应当保留 .w。但是跨平台时，这会被 Unity 从 HLSL 转译成 GLSL ES，再由 Mali 驱动编译。如果某个编译器阶段把 shared float4 的分量写转成不正确的整向量覆盖，.w 就可能变成 0 或未定义值。

而 w 一旦被破坏：

1
wi = 0
2
wj = 0
3
wsum = 0
4
→ continue
5
→ 所有球球 pair 都不做位置修正

这与“其他模拟正常，但球球完全无法碰撞”的表现高度吻合。

现在的代码在加载阶段立即拆开：

1
float4 velInvMass = _VelInvMass[gIdx];
2
sVelInvMass[tid] = velInvMass;
3
sInvMass[tid] = velInvMass.w;

后续所有速度更新都整向量写：

1
sVelInvMass[tid] = float4(vel, sInvMass[tid]);

球碰撞只从独立标量数组读取质量：

1
float wi = sInvMass[i];
2
float wj = sInvMass[j];

最终写回也显式恢复 w：

1
_VelInvMass[gIdx] = float4(sVelInvMass[tid].xyz, sInvMass[tid]);

这样就消除了“分量写误伤质量数据”的可能性。

串行 GS 为什么进一步规避 Mali shared-memory 问题#

旧 Jacobi 每个活动线程都会：

• 动态读取 sPosRad[j]。
• 动态读取 sVelInvMass[j].w。
• 写入自己的 sBallDelta[tid]。
• Barrier 后再写自己的 sPosRad[tid].xyz。

即 15 个线程同时执行带动态索引的 shared-memory 访问。

新版本中，球碰撞期间只有线程 0 工作：

1
if (tid == 0)
2
{
3
    for (int i = 0; i < n; i++)
4
    {
5
        for (int j = i + 1; j < n; j++)
6
        {
7
            ...
8
        }
9
    }
10
}

此时从线程 0 的角度看，球碰撞阶段的 shared-memory 访问等价于普通串行数组操作：

1
读取 pair
2
计算
3
写回 pair
4
读取下一个 pair

同一个 shader invocation 对自己此前写入的值拥有明确的程序顺序，不再依赖多个 invocation 之间复杂的 shared-memory 可见性。

这带来三层稳定性：

• 不再有多个线程同时动态访问球碰撞数组。
• 不需要 sBallDelta[] 这个跨线程临时数组。
• pair 修正由同一线程读取和写回，不需要原子操作或跨线程归并。

Khronos 规范明确说明：同一个 invocation 对自己写入的数据具有确定顺序；不确定性主要发生在不同 invocation 对 shared memory 的交叉读写上。Khronos GLSL ES 规范