KlayGE游戏引擎

上一篇讲了低端硬件上如何运行deferred框架。本文是这系列的最后一篇，将会介绍KlayGE 4.5中对虚拟现实设备Oculus Rift的支持。 Oculus Rift是Oculus VR公司推出的虚拟现实头盔。它几乎是市面上同等设备中价格最便宜同时效果最好的一款VR头盔。在硬件上，它分为输入和输出两个系统。输入系统是个9轴sensor（陀螺仪、罗盘、加速度计），采样率高达1000Hz。能精确提供头盔的朝向。第二代设备甚至能提供局部移动信息。输出系统是一个7寸的屏幕，因为和眼睛的距离很近，可以覆盖整个视域。 Oculus同时还提供了个Oculus SDK，可以通过它得到sensor的输入，和输出的参数。但渲染之后的后处理等，需要程序自己处理。 输入系统 KlayGE中 ...

上一篇探讨了G-Buffer里如何紧凑并高质量地存储normal。长期以来，deferred一直被认为只能用于高端显卡，低端卡由于功能和带宽的限制，不适合使用deferred。虽然现今移动设备大行其道，但所有移动设备和桌面相比，都只能算低端。所以OpenGL ES上也一直都被forward渲染占领。一个引擎维护两套流水线是非常麻烦的事情，尤其对于KlayGE这样的开源轻量引擎。所以，如果能在低端设备上也能用同一条deferred流水线，能给维护和扩展提供巨大的方便。 经过一定的改进，deferred流水线已经可以在中上等级的OpenGL ES 2设备和D3D11 feature level 9.3设备上跑了。这样的硬件涵盖了NV GeforceFX 6000以上（2004年）、ATI Radeon X1000以上（2005年） ...

上一篇讲了基于CS的TBDR，目前KlayGE中一共有三条deferred的code path，传统的DR，基于PS的TBDR和基于CS的TBDR。但不论是什么样的deferred，都不可避免需要在G-Buffer上存normal。对G-Buffer优化的重要议题之一也是如何尽量紧凑地存储normal。 原先的做法 在KlayGE 4.0之前，G-Buffer是2张64bpp的纹理，normal用spheremap transform的方式存在2个fp16的通道里，共32bit。这样的G-Buffer占用空间相当大。在4.0的时候，G-Buffer改成了2张32bpp的纹理，normal用best fit的方法存在3个8bit通道里，共24bit。Best fit的有效位数是23bit，两个fp16的总有效位数是22bit，所以这么做反而有助于质量提升。 Normal压缩 Normal的压缩其实应该分为两 ...

KlayGE 4.4中的Tile-based Deferred Rendering（TBDR）是个基于pixel shader的算法，每个batch最多32个光源。这个方法适合于不支持compute shader的设备。因为在compute shader里，可以利用group memory把更多光源打包到同一个batch里，进一步提高效率并减少带宽。 改进的算法 CS可以通过group memory在thread之间共享数据，只要利用得好这部分，就能极大提升性能。在TBDR中，group memory主要用在两部分。第一部分是tiling阶段，用的是常见的reduce方法。先让所有thread读满32x32个depth，reduce得到1x1，再写入目标纹理。 第二部分是shading阶段。每个group会对所有光源做一次求交测试，把有效的光源写入group memory。接着在同一个sh ...

上个月底，我第一次尝试用Clang来编译KlayGE，遇到了很多麻烦，而且最终卡在了mangling的bug上。昨天更新了svn上的LLVM和Clang，惊奇地发现那个bug已经被修正了。这么一来，编译dll不再是问题，可以生成正确的binary。 新麻烦1 自己编译出clang 3.5.0的svn版之后，再次试图编译boost。原先boost并不支持Windows版的clang，所以我改了tools下的工具链，加入了clang-win.jam。结果说不认识-mthreads。去掉这个编译选项之后，编译链接通过，能生成boost的dll。但是文件名不对。首先是MinGW的情况下，首选的dll名应该以lib起头。其次，生成的文件名都是boost_*-35-mt-1_55.dll这样的形式，缺了toolset名，正确的应该是libboost_*-clang35-mt-1_ ...

Clang最近越来越火，多个linux版本已经打算用Clang代替GCC作为默认编译器了。去年Clang宣布改进Windows的支持，所以我打算尝试一下用Clang在Windows上编译KlayGE。一来是想用Clang的静态检查工具来减少bug，二来是为以后移植到MacOSX和iOS做准备。 在这个过程中，发现到处是坑，而且最终问题也还没解决。这里把我遇到的麻烦做个总结，希望能抛砖引玉。也希望有经验的朋友能可以帮忙出出主意。 麻烦1：MinGW还是VC Clang 3.4提供了预编译的Windows版下载，下了之后直接安装即可。在VC里可以看到多了LLVM-xxxx的toolset。按说能直接用它编译原有工程，但试一下才发现，很多VC的编译选项clang-cl并不支持。看了帮助发现可以用-Qunused-argu ...

上一篇我提到了如何用CMake管理Android工程。KlayGE除了Windows、Linux和Android之外，还支持WinRT平台。是的，WinRT虽然和Windows桌面很接近，但在一些细节上存在一些差异，使得它们应该被考虑为两个不同的平台。就好像Android和Linux应该考虑为不同平台一样。 区别 在KlayGE中，WinRT和Windows桌面的区别除了代码上，还涉及到工程文件和开发流程上。WinRT的工程需要考虑资源、打包、签名等，都是Windows桌面不需要的。从概念上看，WinRT开发更像Android这样的移动平台开发。 Android程序构建，用的是MinGW或Unix的makefile的方法，所以只需要把里面定义的编译器等换掉就八九不离十了。WinRT用的是VS2012+的工程文件，需要对其进行修改 ...

2年前KlayGE的工程文件就已经在王锐的帮助下切换到CMake。上个版本中，第三方库也已经都改用CMake。但是，对于Android版本来说，原先仍然使用的是NDK的那套东西。所以在维护上带来了不小的开销。随着代码量越来越大，如果能把Android也纳入到CMake工程中，开发起来就能更方便。所以前一阵子做了些探索，最终解决了这个问题。 原有的编译方法 我一直都没有使用Eclipse，而是纯用命令行的方式进行编译。需要： 准备好AndroidManifest.xml、Android.mk、 Application.mk等工程文件 android update project -p . -s --target=android-10，生成build.xml等 ndk-build，编译出.so 把所需资源编译和拷贝到assets目录 ant debug，打包 ...

上一篇我们提到了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的模 ...

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