Skip to content

Archive

Category: KlayGE
其实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 ...
每一次KlayGE新版本的开发初始,都会花一定的时间改进工程系统,会让新版本的开发和使用更为顺利。目前这一步已经基本完成,在这里写个帖子总结一下。 支持NDK r12 对NDK的支持升级到了新的r12。这里包括把android-cmake更新到最新代码,并可以用clang来把KlayGE编译成android版。因为NDK在慢慢去掉对gcc的支持,gcc的版本停留在了4.9。所以以后也将不再支持用gcc编译KlayGE的android版,转向clang。 用clang的好处之一是,链接速度快了无数倍。 GCC 5.1+ 对于其他平台,仍然可以使用gcc编译。但现在要求gcc 5.1以上。这么做省去了很多为了老版本的gcc而作的兼容,尤其是C++11/14的部分。降低了维护开销。这么一来,gcc和clang下,都 ...
上个星期,KlayGE 4.9刚刚发布。几乎与此同时,新版本的开发已经开始。和以前一样,我会在这里公布KlayGE 4.10的开发计划。欢迎有兴趣、有时间加入KlayGE 4.10开发阵营的朋友们继续参加。同时,4.10的开发流程有一些小的调整,也会在本帖中说明。 时间线 这里列出几个重要的时间点,以供进度参考。 2016年12月7日,feature complete:所有功能都已经完成,没完成的推迟到下一个版本。 2016年12月21日,code complete:完成所有代码,除非特殊情况,否则不能再改变接口。 2016年12月31日,release:正式发布KlayGE 4.10。 比起以前的开发周期,feature complete和code complete往后推迟了一周。因为这几个版本的开发中,测试 ...