|
|
第一章 回顾OpenGL
译者：樱
本章是对OPENGL应用程序编程接口(API)的一个简短的回顾，作为以后各章节的基础。本章并不打算做一个详细的描述，如果你已经对OPENGL的时候相当熟悉的话，你可以放心地跳过本章去看后面的各章节了。如果你熟悉其他的3D API的话，本章可以帮助你熟悉OPENGL，并且作为扩展你可以使用OPENGL 着色器语言来编写一些着色器。对OPENGL固定功能的描述是基于OPENGL 1.5说明书的。
1．1 OPENGL的历史
OPENGL是一个跨平台的工业标准API。这套API的说明书于1992年出台，而第一个实现是在1993年出现的。它由一种叫做Iris GL (Graphics Library)的API广泛兼容，这套API是由Silicon Graphics .Inc设计并支持的。为了建立一个工业标准，Silicon Graphics与其他很多硬件公司合作，创立了一个开放的标准。这就是OpenGL。
OpenGL在设计上继承了Iris GL的特性，其目的是在尽可能在低的底层提供对图形硬件的访问能力，同时还做到与硬件无关。OpenGL在不同的系统下有不同的实现，比如Macs, PCs, 以及 UNIX系统。它被许多硬件结构支持，除了它自己的帧缓存外，图形硬件还可以提供许多其他的支持， OpenGL在这些硬件上被加速。
自从1992年6月OpenGL说明手册的第一个版本(v1.0)发行以来，已经被修订了5次，每次都会添加一些新的功能。当前的OpenGL说明手册是1.5版。OpenGL 1.0的第一个统一的版本出现于1993年，1.1版于1997年完成，并且添加了两个重要的功能：顶点数组和纹理对象。OpenGL 1.2的说明手册在1998年发行，同时添加了对3D纹理的支持以及可选的图像功能的子集。2001年完成的OpenGL1.3中，又加入了立方纹理贴图，压缩纹理以及多重纹理等其他功能。OpenGL1.4在2002年也已经完成，加入了自动多纹理(mipmap)生成，附加的混合函数，用于阴影计算的短深度值的内部纹理格式，除此以外，还可以用一个命令来绘制多个顶点，对点的光栅化有更加的控制能力，对模板绕转行为的控制以及纹理渲染能力也获得了提高。OpenGL1.5说明书在2003年7月通过审查并且在同年10月获得出版。它添加了对顶点缓冲对象(VBO)、阴影比较函数，遮挡查询以及哑纹理(nonpower of texture)的支持。OpenGL 2.0预计能在2004年初完成，它将会把顶点处理器和片原处理器的可编程性的作为核心加入到OpenGL说明手册里。基于该版本的OpenGL,应用程序将会得到使用高级着色器语言去实现他们自己的渲染算法的能力。从OpenGL1.5到2.0的变化可以看出，OpenGL可编程性的引入，揭示了其设计上的根本性的转变。然而，主版本号的改变并不意味着先前版本的OpenGL的能力的削弱。OpenGL2.0将会完全地向下兼容OpenGL1.5——可以在OpenGL1.5下正确运行地应用程序将可以在OpenGL2.0中不加修改就能正确运行。
Silicon Graphics成立了一个机构来监督OpenGL的发展，这个机构就是OpenGL ARB(OpenGL Architecture Review Board)。这个组织支配着一组细则，该组织的主要任务是引导OpenGL，控制其说明书以及进行一致性测试。最初的时候ARB包括以下成员：SGI, Intel, Microsoft, Compaq, Digital Equipment Corporation, Evans & Sutherland, 以及 IBM。当前ARB则包括以下成员：3Dlabs, Apple, ATI, Dell, Evans & Sutherland, Hewlett-Packard, IBM, Intel, Matrox, NVIDIA, SGI, 以及 Sun Microsystems。
1．2 OpenGL的发展
在各种各样的OpenGL实现当中，有非常多的功能是以扩展的形式提供的。OpenGL有明确定义的扩展机制，并且硬件销售商可以自由的定义和实现一些特性以展示其硬件的性能。因为OpenGL的根本设计是固定功能的状态机，因此修改OpenGL的唯一方法就是为他提供扩展——当然，也只有OpenGL实现者可以实现扩展。应用程序没有任何方法去超越OpenGL的提供者提供的功能去扩展新的功能。到今天为止，已经有了近300个扩展。扩展由它们的前缀来识别其提供者（比如说：前缀为SGI的扩展就是由Silicon Graphics, Inc.所提供）。如果一个扩展由多家销售商所支持的话，它就以EXT做为前缀。由ARB彻底评估过的扩展会以ARB作为前缀，该前缀指出这些扩展是被推荐的实现某个功能的扩展。下一步ARB就会把这些扩展加入到OpenGL说明手册当中。也就是说，他们成为核心的一部分了。已经发行的OpenGL的扩展的说明手册可以在其注册站点http://oss.sgi.com/projects/ogl-sample/registry上找到。
由某个特别的OpenGL实现所支持的扩展可以通过传递符号常量GL_EXTENSIONS给glGetString而决定。返回字符串包含了所有的该实现所支持的扩展，有些硬件销售商甚至支持了多达100个的扩展。决定所需要的扩展是否存在以及当他们不存在时应该如何处理看起来是有点让人恐惧。OpenGL扩展的增长速度主要随OpenGL的发展而增加，但是从某种意义上来说，他们自己既是成功者又是受害者。扩展允许硬件销售商非常容易地展示自己硬件的特性，但是呈现在应用程序开发者面前的确实一大堆的非标准的选项！而同时ARB对使扩展成为标准也抱着小心谨慎的态度。
自OpenGL1.0以来，底层硬件的可编程性一直没有暴露出来。OpenGL最初的设计者，Mark Segal以及Kurt Akeley是这样说的：“这么决定的一个原因是，出于性能的考虑。图形硬件常常被设计成用来执行某一个特定顺序的操作的，以任意的算法改变这些操作是不可行的。”。这个解释在它被写下的1994年或许还是正确的（即使那样那时候仍然有可编程的图形硬件）。但是现在，所有的图形硬件都具有可编程性了。由于OpenGL扩展数量的增长以及要支持微软 DirectX API的需求，硬件销售商没有任何选择，除了设计可编程图形硬件结构。（正如以后本书章节所要讨论的，提供给应用程序员可编程性是OpenGL高级着色器语言的目的。）
1.3 运行模型
OpenGL API的主要目标是把图形绘制到帧缓存里，稍微做一点扩展，还要从帧缓存里读取数据。因此它在设计上多少会有点独特，包括支持绘制图像和位图以及绘制三维几何（如点，线，多边形等，他们统称为：图元）。
OpenGL的运行模型可以以客户－服务器的形式的来描述。一个应用程序（客户端）发出OpenGL命令流，然后由OpenGL实现（服务器端）来解释和执行。应用程序和OpenGL实现可以运行在同一台机器上，也可以运行在两台不同的机器上。一些OpenGL状态被存储在应用程序（客户机）的地址空间上，但是大部分还是存储在OpenGL实现（服务器）的地址空间上。
虽然所有的指令都被延迟，以进行一个指令缓冲的中间操作过程，但是OpenGL命令处理的形式永远是按照接受他们的先后顺序来执行的。乱序执行OpenGL命令序列是不被允许的。也就是说，一个图元在它之前的图元没有绘制完成之前是不会被绘制的。这种有序的执行模式也被应用于查询状态或者是读取帧缓存数据。这些命令返回一个值，这些值包含之前所有的命令完全执行的结果。
当命令发出的时候，对OpenGL的数据绑定就会发生，而不是在运行的时候。当命令发出的时候，传递给命令的数据就会被解释，并且如果需要的话，就会把数据拷贝到OpenGL内存当中。在命令子序列里，应用程序改变了这些数据也不会对那些存储在OpenGL内存中的数据造成影响。
原文地址：中国虚拟现实开发者
让我PS一下：我翻译一节贴一节……大家不要B4我 |
|
发表于 2005-4-2 08:38:00
楼主
