Skip to content
前不久有人问我是否把版本控制考虑转移到git的事情,其实我在2013年就写过一篇从hg导入git的方法和坑,里面给出了转移的实验,但没有具体计划。已经1年多过去了,git的工具和工作流也慢慢成熟。虽然git仍有一些基础上的缺点,比如无法进行文件改名以及轻易就可以改变历史记录,但由于有submodule和轻量的分支,再加上github的发展,从用户采纳程度来看,在git和hg的竞争中,git已经胜利。是时候再次考虑这个问题了。 需要注意的是,目前KlayGE的hg repository已经超过500M,初次pull的速度很慢,每次push的性能也受其影响。如果能在转移到git的过程中解决这个问题,这样的转移才有意义。否则只是换汤不换药。 几个选择 转移到git有多种 ...
OSX版本完成之后,下一步就是iOS。 在之前的实现中,OSX的程序框架和别的平台很不一样,给维护和效率带来了一些麻烦。现在钱康来对OSX的进一步改进是,按照SDL2的方法,实现一个自己的消息循环。这么一来,程序主体和其他平台的结构达成了一致。同时,这个方法对iOS也有好处。于是在很短的时间内,KlayGE就已经完成了iOS的移植。目前,一些简单的例子已经可以运行,但诸如Deferred rendering框架这样的复杂情况,还有些问题。在iPad2等老的GLES2设备上,由于无法渲染到纹理的0层之外的mipmap level,建立multi resolution的时候失败了。GLES3设备上出错原因正待查明。 至此,KlayGE已经可以在Windows、Linux、MacOSX、Android、Windows ...
最近,钱康来的实验把KlayGE移植到了OSX平台上。在上一次更新中,绝大部分问题已经解决。现在,我高兴地宣布,所有的例子都已经可以在OSX上顺利执行,并都能得到正确的结果。至此,OSX版本已经完成。 另外,iOS版本也已经有了很好的进展,一些基本的例子已经可以执行。下一阶段,我们将进一步改进OSX和iOS的框架,按照SDL2的方法,调用Apple平台底层的函数,实现一个自己的消息循环,而不是把一切都交给Apple的程序框架。这样一来,程序主体可以接近其他平台的结构。性能优化等也会比较容易。
前几天,KlayGE 4.6刚刚发布,现在新版本的开发已经开始了。这里公布一下我对KlayGE 4.7的一些计划。和以前一样,欢迎有兴趣、有时间加入KlayGE 4.7开发阵营的朋友们继续参加。 KlayGE 4.7将会更加高效,并继续发展移动平台的支持。 时间线 这里列出几个重要的时间点,以供进度参考。 2015年5月31日,feature complete:所有功能都已经完成,没完成的推迟到下一个版本。 2015年6月15日,code complete:完成所有代码,除非特殊情况,否则不能在改变接口。 2015年6月30日,release:正式发布KlayGE 4.7。 必然出现 这些特性一定会出现在KlayGE 4.7中。其中有些需求来自于KlayMark。 Transient Buffer。高效buffer管理 ...
在KlayGE走上OSX的实验中,我提到了目前OSX的版本还有两个主要问题,一是没法打开post processing,而是shader编译用的是Cg,以至于不能支持GL3+的功能。钱康来这几天又做了一些实验,在很大程度上解决了这些问题。 Post processing 原先一打开HDR、FXAA、Gamma校正等流水线末端的post processing之后,只能看到黑屏或一片混乱。在xcode的调试中看到的是,back buffer中有正确的结果,但swap到front buffer就只有错误的画面。这就排出了是depth或stencil没用清空造成的错误,只能是swap的地方有什么蹊跷。 经过一番尝试和查阅资料,发现了OSX和其他平台在swap上有所不同。Windows上的SwapBuffers,以及Linux上的glXSwapBuffers,都可以 ...
[zh] 大家圣诞快乐!又到了KlayGE的发布周期。今天,KlayGE 4.6正式发布了!这个版本创造了很多个第一次,下面会给予逐个列出。在这个版本的开发中,我因为一些个人原因,投入的时间比以往有所减少。幸运的是,由于有了一次新的开发人员招募,新老成员完成了不少组件,同时也有很多朋友提供了宝贵意见和bug报告,在此表示感谢。KlayGE 4.6的主要更新如下: 引擎方面的改进 现代化OpenGL,由刘瀚阳协助完成。增加uniform buffer、debug output等OpenGL 3.x的特性。OpenGLES插件也会做相应修改。 改进的DXBC2GLSL。林胜华进一步增强了DXBC2GLSL,增加了HS/DS/CS的支持。 支持最新的OpenGL 4.5。 改进OpenGL在AMD和Intel显卡上 ...
长期以来,把KlayGE移植到iOS的呼声很高。从别的平台直接移植到iOS,跨度有点大。所以我的计划里把MacOSX当作一个中间平台,先移植到OSX,把OSX当作开发平台来开发iOS版本。现在,KlayGE的OSX版本有些进展,在这里总结一下。 OSX几乎完全由新加入的组员钱康来完成的,在此表示感谢。这也是第一次不是由我亲自完成的平台移植。除了需要对付平台API的差异之外,还需要把一部分窗口相关代码用ObjC完成,在通过跨语言调用接入引擎的其他部分。目前有些初步的结果,在不加上post processing的情况下,一些sample可以顺利执行了。post processing一加就黑屏,具体原因正在调查中。 下面是一些结果。 除了post processing,还有 ...
不久以前,KlayGE附带的boost破例升级到了1.56.0。随着boost的开发进度重回正轨,1.57又如期发布了。所以KlayGE第三方库的boost再次回到传统的只更新单数版本的规则。 在boost 1.57之前,any用的是C++原生的typeid,在使用的时候必须打开编译器的RTTI。于是我提交了一个补丁,让any使用Boost.Core中的一个替代typeinfo。由于现在有了更完善的Boost.TypeIndex,any可以直接使用它。这样就能在不打开RTTI的情况下使用any。再加上1.57更好地兼容了WinRT和Android,原先很多修改变得不必要了。这么一来,要在KlayGE支持的所有平台上都使用boost,需要修改的地方前所未有地少了。 接下去我还打算把Boost.SmartPtr等地方用到typeid的也都改成 ...
面光源一直是实时渲染的一大难点。原先所有实时渲染中都只敢用点光源(spot光源也是从一个点发射出来的,在这里也算做点光源)。直到这两年,软硬件水平逐步提高了之后,面光源的实时近似才慢慢变得实用起来。 面光源的难处 从ray tracing的角度来说,在计算一个点的光照时,需要根据BRDF沿着反射方向发出多根光线,每一根都需要与光源求交。如果是点光源,那么只要计算一个点和射线求交。如果是个有体积的物体,求交就比较麻烦了,并且需要发射出更多的光线才能逼近真实效果。 在实时渲染中,光照的计算可以分为两部分。第一是来自光源的贡献。点光源可以用常见的光照模型进行计算,最近流行的基于物理的渲染,前提之一就是光源为点光 ...
去年我曾经尝试过把KlayGE嵌入其他GUI框架,当时试验的是MFC。现在,为了更方便地使用和开发GUI部分,我选择了WPF。 由于WPF是C#的,这里必不可少需要跨语言调用。我使用的方法是,把KlayGE和主窗口需要的东西包装到一个dll中,导出成纯C接口。在C#中用Dllimport引入使用。这样只需要2个工程就能完成任务。WPF的界面上内嵌了一个WinForm的窗口,可以拿到HWND,就能用来初始化KlayGE。这么做虽然没有D3D控件来得方便,但能避免多次拷贝带来的性能损失。 有了WPF的支持,把ModelViewer这样的工具转到WPF就成了顺理成章的事情。新的工具叫做MeshMLViewer,可以用来查看MeshML格式的模型。使用和修改起来比以前自画界面来得方便。 ...