KlayGE游戏引擎

KlayGE 4.4的开发刚刚开始。在目前的开发版本里，编译脚本有了较大的改进，速度提升、内存消耗降低。这里就先总结一下一些经验。 MSBuild KlayGE的编译脚本原先是通过调用devenv，也就是Visual Studio的IDE来编译工程的。用户的普遍反映是编译信息不断滚动，很难看清是否有错误。前不久在编译Salvia的时候，看到空明大大的脚本输出通过不同颜色区分warning和error。问了一下才知道他调用的是MSBuild，本身就带颜色高亮。 MSBuild从VS2008开始就集成到Visual Studio了，在VS2010的时候已经全面接管了C++工程的编译。所以，如果调用devenv来编译一个工程，那么它的流程是： 启动VS IDE 启动MSBuild，调用cl和linker等 关闭VS IDE ...

经过团队成员半年来的努力，KlayGE 4.3在上周顺利发布。最近几个版本的习惯都是，在一个版本开发过程中就已经把一些ticket规划入下一个版本，并在发布之前提前进入了下一个版本的开发阶段。这里公开一下对KlayGE 4.4的一些规划。 时间线 这里列出几个重要的时间点，以供进度参考。 2013年11月30日，feature complete：所有功能都已经完成，没完成的推迟到下一个版本。 2013年12月15日，code complete：完成所有代码，除非特殊情况，否则不能在改变接口。 2013年12月31日，release：正式发布KlayGE 4.4。 必然出现 这些特性一定会出现在KlayGE 4.4中。其中有些需求来自于KlayMark。 High quality terrain：高质量的无限大地 ...

[zh] 经过KlayGE团队半年来的努力，今天KlayGE 4.3正式发布了！在这个版本的开发和测试过程中，很多朋友也提供了宝贵意见和bug报告，为KlayGE的发展和完善做出了贡献，在此表示感谢。KlayGE 4.3的主要更新如下： 一个新的子项目KFL 脚本引擎（由王锐完成） 高质量细节效果 改进的Deferred Rendering 改进阴影生成（由李渊完成） Deferred框架和GI分离 大量重构（论坛里的lcbiotech提出的建议） 大范围阴影支持 支持官方版Android NDK r8 全新的输入系统，支持触摸输入 非阻塞式资源载入和管理（论坛里的lcbiotech提出的建议） 增强的立体输出（由孙文全帮助测试） 支持嵌入其他GUI框架 支持多种OIT方 ...

长期以来，KlayGE一直是单独执行的，窗口上的UI也都是自己画。很多人都提到这么做给编辑器等应用造成了困难。所以如果适度修改KlayGE的窗口系统，使得KlayGE可以嵌入其他的GUI框架，比如MFC、QT、WPF等，有些时候会方便得多。 第一个尝试做这件事情，并且取得成功的在这里。他通过修改Window类，支持从外部传入HWND，让KlayGE复用外部建立的窗口。这么做能顺利地把KlayGE嵌入MFC等框架中。同时，作者也指出了单独这么改仍不能达到完美的程度，“并且由于KlayGE没有开放单独绘制一桢这样的函数，所以直接关闭程序会有内存泄漏和异常。以后再研究研究，试着把相关功能提取一下，做成和Ogre一样的，那样就可以在OnIdle()和OnPaint()时渲染一桢 ...

本系列的前三篇讲的都是关于Deferred Rendering的改进，本篇会专注于流水线后端的Post Process。 Post Process链 在KlayGE的渲染流水线里，不管用不用deferred，post process链是都会执行的。完整的post process链由一系列单独的post process组成，流程如下图所示。 前三个属于HDR的，经过tone mapping转成LDR之后，又经过三次post process，得到渲染结果。如果开了stereo，就会被stereoscopic的post process处理成立体的。 不管是用CUDA里的GPU kernel launch还是用图形API里的Draw Call来启动一个GPU任务，常见的改进规则都是，如果某次GPU任务不依赖于上次任务的其他单元，就应该和上次任务合并起来。这样可以省去GPU写入和读 ...

