Skip to content
面光源一直是实时渲染的一大难点。原先所有实时渲染中都只敢用点光源(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格式的模型。使用和修改起来比以前自画界面来得方便。 ...
在使用了CMakeMS之后,支持Windows Phone 8+平台就成了理所当然的一件事情了。Boost 1.56已经能支持store和phone,在进一步解决了Phyton和7z在WP下的编译之后,我就开始尝试编译KlayGE本身。 下面讨论的WP,特指VS2013支持的WP8.1。WP8.0还没时间测试。 事实上,因为原先已经可以编译成store版本,切换到WP非常顺利。只有一处需要修改:WP上没有VersionHelpers.h,而且WinRT上也用不到。所以只要#ifndef掉就可以了。除此之外,没有任何别的修改,WP版本就可以顺利编译出来了。 在用模拟器运行的时候,出现了一个异常,WP有声明但没有实现CoreCursor。WP上不需要鼠标指针。同样,这里只需要一个#ifndef跳过那句就可以了。于是,KlayGE的大 ...
几个月前KlayGE的WinRT工程就已经转到CMake的方式进行管理。但因为CMake本身不支持WinRT,当时的做法是修改CMake的代码,打上自己的补丁后才能使用。现今,CMake有了个微软的fork,从我的补丁出发,专攻WinRT等平台上的兼容问题。目前这个分支能很好地生成Windows Store和Windows Phone的工程。 使用方法 对于生成其他平台的工程,这个分支的CMake和原先完全一样。对于WinRT平台,需要通过这样的命令行参数来指定目标系统和版本号: -DCMAKE_SYSTEM_NAME=WindowsPhone(或WindowsStore) -DCMAKE_SYSTEM_VERSION=8.0(或8.1) 实际上这个做法相当于和WinCE一样,在platform generator级别生成WinRT的部分,比我原先用compiler gener ...
KlayGE 4.6的开发刚刚开始。在目前的开发版里,工程方面有了一定的改进,这里总结一下。 boost的CMake化 在之前boost升级的贴子里有提到,现在包括boost在内的所有第三方库,都已经用CMake进行管理了,bjam被完全删除。这样只要一套编译设置就能应用于KlayGE中的所有项目。修改和移植变得更容易。 编译器支持 在KlayGE 4.5里,我做了一系列的实验,试图用Clang来编译KlayGE。原先遇到了一些Clang的bug,使得编译一直不成功。现在Clang解决了部分问题,KlayGE本身的dll都能通过Clang编译产生了,但exe仍然不行。问题还是出在Clang在Windows上对类的导出,有些函数被遗漏了。 VS14已经发布了两个CTP,现在KlayGE里也增加了对VS14的支持 ...
传统上,KlayGE集成的是单数版本的boost。但这次1.56的开发周期实在太长了,原定2月份出来的,足足延期了6个月。原因应该是他们在往git上迁移,并且在做模块化的重构。现在每个boost库的头文件、源文件和帮助文件都在一个单独的git库里,通过submodule的方式加到boostorg这个上层git库中。 还好,对使用boost来说,差别不大,照样可以永远原先的方法编译和使用。所以和升级Python不同的是,把boost升级到1.56.0没有遭遇太大的麻烦。 补丁 在之前的版本里,为了在WinRT和Android上使用boost,需要打很多补丁,修改很多地方才行。这些修改在这几个版本的boost里被逐渐集成进去,所以补丁的数量减少了很多。尤其是,微软的OpenTech团队直接 ...
2011年初,KlayGE进行了第一次招募。一晃3年多过去了,在这段时间里,很多组员为KlayGE的开发做出了巨大的贡献,促成了7个版本的顺利发布。在此表示衷心地感谢。 然而,随着时间的推移,很多成员从学校毕业,进入工作岗位。或者从公司小兵变成了领军人物。能参与到KlayGE里的时间也越来越少。同时,随着越来越多的人开始研究和使用KlayGE,想为KlayGE添砖加瓦的人也逐日增加。因此,KlayGE开发团队开始了第二次招募。 招募计划 只要符合以下条件均有机会: 喜欢游戏和引擎开发 熟悉C++,有一定编程经验 有开源精神,耐心和毅力 需要注意的是,如果您只是想学习KlayGE,并不需要加入开发团队。开源的特点决定了任何人都可以拿 ...
自从2011年KlayGE在代码库中包含所有第三方库以来,Python一直都是基于3.2的版本,这几年来Python本身的发展都没跟上。最近打算把Python移植到WinRT平台,所以干脆先一鼓作气,更新到最新的3.4.1上。 升级3.4.1 把代码更新到3.4.1,虽然文件添加、删除、修改都很多,但cmake里只要做很少的修改,就能完成编译和执行。但原装的python仍然不支持android,所以还得把以前的补丁手工修改到新版本上。另外,默认情况下python用的是mbcs进行编译的,改成unicode之后有几个编译错误,也顺便修改了。纯unicode版本的好处是,Lib/encode目录下不再需要带着各种编码的.py文件,全都用utf-8就行了。 WinRT的支持 原装的python也不支持WinRT。如果直 ...
上一篇完成了specular的环境光渲染。当然,在实际效果中,diffuse也是不可缺少的。在这套基于物理的环境光渲染中,也必须要有diffuse才完整。 Irradiance map GPU Gems 2第10章详细描述了如何通过卷积cube map,得到irradiance map,并用于diffuse的环境光渲染。其基本原理就是,可以把cube map当作一个拥有无数方向光源的物体。场景中的任何一个点,都会受到cube map里所有方向光源的照射,累积起来得到最终结果。 从最基本的光照原理可以得出,对于一个点,只有normal方向的那个半球面会对这个点有影响。而且影响程度按照n dot l的大小来分布。各向同性的纯diffuse情况下,shading和视点方向无关。所以,这里可以用Spherical Harmonic ...
上一篇把BRDF换成了更为常见的blinn-phong,推出了在上面进行importance sampling的公式,以及如何把结果存到一张查找表LUT上。更进一步的做法是把这张LUT拟合成一个曲面,这样就可以在shader中直接计算,省去一次纹理采样。Black Ops II也做了拟合,但它的方法是把F=0和F=1的曲线用F=0.04来表达,最终用一个很粗糙的插值来得到整个曲面。这里我打算用暴力的方法直接拟合整个曲面。 曲线拟合 LUT有两个通道,x表达scale,y表达bias。对于这两个通道,可以表达为f(n_dot_v, roughness)这样的一个函数。原始的LUT大小为128x128,实验中发现LUT本身很平滑,即使缩小到16x16,也不容易从最终渲染结果上看区别。所以这里我们选择16x16的大小作为 ...