KlayGE游戏引擎

FFT镜头效果已经完成，并集成入KlayGE开发版中，命名为FFTLensEffectPostProcess。除此之外，还写了一个命令行工具，用于产生镜头效果的纹理。虽然FFT的方法能在一个pass内产生各种复杂的镜头效果，但目前性能低于默认的多重gaussian blur。其中最主要的开销来自于FFT本身，下面就着重就讨论一下GPU FFT的进展和未来。 前不久我在用Pixel Shader实现FFT的时候，提到了用Compute Shader来实现FFT效率可以更高。之前Ocean的例子里就有用于实现波浪模拟的CS4 FFT（从NV的例子改进而成），它的输入和输出是1D Buffer的形式。为了更通用，在进入KlayGE核心的时候改成了2D Texture的形式。可惜的是，CS4不能写入纹理，就需要增加一个把Buffer转 ...

上周末把GPU Gems 2里的GPU FFT在KlayGE里实现了一下，经过优化和调整，昨晚已经进入KlayGE的开发版本中。完整的FFT Lens Effects也会很快集成进去。 这里用到的是那篇文章中提到的方法1，因为经过测试，方法2在现代GPU上速度不如方法1。我做的改进是把原来的3张查找表合并成1张，并都用16F而不是32F的格式保存输入输出数据。在GTX580上，512x512的数据量，PS版本的FFT花费0.94ms左右，能达到CPU FFTW的75倍速度。但即便如此，对于lens effect那样的应用来说还是有点慢。所以接下去考虑用Compute Shader来实现FFT，pass数会减少到1/3。PS每次处理2个数，512x512需要log(512) + log(512) = 18个pass；CS每次可以处理8个数，所以只要6个pass ...

这几天KlayGE更新变少，主要是在做ScenePlayer。正如其名，Scene Player的作用是把场景描述文件的内容“播放”出来。目前场景描述文件是手工写的，以后会用Scene Editor来生成。 ScenePlayer初始版本在原有Deferred Rendering的框架上加入了脚本驱动的系统，可以完全通过Python脚本来控制灯、摄像机、物体的运动。也顺便加入了projective texture的支持。现在已经有多个例子可以通过场景描述文件在ScenePlayer中执行了。

昨天glloader和kfont改用CMake之后，KlayGE也删除了vc9和vc10的工程文件，改用CMake为主。由于第三方库的源代码也都内含在KlayGE中，王锐的cmake脚本简化得多了，不需要那些寻找模块的过程，直接使用相对路径来设置。一站式编译脚本build_all.py也修改为使用新的cmake来生成IDE工程文件和编译。 注意，在安装cmake的时候需要选择把cmake的目录加入系统PATH。

在KlayGE 3.12里，王锐提供了KlayGE和glloader的cmake工程脚本。但原先手动生成的工程文件仍然存在。比如，glloader提供了cmake、vc9、vc10、codelite和android的工程文件；kfont提供了cmake、vc10和android的。随着时间的发展，IDE越来越多（比如VS11 Beta的发布），维护多种工程文件的负担也随之增多。况且cmake就是用来生成多种IDE的工程文件的。 在最新的开发版本里，glloader和kfont的cmake脚本得到加强，足以取代vc9和vc10的工程文件（很多是从空明的Salvia里借鉴来的）。于是，cmake成为首选的工程文件而继续维护，vc9和vc10的都被删掉了。另外增加了build_glloader.py和build_kfont.py，直接运行就可以完成cmake、编译和安装的任 ...

老用户一定记得，在KlayGE 3.9之前，用来表示effect的.fxml都需要通过一个python写成的编译器进行离线编译，生成.kfx格式才能给runtime使用。在3.9里引入了rapidxml，可以直接在runtime读取xml文件，流程变短，开发效率提高了。但随着这两年shader越写越复杂，编译shader所花的时间越来越多，在载入的时候每次都编译shader，一来浪费时间，二来浪费计算。 KlayGE的模型格式.meshml也有过这样的问题，后来通过一个JIT在载入的时候动态把xml的.meshml编译成二进制的.model_bin，之后的载入速度就极大提高了。既不需要离线编译，也不用担心读取效率。因此，引入一个effect JIT也成了理所当然的事情。所以，事隔多年后，kfx格式原地满血复活。 ...

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就更新了，我没测试） ...

从KlayGE 4.0开始，不但有为了下一版本开发的短期任务，还有一些中长期研发的任务。其中之一就是HLSL bytecode to GLSL编译器。现在KlayGE里的shader主要由HLSL写成，通过#ifdef的土办法兼容Cg。对D3D11来说可以直接使用，但对于OpenGL和OpenGL ES 2就得大费周折了。那种情况下，shader需要经过Cg编译器编译成传统的GLSL，在经过我自己的token级别的编译器转换成现代的GLSL，然后才能使用。 为什么不直接用Cg？看看Cg runtime在ATI卡上的表现吧。 为什么不用传统的GLSL？NV的驱动有一套attribute和index之间的绑定规则，比如gl_Position一定是0，gl_Normal一定是6（或者某个数，但是个常量），而且无法通过API来获取预定义attribute的i ...

[zh] 经过长时间的筹划，今天正式宣布开始次世代评测软件KlayMark的开发。 简介 KlayMark将以KlayGE为引擎，定位为一款集各种先进渲染技术于一身的跨平台评测软件。在提供赏心悦目的画面同时，对系统的性能作出综合评价。不论是PC平台还是移动平台，KlayMark将提供统一的计分方式，使得不同平台之间的得分具有可比性。 虽然动用到许多新技术，但KlayMark仍会保持极高的效率、较低的配置、良好的跨平台能力等特点。 发布计划 KlayMark的源代码将迟于二进制版本发布，类似Doom和Quake的方法。 由于平台的差异，KlayMark 1.0的发布将分拨进行。 Wave 1：预计开发周期1年。Windows平台支持D3D10+和OpenGL，Android平台支持Tegra ...

独具特色的KlayGE字体系统现在可以独立使用啦！ 在开发版本中，字体系统KFont成为了一个不依赖于KlayGE主体的子项目。目前包含的功能有.kfont格式的读写。未来可能加入字体转换工具和渲染代码生成。