KlayGE游戏引擎

2年前，D3D11显卡刚出来没多久的时候，我曾经做过一个《NV GTX480对ATI HD5870：另一个视角》，用DX SDK的D3D11例子来对当时巅峰的显卡进行各个单项的性能评测。时过境迁，现在NV GTX680已经上市，硬指标对比如下表所示。 GTX 680 GTX 580 制程（nm） 28 40 晶体管数量（Million） 3540 3000 Die大小（mm^2） 294 520 显存（MB） 2048 1536 SM数量 8 16 核心配比 1536:128:32 512:64:48 核心频率（MHz） 1006-1058 772 shader频率（MHz） N/A 1544 显存频率（MHz） 6008 4008 像素填充率（GP/s） 32.2 37.06 纹理填充率（GT/s） 128.8 49.41 ...

3DMark11的whitepaper里突出了用FFT实现镜头效果的方法。这里指的镜头效果包括bloom和泛光等，一般在HDR的tone mapping之前做。 传统镜头效果 Bloom是最常见的效果。一般就用一个gaussian blur完成。但那样的结果缺乏层次感，只是亮的一片。在Halo等游戏中，用了较为复杂的bloom方式。它先把HDR image做多次downsample，在每一次上都分别作gaussian blur，然后再以一定的权重混合起来，得到富有层次的bloom。 Bungie的Bloom方法，来自Lighting and Material of HALO 3 对于bloom本身这样已经基本可以了，但如果要增加更多镜头眩光的效果，比如DX SDK里HDRLighting的Star Effect，就得再增加更多的pass。而且如果blur的kernel很大的话，速 ...

AMD的OpenGL驱动问题很多，是个众所周知的事情。以前我也写过《OpenGL驱动的陷阱：ATI篇》和《OpenGL驱动的陷阱：ATI篇，后续》来阐述这个问题，当时最新的驱动是Catalyst 10.10。过了一年多的时间，AMD的驱动和KlayGE的代码都有了不少变化，情况又如何呢？ 失败的例子 在去年的驱动上，发现的问题主要有三个（ticket #58）： Deferred Rendering和Global Illumination中，GI的效果只在第一帧出现。没找到原因。 Detailed Surface和JudaTex Viewer中，纹理显示混乱。没找到原因。 GPU Particle System和Particle editor中，粒子没有显示出来。GS编译失败。 更新到Catalyst 12.1后（也可能在11.12或者11.11就更新了，我没测试） ...

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不会被优化器删 ...

上一篇分析了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硬件来说，甚至要增加 ...

Deferred Rendering在KlayGE中已经出现比较长时间了，我也写过系列文章来阐述KlayGE中的延迟渲染。在将要推出的KlayGE 4.0中，Deferred Rendering进入了渲染系统的核心，可以作为更通用更方便的一个渲染封装来使用。 在功能上，KlayGE 4.0中的Deferred Rendering也有了长足的进步。本系列将着重于解析这些新改进。 流水线 先来看看Deferred Rendering的流水线。 在流水线方面，第一个比较大的变化是，G-Buffer改成了MRT的，用类似Deferred Shading的fat G-Buffer来避免在shading pass再次渲染一遍物体。新G-Buffer的布局将在下一篇分解。在shading pass阶段，只需要渲染一个全屏quad，在每个pixel上把材质和光照信息结合就可以了 ...

[zh] 本文的目的不是为了完整地把Python 3.2移植到Android，只是希望编译出能用在自己程序里的链接库。 完成boost 1.47的移植之后，下一个目标就是Python 3.2。目前Python只有2.6.2非官方地移植到了Android（见P4A），他们迟迟不开始移植3.x，主要原因是他们认为3.x没用-_-。看来这件事情只能自己做了。由于Python 3.x和之前的版本有着巨大的区别，其难度完全不可预测。 准备工作 需要下载 Python 3.2.0 Crystax's NDK r6 Cygwin P4A configure 按照linux平台的老习惯，很多配置是写在.in文件中，需要用configure来生成出对应的.c或者.h。这里需要特别注意的是，需要让configure用NDK的工具链： ./configure --host=a ...