KlayGE游戏引擎

由于sourceforge和bitbucket在国内的访问速度较慢，我在codeplex上申请了个空间http://klayge.codeplex.com/用于存放KlayGE的repository。Mercurial clone的地址是https://hg01.codeplex.com/klayge。如果你不满现在的访问速度，可以考虑用这个新的。

[zh] 继glloader移植到Android之后，KlayGE也可以在Android上执行了。虽然，严格来说，只是能跑最最基本的空框架。 由于我没有Android真机，模拟器又无法执行OpenGL ES 2，所以我的测试方法是在最老的Asus EeePC上执行Android x86。空框架EmptyApp目前可以顺利执行： [/zh] [en] After porting glloader to Android, KlayGE can be run on Android too. Technically, it's only a empty framework. Since I don't have a real Android device, and the emulator can't run OpenGL ES 2, I have to test it on an old Asus EeePC with Android x86. The empty framework "EmptyApp" runs well on it: [/en] [zh] ...

AMD昨天发布了Catalyst 11.12 WHQL驱动。对开发者来说，最大的好处是正式支持了OpenGL 4.2！虽然从11.10 Preview 3开始，Catalyst就支持OpenGL 4.2，但正式版总是返回到了4.1。这是AMD第一个正式支持4.2的驱动。 Catalyst 11.12桌面版下载： Cat 11.12 Win7 64-bit Cat 11.12 Win7 32-bit Cat 11.12 XP 64-bit Cat 11.12 XP 32-bit Catalyst 11.12移动版下载： Cat 11.12 Mobility Vista / Win7 64-bit Cat 11.12 Mobility Vista / Win7 32-bit 至此，主流显卡驱动都支持了OpenGL 4.2。（Intel？Intel也算主流？）

Android从NDK r5之后，就支持使用纯C/C++编写App。但按照NDK中的例子，纯C/C++写的代码总是异于其它平台。它的程序入口是void android_main(struct android_app* state)，而不是其它平台通用的int main()。 就其本质，是因为android上没有其它平台的CRT来调用入口，而是通过android_native_app_glue这个库把native的代码和java端粘起来。所以，我们可以通过修改android_native_app_glue库，来实现和其它平台一样的int main()入口。 可以观察到，android_native_app_glue需要提供给android_main一个关键的参数：android_app指针。同时，android_main里面需要调用android_dummy()这个空函数来保证android_native_app_glue不会被优化器删 ...

glloader，作为KlayGE的一个子项目，是OpenGL扩展载入库，可以载入OpenGL 1.0-4.2，OpenGL ES 1.0-2.0，以及WGL、GLX等OpenGL扩展。只要编写xml脚本就能自动生成扩展载入代码。 在王锐的帮助下，glloader完成了移植到Android的工作。目前glloader可以用NDK r6和r7进行编译，在模拟器和真机Xoom上均测试通过。目前，支持Android的glloader代码可以在hg上找到。正式版本glloader 4.0将会在晚些时候发布。 这里有一个在Android NDK中使用glloader的例子，从NDK自带的native-activity修改而来。从这里可以看出，从原先的直接调用GLES改为使用glloader之需要修改#include和link选项。 native-activity.7z 需要注意的是，由于NDK r6的 ...

随着Android 4.0的发布，NDK也更新到了r7。不用白不用，我就下了一个试试。在初探的过程中，发现一些令人惊喜的地方。 惊喜1：不再需要Cygwin才能编译 这个惊喜其实在release note里就有提到，标记为Experimental features。 NDK r7提供了ndk-build.cmd和make等，可以直接在Windows上调用ndk-build了，不再需要Cygwin。但是ndk-gdb仍然必须有Cygwin才能debug。 惊喜2：wstring的支持 没有任何地方提到这一点，而且是默认关闭的。 原先的NDK在android-9下是支持wchar_t的，但是不支持wstring、wstringstream等。当需要用到那些的时候，就得用第三方定制的NDK，比如CrystaX NDK r6。但CyrstaX更新速度较慢，还没有对应于r7的版本。我 ...

上一篇分析了KlayGE中实现实时全动态GI的方法，本篇是这个系列的完结篇，主要讲流水线的最后一段：Post process。 Post process 在KlayGE 4.0的Deferred Rendering中，post process主要有HDR、AA和color grading。下面将分别讲述它们的改进。 HDR 在KlayGE 3.12用了filmic tonemapping之后，HDR部分就几乎没有别的改变。这里唯一的变化是最终输出的float4，把亮度存在A通道上。这是为了后面FXAA的需要。 AA 在Deferred框架中，无法使用硬件AA曾经是个恼人的问题。随着这些年各种基于post process的AA方法大量出现，Deferred下AA的问题基本被解决了。 团队成员陈顺斌和郭鹏曾为KlayGE 3.12提供了FXAA。在新版本中，FXAA也升级到了最 ...

上一篇解决了透明物体的渲染问题；本文将挑战另一个实时渲染的神话，实时全局光照（GI）。 实时全动态GI 目前direct lighting在游戏中日趋成熟，比较前卫的游戏引擎已经不满足于diect lighting的效果了，逐渐开始尝试indirect lighting。早期的方法有通过离线渲染light map来实现静态场景、静态光源的GI。接着出现了PRT，可以处理静态场景、动态光源。CE3用了Light Propagation Volumes的方法，不需要预计算，可以产生动态场景、动态光源的diffuse GI。不过其速度和质量确实不敢恭维。难道就不能有全动态场景、全动态光源、diffuse和specular通吃的实时GI方法吗？有！Multiresolution splatting for indirect illumination（MRSII）前来救 ...

上文讲到了如何把信息挤入有限的G-Buffer，另一个在实际中面临的问题是如何渲染透明物体。 透明物体 游戏中透明物体是不可缺少的，对于Deferred Rendering来说，透明物体一直是痛苦的。常见的做法是在deferred rendering的场景之上用forward shading来单独渲染透明物体，但那样就意味着必须单独实现一整套forward shading的流水线。这对于维护和扩展都是很不利的，对性能也很有影响。 在KlayGE 4.0里，我用的方法被称为Deep G-Buffer。其基本过程是，把第一篇所描述的Deferred Rendering流水线复制三份，不透明的物体、透明物体的背面、透明物体的正面分别有自己独立的G-Buffer、lighting pass、shading pass和special shading pass。最 ...

上一篇讲了在KlayGE 4.0中，Deferred Rendering的流水线改进。本篇继续讲G-Buffer的变化。 G-Buffer布局 前面提到了G-Buffer改成了MRT，那么现在就来比较一下新老G-Buffer的区别。老G-Buffer的安排如下： 老G-Buffer是4个通道、每个通道都是fp16的RGBA16F格式。其中normal用Spheremap Transform的方式映射到2个通道；depth单独存一个通道；specular和shininess挤在一个通道内，整数部分为specular * 100，小数部分为shininess / 256.0f。 这样的G-Buffer需要占据64-bit，IO开销不小，而且depth精度有限。如果按照新的MRT G-Buffer扩展到2个RT，就需要再增加一个32-bit的RT。对于不支持Independent MRT的D3D9硬件来说，甚至要增加 ...