KlayGE游戏引擎

上一篇我们提到了SSSSS，作为本系列的最后一篇，本文将介绍KlayGE 4.4的OpenGL和OpenGLES插件的改进。 OpenGL 4.4 KlayGE在OpenGL方面一直是紧跟spec的步伐，这次也不例外。在八月份OpenGL 4.4发布的时候，glloader和KlayGE的OpenGL插件就很快加上了4.4的支持。并且这次把代码彻底过了一遍，很多原先通过扩展实现的功能，都尽量替换成用核心实现的，提高兼容性。 经过测试，OpenGL插件在NV和Intel的显卡上所有例子都能正常工作。 OpenGLES 3.0 虽然GLES3出了有一段时间了，但硬件支持度和开发环境都还没跟上，所以原先OpenGLES插件只支持2.0。这次尝试了PowerVR和Mali的OpenGLES 3模拟器，觉得还行，就加上了GLES3的支持。Adreno的模 ...

[zh] 随着半年一个新版本的周期，今天KlayGE 4.4正式发布了！在这个版本的开发中，多名团队成员贡献了自己的代码，也有很多朋友提供了宝贵意见和bug报告。也从SALVIA项目的编译脚本中学习和借鉴了很多经验。这些都为KlayGE的发展和完善做出了贡献，在此表示感谢。KlayGE 4.4的主要更新如下： 改进的编译系统 尽可能使用MSBuild 第三方库使用cmake工程文件 自动搜索OpenGLES SDK的目录，简化了编译的配置 OpenGL ES 3.0支持 Tile-based deferred rendering OpenGL 4.4支持 Multi-resolution层 高质量地形渲染（由孙文全协助完成） 屏幕空间SSS和半透明效果（由石裕隆完成） 基于后处理的图片放缩 多线程场 ...

本系列的上一篇提到了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 ...