KlayGE游戏引擎

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，打包 ...

[zh]三年前，我就曾经计划过一个KlayGE的长期研发子项目，D3D11 HLSL字节码到GLSL的编译器。两年前，在d3d1x for linux代码的帮助下，基本的字节码解析和反汇编工具已经实现。如今，这个子项目被正式命名为DXBC2GLSL，在库和工具两个层面上提供HLSL字节码（DXBC）到GLSL的转换。2013年底，DXBC2GLSL支持VS和PS初始版本已经由团队新成员林胜华完成，并提交到开发版本中。GS的支持也已经在上个月加入。当前所有KlayGE中的shader已经全部通过测试。[/zh] [en]Three years ago, I've planned a long-term R&D sub-project of KlayGE, D3D11 HLSL bytecode to GLSL complier. Two years ago, derived from d3d1x for linux, a simple bytec ...

经过团队几个月的努力，KlayGE 4.4已经在去年年底顺利发布。在此感谢大家的支持和帮助。实际上从上个月开始，KlayGE 4.5就已经进入了计划阶段。这里公开一下对KlayGE 4.5的一些规划。和以前一样，欢迎有兴趣、有时间的朋友加入KlayGE 4.5的开发阵营。 KlayGE 4.5将会更好地支持移动平台，包括Android和WinRT，并为以后支持iOS跨出第一步。同时，在4.5里，会继续把一些原本在例子中的技术集成入引擎的核心层，方便使用。 时间线 这里列出几个重要的时间点，以供进度参考。 2014年5月31日，feature complete：所有功能都已经完成，没完成的推迟到下一个版本。 2014年6月15日，code complete：完成所有代码，除非特殊情况，否则不能 ...

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