KlayGE游戏引擎

HDR post process几乎存在于所有PC桌面引擎中，也开始在一些高端移动平台上得到了支持。HDR太常见了，以至于这年头如果看到一个不带HDR的真实感实时渲染，就会觉得很突兀。（比如，在SIGGRAPH展会上，看了Qualcomm的展台，再看ARM和Imagination的，就有一种回到dx8时代的感觉。大部分原因就来自于Mali和PowerVR缺乏很好的HDR。）在这方面，KlayGE的目标是在不同平台上，都能尽量多地复用HDR post process里的组件，同时效果也尽量接近。首先让我们看一张只有LDR的图。 啥都支持的平台 代表的平台有D3D11 level 10+，OpenGL 3+。支持包括B10G11R11F在内的各种浮点纹理。在这样的平台上，KlayGE的HDR流程是这样的。注意红字标出来的数据 ...

前一阵子在把KlayGE的OpenGLES插件升级到OpenGL ES 3的过程中，原先还满怀希望地觉得GLES3总该全面支持浮点纹理的读写了，结果发现GLES3的标准支持float16和float32的读取，但不支持渲染到float16/float32的纹理上。只有支持GL_EXT_color_buffer_float或GL_EXT_color_buffer_half_float扩展的硬件，比如Tegra 4和Adreno 3xx才能很好地支持。所以，在其他设备上如果要渲染到浮点纹理，就得另想办法了。 编码和解码 单通道的float是32-bit，RGBA8也是，所以按说把float编码到RGBA8的纹理中应该没啥问题。很可惜的是，不支持浮点纹理的硬件往往也不支持整数指令和位运算操作。所以在这里需要有些限制。在网上搜了一下，最靠谱的应该是大牛Aras ...

之前放出过两批3D模型，这次继续几个整理好的高质量3D模型。有兴趣的话仍然可以到这里下载。

网上看到的GPU比较，都是桌面和桌面比，移动和移动比。很多人对此没有概念，总觉得移动的CPU/GPU在性能上也能比肩桌面CPU/GPU。那么就让我们来看看把各家的顶级GPU放在一起比硬指标，是什么样的结果吧。资料来自wikipedia和厂商自家宣传。 计算单元对比 Model Fab (nm) Core Clock rate API Core (MHz) Memory (MHz) NVIDIA GeForce GTX Titan 28 2688 836-993 6008 D3D 11.0, OpenGL 4.4, CUDA 5.5, OpenCL 1.2 NVIDIA Quadro K6000 28 2880 901.5 6008 D3D 11.0, OpenGL 4.4, CUDA 5.5, OpenCL 1.2 AMD Fusion APU 8670D 32 384 844-950 1066 D3D 11.0, OpenGL 4.3, OpenCL 1.2 AMD ...

在渲染场景的时候，一般来说分辨率和输出大小，也就是窗口大小相同。但在移动平台上，基本上没机会让你随便切换分辨率，都是只告诉你大小。在这时候，你如果想要用特定的分辨率渲染，就不可避免需要一次放缩。另一个常见的情况是，如果一个平台性能达不到需要的帧速率，也需要渲染较小的图之后，拉伸到指定分辨率。在XBox 360等console平台，有个专门的硬件放缩机制，只要打开就能自动把输入图像拉伸到720p或1080i/p（DX11.2才开始引入这样的机制）。但在PC和移动平台上，这个事情得在引擎里自己完成。所以在post process后端，加一个resizer就成了必然之选。 框架 这个放缩的框架很简单，把窗口大小填充给screen resolution，而渲染的分辨 ...

最近不少朋友提出为何不把KlayGE推到github的问题，原因是目前github只支持git，而我暂时不打算从hg切换到git。我原先觉得，既然有hg-git这样的插件，这件事情技术上应该很容易，直接转就可以了。试验了一下，发现其实还存在一些坑，必须要对付。这里拿空明大牛的salvia的repository为例子，试验从hg转到git。 第一次尝试，直接转换 安装了hg-git之后，建立一个叫做salvia-git的目录，在里面初始化一个git repository。然后在到salvia-hg的目录，直接执行hg push ../salvia-git。结果在执行了很久之后，出现 pushing to ../salvia-git abort: The system cannot find the file specified 以失败告终。 第二次尝试，bare 在初始化git r ...