延迟渲染 - Revision history

Gongminmin at 08:50, 13 June 2013

2013-06-13T08:50:49Z

Gongminmin at 14:05, 6 May 2012

2012-05-06T14:05:30Z

Gongminmin: /* HDR */

2012-05-01T11:01:51Z

‎HDR

Gongminmin: /* HDR */

2012-05-01T11:01:27Z

‎HDR

Gongminmin: /* 实时全动态GI */

2012-05-01T10:34:22Z

‎实时全动态GI

Gongminmin: /* 实时全动态GI */

2012-05-01T10:23:07Z

‎实时全动态GI

Gongminmin at 10:22, 1 May 2012

2012-05-01T10:22:49Z

Gongminmin: /* 实时全动态GI */

2012-05-01T10:17:26Z

‎实时全动态GI

Gongminmin at 16:01, 30 April 2012

2012-04-30T16:01:40Z

Gongminmin at 09:43, 18 April 2012

2012-04-18T09:43:25Z

@@ Line 374: / Line 374: @@
 * 支持移动平台。精简的Deferred Rendering流水线将会以至到移动平台上。
 * 更多例子用[[延迟渲染]]实现。目前只有3个例子用到了deferred框架，其他还是forward的。以后会有越来越多的例子转到deferred中。
 [[Category:渲染]]
 [[en:Deferred rendering]]

← Older revision		Revision as of 14:05, 6 May 2012
Line 376:		Line 376:

	[[Category:渲染]]		[[Category:渲染]]
		+
		+	[[en:Deferred rendering]]

@@ Line 350: / Line 350: @@
 ==== HDR ====
-在[[KlayGE]] 3.12用了[[filmic tone mapping|色调映射]]之后，HDR部分就几乎没有别的改变。这里唯一的变化是最终输出的float4，把亮度存在A通道上。这是为了后面FXAA的需要。
+在[[KlayGE]] 3.12用了[[色调映射|filmic tone mapping]]之后，HDR部分就几乎没有别的改变。这里唯一的变化是最终输出的float4，把亮度存在A通道上。这是为了后面FXAA的需要。
 ==== AA ====

@@ Line 350: / Line 350: @@
 ==== HDR ====
-在[[KlayGE]] 3.12用了[[filmic tonemapping]]之后，HDR部分就几乎没有别的改变。这里唯一的变化是最终输出的float4，把亮度存在A通道上。这是为了后面FXAA的需要。
+在[[KlayGE]] 3.12用了[[filmic tone mapping|色调映射]]之后，HDR部分就几乎没有别的改变。这里唯一的变化是最终输出的float4，把亮度存在A通道上。这是为了后面FXAA的需要。
 ==== AA ====

@@ Line 342: / Line 342: @@
 === 实时全动态GI ===
-{{main|全局光照}}
+{{主|全局光照}}
 === Post process ===

@@ Line 299: / Line 299: @@
 和Crytek的方法不同的是，我省掉了它所说的y/x变换，所以从normal计算纹理坐标的时候也得去掉vTexCoord.y /= vTexCoord.x一行。
-== 透明物体 ==
+=== 透明物体 ===
 游戏中透明物体是不可缺少的，对于[[延迟渲染]]来说，透明物体一直是痛苦的。常见的做法是在[[延迟渲染]]的场景之上用forward shading来单独渲染透明物体，但那样就意味着必须单独实现一整套forward shading的流水线。这对于维护和扩展都是很不利的，对性能也很有影响。
@@ Line 341: / Line 341: @@
 这一节抛砖引玉地提出了在Deferred框架下渲染透明物体的一个方法，它能简单有效地解决问题。缺点是三倍的内存和带宽消耗。如果depth peeling的层数增加，内存和带宽的消耗还会增加。这里其实也可以借鉴其他order independent transparency的方法，来取代depth peeling分离G-Buffer。
 {{main:全局光照}}
-== Post process ==
+=== Post process ===
 在[[KlayGE]] 4.0的[[延迟渲染]]中，post process主要有HDR、AA和color grading。下面将分别讲述它们的改进。
-=== HDR ===
+==== HDR ====
 在[[KlayGE]] 3.12用了[[filmic tonemapping]]之后，HDR部分就几乎没有别的改变。这里唯一的变化是最终输出的float4，把亮度存在A通道上。这是为了后面FXAA的需要。
