KlayGE游戏引擎

上一篇总结了VDM、动画导入、双面材质、矢量纹理这几个新功能，本篇将概括地讲一下抗锯齿和渲染框架上的改进 SMAA 原先KlayGE里一直用的FXAA。而FXAA虽然非常快，但有个很大的问题就是会让画面整体变得模糊。而后来出现的SMAA则可以解决这个问题。这里参考的是http://iryoku.com/smaa/。 SMAA和FXAA都是MLAA的一个GPU算法，SMAA注重的是把原算法搬到GPU，FXAA注重的是把原算法的思想简化后在GPU上做的尽量快。所以两者的基本算法还是差不多的，都是通过一个像素和周围像素的信息，恢复出局部几何，确定如何AA。但SMAA的搜索更为彻底，所以不是遇到边就模糊了事。这里可以看一组对比。 这是FXAA的结果。线条不连续，模糊。 这 ...

在这里总结一下在KlayGE 4.11中对渲染的一些改进。 VDM粒子渲染 通过Variance Depth Maps的方法，粒子渲染的速度是以前的近10倍。具体内容在用VDM加速粒子渲染一文中讲解。 动画导入 这部分其实去年就由speakfool完成了雏形，现在终于有时间集成进来了。这个改进分两部分。第一个是在MeshConv工具里，加入了对骨骼动画的导入支持。可以从fbx等格式直接导入骨骼动画。第二部分是在MtlEditor里显示骨骼，作为辅助。 双面材质 原先在导入模型的时候，遇到双面材质，会生成两倍的三角形，一正一反。而现在直接支持了双面材质，遇到这样的材质，在渲染的时候关闭背面剔除，并把normal反一下。有了双面材质，树叶这样的物体就很容易 ...

其实KlayGE 4.11工程系统的改进在1月份已经完成，但一直没有时间写篇总结。现在才补上。 编译脚本 原本的编译脚本里面，只有编译器的配置。比如选择了vc140，就一定是用VS2015，选择了vc120，就一定是用VS2013。这样的系统逐渐不适应新的IDE了，因为现在的IDE往往可以搭配多个不同的编译器来使用。光指定编译器并不够明确。 在这个版本的编译脚本配置cfg_build.py里，不但可以指定编译器（通过compiler），还可以指定工程类型（通过project）。如果两者中只指定了一个，会根据默认值找到另一个。但推荐两者都指定，已达到最期望的结果。 VS2017 VS2017已经在不久前推出，这里也需要对其进行支持。这里不但需要能生成VS2017的工程文件 ...

很多跨平台游戏引擎都有统一shader的需求。比如KlayGE从建立伊始，就强调一份代码跨多个平台，shader代码也不例外。如果需要对不同平台都分别写一遍shader，那样的工作量和可维护性都很糟糕。 既然有这样的需求，就必然会在技术上遇到一个问题，如何把一份代码编译成不同API上的shader。从目前的API上，我们至少需要应对HLSL/GLSL/ESSL，以后还有Vulkan加入战团。这里就打算探讨一下跨平台shader编译的情况，希望对大家有启发意义。 过去 刚有shader高级语言的时候，Cg是几乎唯一的shader语言。后来才在D3D9时代衍生出了HLSL，再往后有了GLSL和ESSL。所以自然而然一开始都会从Cg入手。在KlayGE发展的过程中，这还分为两个阶段。 运行中 ...

圣诞节前，KlayGE 4.10刚刚发布。与此同时，新版本的开发已经开始。和以前一样，在这里公布一下KlayGE 4.11的开发计划。欢迎有兴趣、有时间加入KlayGE 4.11发阵营的朋友们继续参加。 时间线 这里列出几个重要的时间点，以供进度参考。 2017年6月7日，feature complete：所有功能都将完成，没完成的推迟到下一个版本。 2017年6月21日，code complete：完成所有代码，除非特殊情况，否则不能再改变接口。 2017年6月30日，release：正式发布KlayGE 4.11。 Ticket系统 我们会继续使用github的issues系统，大家遇到问题可以到上面提。这次还用上了github的新功能Project来管理4.11，可以更方便地看到每个ticket的进展。 必然出 ...

