KlayGE游戏引擎

一年半之前，在开发KlayGE 4.0的时候，郭鹏就已经设计了一个资源载入系统，可以解决异步载入和重复载入的问题。但我只是实现了一个很粗略的异步载入。随着场景复杂度的需求越来越高，一个完善的资源载入系统也就成为必需。顺着之前的设计思路，我最近终于完成了实现。 目标 KlayGE的资源载入系统有几个设计要求： 至少支持Texture、Model、Effect、Font和Post Processor这五种资源，并能快速扩展支持新的资源。 可以选择同步或异步载入。 不重复载入资源，以减少浪费。 自动化管理，不需要手动指定资源ID，尽量不需要显式删除。 资源不需要单根继承。 异步无阻塞载入。 之前的ResLoader能支持2，4和5，部分支持1，并以很 ...

经过前两次实验，大部分C++11里有的boost组件都被替换成了C++11中相应的。剩下的还有random库和bind/function/mem_fn/ref/smart_ptr这一组。看来，到了不得不改代码的时候了。 random 在第一次实验里提到过，random虽然在boost和C++11都有，但接口不相同，所以原先我用Boost.Random实现的代码，无法直接替换成C++11的。翻了一遍boost文档，发现现在的boost其实有实现了一套名字和C++11相同的组件，于是我重写了所有用到random的地方，用和C++11兼容的代码，就解决了这个问题。好在random用得不多，改几个地方就都好了。 bind/function/mem_fn/ref/smart_ptr 这几个组件相互依赖，要么全换，要么不换。再加上牵扯面非常广，修改起来几乎都 ...

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

从Android SDK R17开始，模拟器就支持OpenGL ES 2。如果能让KlayGE在模拟器上跑起来，开发和测试就能方便许多。于是我装了最新的R21和Android 2.1的ARM v7a的镜像，经过几个小时的努力，终于成功执行了一些原来能在Android x86 2.3上跑的简单例子。途中发现了一些小陷阱，这里总结一下。 屏幕宽高 原先我的做法是通过ANativeWindow_lock获得buffer，再拿buffer的width和height。在ICS上，这么做会导致后面eglCreateWindowSurface失败。原因似乎是ANativeWindow_lock之后这个窗口就被连到2D API，那么在eglCreateWindowSurface的时候就会说那个窗口已经被别的API连接了。即便是ANativeWindow_unlockAndPost也没用。解决方法是改成用ANativeW ...

如果选择了一条路，就要走到底。 前天做了第一次用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是语言核心提供的，需要写个宏来统 ...

随着KlayGE的发展，逐渐出现了glloader、kfont、MeshMLLib等多个子库。这几个子库原本是完全独立的，但这样难免出现很多重复代码。受到Salvia的eflib和MFC的启发，在KlayGE的开发版本中加入了称为KlayGE Foundation Library的公共库，简称KFL。（不能叫KFC了，这个名字满大街都是） KFL包括了一些平台/编译器检测的宏、类型定义、数学库、线程、Log记录、XML读写等常用代码，能用极大地减少几个子库之间的重复，减轻维护和开发的负担。KFL不依赖于KlayGE的其他任何部分，所以甚至别的项目也可以利用到它。 KFL目前存在于开发版本中，将会随着KlayGE 4.3一起发布。

经过多名成员几个月的努力，KlayGE 4.2在上周顺利发布！和上一个版本相同，在KlayGE 4.2的开发过程中，已经把一些ticket规划入KlayGE 4.3，并在十二月中旬已经提前进入了开发阶段。 时间线 这里列出几个重要的时间点，以供进度参考。 2013年5月31日，feature complete：所有功能都已经完成，没完成的推迟到下一个版本。 2013年6月15日，code complete：完成所有代码，除非特殊情况，否则不能在改变接口。 2013年6月30日，release：正式发布KlayGE 4.3。 必然出现 这些特性一定会出现在KlayGE 4.3中。其中有些需求来自于KlayMark。 Script plugin LEAN mapping Build by official Android NDK Improved deferred rend ...