-=== AA ===
+==== AA ====
 在Deferred框架中，无法使用硬件AA曾经是个恼人的问题。随着这些年各种基于post process的AA方法大量出现，Deferred下AA的问题基本被解决了。
@@ Line 357: / Line 358: @@
 团队成员陈顺斌和郭鹏曾为KlayGE 3.12提供了[[FXAA]]。在新版本中，FXAA也升级到了最新的3.11版。从FXAA 3开始，就要求输入纹理是LDR的RGBL格式（L为亮度），所以计算AA的地点也就从HDR之前改到了HDR之后。虽然FXAA 3.11可以用G通道代替L，但效果肯定会受影响。既然让HDR post process输出RGBL轻而易举，我就没有把L改成G。FXAA极快，目前的实现在GTX480上可以达到0.1ms的惊人速度。几乎做到了无性能损失的高质量AA。
-=== Color grading ===
+==== Color grading ====
 Color grading是这个版本新增的。以前游戏一般不太重视color grading的作用，但在电影业，color grading是流水线非常重要的一步（可以和skinning相提并论的）。这里我实现的color grading是用16x16x16的3D texture作为查找表，用原RGB作为地址去查询，查询出的结果即为调色后的颜色（来自[http://developer.nvidia.com/node/43 GPU Gems 2: Chapter 24. Using Lookup Tables to Accelerate Color Transformations]）。除了runtime的post process之外，还需要一个离线工具，用来生成那个3D texture。这里我用的方法类似CE3，先生成一个摊平的256×16的2D texture：
@@ Line 365: / Line 366: @@
 在photoshop里打开一张游戏截图，调整RGB曲线至需要的色调，然后把那个RGB曲线应用到之前生成的2D texture，最终打包成3D texture就得到了我们所需要的查找表。以后可能会根据需要做一个在线调整color grading的工具。
-== 总结 ==
+=== 总结 ===
 这一章节把[[KlayGE]] 4.0中[[延迟渲染]]的改进逐一介绍了一下，希望能对也在做类似事情的朋友有所帮助。在总结里我也身边展望一下未来，看看在[[KlayGE]] 4.1中，[[延迟渲染]]部分还会可能出现什么改进。

@@ Line 341: / Line 341: @@
 这一节抛砖引玉地提出了在Deferred框架下渲染透明物体的一个方法，它能简单有效地解决问题。缺点是三倍的内存和带宽消耗。如果depth peeling的层数增加，内存和带宽的消耗还会增加。这里其实也可以借鉴其他order independent transparency的方法，来取代depth peeling分离G-Buffer。
-== 实时全动态GI ==
+{{main:全局光照}}
-−
-目前direct lighting在游戏中日趋成熟，比较前卫的游戏引擎已经不满足于direct lighting的效果了，逐渐开始尝试indirect lighting。早期的方法有通过离线渲染light map来实现静态场景、静态光源的GI。接着出现了PRT，可以处理静态场景、动态光源。CE3用了Light Propagation Volumes的方法，不需要预计算，可以产生动态场景、动态光源的diffuse GI。不过其速度和质量确实不敢恭维。难道就不能有'''全动态场景、全动态光源、diffuse和specular通吃的实时GI'''方法吗？有！Multiresolution splatting for indirect illumination（MRSII）前来救驾。
-−
-在[[KlayGE]] 3.12中，团队成员atyuwen就已经实现了MRSII。经过半年多的改进，这种GI方法已经融入了新的Deferred Rendering框架中，并且性能也得到了很大的提升。下面就让我们来看看这种神奇的GI。
-−
-MRSII的渲染流程如下（感谢vanish整理了此流程图）：
-−
-[[File:GI_pipeline.png|640px|thumb|center|GI pipeline]]
-−
-首先，G-Buffer需要做mipmap，接着在每一层检测深度和法线的间断点，把那些间断点在stencil buffer中标记出来，得到了这样的stencil buffer：
-−
-[[File:stencil_mip0.png|640px|thumb|center|Stencil Mip 0]]
-[[File:stencil_mip1.png|320px|thumb|center|Stencil Mip 1]]
-[[File:stencil_mip2.png|160px|thumb|center|Stencil Mip 2]]
-−
-和之前的stencil规则一样，最高位是1表示忽略。所以灰色的pixel是可以忽略掉的，黑色的是需要计算光照的。可以看出黑色所占的面积并不大，绝大部分pixel都被略过了。
-−
-另外，还需要生成一个Reflective shadow map。和shadow map类似，RSM也是从光源视角渲染一遍场景。除了深度以外，RSM还需要保存normal和flux信息。把RSM采样出一些点，比如256个，作为虚拟点光源（VPL）。目前KlayGE里面用的是均匀采样的方式，以后将改成importance sampling的方式提高VPL分布效率。
-−
-最后，每个VPL都可以根据BRDF生成一个light volume。用这些light volume去照亮G-Buffer的每一层。初始的light volume是个半球，在它的vertex阶段会根据各方向反射的亮度拉出某些顶点，生成一个奇怪形状的light volume。这个阶段因为涉及到大量的填充和计算，非常耗时，但因为stencil test是打开的，绝大部分pixel都会被挡掉，真正参与计算的pixel数远远少于G-Buffer的总pixel数，GI因此得到明显的加速。经过测试，在目前的场景下，如果只用一层G-Buffer（也就是不用multiresolution），速度只有用三层的一半。如果大于三层，速度已经没有提高了。所以默认就选了三层G-Buffer。
-−
-在生成每一层的indirect lighting结果之后，还需要做一个特殊的插值upsampling，才能得到光滑的结果。这个插值在MRSII的原paper中有描述，这里就不累赘了。
-−
-[[File:indirect_smooth.jpg|400px|thumb|center|Indirect lighting: smooth sampling]]
-−
-如果只是用一般的最近点插值或者双线插值，结果会有很多悲催的锯齿：
-−
-[[File:indirect_poing.jpg|400px|thumb|center|Indirect lighting: point sampling]]
-−
-最后，把indirect lighting加到direct lighting中，继续做下一步的shading pass。最终结果如下：
-−
-[[File:final_GI.jpg|400px|thumb|center|Final GI]]
-−
-比较只有direct lighting的结果，可以看到右边和地面被照亮了：
-−
-[[File:final_no_GI.jpg|400px|thumb|center|Final no GI]]
-−
-用了MRSII后，对于512×512的RSM、256个VPL、三层G-Buffer的情况下，GI在GTX480上只需要1.09ms、在9800GT上需要4.3ms。目前还有不少性能空间可以挖掘，我预计在同质量的情况下，最终能达到在GTX480上0.5ms、9800GT上2.5ms的速度。
-−
-这套GI的框架不但可以做这样的反射型indirect lighting，也可以做caustics这样的高频反光，也可以处理sub-surface scattering等材质效果。在[[KlayGE]]以后的版本中，MRSII将会得到持续的发展。
 == Post process ==

← Older revision		Revision as of 16:01, 30 April 2012
Line 413:		Line 413:
	* 支持移动平台。精简的Deferred Rendering流水线将会以至到移动平台上。		* 支持移动平台。精简的Deferred Rendering流水线将会以至到移动平台上。
	* 更多例子用[[延迟渲染]]实现。目前只有3个例子用到了deferred框架，其他还是forward的。以后会有越来越多的例子转到deferred中。		* 更多例子用[[延迟渲染]]实现。目前只有3个例子用到了deferred框架，其他还是forward的。以后会有越来越多的例子转到deferred中。
		+
		+	[[Category:渲染]]

@@ Line 404: / Line 404: @@
 在photoshop里打开一张游戏截图，调整RGB曲线至需要的色调，然后把那个RGB曲线应用到之前生成的2D texture，最终打包成3D texture就得到了我们所需要的查找表。以后可能会根据需要做一个在线调整color grading的工具。
-本系列文章把[[KlayGE]] 4.0中[[延迟渲染]]的改进逐一介绍了一下，希望能对也在做类似事情的朋友有所帮助。在总结里我也身边展望一下未来，看看在[[KlayGE]] 4.1中，[[延迟渲染]]部分还会可能出现什么改进。
+== 总结 ==
 * 更高的速度。Multiresolution的方法在GI中获得了成功，也许也可以扩展到direct lighting和SSVO中，用于加速整个[[延迟渲染]]。