KlayGE游戏引擎

在KlayGE开发版中，deferred rendering的流水线中新增加了由组员王清源实现的屏幕空间反射（Screen Space Reflection，SSR），也称为Real Time Local Reflections。 反射对rasterizer来说是非常郁闷的，一般只能是平面反射或者cubemap的环境反射，并且需要多次渲染场景。对于非平面物体，可能性之一是使用Real-time Multi-perspective Rendering on Graphics Hardware的方法，把场景中的所有三角形通过非线性映射重新投射到反射物体上。这样的方法仍需要多次渲染场景，而且pixel shader开销巨大。相反，对于ray tracing来说，反射是个非常直接的事情，只要多算一次求交就可以了。 SSR就是借用了ray tracing的思想，对于每个要反射的pix ...

大气散射是日常生活中天天能见到的现象。由于大气的厚度、密度和微尘的影响，大气散射不但会在亮度，还会在频谱上产生丰富的变化（雷利散射）。最明显的是蓝色的天空和金黄的夕阳。 近几年的游戏（尤其是有太空镜头的）也开始试着表现大气散射的效果了。由于存在各种各样的变化，如果完全靠手调，工作量很大。所以各种自动计算的方法油然而生。比较有影响力的有GPU Gems 2第 16章的Accurate Atmospheric Scattering。它用视线穿越大气的厚度来直接计算散射，不需要预计算，但效果集中在单方向单次散射。接着就出现了Precomputed Atmospheric Scattering，通过预计算的4D table来表达不同视线方向接收到的散射频谱。可以处理单次和多次散射 ...

经过两天的努力，手写的ResizeTexture已经取代了D3DX11LoadTextureFromTexture和D3DX11FilterTexture，成功地去掉了所有D3DX的依赖（去掉的原因在此）。同样，原先glu里面我也只用到了gluScaleImage，现在也被替换了。 另一个改动是把D3DReflect的调用彻底挪到了shader JIT中。这样不但提高了载入速度，还去掉了运行期对D3DCompiler_xx.dll的依赖。 现在的KlayGE离Metro-ready越来越近。Windows的ARM版不能完全支持所有传统的Windows API，仍然需要对程序做一些改动才能支持。目前的障碍在于由于ARM没有注册表相关的函数，Python无法顺利地通过VC11编译成ARM版。影响了KlayGE核心的移植。不知道大家有没有什么办法对付这个问题。

自从DX9 SDK提供了D3DX的库之后，相信D3DX一度成了所有相关开发人员必不可少的库。但随着时间的发展，D3DX慢慢被拆散、重组，出现了XNAMath、DirectXTex、D3DCompile之类独立的组件，逐渐取代了D3DX的功能。 现在，DX SDK早已不再更新，被合并到了Windows SDK中。D3DX也彻底退休。虽然你仍可以通过使用DX SDK June 2010来支持D3DX，但Metro风格的新程序就没法那么做了。所以，从现在开始应该逐步减少对D3DX的依赖。 在KlayGE中，出于可移植的原因，从多年前就开始减少使用D3DX了。最先是用自己实现的模板数学库MathLib代替了D3DX Math，接着D3DXEffect这种重量型的框架也被自己实现的更高效的特效管理系统所取代。关于字体渲染，我就不 ...

参考了google的C++风格指南之后，我也照着写出了一份KlayGE C++代码风格指南。主要方针和google的类似，但有几处理念上的区别： 允许使用异常，但仅仅用来抛出错误 在必要的时候允许小心地使用RTTI const在所修饰类型的右边 可以任意使用boost的库 优先使用stream，而不是printf 有兴趣的朋友可以参考一下。目前只有英文版，中文版正在翻译中，近期将会问世。

多年前就想为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 ...