KlayGE游戏引擎

前几天，KlayGE 4.6刚刚发布，现在新版本的开发已经开始了。这里公布一下我对KlayGE 4.7的一些计划。和以前一样，欢迎有兴趣、有时间加入KlayGE 4.7开发阵营的朋友们继续参加。 KlayGE 4.7将会更加高效，并继续发展移动平台的支持。 时间线 这里列出几个重要的时间点，以供进度参考。 2015年5月31日，feature complete：所有功能都已经完成，没完成的推迟到下一个版本。 2015年6月15日，code complete：完成所有代码，除非特殊情况，否则不能在改变接口。 2015年6月30日，release：正式发布KlayGE 4.7。 必然出现 这些特性一定会出现在KlayGE 4.7中。其中有些需求来自于KlayMark。 Transient Buffer。高效buffer管理 ...

在KlayGE走上OSX的实验中，我提到了目前OSX的版本还有两个主要问题，一是没法打开post processing，而是shader编译用的是Cg，以至于不能支持GL3+的功能。钱康来这几天又做了一些实验，在很大程度上解决了这些问题。 Post processing 原先一打开HDR、FXAA、Gamma校正等流水线末端的post processing之后，只能看到黑屏或一片混乱。在xcode的调试中看到的是，back buffer中有正确的结果，但swap到front buffer就只有错误的画面。这就排出了是depth或stencil没用清空造成的错误，只能是swap的地方有什么蹊跷。 经过一番尝试和查阅资料，发现了OSX和其他平台在swap上有所不同。Windows上的SwapBuffers，以及Linux上的glXSwapBuffers，都可以 ...

[zh] 大家圣诞快乐！又到了KlayGE的发布周期。今天，KlayGE 4.6正式发布了！这个版本创造了很多个第一次，下面会给予逐个列出。在这个版本的开发中，我因为一些个人原因，投入的时间比以往有所减少。幸运的是，由于有了一次新的开发人员招募，新老成员完成了不少组件，同时也有很多朋友提供了宝贵意见和bug报告，在此表示感谢。KlayGE 4.6的主要更新如下： 引擎方面的改进 现代化OpenGL，由刘瀚阳协助完成。增加uniform buffer、debug output等OpenGL 3.x的特性。OpenGLES插件也会做相应修改。 改进的DXBC2GLSL。林胜华进一步增强了DXBC2GLSL，增加了HS/DS/CS的支持。 支持最新的OpenGL 4.5。 改进OpenGL在AMD和Intel显卡上 ...

长期以来，把KlayGE移植到iOS的呼声很高。从别的平台直接移植到iOS，跨度有点大。所以我的计划里把MacOSX当作一个中间平台，先移植到OSX，把OSX当作开发平台来开发iOS版本。现在，KlayGE的OSX版本有些进展，在这里总结一下。 OSX几乎完全由新加入的组员钱康来完成的，在此表示感谢。这也是第一次不是由我亲自完成的平台移植。除了需要对付平台API的差异之外，还需要把一部分窗口相关代码用ObjC完成，在通过跨语言调用接入引擎的其他部分。目前有些初步的结果，在不加上post processing的情况下，一些sample可以顺利执行了。post processing一加就黑屏，具体原因正在调查中。 下面是一些结果。 除了post processing，还有 ...

不久以前，KlayGE附带的boost破例升级到了1.56.0。随着boost的开发进度重回正轨，1.57又如期发布了。所以KlayGE第三方库的boost再次回到传统的只更新单数版本的规则。 在boost 1.57之前，any用的是C++原生的typeid，在使用的时候必须打开编译器的RTTI。于是我提交了一个补丁，让any使用Boost.Core中的一个替代typeinfo。由于现在有了更完善的Boost.TypeIndex，any可以直接使用它。这样就能在不打开RTTI的情况下使用any。再加上1.57更好地兼容了WinRT和Android，原先很多修改变得不必要了。这么一来，要在KlayGE支持的所有平台上都使用boost，需要修改的地方前所未有地少了。 接下去我还打算把Boost.SmartPtr等地方用到typeid的也都改成 ...

