Forum Replies Created
-
Posts
-
不好意思我可能有点没说清楚…我的意思是修改PCSS中step2 penumbra size的计算，而所有关于shadow map中深度的比较都是用的[0,1]范围的深度这个没错。
这个是我原来的代码float filterSize = (coords.z / avgBlockerDepth - 1.0) * LIGHT_WIDTH_UV; float ret = PCF(shadowMap, coords, filterSize);其中coord.z和avgBlockerDepth都是[0,1]的值。
这个是我更新后的代码float vsReceiverDepth = linearizeDepth(coords.z); float vsBlockerDepth = linearizeDepth(avgBlockerDepth); float filterSize = (vsReceiverDepth / vsBlockerDepth - 1.0) * LIGHT_WIDTH_UV; float ret = PCF(shadowMap, coords, filterSize);简单来说就是把这里normalized的depth转换到linear depth再求解filterSize。我非常同意你说的有可能改一点就会让结果差很多，比如你可以加一个scalar来进行调参，不过这样并不能保证是physically correct的。我的理解是求解filterSize的本质是相似三角形，不过当所有距离都进行来非线性变换（从linear depth变成[0,1]）之后相似三角形的比例关系并不能保证一定满足，所以这里利用linear depth求解是比较合理的。实践上来看我自己的测试也得到了更好的效果，同时我也参考了一些别人的实现，包括Nvidia的实现（http://developer.download.nvidia.com/whitepapers/2008/PCSS_Integration.pdf），感觉大多都是使用linear depth来计算的。
这些就是我大致的理解和推测，如果有问题的话欢迎继续讨论：）linear depth计算：https://learnopengl.com/Advanced-OpenGL/Depth-testing
我猜可能是光源宽度过大（建议尝试调至0.1甚至0.01的数量级）以及findBlocker函数中filterSize的计算方式不对，这里不应该去sample shadow map，而是应该用near plane的值。可以先用固定的blocker search region（e.g. 16×16 texel）看一下结果对不对排除一些其他错误的可能。希望有帮助：）
我觉得渲染顺序就是在WebGLRenderer.js的render()函数里确定的，先渲染shadow pass然后渲染camera pass。GPU上commands的执行顺序是由submit的顺序决定的，所以如果CPU先submit shadow pass的draw call再submit camera pass的draw call，那么GPU也会先shadow再camera，而不是同时进行。OpenGL也有一些强制同步的命令比如glFinish()和glFlush(),不过在这种情况下并不需要。不知道我有没有理解对你的问题…
stackoverflow上类似问题的解答：https://stackoverflow.com/questions/20696150/execution-sequence-for-opengl-commands
还有一些opengl wiki上关于synchronization的参考资料：https://www.khronos.org/opengl/wiki/Synchronization我认为理论上说是会的，不过自遮挡的问题在离散化深度值的时候就已经产生了，双线性插值肯定比point sampler要好，但是改善的很有限。考虑一张分辨率较低的shadow map，可能某个深度连续变化的区域在shadow map上都是同一个值，而此时sample方式并不会改善自遮挡问题。
其实PCF的思想就是用更多邻近的pixel去判断单一pixel的visibility，也可以看作一种区域插值，只不过不是对于shadow map插值的，而是对于比较结果插值的。
