Glsl 预烘焙软阴影的局限性

我在使用WebGL中的cubeTextures预烘焙nVidia的PCS上工作了2个月。 我已经成功地实时实现了beast。预烘焙最终也能起作用，但有一些明显的瑕疵

简单地说，我突出显示了我拥有的主要工件，并解释了为什么我会得到它，在一般情况下，如果每个人都尝试预烘焙软阴影，就会遇到这种情况。 总而言之，围绕这个问题的每一条建议都可以帮助我：

我们如何处理预烘焙的软阴影瑕疵？

让我们通过讨论软阴影来简化情况，而不是关注PCS。这意味着我们正在使用一个阴影贴图，每个纹理的可见性值从0到1不等（而硬阴影生成的阴影贴图只有两个可能的值：0或1）

因为我们不是实时的，所以我们必须固定一个视点，而不是在每一帧使用摄影机视点。我的柔和阴影是从光线的角度计算出来的。为了建造它们，我：

• 使用所有阻挡器（遮光罩）计算基本阴影贴图
• 在第二个过程中，仅包含接收器，我使用阴影贴图计算软阴影，并存储每个像素的可见性

这给了我一个预先计算的阴影图，我可以实时采样

预烘焙软阴影的第一个限制是阻挡器不能成为接收器的一部分。想象一个满是封堵器的房间，那么唯一的接收器肯定就是这个房间。否则，将在房间网格上丢失一些阴影。 原因是我们停留在光的角度，所以如果我们把拦截器也当作接收器，我们就看不到拦截器后面是什么

此限制导致获得房间具有良好可见性值的阴影贴图，但对于遮光罩上的阴影显然不是很好。 我不介意在拦截器上获得正确的可见性值，我希望能够使用房间的阴影作为拦截器上阴影的近似值。但实际上，因为在遮光罩后面，房间阴影的可见性值是完全黑色的

在最上面的情况下，我只把房间当作接收器。在最下面的例子中，我也使用拦截器作为接收器。您可以很容易地看到在这两种情况下都会出现问题。 因为对于阴影贴图的相同纹理，我们需要两个不同的可见性值：房间上的点是完全黑色的，而遮光罩上的点是半影

我有很多想法来处理这个工件：

为每个网格向着色器发送一个meshId，并计算该id，以了解我们是否对阻挡器进行阴影处理

分别对每个阻挡者进行PCSS传球，并在最后混合所有阴影贴图

分别为每个接收器进行PCSS传递（考虑拦截器）

预计算一半计算，并实时计算另一半

从多个视点（而不是灯光视点）预计算阴影贴图

我第一次和第二次都失败了。 想法3似乎与想法2相同。 4是愚蠢的，它不再是预计算了。 我担心我无法将想法5变成通用的

关于这一主题的文献确实很少。我发现大多数的纪录片都是在理想的场景下拍摄的，没有阻挡者遮挡着另一个阻挡者，好像这不是一个常见的情况。 那么，也许这里有人已经面临这个问题，或者对这个主题感兴趣？希望它也能帮助我之后的其他人

不过，谢谢你考虑这个问题