KlayGE游戏引擎

Normal map已经在实时应用中被广泛使用了，但长期以来一直有个缺陷：无法很好地做mipmap。所以在一定的视角和距离下，会出现明显的aliasing现象。在非实时渲染中，因为sampling rate很高，对于一个pixel，积分发生在计算完shading之后，也就是 [latex]spec = \sum {\left (\frac {N_{i} \cdot H}{|N_{i}|} \right )^\alpha}[/latex] 而实时渲染的sampling rate极其有限，一般只有1，积分是在建立mipmap的时候对normal做的，shading用的是积分后的normal： [latex]spec = \left (\frac {(\sum {N_{i}}) \cdot H}{|\sum {N_{i}}|} \right )^\alpha[/latex] 很显然这两个不等价，造成了aliasing。 LEAN Mapping I3D 2010的LEAN Mapping ...

上次实现的是Per-pixel Linked Lists方法，能做到高效地在单pass内剥离多层物体，但内存消耗不可控，而且性能和每个pixel的fragment list长度很有关系。HPG 2011上intel有个改进的方法，称为Adaptive Transparency（AT），号称能在可控的内存内做到稳定的性能和高质量的OIT。于是我打算实现一下这个方法。 方法描述 AT首先从alpha blending的方程本身下手。Alpha blending需要一个迭代的过程： [latex]C_{n} = \alpha_{n} C_{n}+(1-\alpha_{n}) C_{n-1}[/latex] 透明渲染需要按照顺序，也就是因为这个迭代所致。AT引入了一个可见性函数 [latex]vis(z) = \prod_{0<z_{i}<z}(1-\alpha_{i})[/latex] 于是alpha blending方程就能重构 ...

2009年AMD在发布HD 5800的时候也发布了一个Order Independent Transparency（OIT）的demo，但只有介绍，没有多少可以参考的东西。GDC 2010上的OIT and GI using DX11 linked lists才给出了比较完整的算法细节。虽说这几年也有不少新的OIT算法出现，但作为具有标杆意义的OIT算法，Per-Pixel Linked Lists还是值得实现到KlayGE的开发版本中，以做对比。 算法 顾名思义，Per-Pixel Linked Lists的意思就是每个pixel上一个链表，存放属于该pixel的所有fragment。这种不均匀的数据结构对GPU来说是很要命的。 在Per-Pixel Linked Lists中，链表需要两个额外的buffer，一个称为fragments buffer，需要是屏幕尺寸的N倍，负责存放所有的fragment ...

如果选择了一条路，就要走到底。 前天做了第一次用C++11替代Boost的实验，用C++11的组件替换掉了很多Boost组件。这两天进行了第二次实验，对一些不能整个库替代的组件，做一些局部取代的尝试。同时，因为VC11提供了filesystem，我也测试了一下这个。 可以直接替换 Utility的result_of 唯一的区别在于boost::result_of不能作用于成员变量的指针，但KlayGE没用到这个，所以直接替换了。 稍作修改后可以替换 Filesystem MPL的if_ VC11提供了一个基于Filesystem V2的库，而Boost.Filesystem是V3，接口上有略微不同，但不难处理。这里一个额外好处是，原先在Metro下因为一些API的原因，Boost.Filesystem不能编译成功，所有用 ...

长期以来，KlayGE的很多代码都依赖于boost。（这里有个列表）。上次我提到过，随着C++11编译器和库的普及，boost中的很多东西都可以用C++11来代替。我这两天正试着在KFL中做这件事情，以下的过程中总结的经验和教训。当然，这里只涉及到KlayGE使用的boost组件，没使用到的我没做测试。所有这些替换都保证了可以通过宏来切换回boost的实现。 可以直接替换 标记了*的表示需要编译才能使用的boost组件。下同。 Array Chrono * Foreach Regex * System * Static Assert Type Traits Typeof Unordered 这些boost组件都可以直接用C++11的相应组件替换掉。Foreach、Static Assert和Typeof是语言核心提供的，需要写个宏来统 ...

时间过得真快，离上一次讨论编译期字符串Hash已经差不多2年了。上次的尝试失败了，只能产生优化期常量，没有做到编译期常量的效果。现在有了C++11，情况会不会有所改变呢？ constexpr 上次的帖子中，在回复mtlung的时候，我提到了C++0x的constexpr可能会成为救星。现在C++11的标准出来了，GCC 4.6+和Clang 3.1+也开始支持constexpr了。首先尝试宏的做法，代码和上次几乎相同： constexpr inline size_t HASH_FUNCTION(size_t seed, char ch) { return seed ^ (ch + 0x9e3779b9 + (seed << 6) + (seed >> 2)); } #define HASH_RECURSE_00(seed, str) (*(str + 1) == 0 ? HASH_FUNCTION((seed), *(str)) : HASH_RECUR ...

Surface的GPU是Tegra3，但它对应的D3D能力，在网上却很难查到。昨天我自己在Surface上执行了一下Windows Kits 8带的ARM版dxcapsviewer，dump出了这个文件。我已经去掉了Microsoft Basic Renderer Driver和WARP这两个和PC上相同的部分，就剩下Tegra3本身的。 从这个列表可以看出，Surface只能支持D3D_FEATURE_LEVEL_9_1。估计是因为Tegra3不支持完整的occlusion query，以及最大纹理只支持到了2048，必须放弃9_2和9_3。很可惜的是MRT的功能也因此被禁用了。

上次对各编译器对C++11的支持比较之后，很多观众提议加入Intel C++ Compiler（ICC）和Clang。这次修订还加入了在VC11 Nov 12 CTP中对C++11的提升。上回表中的Yes/No标识也被我改成了写明支持一个feature的最低版本号，feature的顺序也调整了一下。为了方便查询，还加入了Proposal的链接。 C++11 Core Language Features Language Feature Proposal MSVC GCC ICC Clang 替代方案 Rvalue references N2118 10.0 4.3 12.0 2.9 Boost.Move     Rvalue references for *this N2439 No No No 2.9 Initialization of class objects by rvalues N1610 9.0 4.3 11.1 2.9 Non-static data membe ...

昨晚在升级了Intel和NV的显卡驱动之后，突然发现原先在程序中启用Optimus的NvOptimusEnablement失效了。及时回滚到老的驱动，仍无法解决问题。试了多种方法之后，最终发现在NV Control Panel的Manage 3D Settings里面点一下Restore，即便在UI上看不出什么，但NvOptimusEnablement恢复了作用！之前尝试失败的朋友不妨也用这个方法试试看。

在KlayGE首次引入C++11特性之后，我顺便调研了一下个主流编译器对C++11的支持度，以便在下个版本中加入更多的C++11元素。这里还列出了在不支持的时候，可以采用的替代方案。主要参考了C++11 Features in Visual C++ 11，Status of Experimental C++0x Support in GCC 4.6，Status of Experimental C++0x Support in GCC 4.7，Boost。 C++11 Core Language Features   VC 10 VC 11 GCC 4.6 GCC 4.7 替代方案 Rvalue references Yes Yes Yes Yes Boost.Move Rvalue references for *this No No No No Non-static data member initializers No No No Yes Variadic templates No No Yes Y ...