（这个功能本来应该是KlayGE 4.10就有的，但因为时间原因，拖过了发布时间。所以变成4.11里第一个实现的功能。） 粒子系统在游戏引擎里用得非常普遍。而粒子系统的渲染本身，却是一个不怎么快的过程。因为大量粒子会叠在屏幕上，给填充很大的压力。 加速的方向 既然是填充率的瓶颈，那显而易见的加速方法就是缩小分辨率。常见的做法是把粒子渲染到一个半分辨率的纹理上，在根据depth的分布混合到全分辨率。在KlayGE里，shadowing是就是用这个方法加速的。如果插值后的depth更接近于point采样的depth，就填充point采样的颜色，否则填充linear采样的颜色。这么做的话，大约能达到原先4倍的速度。GPU Gems 3的High-Speed, Off-Screen Parti ...

[zh]又到了12月底，首先，祝大家圣诞节和新年快乐！今天，经过6个月的研发，KlayGE 4.10正式发布了。在这个过程中，有很多用户提供了宝贵的建议和bug报告，在此表示感谢。由于时间和设备的限 制，难免有一些测试不足的情况，尽请见谅。KlayGE 4.10的主要更新如下：[/zh] [en]It's the end of December, happy holidays and new year! After 6 months' R&D, I'm glad to announce that KlayGE 4.10 is released. During this development cycle, many users provide great suggestions and bug reports. Thanks again for your help. The highlight features of KlayGE 4.10 are:[/en] [zh]引擎方面的改进[/zh][en]Improvements in engi ...

上一篇讲了tone mapping的改进。作为引擎的一个长期议题，优化是不可缺少的。本篇就讲讲在4.10中引入的新优化。 CPU端 在profiler里看到的占据CPU耗用第一名的一直是驱动。原先一直没在意这个，前一阵自己看了一下，发现前几位的好几个都是在SceneManager里，而且都和渲染队列相关。具体情况是，在每一帧确定渲染队列的时候，会执行一遍这样的步骤： 扫描一遍场景里的所有SceneObject，根据它的Renderable的类型建立一个从Renderable到SceneObject列表的unordered_map，每个物体作为那个Renderable的instance 把unordered_map中的Renderable建立一个队列 渲染这个队列 销毁unordered_map 所以其实这里的unordered_map只是 ...

上一篇讲了新的材质系统。本篇将讲tone mapping的改进。 Tone mapping的进化 KlayGE早在2006年的时候就引入了HDR的流水线。和当年的其他引擎一样，HDR的内容经过渲染，需要通过tone mapping转成LDR之后送去显示。这时候，tone mapping的质量就可以决定最后的画面细节度和对比度。 在KlayGE的发展过程中，tone mapping这个看似简单的步骤经历了多次进化。 Reinhard 早期的普遍做法是一篇叫做Photographic Tone Reproduction for Digital Images的论文，大家就用作者的名字称它为Reinhard tone mapping。这是个经验公式，把HDR到LDR的变换简单的描述了出来。 float3 ReinhardToneMapping(float3 color, float adapted_lum) { con ...

好久没写这样的系列了，上一次总结渲染的改进，还是4.5的时候。最近，又对KlayGE的渲染做了一些系统性的修改，所以在这里总结一下。 材质系统 原先的材质系统里，diffuse颜色和specular颜色是分开的。要放到GBuffer里的时候，specular颜色就剩下亮度，之后跟光的亮度操作后，从diffuse的颜色恢复出specular颜色。这只是一个情非得已的hack，因为G-Buffer里只有4个通道可供使用，放不下diffuse和specular颜色。 2015年的Physics and Math of Shading里，详细分析了导体、绝缘体、半导体的diffuse和specular分布，得到的结论是，只需要有个albedo的颜色（3通道）以及一个metalness（1通道），就已经足够。因为导体的diffuse是0，绝缘体的s ...