KlayGE游戏引擎

CPUWizard是我97年刚开始用C++的时候写的一个CPU检测和降温软件。完成功能之后就基本没有动过，除了2001年的时候加上一些对新CPU支持。有感于没找到一个CPU-Z的开源替代，同时CPUID SDK又得卖几千欧元的天价，我决定复活CPUWizard，并在近期作为GPL发布。 当然，十多年过去了，当时用的还是VC4.2或者VC5，内含大量汇编。现在虽然能直接编译，但CPU降温的部分已经失效（in/out/hlt这些指令在NT内核上必须ring 0才能执行），而且已经失去意义。所以复活后的版本就主打CPU检测的功能。同时还会做很多现代化的改造： 分为SDK和UI两层 cmake的项目文件，跨平台的代码，去掉汇编 支持现代的CPU 检测结果可以云存储  

IE 10 for Windows 7在发布的时候，包含了一个补丁KB 2670838，给Win7带来了DirectX 11.1和DXGI 1.2的部分能力。这个补丁也可以在不需要IE10的时候单独安装。详细的更新内容在这里。比较有意思的是，WARP被升级到支持feature level 11.1了。 很遗憾的是，如果装了KB 2670838，PIX for Windows和D3D11_CREATE_DEVICE_DEBUG会受影响，因为DirectX SDK (June 2010)的debug runtime和KB 2670838不兼容。解决方法是安装Windows 8.0 SDK standalone，或者升级到使用Win8 SDK的VS 2012 Update 2。

继前不久放出了一批3D模型之后，我进一步整理了几个模型。有兴趣的话仍然可以到这里下载。

长期以来，KlayGE一直是单独执行的，窗口上的UI也都是自己画。很多人都提到这么做给编辑器等应用造成了困难。所以如果适度修改KlayGE的窗口系统，使得KlayGE可以嵌入其他的GUI框架，比如MFC、QT、WPF等，有些时候会方便得多。 第一个尝试做这件事情，并且取得成功的在这里。他通过修改Window类，支持从外部传入HWND，让KlayGE复用外部建立的窗口。这么做能顺利地把KlayGE嵌入MFC等框架中。同时，作者也指出了单独这么改仍不能达到完美的程度，“并且由于KlayGE没有开放单独绘制一桢这样的函数，所以直接关闭程序会有内存泄漏和异常。以后再研究研究，试着把相关功能提取一下，做成和Ogre一样的，那样就可以在OnIdle()和OnPaint()时渲染一桢 ...

可以自由使用的3D模型很少，高质量的就更少了。我打算把长期以来收集到的模型逐步共享出来，希望大家能相互交流。 有兴趣的朋友可以到这里下载。未来还会有越来越多的模型放出来。

本系列的前三篇讲的都是关于Deferred Rendering的改进，本篇会专注于流水线后端的Post Process。 Post Process链 在KlayGE的渲染流水线里，不管用不用deferred，post process链是都会执行的。完整的post process链由一系列单独的post process组成，流程如下图所示。 前三个属于HDR的，经过tone mapping转成LDR之后，又经过三次post process，得到渲染结果。如果开了stereo，就会被stereoscopic的post process处理成立体的。 不管是用CUDA里的GPU kernel launch还是用图形API里的Draw Call来启动一个GPU任务，常见的改进规则都是，如果某次GPU任务不依赖于上次任务的其他单元，就应该和上次任务合并起来。这样可以省去GPU写入和读 ...

上一篇提到了在视口间共享shadow map的优化，以及对代码的重构。重构中的一个小发现造就了在不增加存储占用的情况下，就能支持透明物体的渲染。 透明物体和Deep G-Buffer 在透明的烦恼一文中，为了用纯Deferred的框架解决透明物体渲染的问题，KlayGE引入了Deep G-Buffer的方法。对不透明物体、透明物体的背面、透明物体的正面分为三个G-Buffer layer，分别有一条Deferred流水线，最终通过alpha把三层blend成最终结果。这种方法虽然能简单有效地解决问题，并避免繁琐的forward流水线，但需要三倍的存储和带宽。而且如果depth peeling的层数增加，开销还会进一步加大。最近出现的几种OIT方法，都不兼容于deferred。所以如果不用forward，就得 ...

上一篇讲到了把GI系统从Deferred Rendering框架中分离出来，以降低耦合度。本篇会涉及到一个共享shadow map、提高性能的改进。 多视口的改进 多视口的特性是KlayGE 4.2引入的。Deferred rendering layer支持通过多个视口生成多个渲染结果，可以用于分屏、反射、缩略图等情景。原先每个视口都是完全独立渲染的，互相不共享任何东西。实际上spot light和point light的shadow map是view independent的，不会因为视点不同而改变，就应该在视口间共享。 于是开发团队成员李渊完成了这个任务，把shadow map的生成提前到所有视口的G-Buffer之前。也就是说，原先的流水线是： for each view port: generate g-buffer. for each shado ...

从KlayGE 4.0确定了Deferred Rendering的框架以来，每个版本都有一些小改进。在正在开发的4.3里，多个改进经过这几个版本的融会贯通，产生了一些新的变化。这里做个系列总结一下。 GI和Deferred的分离 最早提到这个问题的是团队成员陈顺斌。他在去年就提出Deferred rendering layer太过复杂，应该把相对独立的GI拆出去。当时我的想法是，Deferred和MRSIL GI（Multiresolution splatting for indirect lighting）在逻辑上关联甚大，应该是一体的。后来实现了SSGI，也放在Deferred框架内，复杂度进一步增加。Deferred也成了个带有多种GI方法的怪物，各个组件之间的耦合度很高。 在分析了MRSIL、SSGI以及未来可能支持的SVO等多种GI方法之后 ...

上一篇提到了PSSM的方法，及其它的两个缺点。I3D2011上的Sample Distribution Shadow Maps可以用很低的代价同时解决掉那些缺点，在最大程度上优化shadow map上sample的分布。 SDSM PSSM的那两个缺点实际上都来自于同一个根源：光锥区域是根据视锥的大小，而不是可见pixel的范围来调整。这里所说的pixel范围涉及到两个方面。第一是pixel在view space的深度范围，这会影响区域的划分。另一个是pixel投影到light space的坐标范围，这影响到scale和bias的计算。很显然最佳情况是，shadow map的sample分布在所有可见pixel上，其他地方不浪费。而这两个方面都可以很简单地通过场景的depth texture得到。 原论文提到了多种sample distribution ...