KlayGE游戏引擎

在压缩tangent frame一文中，我们看到了把tangent frame压缩到4个字节的方法。现在让我们看看如何压缩其他属性，以达到减小顶点数据的目的。 顶点属性 首先看看完整的顶点都包含了哪些属性： 属性 类型 大小（字节） 备注 position float3 12 texcoord float2 8 tangent float3 12 binormal float3 12 normal float3 12 blend_index uint4 16 骨骼动画模型才有 blend_weight float4 16 骨骼动画模型才有 总共 88 经过tangent frame压缩，同时一般引擎都会把blend_index和blend_weight存入uint32，顶点格式就成了： 属性 类型 大小（字 ...

最近，在KlayGE的开发版中，正式加入了MeshMLLib这个独立子库。这也是在KlayGE 4.2的计划中。顾名思义，MeshMLLib是用来与KlayGE的模型格式MeshML打交道的库。去年在计划Maya的导出插件时，就想过把3DSMax和Maya的插件后端统一，以简化插件的开发。时至今日，该目标终于完成。 MeshMLLib简介 MeshMLLib目前可以编译成.lib的库，静态链接到别的程序中。它的目标就是让程序可以很简单地生成.meshml格式的文件，以供KlayGE载入。因此插件和转换器就不需要总写重复代码，开发和测试都更加方便。 MeshML简介 MeshML是KlayGE的模型格式，基于xml。在设计上，MeshML参考了idSoftware的MD5。支持静态模型、骨骼动画，在新版本中还增加了动画压缩 ...

现代3D游戏经常会需要用到decal，子弹孔、脚印……传统的decal渲染从Quake 2时代开始就没怎么变过，通过画一个紧贴着物体的四边形来实现。问题一直很多，比如光照的不一致，z-fighting造成的闪烁，渲染状态的来回切换，等等。那么到了deferred框架中，这种情况会有所好转吗？ 有趣的是，deferred框架内实现decal不但非常容易：100行之内的代码量，不到20分钟就能完成，而且非常稳定，完全没有上述各种缺点。更有趣的是，deferred的decal被至少三组不同的人都提出过完全相同的算法，都在讨论会出现的相同问题，只是被分别叫成了不同的名字。现在看看这三组： Crytek的Jan Krassnigg在2010年于Game Engine Gems 1里的一篇文章A Deferred D ...

经过多名成员几个月的努力，KlayGE 4.1在上个月底顺利发布！与以往不同的是，在KlayGE 4.1的开发过程中，已经把一些ticket规划如KlayGE 4.2，并在六月中旬已经提前进入了开发阶段。另外，由于有了KlayMark的需求，在计划KlayGE 4.2的过程中也会有所考虑。 时间线 这里列出几个重要的时间点，以供进度参考。 2012年11月30日，feature complete：所有功能都已经完成，没完成的推迟到下一个版本。 2012年12月15日，code complete：完成所有代码，除非特殊情况，否则不能在改变接口。 2012年12月31日，release：正式发布KlayGE 4.2。 必然出现 这些特性一定会出现在KlayGE 4.2中。其中有些需求来自于KlayMark。 Volume ...

[zh] 经过KlayGE团队半年的通力合作，今天KlayGE 4.1正式发布了！这个版本主要注重性能的提升和现有功能的改进，为次世代评测软件KlayMark的开发做好准备。KlayGE 4.1的主要更新如下： 完全使用cmake工程 字体读写成为独立的库 屏幕空间反射（由王清源完成） FFT镜头效果 性能无损的立体显示 （由王锐完成） 加速全局光照（由陈顺斌完成） 碰撞检测函数（由朱晓阳协助完成） 增强了对OpenGLES的兼容 支持大气散射效果 支持SSGI Effect的JIT系统 增加了新的工具 增加了教程 3DSMax导出插件增强 从此处下载KlayGE 4.1。 KlayGE 4.1仍然使用双协议：开放源代码的GPL和封闭的KlayGE Proprietary License ...

在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核心的移植。不知道大家有没有什么办法对付这个问题。

参考了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是手绘而成，就 ...