KlayGE游戏引擎

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 ...

[zh] 在PC上的C++开发中，boost已经很普遍。但对于Android这样的移动平台呢？由于KlayGE正在移植Android，作为依赖库之一的boost也必须移植过去。官方的boost并没有提供Android支持，看来得自己做了。 受MysticTreeGames的Boost-for-Android启发，我想用最新的Crystax NDK来编译boost 1.47。 准备工作 需要下载 boost 1.47 Crystax's NDK r6 MysticTreeGames的Boost-for-Android 补丁 首先，MysticTreeGames的补丁是基于boost 1.45和官方的NDK r5，在最新版上不一定能完美运作。因为有些源文件在1.45到1.47的过程中更改了，无法自动打上补丁。所以我手工地在原始的boost 1.47上根据补丁进行修改。其实不太难，因为只有12 ...

上文介绍了D3D11的两个重要特性compute shader和multi-threaded，本篇专注于两个不能在D3D10硬件上使用的、纯D3D11的新特性tessellation和BC6H/BC7纹理压缩。 Tessellation 很 多人会说D3D11增加了tessellation shader这个stage，但真相是增加了hull shader、tessellator和domain shader三个stage。Hull shader的输入是patch的控制点（三角形、四边形这样的图元，最多有32个控制点），计算出tessellation等级、确定 tessellation的方法等。它的输出被送给固定单元的tessellation进行细分。Domain shader的输入是细分后的bary centric坐标、来自hull shader的控制点，它负责计算插值后的顶点坐标。 Tessellation早就存在于一些GPU。 D3D9 ...