前面几篇阴影相关的:
https://www.cnblogs.com/crazii/p/5443534.html 这个是在做bh3 MMD角色自阴影时的笔记
https://www.cnblogs.com/crazii/p/7227269.html 这个是blade的CSM笔记和相关思考
这次在项目里对unity又做了新的改进, 整体思路还是沿用第二篇的方式:
1.使用足够长/远的视锥（view/projection）剔除场景 （渲染shadow map总是要剔除的，所以先用足够远的视锥，保证所有可见阴影的shadow caster都在）
2.根据剔除后的包围盒，代替场景包围盒，做凸包体相交
3.重新计算并设置渲染用的view/projection也就是说(shadow) scene culling和rendering用的view/projection是不一样的，后者基于前者的culling结果重新计算。
记录几个要点:
1. shadowmap剔除以后的结果, 可以是一组世界空间的caster(的包围盒), 变换到光空间, 再合并; 也可以是他们合并后的结果, 再变换到光空间. 建议使用前者, 因为合并后包围盒已经变大, 再做空间变换,会导致包围盒(AABB)变更大. blade为了偷懒使用了后者, 最近在unity的项目里里使用了前者.
2.一般CSM的cascade判断,可以简单的用场景相机的视距分割. unity使用的是球体. 最好的方式是用光视锥(Light Frustum OBB, xy without z), 几个cascade的光视锥方向一样. 比如4个cascade: shader里需要光空间UP,光空间RIGHT, 然后4个viewpoint和4个视锥的width, height. 按球体/距离划分很容分到质量更低的cascade, 但是前一级很可能有深度可以采样. 极端的例子: 光接近平行地面的时候, 影子被拉很长, 相机近处的物体投影很远, 如果按光视锥OBB, 近处物体的影子就只会采样cascade0, 不会采样更低的cascade. 另外, receiver的范围可以忽略, 只考虑caster的范围, 否则为了显示拉长的阴影, 使用更大的阴影范围, 阴影质量也会下降.
另外OBB检测会多出4个dot指令和一组比较指令, 对于收益来说时可以接受的
比如下图里shadow range只有10, sm利用率几乎沾满整个cascade 0. 实际投影距离却很长,30多米, 质量也没有降低:
3.基于第2点, OBB是完全契合shadowmap视锥的, 所以只要在OBB内的receiver,一定可以在对应的cascade采样到阴影, 所以如果一个物体的阴影完全渲染在cascade0里时, 就可以不用再画到cascade1里. 这个优化可以根据caster的个数来决定要不要做, 比如一个只有10个caster物体的手游, 可以考虑迭代检测. 可能出现的结果是: cascade0里有2个object, cascade1里只有1个object, 又因为紧凑包围盒, 所以cascade1的质量比cascade0还要高.
4.一直在说的重新计算紧凑包围盒, 不仅在blade里做了实现和验证, 在mmd视频渲染里得到了验证, 也在实际项目里也得到了验证, 特别是有CSM时, cascade0(视点近处几米内)的质量会有明显提升, sm利用率变高, 阴影会占据大部分区域.
下面时图示 (光视锥的视角):
5. 在考虑使用light space的投影体的bounding volume, 用stencil标记receiver的范围(类似shadow volume的标记方式), 圈出来的部分才做阴影采样, 这样对于soft shadow和pcss可以有优化. 但是依赖于early stencil, 也要看游戏场景是否适用. 目前6s测试, 1.2ms=>0.6ms, 节省了0.6ms, 用unity tent7x7 softshadow, 4=>1.5ms 省了2.5ms, 60%左右, 目测和阴影站整个地面的比例有关, 符合优化的原理. 根据理论来推测, 对于地面阴影占据绝大多数的情况, 优化不明显.