GAMES202 PCSS软阴影算法细节解析

创始人

2024-05-24 08:15:19

0次

在LearnOpenGL框架的基础上实现了一遍GAMES202的PCF+PCSS软阴影，之前学习GAMES202时一些没弄清楚的问题顺便搞清楚了。
注：本文中代码和shader均在笔者自学LearnOpenGL的框架中实现，因此有一些细节可能和GAMES202作业框架不一致，且对202框架中的一些错误进行了修正。

PCSS算法

在这里插入图片描述

PCSS的核心就是根据遮挡物(Blocker)的平均深度去估算当前着色点的半影大小。而半影大小就对应着PCF的过滤半径。上图中计算半影大小的公式通过简单的相似三角形即可推导出，很简单，不做过多解释。需要注意的是这儿的深度值dxx，都是和shadow map中记录的深度值是同一个坐标系，正常来说都是Screen Space Z，即NDC [-1,1]的z线性变换到[0,1]。强调这个是因为在Find Blocks时其实使用的是eye space的Z，而202框架中把这两个不同坐标系的Z混用了，其实是错误的。
为了计算遮挡物的平均深度，需要在shadow map上的一个范围内去进行测试和计算平均深度值。而如何确定这个范围是PCSS的另一个核心点。当然也可以使用一个固定范围，而202中使用了相似三角形的方法，如下图：

这儿需要理解一下，Shadow Map是在光源的视锥的Near plane上。上图中没有画出光源的视锥，如果是平行投影，就是这个面光源向下（因为根据这个图的位置关系，可知光源方向是向下的），范围为光源的尺寸；如果是透视投影，则从面光源的中心点出发向下。

计算细节分析

Find Blocker中计算 searchRadius

float searchRadius = LIGHT_SIZE_UV * (zReceiverEyeSpace - NEAR_PLANE) / zReceiverEyeSpace;

这是我修正过的代码，202框架中，使用的zReceiver其实是screen space的（尽管他的注释里面写了z当做是eye space的，但这个z还要和shadow map中的z比较，所以只能是screen space），因此我独立出了一个eye space的z用于计算，eye sapce z的计算可参考代码。
首先，理解这个算法，要看一下LIGHT_SIZE_UV 和 NEAR_PLANE的含义。
在我的代码中进行如下定义：

#define LIGHT_WORLD_SIZE 0.05
#define LIGHT_FRUSTUM_WIDTH 6.0
#define LIGHT_SIZE_UV (LIGHT_WORLD_SIZE / LIGHT_FRUSTUM_WIDTH)
#define NEAR_PLANE 1.0

LIGHT_WORLD_SIZE 是世界坐标系下面光源的大小，如果单位是米，这儿面光源大小为5厘米，显然面光源越大，半影范围越大，阴影越软。（注：这儿只讨论宽度，可认为光源和视口都是方的）
LIGHT_FRUSTUM_WIDTH 是光源视锥的宽度，这个宽度也是在世界空间度量的。因此这两个值相除得到的其实是光源在视锥截面上的比例（平行投影等于是在近裁面上，透视投影也可映射到近裁面，只要使用近裁面的尺寸作为LIGHT_FRUSTUM_WIDTH ），这个比值的范围为[0,1]，而Shadow Map同样是可以认为在视锥的近裁面上。因此LIGHT_SIZE_UV可认为是在shadow map uv坐标系下的一个长度。
而NEAR_PLANE 就是近裁面的位置，即光源位置到近裁面的距离。
回到上面searchRadius的计算，我在图上标注几个长度：
在这里插入图片描述

绿色的箭头线长度就是NearPlane的距离
蓝色的箭头线长度就是zReceiverEyeSpace，即eye space下着色点在光源视锥中的深度值。
红色的箭头线的长度就是光源的尺寸（宽度），映射到uv空间就是LIGHT_SIZE_UV
而黄色箭头线的长度就是我们要计算的serachRadius。
那么根据相似三角形，很容易计算得到：
黄线长/红线长 = （蓝线长-绿线长）/ 蓝线长
也就是：

float searchRadius = LIGHT_SIZE_UV * (zReceiverEyeSpace - NEAR_PLANE) / zReceiverEyeSpace;

可以看到，这儿必须使用光源空间eye space的zReceiver，否则计算单位不统一，计算结果失去物理意义。
由于这是一个比例关系，因此计算得到的searchRadius 的范围和LIGHT_SIZE_UV 一样是[0,1]。即在shadow map这张贴图上的一个归一化的范围。使用这个值进行采样距离的调节如下：

vec2 sample_coords = uv + poissonDisk[i] * searchRadius;

因此这儿不需要知道shadow map的尺寸，以及计算texel的尺寸了，因为直接计算的radius是一个归一化的范围，或者说缩放值。
另外上面几个常量值，除光源尺寸外，都要和代码中设置的光源空间的相关参数匹配，这儿偷懒都直接写了，可以看一下c++代码中如何设置的，可以看到是匹配的：

	glm::mat4 lightProjection, lightView;glm::mat4 lightSpaceMatrix;float near_plane = 1.0f, far_plane = 7.5f, view_half_size = 3.0f;lightProjection = glm::ortho(-view_half_size, view_half_size, -view_half_size, view_half_size, near_plane, far_plane);lightView = glm::lookAt(lightPos, glm::vec3(0.0f), glm::vec3(0.0, 1.0, 0.0));lightSpaceMatrix = lightProjection * lightView;

PCF filterSize的计算

这个filterSize就根据图1的公式即可计算，注意要使用screen sapace下的zReceiver和avgBlockerDepth:

	// STEP 2: penumbra sizefloat penumberaRatiio = (zReceiver - avgBlockerDepth) / avgBlockerDepth;float filterSize = penumberaRatiio * LIGHT_SIZE_UV * NEAR_PLANE / zReceiverEyeSpace;

但是202框架代码和讲义不一样的是，对算出来的半影尺寸，又使用 NEAR_PLANE / zReceiverEyeSpace 这个系数进行了缩放。同样这儿要使用eye space的着色点在光源空间的深度，否则坐标系不一致失去物理意义。由于着色点的eye space深度肯定是大于等于Near Plane的，因此这个比值是小于1的，乘上这个比值会让filterSize变小，减少软的程度。这么做也是有意义的，因为物体离近裁面越近，半影越大，反之半影越小。

关于PCF_Filter

这里的PCF Filter计算，使用了泊松分布的圆盘进行随机抽取采样点，这样避免使用固定位置的采样点造成规则的条带。当然由于引入了随机数，会有噪声，需要降噪。202框架中，对于采样点使用了两次，第二次是在斜对角的方向(-yx）,这相当于双倍采样点数量，但是由于减少了一些随机性会在噪声方面表现好些（我猜的）。而业界中，我发现Unity等引擎并不使用随机采样，而是使用固定的过滤，可能是为了避免噪音。另外Unity中会使用基于硬件的2x2采样&比较，这样一次采样相当于4个textel。且Unity的软阴影并不是PCSS,就是PCF，即只是边缘软化的阴影，没有PCSS那种越远越软的感觉。