- 渲染路径
- 渲染方式
- FORWARD
- 流程
- Unity中规则
- DEFERRED
- 流程
- 几何处理Pass
- 光照Pass
- 透明物体
- 不同渲染路径的特性
- 异同
- 优劣
- 前向渲染
- 优点
- 缺点
- 延迟渲染
- 优点
- 缺点
- 其他
- Unity中渲染路径设置
- TBDR
- 更多渲染路径
- 延迟光照Deferred Lighting
- 分块正向渲染Forward+
- 群组渲染Clustered Rendering
- 不同Pass下光源shader的编写
- PreZ
- 补充
Render Path:决定光照的实现方式,即决定光照的计算流程。渲染方式
FORWARD
DEFERRED
目前看起来前向渲染明显比延迟渲染暗,为什么呢?
先来看看两者的渲染方式。
片元化之后在片元着色器里面逐片元逐光照计算。
比如有m个片元,n个光源,那就是m个片元里算n次光照,复杂度O(mn)。
很直观的渲染思路,也比较简单粗暴。
问题在哪呢?如果在某个片元里,场景里有一个光源和它隔了十万八千里,那明显这个光源对它的影响是微乎其微的。但这所做的计算量和算一个离它很近的光源所做的计算量是一样的。
那如果场景中的光源翻一倍,计算量就成了原来的两倍,那就不兴打太多光源了。
Unity里分了像素光照、顶点光照、球面调谐光照。质量递减,当然计算量也递减。
像素光照数:在设置面板里可以调
顶点光照数:最多4个
球面调谐光照数:总光照数-像素光照数-顶点光照数
一定是像素光照的:最亮的光、Light-Render Mode里勾了Important的光
Base Pass:一盏像素光、所有顶点光和球面调谐光,计算阴影
Additional Pass:剩下的像素光人手一个
这就是为什么上面的前向渲染看起来这么暗了,一些被Unity认为不这么重要的光变成了球面调谐光照,提供的亮度比较敷衍。
事实上如果将每个光照都变成像素光,前向和延迟得到的结果基本是一样的。
将场景中待渲染目标的各种几何信息存到G-Buffer里
由于深度测试,所以屏幕上所有的片元都是离摄像机最近的
把G-Buffer里的信息拿出来按光照模型算
直接用保存在图片中的各种信息算…怎么说呢,有点像2D后处理。但屏幕本身就是2D的不是吗?
复杂度O(m+n)
那G-Buffer里有啥呢?比如Position、Normal(WS)、Color…
一种典型G-Buffer
按 视图模式—缓冲显示—总览 看UE G-Buffer
透明物体不会前面遮住后面(后面的像素仍是需要保留的),所以透明物体的渲染是在所有不透明按照延迟渲染的方式渲染完之后,再按照前向渲染的方式加上去。
不同渲染路径的特性 异同后处理方式不同(前向渲染要拿深度图要单独抓,延迟直接从G-Buffer拿)
着色方式不同(延迟只能算一种光照模型)
抗锯齿不同(延迟无法硬件抗锯齿)
支持半透明
支持多Pass
支持自定义光照计算方式
复杂度O(mn)
拿深度图要额外拿
大量光照时效果好速度快,复杂度O(m+n)
只渲染屏幕可见像素
后处理支持好,深度图直接拿
用更少的shader,也方便统一美术风格
要存G-Buffer,占用大量带宽(每一帧要几个rt在显存中传输、清理等)
透明物体
只能用同一个光照Pass
MSAA支持差(DX9以前的MRT不支持,10.1开始支持,但需要多倍大小的G-Buffer(本来带宽就是问题了))
https://catlikecoding.com/unity/tutorials/rendering/part-13/
如果光照比较简单(比如就给一两盏平行光之类的)没必要开延迟管线,因为光照计算不会太复杂,直接用前向算性能也不会太差。
如果场景中存在大量不透明物体,那就算开了延迟管线也会回到前向做大量的透明渲染。
目前手游上对延迟渲染管线的使用并不算普遍,比较典型的有原,大量辅助光达成更好的美术效果。
项目设置
相机设置
一种是分块降低带宽内存用量
还有一种方法也叫TBDR,名同意不同。
在移动端TBR的架构上多加一次Defer,通过HSR减少Overdraw
过几章在详细补。
减少G-buffer占用的过多开销,着色计算时开始forward,支持多种光照模型
分块正向渲染Forward+用分块、索引的方式,减少带宽,支持多光源,强制需要一个preZ
群组渲染Clustered Rendering带宽相对减少,多光源下效率提升
分前向、延迟两种
https://zhuanlan.zhihu.com/p/54694743
用一个Pass算深度
大规模草、透明排序等都会用到
early-z失效(如面数过高)或者需要深度图时一种手动替代方案。
Unity urp不支持deferred
UE默认deferred
一般用于主机平台多一点



