Skip to content

Archive

Archive for February, 2012
老用户一定记得,在KlayGE 3.9之前,用来表示effect的.fxml都需要通过一个python写成的编译器进行离线编译,生成.kfx格式才能给runtime使用。在3.9里引入了rapidxml,可以直接在runtime读取xml文件,流程变短,开发效率提高了。但随着这两年shader越写越复杂,编译shader所花的时间越来越多,在载入的时候每次都编译shader,一来浪费时间,二来浪费计算。 KlayGE的模型格式.meshml也有过这样的问题,后来通过一个JIT在载入的时候动态把xml的.meshml编译成二进制的.model_bin,之后的载入速度就极大提高了。既不需要离线编译,也不用担心读取效率。因此,引入一个effect JIT也成了理所当然的事情。所以,事隔多年后,kfx格式原地满血复活。 ...
在越来越多的人讨论Cg存留问题的时候,Cg 3.1突然发布了。主要的改进有: Cg语言支持uniform buffer。 增加了OpenGL Unified Buffer Object(UBO)。 增加了翻译成OpenGL GLSL version 110和120的支持。 新的tessellation例子。 新的uniform buffer例子。 各个例子都加上了VC10的工程文件。 不知道NV怎么了,给出来的下载链接居然是错误的。正确的是http://http.developer.nvidia.com/Cg/cg_3_1_0010.html,有兴趣的朋友可以看看。
AMD的OpenGL驱动问题很多,是个众所周知的事情。以前我也写过《OpenGL驱动的陷阱:ATI篇》和《OpenGL驱动的陷阱:ATI篇,后续》来阐述这个问题,当时最新的驱动是Catalyst 10.10。过了一年多的时间,AMD的驱动和KlayGE的代码都有了不少变化,情况又如何呢? 失败的例子 在去年的驱动上,发现的问题主要有三个(ticket #58): Deferred Rendering和Global Illumination中,GI的效果只在第一帧出现。没找到原因。 Detailed Surface和JudaTex Viewer中,纹理显示混乱。没找到原因。 GPU Particle System和Particle editor中,粒子没有显示出来。GS编译失败。 更新到Catalyst 12.1后(也可能在11.12或者11.11就更新了,我没测试) ...
从KlayGE 4.0开始,不但有为了下一版本开发的短期任务,还有一些中长期研发的任务。其中之一就是HLSL bytecode to GLSL编译器。现在KlayGE里的shader主要由HLSL写成,通过#ifdef的土办法兼容Cg。对D3D11来说可以直接使用,但对于OpenGL和OpenGL ES 2就得大费周折了。那种情况下,shader需要经过Cg编译器编译成传统的GLSL,在经过我自己的token级别的编译器转换成现代的GLSL,然后才能使用。 为什么不直接用Cg?看看Cg runtime在ATI卡上的表现吧。 为什么不用传统的GLSL?NV的驱动有一套attribute和index之间的绑定规则,比如gl_Position一定是0,gl_Normal一定是6(或者某个数,但是个常量),而且无法通过API来获取预定义attribute的i ...
[zh] 经过长时间的筹划,今天正式宣布开始次世代评测软件KlayMark的开发。 简介 KlayMark将以KlayGE为引擎,定位为一款集各种先进渲染技术于一身的跨平台评测软件。在提供赏心悦目的画面同时,对系统的性能作出综合评价。不论是PC平台还是移动平台,KlayMark将提供统一的计分方式,使得不同平台之间的得分具有可比性。 虽然动用到许多新技术,但KlayMark仍会保持极高的效率、较低的配置、良好的跨平台能力等特点。 发布计划 KlayMark的源代码将迟于二进制版本发布,类似Doom和Quake的方法。 由于平台的差异,KlayMark 1.0的发布将分拨进行。 Wave 1:预计开发周期1年。Windows平台支持D3D10+和OpenGL,Android平台支持Tegra ...
独具特色的KlayGE字体系统现在可以独立使用啦! 在开发版本中,字体系统KFont成为了一个不依赖于KlayGE主体的子项目。目前包含的功能有.kfont格式的读写。未来可能加入字体转换工具和渲染代码生成。