上一篇提到了在视口间共享shadow map的优化，以及对代码的重构。重构中的一个小发现造就了在不增加存储占用的情况下，就能支持透明物体的渲染。 透明物体和Deep G-Buffer 在透明的烦恼一文中，为了用纯Deferred的框架解决透明物体渲染的问题，KlayGE引入了Deep G-Buffer的方法。对不透明物体、透明物体的背面、透明物体的正面分为三个G-Buffer layer，分别有一条Deferred流水线，最终通过alpha把三层blend成最终结果。这种方法虽然能简单有效地解决问题，并避免繁琐的forward流水线，但需要三倍的存储和带宽。而且如果depth peeling的层数增加，开销还会进一步加大。最近出现的几种OIT方法，都不兼容于deferred。所以如果不用forward，就得 ...

上一篇讲到了把GI系统从Deferred Rendering框架中分离出来，以降低耦合度。本篇会涉及到一个共享shadow map、提高性能的改进。 多视口的改进 多视口的特性是KlayGE 4.2引入的。Deferred rendering layer支持通过多个视口生成多个渲染结果，可以用于分屏、反射、缩略图等情景。原先每个视口都是完全独立渲染的，互相不共享任何东西。实际上spot light和point light的shadow map是view independent的，不会因为视点不同而改变，就应该在视口间共享。 于是开发团队成员李渊完成了这个任务，把shadow map的生成提前到所有视口的G-Buffer之前。也就是说，原先的流水线是： for each view port: generate g-buffer. for each shado ...

从KlayGE 4.0确定了Deferred Rendering的框架以来，每个版本都有一些小改进。在正在开发的4.3里，多个改进经过这几个版本的融会贯通，产生了一些新的变化。这里做个系列总结一下。 GI和Deferred的分离 最早提到这个问题的是团队成员陈顺斌。他在去年就提出Deferred rendering layer太过复杂，应该把相对独立的GI拆出去。当时我的想法是，Deferred和MRSIL GI（Multiresolution splatting for indirect lighting）在逻辑上关联甚大，应该是一体的。后来实现了SSGI，也放在Deferred框架内，复杂度进一步增加。Deferred也成了个带有多种GI方法的怪物，各个组件之间的耦合度很高。 在分析了MRSIL、SSGI以及未来可能支持的SVO等多种GI方法之后 ...

上一篇介绍了Win7的touch和手势识别状态机。在Win8中，touch API虽然还存在，但新增了一个更方便使用的Pointer API，本篇会介绍一下它的使用。 Win8桌面的Pointer 和Win7的Touch相比，Win8的Pointer成熟得多了。它分为down、up、update等多个消息，甚至还有wheel消息。也就是说，相当于鼠标消息被完全移植过来了，并加入了触点ID。所以可以和容易地把原先处理鼠标消息的经验和代码都转移到WM_POINTER的系列消息来。在功能上还胜过Touch的一点在于，Pointer不光支持触摸屏，还支持鼠标、电子笔等多种设备，并可以返回之前n帧的历史坐标。目前KlayGE并没有用那些功能，仍是把几个基本的消息转到一个经过抽象平台无关的数据结构上。 需要注 ...

上一篇提到了，KlayGE的输入系统正在大改，将要加入触摸支持。本篇将会介绍Win7的touch，以及简单的手势识别。 Win7 Touch API 实际上Win7开始就支持了多触摸，只是UI和续航没跟上，使得Win7的平板体验一般。Win7的touch分为两个层面，第一个是底层的WM_TOUCH消息，应用程序收到的是触点坐标等；第二个是高层的WM_GESTURE消息，应用程序收到的就是已经经过识别的手势了。两者只能选择一个，不能两个都收到。默认的是WM_GESTURE，如果调用了RegisterTouchWindow，系统就会不再发送WM_GESTURE，而把底层的WM_TOUCH发给应用程序。WM_GESTURE虽然简单，但缺点很明显。它受限于支持的几种手势，没有办法添加自定义的。所以这里只打算介绍WM_TOUC ...