# brief
- 和tile based deferred shading的区别:要求更强的hardware支持,用compute shader来算light list。两者原理上挺相似
- 对tile细分cell然后根据light的mask和tile的mask来进一步剔除light.最终渲染还是用tile
- indirect light:还挺有意思的。专门用来生成virtual point light,用这个标记成只生成indirect lighting的light生成RSM,然后在RSM上用很多light来搞出indirect bounce的效果
- 即使是在tile对light做raycast来做阴影,还是让人觉得疯狂。。。
# 18.2 Forward+
- Pre-Z:不过我行不通为啥文章里说pre-z在forward+里更必要,按说你光照计算不是比forward更优化了吗。。。
- light culling: 算出light list effecting each pixel
- final shading: access light的方式变了,应该是要间接索引所有的light中需要的light
- 说了半天per pixel light list,结果还是去用per tile light list
- 提到了UAV,说是什么剩下的限制就是GPU的算力
- 提到了因为可能用到很多light和很多material resource,所以pre-z重要
# 18.3 Implementation and Optimization
- 用dx11的direct compute做了light culling,light culling过程有点像deferred,看tile的frustum是否和light相交
- 如何存lightlist
- 可以用linked list(需要atomic operation)
- 这里的做法
- 先把一个group算的那个tile的light index写到thread group的memory中
- 然后结束阶段还是要写到global memory中
- 先用原子变量来allocate space
- 然后copy到非配的内存中
# 18.4 Results
- 这里是对比了deferred lighting和forward+
- prepass: deferred lighting虽然不用把完整GBuffer搞上了,但是normal和specular power少不了
- light processing: forward+是要用compute shader算light list,deferred shading是算入射光累加.这一步还是deferred lighting慢
- shading: 这个肯定是forward+要慢很多,因为要iterate light list并且做lighting和shading。不过有个优势就是灵活
# 18.5 Forward+ in AMD Leo Demo
- 实际这个scene中只有150个light,50个by hand,其他的是用来造出间接光的效果
- 标记成indirect light的灯光、会生成RSM,然后会自动根据RSM来生成点光源、做出1 bounce的效果
# 18.6 Extensions
- 2.5D culling
- 只是把view frustum划分成若干子frstum的话,一个frustum如果深度很大就会和很多light相交,虽然最终还是一个tile一个light list(非一个cell一个light list),但是可以做些优化进一步过滤掉和tile相交但是其实完全没用到的light。所以考虑在纵深上也做划分(比如32 cells,这样一个32bits integer就够了)
- 需要遍历prez时的深度,遍历tile里的每个pixel,知道这个pixel在那个depth上,标记,这样就知道每个tile到底有哪几段depth mask被用到了
- light processing阶段,如果light和tile的bound相交,就生成light的depth mask,light和tile的mask一相交就知道light是否真的影响到一些tile了
- Shadowing from Many Lights
- 疯了,要用ray cast的方式来判断对于每个tile,某个light是否可见
- raycast的重点:acceleration structure,在这里不讨论。。。。
- 结果就是不再是forward shading,需要一个G pass,因为还需要normal
- 要把raycast从pixel shading里移出来,搞成每个tile算
- 和tile based deferred shading的区别:要求更强的hardware支持,用compute shader来算light list。两者原理上挺相似
- 对tile细分cell然后根据light的mask和tile的mask来进一步剔除light.最终渲染还是用tile
- indirect light:还挺有意思的。专门用来生成virtual point light,用这个标记成只生成indirect lighting的light生成RSM,然后在RSM上用很多light来搞出indirect bounce的效果
- 即使是在tile对light做raycast来做阴影,还是让人觉得疯狂。。。
# 18.2 Forward+
- Pre-Z:不过我行不通为啥文章里说pre-z在forward+里更必要,按说你光照计算不是比forward更优化了吗。。。
- light culling: 算出light list effecting each pixel
- final shading: access light的方式变了,应该是要间接索引所有的light中需要的light
- 说了半天per pixel light list,结果还是去用per tile light list
- 提到了UAV,说是什么剩下的限制就是GPU的算力
- 提到了因为可能用到很多light和很多material resource,所以pre-z重要
# 18.3 Implementation and Optimization
- 用dx11的direct compute做了light culling,light culling过程有点像deferred,看tile的frustum是否和light相交
- 如何存lightlist
- 可以用linked list(需要atomic operation)
- 这里的做法
- 先把一个group算的那个tile的light index写到thread group的memory中
- 然后结束阶段还是要写到global memory中
- 先用原子变量来allocate space
- 然后copy到非配的内存中
# 18.4 Results
- 这里是对比了deferred lighting和forward+
- prepass: deferred lighting虽然不用把完整GBuffer搞上了,但是normal和specular power少不了
- light processing: forward+是要用compute shader算light list,deferred shading是算入射光累加.这一步还是deferred lighting慢
- shading: 这个肯定是forward+要慢很多,因为要iterate light list并且做lighting和shading。不过有个优势就是灵活
# 18.5 Forward+ in AMD Leo Demo
- 实际这个scene中只有150个light,50个by hand,其他的是用来造出间接光的效果
- 标记成indirect light的灯光、会生成RSM,然后会自动根据RSM来生成点光源、做出1 bounce的效果
# 18.6 Extensions
- 2.5D culling
- 只是把view frustum划分成若干子frstum的话,一个frustum如果深度很大就会和很多light相交,虽然最终还是一个tile一个light list(非一个cell一个light list),但是可以做些优化进一步过滤掉和tile相交但是其实完全没用到的light。所以考虑在纵深上也做划分(比如32 cells,这样一个32bits integer就够了)
- 需要遍历prez时的深度,遍历tile里的每个pixel,知道这个pixel在那个depth上,标记,这样就知道每个tile到底有哪几段depth mask被用到了
- light processing阶段,如果light和tile的bound相交,就生成light的depth mask,light和tile的mask一相交就知道light是否真的影响到一些tile了
- Shadowing from Many Lights
- 疯了,要用ray cast的方式来判断对于每个tile,某个light是否可见
- raycast的重点:acceleration structure,在这里不讨论。。。。
- 结果就是不再是forward shading,需要一个G pass,因为还需要normal
- 要把raycast从pixel shading里移出来,搞成每个tile算