KlayGE游戏引擎

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很大的话，速 ...

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

via http://www.iguanademos.com/Jare/wp/?p=2583. Thanks 凃鸣 to forward me the link. Another Game Developers Conference I miss, but I’ll try to track as many presentations as I can: GlassBox, the new SimCity simulation engine Good, Bad, Great Design by Raph Koster The 5 Domains of Play by Jason VandenBerghe Core Games, Real Numbers by Kongregate Math for Game Programmers: Dual Numbers and Physics for Game Programmers: Collision Detection by Gino van den Bergen The Dysfunctional Three-Way rant by Chris Hecker Cutting the Pipe: Achieving Sub-Second Iteration Times by Niklas F ...

昨天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格式原地满血复活。 ...

在越来越多的人讨论Cg存留问题的时候，Cg 3.1突然发布了。主要的改进有： Cg语言支持uniform buffer。 增加了OpenGL Unified Buffer Object（UBO）。 增加了翻译成OpenGL GLSL version 110和120的支持。 新的tessellation例子。 新的uniform buffer例子。 各个例子都加上了VC10的工程文件。 不知道NV怎么了，给出来的下载链接居然是错误的。正确的是http://http.developer.nvidia.com/Cg/cg_3_1_0010.html，有兴趣的朋友可以看看。

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