本文主要是介绍跨越opengl和d3d的鸿沟(一):开篇,希望对大家解决编程问题提供一定的参考价值,需要的开发者们随着小编来一起学习吧!
原文地址
多年来,在论坛和各个网站上不断能看到拿OpenGL和D3D进行比较的帖子和文章。他们经常制造很多谜思,使得初学者和一些从业人员对OpenGL和D3D产生了各种各样的流言。
- 有人说,OpenGL直接调到驱动,性能高于D3D。
- 有人说,Shader都得写两套,很麻烦。
- 有人说,OpenGL和D3D在底层有很多区别,而且不可设置。
- 有人说,图形引擎如果要兼容两者,就只能取其功能的交集,最后还不如任何一种API。
真的么?
本文试图:
- 找出现代OpenGL和D3D的共通之处
- 归纳如何让API对上层代码尽量透明
本文不希望:
- 讲解函数间的对应关系
- 如何在OpenGL和D3D之间作选择
- 贬低一方,抬高另一方
下面先从几个比较基本的方面来探讨如何跨越两个API的鸿沟。
架构
OpenGL和D3D的架构基本上是这个样子的:
在架构上其实两者没有什么区别,只是D3D的runtime是在OS里,对于不同硬件来说都是一样的。而OpenGL的runtime直接是和驱动合为一体的。但这并不会造成性能有所差别,破解了流言1。
Shader
OpenGL 的原生shading language是GLSL,D3D的是HLSL。两者语法相似,但细节上天差地别。好在,NVIDIA的Cg在很大程度上类似于HLSL,而且可以编译 出GLSL来。所以,Cg编译器成了跨越这两种shader的桥梁。当然,要真正实用起来,还需要不少工作。比如Cg的Geometry Shader和HLSL 10+的有些许不同,需要通过#ifdef来分开。另外,Cg编译器生成的GLSL需要一些调整才能在ATI的驱动上工作,所以还需要多一次转换。好在这 些事情都可以通过程序自动完成,而且速度很快。具体可以参考KlayGE的OGLShaderObject::ConvertToGLSL。实际上,KlayGE的所有shader都只写了一份(语法用HLSL 11的),在不同API上可以自动编译成原生的shader使用(有OpenGL和OpenGL ES的编译器,曾经还有D3D9的)。这样就没有重写的繁琐,也没有增加runtime开销,破解了流言2。
当然,这里还有另一种更好的选择,把HLSL编译器生成的bytecode转换成GLSL。UE3等引擎用了MojoShader来完成这件事情。优点是不需要多次编译,缺点是不支持SM4+。
坐标系
初学者经常 说,OpenGL用右手坐标系,而D3D用左手;裁剪空间里OpenGL的z是[-1, 1],而D3D是[0, 1];不可调和。实际上,直接把左手的顶点和矩阵给OpenGL也是没有问题的。毕竟如果在VS里执行的都是mul(v, matrix),得到的会是同样的结果。可能会造成麻烦的反而是viewport的z。假设一个经过clip之后的顶点坐标为(x, y, z, w),那么在OpenGL上,该顶点经过viewport变换的z是(z/w + 1) / 2,而在D3D上则是z/w而已。这对于depth test不影响,但depth buffer里的值就不同了。所以需要对project matrix做一些调整,才能让他们写到depth buffer中的数值相同。具体来说,如果要让OpenGL流水线接受D3D的project matrix,就需要乘上
相当于把project space的顶点z都作了z = z * 2 – 1的操作,所以经过viewport变换就一致了。D3D到OpenGL的矩阵也可以依此类推。所以,在坐标系上,很容易就能使两者接受同样的输入,同时也没有增加runtime开销。
本篇讲的都是可以在不改变API的情况下,通过输入数据来消除OpenGL和D3D之区别。下一篇将讲解如何利用现代OpenGL提供的扩展和新功能,消除一些无法在上层解决的问题,继续破解各种流言。
这篇关于跨越opengl和d3d的鸿沟(一):开篇的文章就介绍到这儿,希望我们推荐的文章对编程师们有所帮助!