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写入。这个带来的 ...

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 ...

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简单， ...

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流程是这样的。注意红字标出来的数据 ...

在渲染场景的时候，一般来说分辨率和输出大小，也就是窗口大小相同。但在移动平台上，基本上没机会让你随便切换分辨率，都是只告诉你大小。在这时候，你如果想要用特定的分辨率渲染，就不可避免需要一次放缩。另一个常见的情况是，如果一个平台性能达不到需要的帧速率，也需要渲染较小的图之后，拉伸到指定分辨率。在XBox 360等console平台，有个专门的硬件放缩机制，只要打开就能自动把输入图像拉伸到720p或1080i/p（DX11.2才开始引入这样的机制）。但在PC和移动平台上，这个事情得在引擎里自己完成。所以在post process后端，加一个resizer就成了必然之选。 框架 这个放缩的框架很简单，把窗口大小填充给screen resolution，而渲染的分辨 ...

最近不少朋友提出为何不把KlayGE推到github的问题，原因是目前github只支持git，而我暂时不打算从hg切换到git。我原先觉得，既然有hg-git这样的插件，这件事情技术上应该很容易，直接转就可以了。试验了一下，发现其实还存在一些坑，必须要对付。这里拿空明大牛的salvia的repository为例子，试验从hg转到git。 第一次尝试，直接转换 安装了hg-git之后，建立一个叫做salvia-git的目录，在里面初始化一个git repository。然后在到salvia-hg的目录，直接执行hg push ../salvia-git。结果在执行了很久之后，出现 pushing to ../salvia-git abort: The system cannot find the file specified 以失败告终。 第二次尝试，bare 在初始化git r ...

KlayGE 4.3.0的输入插件新增了对触摸输入的支持。但这部分代码在WinXP上执行的时候，说user32.dll缺少GetTouchInputInfo的入口。这里出个补丁，通过动态检测和载入可以有效的解决这个问题。同时感谢黄河水报告了这个bug。分别解压后覆盖掉源文件即可。 KlayGE源代码的补丁：KlayGE_4_3_0_patch.7z Sample的补丁：KlayGE_Samples_4_3_0_patch.z7