KlayGE游戏引擎

本系列的上一篇讲了DR中的一些改进。本篇开始将描述这个版本加入的新功能，高质量地形。 原有的地形 以前的地形实现和水面的方法一样，都是从Crytek在2008年的老方法改进而来。虽然比projected grid的好得多，并且速度很快，但有一些很明显的缺点： 视点移动的时候会抖动。水面比较平，而且有波浪看不出抖动。如果用来做静态地形抖动就会非常明显。尤其是far plane变大之后，远处更明显，所以限制在3000以下。 不支持shadow。因为只有产生了视野内的三角形，视野外的地形无法正确投出shadow。 顶点密度较低，无法表达精细的地形。原先的方法三角型分布接近于screen space，不足以很好表达地形。 这个抖动的消除可以靠snappi ...

上一篇讲了TBDR的实现，本篇继续讲解deferred rendering层的一些重要改进。 切换到ESM 原先deferred系统用的是VSM，现在切换到开销更小的ESM。具体参见我之前的一篇文章。用ESM之后只需要一个通道，空间占用减少，性能也有所提升。下个版本会进一步改成支持打包到RGBA8的纹理，让不支持浮点纹理的硬件也可以使用ESM。 Multi-resolution层 KlayGE很早就引入了multi-resolution的概念，用来加速SIL的GI。但原先的MR、SIL和Deferred绑在了一起。从上一版开始，MRSIL从Deferred独立出来之后，这个版本继续改进，把MR和SIL也分开了。现在MR可以用于其他地方，比如SSGI。原本SSVO也打算上MR，但后来来不及改了。 这个分离的思路是，MR层负责 ...

KlayGE从4.0开始引入deferred rendering层（DR），并且这几个版本都在持续地改进，以提高性能和降低使用难度。在即将发布的4.4里，deferred rendering更是往前跨了一大步，实现了一个初步的Tile-based Deferred Rendering（TBDR）。和常见的TBDR不同之处在于，这里的方法只需要SM3。（其实SM2也没问题，只是如果光源较多，会遇到指令长度限制） Tile-based 在传统的deferred rendering中，每个光源需要和每个像素做一次相交测试，测试通过的才计算光照。这个相交测试一般通过light volume的方式进行优化。但最终仍然需要对每个light画1次。也就是说，每个像素需要对每个光源读取一次G-Buffer，计算一个光照，并做一次blend写入。这个带来的 ...

随着工程代码量越来越大，pdb的尺寸也会一直增长。比如KlayGE核心没多大，但pdb已经到了73.7M。一个偶然的机会让我发现了vc的link一直以来都有个undocument的选项/pdbcompress。加上之后可以在生成pdb的时候自动打开NTFS的压缩。 由于pdb里面大量内容都是文本信息，即便是NTFS的压缩都可以得到比较高的压缩比。经常可以压到剩下1/3的大小。NTFS压缩的算法比较简单，压缩和解压的的速度也不错。所以在生成和调试的时候，读写速度并不会有很大影响。所以能用这个选项的时候还是尽量使用吧。 话说，这年头还有人不用NTFS吗？

D3D11.1和OpenGL ES都提供了discard frame buffer的方法，分别成为DiscardView和GL_EXT_discard_frame_buffer。虽有文档，但却很少有例子来表达这功能在什么情况下使用。这里我只能根据我的理解做一些探讨。希望有更了解的朋友可以一起讨论。 从tile-based说起 移动平台上最常见的GPU架构是tiled-based。它把frame buffer划分成许多大小相同的tile。每个rasterizer一次处理一个tile，把这个tile中包含的三角形光栅化到那个区域。为了提高性能、减少功耗，tile-based硬件会有一个片上空间，真正的光栅化仅仅发生在这个片上空间，当一个tile的所有三角形都渲染完成之后，才写入位于video memory的frame buffer。可以认为，那个片上空间是个ca ...

