回复：分享一下个人的开源，技术细节可能会在本帖更新

有人顶又让我开心了起来，明天会更一下体积光的原理

在说到体积光时，我们需要首先复习一下shadowmap计算阴影的方法。Shadowmap的方法大致如下：在forward下利用像素的坐标，在deferred下利用屏幕像素深度，使用viewprojection的逆矩阵求出坐标对应的世界坐标，shadowmap本身相当于在灯光上安装了一个摄像机，渲染了周围的一圈深度，我们使用像素坐标与灯光的距离与shadowmap深度进行比较，最后得到当前像素是否被物体遮挡，投影。
知道了shadowmap的基本原理，体积光就很容易了，实时体积光的计算基于raymarch，近似于屏幕空间的后处理操作。基本思想就是，从摄像机到像素方向发射一条射线，在射线上取样数次，然后获得每个取样点的遮挡信息，最后加起来就是体积光的效果，由于多次迭代的性能消耗极高，我们一般采用降采样的方法降低性能消耗。

显然，directonal light是可以使用这种整个屏幕后处理的方法进行处理的，效果非常不错，然鹅，Spot light或是point light就不能这么简单粗暴了，否则会造成计算的高度复杂以及性能消耗的爆炸，这时候我们应该使用commandBuffer来单独渲染灯光的轮廓，并且进行上述的处理，为什么要用commandBuffer而不是直接用queue=3000的shader呢，原因很简单，出于性能角度考虑，我们希望使用一个降采样过的renderTexture来进行计算，然后再使用高斯模糊让体积光变得朦胧，这样既可以大幅度降低raymarch的性能消耗，也可以让画面更加柔和，避免出现许多游戏中体积光的犀利的效果，毕竟丁达尔效应是依赖于散射的，如果光线因为高度采样非常清晰，反而违背了我们的初衷，费力不讨好。

楼主你好，我想请教一下，透视眼镜的设计思路，比如我带上眼镜，镜片后的人物部分衣服会透明化

最近刚刚开了一个新的开源坑，关注我的应该也看到了，Unity Async Loader，目的是实现一套模仿UE4的大地图加载的系统，现在主要难点在于实时GI (天空环境光遮蔽，lighting probe)， Unity首先是不支持直接光的realtime GI的，这点非常讨厌,但是也可以理解，毕竟场景碎片化也无法要求引擎将索引全部链接好，目前没发现什么好办法，只能暂时战略性放弃，天空盒子的实时GI有一定缺陷，这个会在导入模型的时候需要额外注意，尽可能不让相邻太近的物体挨到一起，lighting Probe的支持倒是不错。
总的来讲，Unity实现大地图控制，可行性还是相当高的，GI方面的缺陷其实问题不大，像PUBG这样的游戏甚至都没有GI，即使GTA5看起来也是只有环境光的GI与静态的光照贴图强度变化，这些后边可以用一些脚本控制shader来实现。
开原地址：https://github.com/MaxwellGengYF/Unity-Async-Loader
对自己的图形开发能力有信心的朋友，欢迎加QQ群：146025605 参与大地图动态加载的研发

还有集中回应一下一些朋友的问题：你对新的SRP怎么看。现在的SRP主要是基于CommandBuffer的，这里的commandBuffer和DX11中的commandBuffer还是有些区别的，dx11中的cb是默认的，自动的drawcall设计，在dx11中在不同线程使用draw指令，并不会导致任何的堵塞和线程不安全，drawcall是完全异步的，而且由于原子队列的存在也是完全线程安全的，然而unity中的CommandBuffer就大不一样了，属于一个非常上层的封装，然而CommandBuffer并不允许多线程调用，所以其实所有的控制几乎都是在主线程完成的，即使强行做多线程优化，那么结局也会是多线程->单线程队列cb->引擎底层多线程->图形api迭代drawcall，途中的数据传输消耗会很大，还是希望官方能拿出可行的方案让srp的效率高起来，api简单起来，最好可以一条龙服务，直接给出RenderTarget接口(Single Render Target或Multiple Render Target)，然后Stencil等也可以尽可能简单，否则开发者一定会花更多时间编写会产生GC的脚本，导致效率低下。