我在使用WebGL中的cubeTextures预先烘焙nVidia的PCSS工作了2个月。 我成功地实现了野兽。 Prebaking它最终也有效，但有一些明显的文物。
简而言之，我突出了我的主要神器，我解释了为什么我得到它，在一般情况下，每个人都应该遇到，如果他试图预先烘烤软阴影。 总结这个主题，围绕这个问题的每一条建议都可以帮助我：
我们如何处理预烘焙的软阴影瑕疵？
让我们通过谈论软阴影而不是关注PCSS来简化这种情况。这意味着我们正在使用包含每个纹素的可见性值范围从0到1 的shadowMap（而硬阴影生成只有2个可能值的shadowMaps：0或1）。
由于我们不是实时的，我们必须修复一个观点，而不是在每一帧使用相机视点。我的柔和阴影是从光的角度计算出来的。为了构建它们，我：
这给了我一个可以实时采样的预先计算的shadowMap。
预烘烤软阴影的第一个限制是阻挡器不能成为接收器的一部分。想象一个充满遮挡物的房间，然后唯一的接收器肯定是房间。否则，你会在房间网格上丢失一些阴影。 原因是我们陷入了光明的视野，所以如果我们把它作为接收器，我们也看不到拦截器背后的东西。
这种限制导致阴影地图具有良好的可见度值，但显然不是阻挡者阴影的好处。 我不介意在阻挡者身上获得正确的能见度值，我希望能够使用房间的阴影作为阻挡者阴影的近似值。但实际上，you'll get hard shadows on blockers因为在阻挡者背后，房间阴影的能见度值完全是黑色。
Here is a graphic to illustrate why this is happening.
在最好的情况下，我只把房间作为接收器。在底部的情况下，我也使用阻塞作为接收器。您可以轻松地看到两种情况都出现问题。 因为对于shadowMap的相同纹理元素，我们需要两个不同的可见性值：房间上的点是全黑的，而阻挡点上的点是半影。
我有很多想法来处理这个神器：
我失败了1＆amp; 2。 想法3似乎与想法2相同。 4是愚蠢的，它不再是预先计算。 而且我担心我无法创造出5个通用的想法。
关于这个主题的文档很少。我发现的大多数文档都使用了理想的场景，没有阻挡器遮挡另一个阻塞，就好像它不是一般的情况。 那么也许这里有人已经遇到过这个问题或者对这个问题感兴趣？希望它能帮助其他人跟在我后面。
但是，感谢您考虑这个问题。
