KlayGE游戏引擎

在OpenGL 4.3发布的同时，Khronos同时宣布了OpenGL ES 3.0。由于从OpenGL 3.3和4.2里吸取了大量内容，OpenGL ES 3.0给移动平台带来了许多原本只有桌面才有的功能。其中包括： 对渲染流水线的多项增强，用于加速高级视觉效果：遮挡查询、transform feedback、instanced rendering和支持4个或更多render target。 高质量的ETC2 / EAC纹理压缩成为标准，这样就不再需要给每个平台不同格式的纹理。 新版本的GLSL ES shading language，完整地支持整数和32位浮点操作。 极大地增强了纹理功能，包括保证支持浮点纹理、3D纹理、深度纹理、顶点纹理、NPOT纹理、R/RG纹理、固定纹理、2D纹理数组、通道交换、LOD和mip level钳制、无缝cube ma ...

在SIGGRAPH 2012上，Khronos发布了OpenGL 4.3的spec，其中最主要的更新就是增加了compute shader！这里有spec的链接： OpenGL 4.3 Core Profile Specification (updated August 6, 2012) OpenGL Shading Language 4.30.6 Specification (updated August 3, 2012) 扩展的更新列表包括： GL_ARB_arrays_of_arrays：允许在GLSL中使用多维数组，比如float f[4][3]。 GL_ARB_ES3_compatibility：提供了EAC和ETC2纹理压缩格式。 GL_ARB_clear_buffer_object：用一个常量来清除buffer object。 GL_ARB_compute_shader：引入了一个新的shader stage，类似于D3D11的compute shader。 GL_ARB_copy_image：在纹理和渲染缓冲区之间 ...

在The Valve Linux Team的博客上看到他们把Left 4 Dead 2移植到Linux，并通过一定的优化，使得速度神奇般地超过了Windows OpenGL和Windows D3D（315 FPS vs 303.4 FPS vs 270.6 FPS）。原文在这里。他们还分析了Windows上OpenGL和D3D的性能差异，结论是在每个batch，OpenGL驱动都比D3D少了一个几毫秒开销。 不过这里比较的应该是D3D9，如果用D3D11的话情况可能会有所区别。毕竟，D3D11的调用开销远小于D3D9，API call的数量也少得多。

经过多名成员几个月的努力，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核心的移植。不知道大家有没有什么办法对付这个问题。

自从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 有兴趣的朋友可以参考一下。目前只有英文版，中文版正在翻译中，近期将会问世。