面光源一直是实时渲染的一大难点。原先所有实时渲染中都只敢用点光源（spot光源也是从一个点发射出来的，在这里也算做点光源）。直到这两年，软硬件水平逐步提高了之后，面光源的实时近似才慢慢变得实用起来。 面光源的难处 从ray tracing的角度来说，在计算一个点的光照时，需要根据BRDF沿着反射方向发出多根光线，每一根都需要与光源求交。如果是点光源，那么只要计算一个点和射线求交。如果是个有体积的物体，求交就比较麻烦了，并且需要发射出更多的光线才能逼近真实效果。 在实时渲染中，光照的计算可以分为两部分。第一是来自光源的贡献。点光源可以用常见的光照模型进行计算，最近流行的基于物理的渲染，前提之一就是光源为点光 ...

去年我曾经尝试过把KlayGE嵌入其他GUI框架，当时试验的是MFC。现在，为了更方便地使用和开发GUI部分，我选择了WPF。 由于WPF是C#的，这里必不可少需要跨语言调用。我使用的方法是，把KlayGE和主窗口需要的东西包装到一个dll中，导出成纯C接口。在C#中用Dllimport引入使用。这样只需要2个工程就能完成任务。WPF的界面上内嵌了一个WinForm的窗口，可以拿到HWND，就能用来初始化KlayGE。这么做虽然没有D3D控件来得方便，但能避免多次拷贝带来的性能损失。 有了WPF的支持，把ModelViewer这样的工具转到WPF就成了顺理成章的事情。新的工具叫做MeshMLViewer，可以用来查看MeshML格式的模型。使用和修改起来比以前自画界面来得方便。 ...

在使用了CMakeMS之后，支持Windows Phone 8+平台就成了理所当然的一件事情了。Boost 1.56已经能支持store和phone，在进一步解决了Phyton和7z在WP下的编译之后，我就开始尝试编译KlayGE本身。 下面讨论的WP，特指VS2013支持的WP8.1。WP8.0还没时间测试。 事实上，因为原先已经可以编译成store版本，切换到WP非常顺利。只有一处需要修改：WP上没有VersionHelpers.h，而且WinRT上也用不到。所以只要#ifndef掉就可以了。除此之外，没有任何别的修改，WP版本就可以顺利编译出来了。 在用模拟器运行的时候，出现了一个异常，WP有声明但没有实现CoreCursor。WP上不需要鼠标指针。同样，这里只需要一个#ifndef跳过那句就可以了。于是，KlayGE的大 ...

几个月前KlayGE的WinRT工程就已经转到CMake的方式进行管理。但因为CMake本身不支持WinRT，当时的做法是修改CMake的代码，打上自己的补丁后才能使用。现今，CMake有了个微软的fork，从我的补丁出发，专攻WinRT等平台上的兼容问题。目前这个分支能很好地生成Windows Store和Windows Phone的工程。 使用方法 对于生成其他平台的工程，这个分支的CMake和原先完全一样。对于WinRT平台，需要通过这样的命令行参数来指定目标系统和版本号： -DCMAKE_SYSTEM_NAME=WindowsPhone（或WindowsStore） -DCMAKE_SYSTEM_VERSION=8.0（或8.1） 实际上这个做法相当于和WinCE一样，在platform generator级别生成WinRT的部分，比我原先用compiler gener ...

KlayGE 4.6的开发刚刚开始。在目前的开发版里，工程方面有了一定的改进，这里总结一下。 boost的CMake化 在之前boost升级的贴子里有提到，现在包括boost在内的所有第三方库，都已经用CMake进行管理了，bjam被完全删除。这样只要一套编译设置就能应用于KlayGE中的所有项目。修改和移植变得更容易。 编译器支持 在KlayGE 4.5里，我做了一系列的实验，试图用Clang来编译KlayGE。原先遇到了一些Clang的bug，使得编译一直不成功。现在Clang解决了部分问题，KlayGE本身的dll都能通过Clang编译产生了，但exe仍然不行。问题还是出在Clang在Windows上对类的导出，有些函数被遗漏了。 VS14已经发布了两个CTP，现在KlayGE里也增加了对VS14的支持 ...