KlayGE游戏引擎

多年前就想为KlayGE做个Normal2Height的工具，一直没时间，现在终于抽空把它完成了。 缘由 Normal map的来源有多种。游戏开发中常规的做法是根据高模和低模的位置对应关系生成height map，然后用height map生成normal map。这种情况下不必担心是否能得到高精度的height map。但很多低端的做法是让美术直接画normal map，根本没有高模。随着游戏渲染水平的提高，normal mapping（NM）这种1970年代的技术已经不能满足需要了，越来越多的游戏开始过渡到更精确的parallax mapping（PM）、parallax occlusion mapping（POM）甚至displacement mapping（DM）。他们除了normal map，还需要有height map才能工作。所以如果normal map是手绘而成，就 ...

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

AMD在7900系列显卡发布的时候同时推出了Leo demo，并说明它不是用近年流行的Deferred框架渲染完成，而是用到了一种叫Forward+的框架。这个框架不需要Deferred的大带宽要求，却仍能实时渲染上千光源。EG2012上有篇新paper叫做Forward+: Bringing Deferred Lighting to the Next Level，讲述的就是这个方法。但目前作者还没有放出该论文的全文，这里我只能通过只言片语和AMD的文档来解析这个神奇的Forward+。 Tiled-based Deferred Shading 在进入正题之前，我们先回顾一下Intel在SIGGRAPH Courses 2010里提到的Tiled-based Deferred Shading。它的算法框架是： 生成G-Buffer，这一步和传统deferred shading一样。 把G-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 ...

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

这几天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、编译和安装的任 ...