几个月前我提到过如果通过IE10或单独装补丁的方法，可以在Win7上获得部分D3D 11.1和DXGI 1.2的能力。代价是，由于debug layer的不同，那么做的话无法用D3D11_CREATE_DEVICE_DEBUG标志建立设备，所以就不能使用调试模式的D3D。Win8.1再次修改了debug layer的名字，使得这个现象在Win8.1上也会出现。如果在Win8.1上使用VS2012及以前的Win SDK，就无法建立debug设备。 Win7上的D3D11.1 从文件日期可以看出，安装了D3D11.1后的Win7，d3d11.dll已经被升级了。原先的debug layer叫做d3d11sdklayers.dll，而在Win8 SDK里有了个d3d11_1sdklayers.dll。新的d3d11.dll会去找那个文件，而不是原先的。如果把Win8 SDK或者VS2012里的d3d11_1sdklayers.dl ...

MinGW-w64是另一组人做的修改版GCC，比起原先的MinGW，它的好处是可以编译出x64和x86的Windows程序，而且对Windows API的支持更好。原先用MinGW编译KlayGE的时候，需要对MinGW的头文件（或者说w32api的头文件）做一些修改，才能完成。如果用MinGW-w64，会不会好些呢？ 版本的选择 和其他第三方的MinGW一样，由于选项的不同，MinGW-w64在Windows上其实有多个不同的版本。C++ Exceptions有DWARF、SJLJ、SEH三种处理方式；GCC Threading Model有Win32和Posix两种实现；编译器本身还分Win32和Win64的，虽然都可以交叉编译出x86和x64的代码。这些方式组合爆炸后，最终的binary版本就眼花缭乱了。我这里测试的是x32-4.8.1-release-win32-sjlj-rev ...

2006年以来， KlayGE一直都是用Variance Shadow Map（VSM）来表达阴影。VSM只比标准shadow map（SSM）增加了几行代码，但却能通过插值，极大减少边缘的锯齿，甚至模拟软阴影的效果。VSM的缺点是，需要抓用两个32F的通道。这么一来，带宽消耗大得多了，并且没办法通过编码到RGBA8的技巧在不支持浮点纹理的设备上使用。另外，VSM的light leak也是很讨厌的毛病，需要仔细调参数才能减轻。 Exponential Shadow Map 实际上在VSM出来不久之后的2008年，就有了Exponential Shadow Map（ESM）的方法。和VSM类似，ESM也是通过巧妙的方法使线性插值成为可能，从而完成各种blur。比较一下SSM、VSM和ESM的生成和使用，就能看出来ESM在代码上比VSM简单， ...

KlayGE的源代码包里带了包括boost在内的所有第三方库。如果使用完整版的boost，那么大小会吃不消的。因为只用了boost中很少的一部分（列表在这里），以前用的方法是手工删掉了libs和tools等目录下所有不使用子目录，以及帮助文件和例子。通过这样的缩减，已经让boost从356M减少到了96.8M。但是，头文件的目录仍不容易直接删减，因为互相依赖很大。 上周空明流转大牛说他在SALVIA里也遇到了类似的问题，打算用boost自带的bcp工具处理一下。所以我也做了一下测试，用bcp来砍掉所有不用的库： bcp atomic chrono filesystem program_options regex system thread algorithm any array assert assign bind circular_buffer container foreach ...

HDR post process几乎存在于所有PC桌面引擎中，也开始在一些高端移动平台上得到了支持。HDR太常见了，以至于这年头如果看到一个不带HDR的真实感实时渲染，就会觉得很突兀。（比如，在SIGGRAPH展会上，看了Qualcomm的展台，再看ARM和Imagination的，就有一种回到dx8时代的感觉。大部分原因就来自于Mali和PowerVR缺乏很好的HDR。）在这方面，KlayGE的目标是在不同平台上，都能尽量多地复用HDR post process里的组件，同时效果也尽量接近。首先让我们看一张只有LDR的图。 啥都支持的平台 代表的平台有D3D11 level 10+，OpenGL 3+。支持包括B10G11R11F在内的各种浮点纹理。在这样的平台上，KlayGE的HDR流程是这样的。注意红字标出来的数据 ...