Skip to content

Archive

Tag: Deferred
上一篇提到了在视口间共享shadow map的优化,以及对代码的重构。重构中的一个小发现造就了在不增加存储占用的情况下,就能支持透明物体的渲染。 透明物体和Deep G-Buffer 在透明的烦恼一文中,为了用纯Deferred的框架解决透明物体渲染的问题,KlayGE引入了Deep G-Buffer的方法。对不透明物体、透明物体的背面、透明物体的正面分为三个G-Buffer layer,分别有一条Deferred流水线,最终通过alpha把三层blend成最终结果。这种方法虽然能简单有效地解决问题,并避免繁琐的forward流水线,但需要三倍的存储和带宽。而且如果depth peeling的层数增加,开销还会进一步加大。最近出现的几种OIT方法,都不兼容于deferred。所以如果不用forward,就得 ...
上一篇讲到了把GI系统从Deferred Rendering框架中分离出来,以降低耦合度。本篇会涉及到一个共享shadow map、提高性能的改进。 多视口的改进 多视口的特性是KlayGE 4.2引入的。Deferred rendering layer支持通过多个视口生成多个渲染结果,可以用于分屏、反射、缩略图等情景。原先每个视口都是完全独立渲染的,互相不共享任何东西。实际上spot light和point light的shadow map是view independent的,不会因为视点不同而改变,就应该在视口间共享。 于是开发团队成员李渊完成了这个任务,把shadow map的生成提前到所有视口的G-Buffer之前。也就是说,原先的流水线是: for each view port: generate g-buffer. for each shado ...
从KlayGE 4.0确定了Deferred Rendering的框架以来,每个版本都有一些小改进。在正在开发的4.3里,多个改进经过这几个版本的融会贯通,产生了一些新的变化。这里做个系列总结一下。 GI和Deferred的分离 最早提到这个问题的是团队成员陈顺斌。他在去年就提出Deferred rendering layer太过复杂,应该把相对独立的GI拆出去。当时我的想法是,Deferred和MRSIL GI(Multiresolution splatting for indirect lighting)在逻辑上关联甚大,应该是一体的。后来实现了SSGI,也放在Deferred框架内,复杂度进一步增加。Deferred也成了个带有多种GI方法的怪物,各个组件之间的耦合度很高。 在分析了MRSIL、SSGI以及未来可能支持的SVO等多种GI方法之后 ...
去年4月,Forward+刚出来的时候,我写过一篇介绍的文章。很遗憾的是,原来的paper只比较了Forward+和传统Deferred,甚至是个没怎么好好优化的Deferred。对于Tiled Deferred(TD)的比较,一直都没见到详细的。今年GDC上,终于看到了一个对Forward+和Tiled Deferred的全面性能对比,包括不同光源数,不同render target(RT)个数和是否MSAA。 别的不说,直接看结论阶段。 算法分析 首先是对Forward+和Tiled Deferred的算法分析,列出可能影响性能的地方。     RT数量对比 G-Buffer包含了多少个render target,也就是用多少带宽,对性能应系那个很大。第一轮是关闭MSAA,三角形数量较多(1.25M个),Forward+和RT数 ...
现代3D游戏经常会需要用到decal,子弹孔、脚印……传统的decal渲染从Quake 2时代开始就没怎么变过,通过画一个紧贴着物体的四边形来实现。问题一直很多,比如光照的不一致,z-fighting造成的闪烁,渲染状态的来回切换,等等。那么到了deferred框架中,这种情况会有所好转吗? 有趣的是,deferred框架内实现decal不但非常容易:100行之内的代码量,不到20分钟就能完成,而且非常稳定,完全没有上述各种缺点。更有趣的是,deferred的decal被至少三组不同的人都提出过完全相同的算法,都在讨论会出现的相同问题,只是被分别叫成了不同的名字。现在看看这三组: Crytek的Jan Krassnigg在2010年于Game Engine Gems 1里的一篇文章A Deferred D ...
AMD在7900系列显卡发布的时候同时推出了Leo demo,并说明它不是用近年流行的Deferred框架渲染完成,而是用到了一种叫Forward+的框架。这个框架不需要Deferred的大带宽要求,却仍能实时渲染上千光源。EG2012上有篇新paper叫做Forward+: Bringing Deferred Lighting to the Next Level,讲述的就是这个方法。但目前作者还没有放出该论文的全文,这里我只能通过只言片语和AMD的文档来解析这个神奇的Forward+。 Tiled-based Deferred Shading 在进入正题之前,我们先回顾一下Intel在SIGGRAPH Courses 2010里提到的Tiled-based Deferred Shading。它的算法框架是: 生成G-Buffer,这一步和传统deferred shading一样。 把G-Buffer划分成许 ...
上一篇分析了KlayGE中实现实时全动态GI的方法,本篇是这个系列的完结篇,主要讲流水线的最后一段:Post process。 Post process 在KlayGE 4.0的Deferred Rendering中,post process主要有HDR、AA和color grading。下面将分别讲述它们的改进。 HDR 在KlayGE 3.12用了filmic tonemapping之后,HDR部分就几乎没有别的改变。这里唯一的变化是最终输出的float4,把亮度存在A通道上。这是为了后面FXAA的需要。 AA 在Deferred框架中,无法使用硬件AA曾经是个恼人的问题。随着这些年各种基于post process的AA方法大量出现,Deferred下AA的问题基本被解决了。 团队成员陈顺斌和郭鹏曾为KlayGE 3.12提供了FXAA。在新版本中,FXAA也升级到了最 ...
上一篇解决了透明物体的渲染问题;本文将挑战另一个实时渲染的神话,实时全局光照(GI)。 实时全动态GI 目前direct lighting在游戏中日趋成熟,比较前卫的游戏引擎已经不满足于diect lighting的效果了,逐渐开始尝试indirect lighting。早期的方法有通过离线渲染light map来实现静态场景、静态光源的GI。接着出现了PRT,可以处理静态场景、动态光源。CE3用了Light Propagation Volumes的方法,不需要预计算,可以产生动态场景、动态光源的diffuse GI。不过其速度和质量确实不敢恭维。难道就不能有全动态场景、全动态光源、diffuse和specular通吃的实时GI方法吗?有!Multiresolution splatting for indirect illumination(MRSII)前来救 ...
上文讲到了如何把信息挤入有限的G-Buffer,另一个在实际中面临的问题是如何渲染透明物体。 透明物体 游戏中透明物体是不可缺少的,对于Deferred Rendering来说,透明物体一直是痛苦的。常见的做法是在deferred rendering的场景之上用forward shading来单独渲染透明物体,但那样就意味着必须单独实现一整套forward shading的流水线。这对于维护和扩展都是很不利的,对性能也很有影响。 在KlayGE 4.0里,我用的方法被称为Deep G-Buffer。其基本过程是,把第一篇所描述的Deferred Rendering流水线复制三份,不透明的物体、透明物体的背面、透明物体的正面分别有自己独立的G-Buffer、lighting pass、shading pass和special shading pass。最 ...
上一篇讲了在KlayGE 4.0中,Deferred Rendering的流水线改进。本篇继续讲G-Buffer的变化。 G-Buffer布局 前面提到了G-Buffer改成了MRT,那么现在就来比较一下新老G-Buffer的区别。老G-Buffer的安排如下: 老G-Buffer是4个通道、每个通道都是fp16的RGBA16F格式。其中normal用Spheremap Transform的方式映射到2个通道;depth单独存一个通道;specular和shininess挤在一个通道内,整数部分为specular * 100,小数部分为shininess / 256.0f。 这样的G-Buffer需要占据64-bit,IO开销不小,而且depth精度有限。如果按照新的MRT G-Buffer扩展到2个RT,就需要再增加一个32-bit的RT。对于不支持Independent MRT的D3D9硬件来说,甚至要增加 ...