KlayGE游戏引擎

本系列的上一篇提到了KlayGE 4.4将会出现的高质量地形渲染。本篇仍讲一个新功能，Screen Space Sub Surface Scattering（SSSSS）和Translucency。这两个效果都是由团队成员石裕隆实现的。 Sub Surface Scattering（SSS）对渲染效果的提升有很明显的左右，尤其是皮肤和植被之类物体。早在GPU Gems 1里就有在texture space作的近似SSS。GPU Gems 3里的方法更是大张旗鼓地用了多次Gaussian来逼近Dipole，在texture space作6次blur后线性叠加，得到非常真实的皮肤效果。但这么做的开销实在太大了。 首先看看直接用Blinn Phong BRDF渲染的结果，皮肤本身看起来很塑料。 SSSSS 到了GPU Pro里，Jorge Jimenez等人提出了SSSSS的方法。在s ...

本系列的上一篇讲了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写入。这个带来的 ...

boost 1.55.0前两天发布了。长期以来KlayGE中集成的boost源代码是用的都奇数版本号的boost，上一个是1.53，所以这次1.55也要集成进来。 除了用bcp缩减boost的大小之外，由于boost在开发的时候没有考虑WinRT和Android这样的平台，所以每次集成后都需要做一些修改才能让boost通过所有的编译。纵观这次的1.55.0，需要修改的地方比以往的都少得多了。主要原因来自几方面： KlayGE从4.3开始引入C++11。原先需要修改的一些库，比如Chrono、Thread、SmartPtr，都因为不再使用boost的实现而没有去修改。 bjam和Config已经支持vc12，所以不需要自己打补丁。 Endian改用新增的Predef库，已经支持Android和ARM。 Boost.Filesystem已经支持A ...

随着工程代码量越来越大，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简单， ...