可编程实时图形

1. OpenGVS的概念

OpenGVS是Quantum3D公司高级三维图形卡的捆绑软件，它的前身是GVS。OpenGVS是实时三维场景驱动软件，为3-D软件开发者提供了高级的API。OpenGVS API由许多强大的函数组成，开发人员可迅速开发出高质量的3-D应用软件。

OpenGVS的历史

1988年第一个GVS SDK版本由Gemini Technology Corporation发行，用于军事训练和研发仿真效果。早期的图形工作站价格昂贵，使用专用硬件、专门微代码和系统软件，用于实时生成外部场景。缺点：价格贵，不可编程。后来，用户青睐于可编程图形工作站，但却没有足够用的开发工具包。GVS应运而生。

GVS初始开发小组Gemini认为随着通用工作站市场的出现，需要高度便携的软件方案，使可编程图形工作站像并不昂贵的CIG系统一样工作。由于图形生成函数并不在硬件或微代码中实现，最好它能够扩展甚至接口到其它三维图形环境。由这样的开发工具，终端用户能一次书写代码，即使运用不同的三维图形硬件，也能重复利用于其它工程。

版本1、2的GVS为“Generic Visual System”的缩写。仅支持几种图形系统，如Evans and Sutherland (E&S), Silicon Graphics (SGI), Alliant, Megatek, and AT&T Pixel Machines。由于当时PHIGS是唯一的便携生成系统，版本1、2就围绕其开发的。不幸的是，此后几乎没有厂家采用PHIGS＋作为其低级生成API。

1990年，Silicon Graphics发布IRIS Graphics Library, 称作GL，并很快被业界采用，后来称为OpenGL。OpenGL性能远优于PHIGS＋，故GVS版本3采用IRIS GL作为其内部低级生成引擎。此后，GVS就是指“Gemini Visual System”。

九十年代中期，OpenGL已成为主要工业界图形生成标准，GVS版本4系列更名为OpenGVS，4.0采用OpenGL1.0 API。与此同时，微软的图形API Direct3D面世，它主要面向PC机及游戏开发商的。此时也出现了三维芯片Voodoo Graphics，它对三维游戏开发产生革命性的影响。Voodoo Graphics能提供工作站级的三维图形性能，但却没有为Direct3D或OpenGL的驱动器，而只有自己的低级Glide API(一种屏幕坐标生成层，有些类似于OpenGL)。OpenGVS开发者认为GVS的面向对象设计的性质适合于构建一个抽象层SimGL。它是对Glide and Direct3D图形生成API的抽象，这样，三维硬件看起来就像OpenGL运作。

OpenGVS V4.1用一个抽象层SimGL使运用Glide(Voodoo Graphics)变得方便了。版本4.2支持Microsoft’s Direct3D API。版本4.3支持Voodoo3芯片(Glide3 API)和Quantum3D的第一个PC-1G系统，包括硬件支持全场景和象素反走样。版本4.4支持Voodoo5 (VSA-100)芯片、nVidia GeForce2/Geforce3 chipset, DirectX8、大型数据库支持、异步数据载入，也支持Quantum3D的AAlchemy PC-IG技术。

OpenGL通常描述低级生成要素，如如何用用户定义的属性(颜色、纹理图)绘制多边形，对象对模拟光源如何反应等。而OpenGVS是一个场景管理器，它的功能就是从低级生成API功能结束的地方开始的。

OpenGVS 实时三维视景管理软件-------实时三维开发者的梦想
如果开发实时3维图形应用，OpenGVS是提供给开发者领先、成熟、方便的视景管理系统。OpenGVS是世界上第一个通用工作站平台的3D视景管理软件。在1990年推出的在SGI工作站IRIS GL版本上的GVS是OpenGVS的早期产品。

OpenGVS不仅基于OpenGL 图形标准，而且它可以被应用于所有图形平台标准。一旦你编好你的应用程序，它可以运行在从高端图形工作站到PC的任何系统上。

功能强大的3D SDK帮助你快速有效的制作3D产品。OpenGVS是一个开放的系统。它可以使开发者的应用使用任何软硬件平台上。

高级面向对象的OpenGVS API 满足用户的各自项目的要求。诸如：模型、运动方程、灯光照明等。OpenGVS替用户完成底层的难度较大的3D图形工作。使用OpenGVS你只需用很少的几行代码就可编写一个完整的简单应用程序。

2. 什么是VertexShader、PixelShader

Vertex Shader & Pixel Shader 介绍

1. 固定功能的图形处理流水线（fixed function graphics pipeline）

能够实现Vertex Shader和Pixel Shader的显卡的图形处理流水线被称作为是可编程的，相对而言，在此之前的图形处理流水线被称作为是固定功能（fixed function）,下面是OpenGL图形处理的一个简图：

完整的OpenGL图形处理流水线为称作为OpenGL机器（OpenGL machine，在OpenGL参考手册上可以找到这份框架图），就像一个电路图一样，上面有许许多多的开关，我们可以打开或者闭合这些开关，还可以设置图中各个处理单元的参数以控制处理的方法，但是无论如何整个系统的功能已经确定下来了，你只有使用或者不使用某些功能和控制某些功能的具体执行方法的权利而无法实现自己定制的功能，所以这样的图形处理流水线被称作为是固定功能的。（有实力的显卡厂商在自己的OpenGL实现中添加了许多OpenGL扩展实现了一些标准OpenGL规范所没有的功能，现在有了可编程的图形流水线，一般用户也有机会实现一些自己定制的功能。）

2. Vertex Shader & Pixel Shader

虽然实现Vertex Shader和Pixel Shader功能的图形流水线被称作为是可编程的，但是实际上可编程的只有流水线的一部分，正如Vertex Shader 和Pixel Shader的字面意思一样，现在可编程的部分只有处理顶点的和处理象素的单元。

Vertex Shader 和 Pixel Shader在不同的文档里面有不同的叫法，Nvidia在自己的OpenGL扩展中把Vertex Shader叫做Vertex Program、把Pixel Shader叫做Texture Shader，3Dlabs在自己提出一份OpenGL 2.0的提议里面把这两者分别叫做Vertex Shader和Fragment（片元）Shader。抛开叫法的差异，实际上的功能都是差不多的，下面的一段话对这种状况作了一个完美的解释：

Shader or Program? Shader has been used as the preferred name as this fits in with common usage in RenderMan and DX8. There is some argument that shading has connotations of being a color operation so doesn't fit with a vertex operation. RenderMan doesn't make this distinction, nor does DX8. It seems wise to go along with the common usage of shader as a general term for a program which operates on some part of a graphics pipeline.

（Shader 还是 Program，在RenderMan和DX8中，通常情况下倾向于使用Shader这个名字。这个叫法有一些争议，因为Shading蕴涵地表示为进行了相关的颜色操作而不适合用来描述顶点操作。但是在RenderMan和DX8中并没有理会这种区别。所以跟随通常的叫法，把Shader作为在图形处理流水线某些部分起作用的program的一般术语似乎是一个明智的做法。）

3. 安装directx10之后有什么用

下面我们就来仔细的看一下这三种方式：

提高绘图效率

在DirectX 10中，对上代DirectX版本中三维数据和绘制命令的验证过程进行了很大程度的修改。所谓三维数据和命令的验证，是指在DirectX绘制图形之前，对传给它的图形数据和绘制命令进行格式和数据完整性的检查，以保证它们被送到图形硬件时不会导致硬件出问题；这是很必要的一步操作，但是不幸的是这会带来很大的性能开销。

从上表我们可以很容易的看出，在DirectX 9中，每次绘制一帧画面之前，都会对即将使用的相关数据进行一次验证。而DirectX 10中，仅当这些数据被创建后验证一次。这很明显是可以大大提高游戏进行中的效率的。

降低图形运算对CPU的依赖

在降低图形运算对CPU的依赖方面，DirectX 10 引入的三个重要机制就是：纹理阵列(texture arrays)、绘制预测 (predicated draw)和流式输出(stream out)。不要被这三个晦涩的名词吓倒，实际上它们是三个不难理解的机制。

纹理阵列

传统的DirectX在多张纹理中进行切换的操作是种很给CPU带来很大压力的操作，因为每切换一次，都要调用一次DirectX的API函数。而每绘制一个使用新纹理的物体，就要进行一次这样的切换操作；有时为了实现特殊的材质特效，绘制一个物体时可能就要切换好几次纹理，开销很大。

所以，之前游戏中经常会出现将大量的小纹理拼合到一张大的纹理中，通过给不同的三维物体分配这张大纹理的不同局部的方式，以期减少纹理切换，提高游戏运行效率。这种方式实现起来相当复杂，而且DirectX 9中对纹理的尺寸的限制是4048×4048像素，也就是说，如果要容下更多的小纹理块，可能就得加载很多张这样的大纹理。

DirectX 10引入的新的纹理阵列机构，将允许在一个由显卡维护的阵列中容纳512张单独的纹理，而且，在shader程序中可以使用一条新的指令来获取这个阵列中的任意一张纹理。而这种shader指令是运行在GPU中的；这样，就把原来要消耗很多CPU时间的纹理切换工作轻松地转给了GPU。由于纹理一般是直接放在显存中的，因此以这样的方式，将工作交与和显存一同位于显卡上的GPU来完成更有效率。如今，在DirectX 10中，只要一开始设置好纹理阵列中的纹理，然后每次绘制一个物体时为它指定一个纹理的索引号，并同物体三维数据一起传递到shader中，就可以放心的让GPU来给物体选纹理了。

绘制预测

在一般的三维场景里，很多物体都是完全被别的物体挡在后面的。这时候如果要显卡绘制这些物体就是白费力气。尽管高级的GPU可以通过硬件算法将场景画面中被挡住的像素(注意是像素)预先剔除，但是仍然会有很多不应进行的多余运算。例如，一个完全被挡住的复杂的角色模型，它的身上可能有几千个顶点，需要做复杂的骨骼皮肤动画处理、顶点光照运算等等，然而，GPU是在处理完这些顶点之后，并要把这个角色模型一个像素一个像素地画到画面中时，才开始判断每个像素是否需要画，而当所有的像素都被剔除了时，之前做的顶点处理也就全白费了。在DirectX 10中的绘制预测便正是针对这种情况的解决，简言之，绘制预测通过用一个可以代表某个复杂物体的简单物体来判断这个物体是否被全部挡住了，例如用一个可以罩住刚才那个角色的大盒子，当绘制这个盒子时，如果发现所有的像素都被屏蔽掉了，也即是说这个盒子肯定完全看不见，那么，里面的角色绘制包括骨骼皮肤运算等之类的操作便完成不必进行。而一个盒子顶多有八个顶点，相比处理几千个顶点，开销小得多。

另外，以前这个步骤中有些真运算也需CPU完成的，在DirectX 10中，已经完全交由GPU来做，这也可以在一定程度上减轻CPU的压力。

数据流式输出

数据流式输出也是DirectX 10的重要特性，它允许GPU上的Vertex shader或Geometry shader向显存中添加数据，而这在以往的vertex shader中是不可能的。

在之前的DirectX版本中，vertex shader只能读取显存中已有的顶点数据；而DirectX 10中引入的新的Geometry shader，不但能读取显存中的顶点数据、几何(点、线段、三角形)数据，还可以生成新的几何数据放回显存。

批量绘制

在DirectX 9中，对渲染状态的管理一直是个十分信赖于CPU运算能力的操作。所谓渲染状态，是指显卡进行一次绘制操作时所需要设置的各种数据和参数。例如，要绘制一个人物角色，就需要先设置他的几何模型数据的数据格式、纹理过滤模式、半透明混合模式等等，每设置一项，都要调用一次DirectX API，占用大量CPU时间，极大的约束了渲染的性能。

为了使这些操作能够批量的进行，DirectX 10中引入了两个新的结构——状态对像(state object)和常量缓冲(constant buffers)。

状态对像就是将以前的零散状态按照功能归结为几个整体，这样，当要设置一系列相关状态时，无需为每一个状态来调用一次DirectX API,只需要调用一次将这些状态统统设置到显卡中去。

而常量缓冲是另一个十分有意义的机制。在绘制模型前的准备工作中，渲染状态的设置只是一小部分。还是拿绘制人物角色来说，能照亮这个人的光源的颜色、位置、类型、范围等等，都要提前设给显卡；为了通过骨骼来带动他的皮肤做出姿势，还要设置骨骼的位置信息等等，而这些东西主要都是通过GPU中的常量寄存器(constant registers)来传递给它的。每个常量寄存器可以存储一个4维的浮点型向量(即四个浮点数)。常量寄存器是游戏程序向GPU输入游戏场景中数据的重要途径。

在DirectX 9中，这种常量寄存器的数量是十分有限的，而且每次更新一个寄存器，都需要调用一次DirectX API函数。DirectX 10通过使用常量缓冲(constant buffer)这种结构，在每个constant buffer中都可以容纳4096个常量，而且只需调用一次API就可以更新一大批常量。

比如说，在以前的DirectX版本中，如果程序想在场景里画很多的树木和杂草，可以采用一个类似于“克隆”的方法：先做好一棵或几棵树、草的三维模型，然后在画一帧画面时，不停的在不同的位置、方向，用不同的大小为参数，调用DirectX API的绘制函数来画这些模型，就可以画出很多草木来。但是每画一棵，都要设置一大堆参数后调用一次API，这是很耗CPU时间的，所以在以前的游戏中鲜有大规模且细节丰富的森林场景。

而在DirectX 10中，我们可以先把树、草的几个模型设给显卡，然后将所有要画的树木的位置、方向和大小一次性的写入到constant buffer中，这样，显卡便一下把所有的树木和草都一起绘制出来了。

总之，DirectX 10通过提前数据验证、纹理阵列、绘制预测、流式输出、状态对像、常量缓冲等机制，帮助游戏的效果和效率上升到一个新的高度。这样，也避免了之前DirectX版本因CPU负载过大而无法对图形实施更多细节优化的问题。

Shader Model 4.0
DirectX 10另一个引人瞩目的特性便是引入了Shader Model 4.0，那么，Shader Model 4.0能够带来怎样的新特性，特别是将它与DirectX 9.0c中Shader Model 3.0相比时？

引入新Shader : Geometry shader

DirectX 10新引入的Geometry Shader，可以简单地编程操纵几何图元，同时， vertex、geometry、pixel shader采用了统一的Sahder架构。

Geometry shaders是可编程图形流水线的一大进步。它第一次允许由GPU来动态的生成和销毁几何图元数据。通过和新的数据流输出功能配合使用，许多以前无法实施的算法现在都可以在GPU中使用了。

统一的Shader架构

在DirectX 9中，Pixel shader总是在各个方面落后于vertex shaders，包括常量寄存器个数、可用的指令个数、shader长度等。程序员需要区分对待这两种shader。

而在shader model 4中，无论 vertex、geometry和pixel shader，均有统一的指令集、同样的临时/常量寄存器个数，它们将平等的共享GPU中的所有可用资源。这样，在编程时便不必再考虑每种shader自身的限制了。

百倍于DirectX 9的可用资源

对于shader中可用的资源，在Shader model 4.0中比原来有了惊人的扩充。就像早期的程序员们绞尽脑汁的省着用可怜的640k内存一样，在使用以前的DirectX开发游戏的过程中，程序员需要小心翼翼的分配珍贵的shader寄存器资源。寄存器的数量，直接影响着shader程序的复杂度。这和在640k内存的 机器上，怎么也不可能写出Microsoft Office这样的大规模软件是同一个道理。

而在DirectX 10中，将临时寄存器由原来的32个扩充到了4096个，将常量寄存器由原来的256个扩充到了65536个。

更多的渲染目标(Render Target)

所谓渲染目标，就是指GPU可以把画面绘制到的目标，我们可以把它理解为GPU的画布。一般来说，渲染目标被输出到屏幕上，这样我们就能看到画好的画面了。但是有时为了实现一些特效，某些渲染结果并不直接画到屏幕上，而是再返给GPU做进一步的特效处理，而且渲染目标中也不一定是画好的画面的颜色信息。

根据图形特效的需要，渲染目标可能是每个物体距离屏幕的远近，或者物体表面上每个像素的方向，或者每个物体表面的温度等等，之为了实现特效，可以按需要在其中绘制任何信息。为了提高这种情况下的效率，很多新的显卡都支持在同一遍Shader执行结束后，同时把不同的信息绘制到不同的渲染目标中。在DirectX 9中就已经支持这种机制了，但是它约束最多同时向四个渲染目标绘制。而DirectX 10将这个数量提升了一倍。

更多的纹理

在Shader Model 4.0中提供了对纹理阵列(Texture arrays)的支持。在前文中已经对纹理阵列有了比较详细的介绍，在这里只着重介绍一下与shader相关的部分。

在每个纹理阵列中，最多可以保存 512张同样大小的纹理。而且每张贴图的分辨率被扩展到了8192×8192。更大的分辨率意味着纹理中更丰富的细节。在一个shader中能够同时访问的纹理个数被增加到了128个，也就是说在每次执行同一个shader时，可以使用一个纹理阵列的512个纹理中的128个。所以说，在DirectX 10中，纹理的多样性和细节程度将会有大幅的提升。

新的HDR颜色格式

要说这些年来在实时图形界炒得最热的概念，应该是HDR了。它通过采用浮点格式的颜色格式来为纹理、光照等计算提供极大的精度和颜色范围(以前的纹理一般 都是采用整数型的颜色格式)。尽管最后显示到屏幕上还是每个颜色通道8位的整数格式，但是以前由于在材质、光照计算中纹理也是用每通道8位的格式来参与计算，所以在显示到画面之前，很多细节就在低精度的运算中丢失了。

而采用每颜色通道16位浮点数的纹理，能够保证在运算过程中几乎没有颜色细节信息的丢失。另外，采用16位浮点格式的颜色通道，可以表现更大的颜色范围。这些就是HDR的优越性。

对用户而言，当游戏中的画面罩上一层HDR效果后，立刻显得和真正的照片一样，有朦胧的光晕、细致的高光和十分自然的色调。

然而，采用每个颜色通道16位浮点数的格式，比采用每通道8位的整数格式的纹理要多占据一倍的显存；这给绘制的效率带来了负面的影响。所以在 DirectX 10中引入了两个新的HDR格式。第一种是R11G11B10，表示红色和绿色通道用11位浮点数，而蓝色通道采用10位浮点数表示。那么，为什么不都用 11位呢？这是为了凑32这个整数。学过计算机的人都知道，当内存中一个数据单元的宽度是32位时，对它的操作效率最高；而且在纹理数据中一般要求每个像素的数据宽度是2的倍数，如2,8,16,32,64等等。又因为人眼对蓝色的敏感度不如对红色和绿色，所以它比其他两个通道少用了一位。

另外一种格式是采用每通道9位尾数、所有通道共享5位指数的形式(众所周知，在计算机中，浮点数是采用尾数附加指数的形式来表示的)，加起来还是32位。 这些新的格式使得纹理能够与原来占用同样多的显存空间，避免了大的空间和带宽消耗。同时，为了适合需要精确的科学计算的场合，DirectX 10能够支持每通道32位(4个通道加起来128位)精度的浮点数纹理。

DirectX 10中带来的这些扩充和提高，使得创建前所未有的细节的实时游戏场景真正成为可能。

几何着色器与流式输出
在DirectX 10发布之前，图形硬件只有在GPU上操作已有数据的能力。顶点着色器(Vertex Shader)和像素着色器(Pixel Shader)都允许程序操作内存中已有的数据。这种开发模型非常成功，因为它在复杂网格蒙皮和对已有像素进行精确计算方面都表现的很出色。但是，这种开发模型不允许在图像处理器上生成新数据。当一些物体在游戏中被动态的创建时(比如新型武器的外形)，就需要调用CPU。可惜现在大多数游戏已经很给CPU带来了很大的压力，游戏进行时动态创建庞大数量新数据的机会就变得微乎其微了。

Shader Model 4.0中引入的几何着色器(Geometry Shader)，第一次允许程序在图像处理器中创建新数据。这一革命性的事件使得GPU在系统中的角色由只可处理已有数据的处理器变成了可以以极快速度既可处理又可生成数据的处理器。在以前图形系统上无法实现的复杂算法现如今变成了现实。

几何着色器被放在顶点着色器和光栅化阶段(Rasterizer)中间。所谓光栅化，就是一行一行的扫描每个三角形，把它们一个像素一个像素的绘制到画面 上。几何着色器把经过顶点着色器处理过的顶点当作输入，对于每个顶点，几何着色器可以生成1024个顶点作为输出。这种生成大量数据的能力叫做数据扩大 (Data Amplification)。同样的，几何着色器也可以通过输出更少的顶点来删除顶点，因此，就叫做数据缩小(Data Minimization)。这两个新特性使GPU在改变数据流方面变得异常强大。

细分的虚拟位移贴图(Displacement Mapping with Tessellation)

几何着色器让虚拟位移贴图可以在GPU上生成。虚拟位移贴图是在离线渲染系统中非常流行的一项技术，它可以用一个简单的模型和高度图(Height Map)渲染出非常复杂的模型。高度图是一张用来表示模型上各点高度的灰度图。渲染时，低多边形的模型会被细分成多边形更多的模型，再根据高度图上的信息，把多边形挤出，来表现细节更丰富的模型。

而在DirectX 9中，GPU无法生成新的数据，低多边形的模型无法被细分，所以只有小部分功能的虚拟位移贴图可以实现出来。现在，使用DirectX 10的强大力量，数以千计的顶点可以凭空创造出来，也就实现了实时渲染中真正的细分的虚拟位移贴图。

基于边缘(Adjacency)的新算法

几何着色器可以处理三种图元：顶点、线和三角形。同样的，它也可以输出这三种图元中的任何一种，虽然每个着色器只能输出一种。在处理线和三角形时，几何着 色器有取得边缘信息的能力。使用线和三角形边缘上的顶点，可以实现很多强大的算法。比如，边缘信息可以用来计算卡通渲染和真实毛发渲染的模型轮廓。

流式输出(Stream Output)

在DirectX 10之前，几何体必须在写入内存之前被光栅化并送入像素着色器(pixel shader)。DirectX 10引入了一个叫做数据流式输出(Stream Output)的新特性，它允许数据从顶点着色器或几何着色器中直接被传入帧缓冲内存(Frame Buffer Memory)。这种输出可以被传回渲染流水线重新处理。当几何着色器与数据流输出结合使用时，GPU不仅可以处理新的图形算法，还可以提高一般运算和物理运算的效率。

在生成、删除数据和数据流输出这些技术的支持下，一个完整的粒子系统就可以独立地在GPU上运行了。粒子在几何着色器中生成，在数据扩大的过程中被扩大与派生。新的粒子被数据流输出到内存，再被传回到顶点着色器制作动画。过了一段时间，它们开始逐渐消失，最后在几何着色器中被销毁。

高级渲染语言(HLSL 10)
DirectX 10 为以前的DirectX 9中的“高级着色语言”(High Level Shading Language )带来了诸多功能强大的新元素。其中包括可以提升常量更新速度的“常量缓冲器”(Constant Buffers)，提升渲染流程中操作数据的灵活性的“视图”(view)，为更广泛的算法所准备的“整数与位指令”(Integer and Bitwise Instructions)，添加了switch语句。

常量寄存器(Constant Buffers)

着色程序同普通的程序一样需要使用常量来定义各种参数，例如光源的位置和颜色，摄像机的位置和投影矩阵以及一些材质的参数(例如反光度)。在整个渲染的过程中，这些常量往往需要频繁的更新，而数以百计的常量的使用以及更新无疑会给CPU带来极大的负载。DirectX 10中新加入的常量缓冲器可以根据他们的使用频率将这些常量分配到指定的缓冲器中并协调的对其进行更新。

在一个着色程序中DirectX 10支持最多16个常量缓冲器，每一个缓冲器可以存放4096个常量。与其相比DirectX 9实在是少得可怜，因为它在每个着色程序中同时最多只能支持256个常量。

∠啾菵irectX 9，DirectX 10不仅提供了更多的常量，最主要的是它大幅的提升了常量更新的速度。对那些被分配到同一个缓冲器中的常量，我们只需进行一次操作就可以将它们全部更新完毕，而非单个单个的去更新。

由于不同的常量更新的时间间隔各异，所以跟据使用的频率来对他们进行组织就可以获得更高的效率。举例来说：摄像机的视矩阵只在每一帧之间发生改变，而类似贴图信息这样的材质参数却会在图元切换时发生改变。于是这些常量缓冲器被分成了两个部分：那些每帧更新的常量缓冲器专门存放那些需要在两帧间更新的常数并在两帧间一次把他们全部更新，另外的图元切换更新的常量缓冲器也同理。这样就会将更新常量过程中的一些不必要的工作消除，以便让整个着色器脚本比在 DirectX 9中运行的更加顺畅。
高级渲染语言(续)
视图(Views)

在DirectX 9中，着色器(shader)中的数据的类型是被严格划分开的。例如，顶点着色器用到的顶点缓冲器中的数据不能当作贴图的数据来让像素着色器使用。这样就将特定的资源类型同其相对应的渲染流程中的特定步骤紧密地结合了起来，同时限制了资源资源在整个渲染流程中可以使用的范围。

DirectX 10舍弃了“严格区分的数据类型”这一概念。当一段数据被创建，那么DirectX 10所做的仅仅是将其简单的当作内存中的一段区域(bit field)来对待。如果要想使用这一段没有定义类型的数据就必须通过使用一个“view”。 使用“view”，相同的一段数据就可以有各种各样的方法来读取。DirectX 10支持对同一段资源在同时使用两个“view”。

通过这种多重“view”的手段，就可以在整个渲染流程的不同部分以不同目的使用同一段数据。例如：我们可以通过像素着色器将一段几何数据渲染到一张纹理 上，之后顶点着色器通过一个“view”将这张纹理视为一个顶点缓冲器并将其中的数据作为几何数据渲染。“view”通过在整个渲染流程中的不同步骤重复 使用同一段数据为“数据处理”带来了更大的灵活性，帮助开发者实现更多更有创意更精彩的特效。

整数与位运算指令(Integer and Bitwise Instructions)

在新的高级着色器语言中添加了“整数与位指令”，这样把“整数与位运算指令”的操作加入其基础运算函数的好处在于帮助一些算法在GPU上的实现。开发者终于可以直接使用整数而非从浮点中强转来计算出准确的答案。数组的索引号现在可以轻松的计算出来。GPU无整数运算的时代终于被终结了。这将为shader 程序的开发带来很大的便利。

Switch 语句(Switch Statement)

在DirectX 10中， HLSL可以支持switch语句，这将大幅简化那些有着大量判断(分支)的着色器脚本的编码。一种用法就是建立一个“航母级的着色器(shader) 程序”——包含了大量的小型着色器程序并且自身体形巨大的着色器程序。在这个“航母级的着色器程序”，我们可以通过设定一个材质ID在switch语句中 判断来轻松的在渲染同一个图元时切换不同的特效。也就是说，现在一个军队中的每个士兵身上都可以拥有各自不同的特效了。

DirectX 10的其他改进
alpha to coverage

在游戏中，经常使用带有半透明信息纹理的多边形模型来模拟复杂的物体，例如，草、树叶、铁丝网等。如果使用真正的模型，一颗边缘参差不齐的小草可能就要消耗掉几百个多边形；然而采用透明纹理，可以只用2～3个多边形就解决了。

透明纹理示意

然而，当使用这种有半透明信息的纹理时候，它的不透明和透明部分的边界线上，常常会出现难看的锯齿。采用半透明混合技术可以解决这个问题，但是它需要把场景中所有这类物体按照由远到近的顺序来绘制，才能保证它们的遮挡关系是正确的，这会给CPU带来很大的压力，并不可取。在以前版本的DirectX中，alpha测试和混合简直就是图形程序员的噩梦。

在DirectX 10中，使用了一种新的技术叫做Alpha to coverage。使用这种技术，在透明和不透明交界处的纹理像素会被进行多极取样(Multi-sample)，达到抗锯齿的效果。这就在不引入大的性能开销的情况下简单并有效地解决了这个问题。室外场景的游戏将大大受益于这种技术，树叶、铁丝网、草的边缘将会更加柔和、圆滑。

Alpha to coverage效果

shadow map filtering

阴影图(Shadow map)技术已经逐渐成为了渲染真实感阴影的流行技术。在包括《战争机器》、《分裂细胞：双重特工》、《Ghost Recon》、《刺客信条》等的各大次世代游戏中都能看到它的身影。然而，由于shadow map的尺寸限制，用它实现的阴影边缘往往有明显的锯齿。在DirectX 10中，提供了对shadow map进行过滤的功能的正式支持。经过过滤后，阴影的边缘将会变得更加柔和。

--------------------------------------------

简而言之：就是让你的所看导的画面更清晰，显示更快！

DirectX10未来技术营造逼真游戏画面(组图)

http://www.pconline.com.cn/pce/softnews/cs/0608/849971.html

4. 什么叫可编程逻辑控制器(PLC)

一种控制机械设备的属于大脑一类的东西，其实他就是一台工业用的电脑，你可以编辑它里面的程序来执行机械复杂的动作，功能非常的强大。

5. 什么是XNA Framework 详细�0�3

XNA Framework 是一系列帮助开发人员编写游戏的类库。在beta 版即将到来之际我想来花点时间通过对XNA 的三个关键点的解释来说明一下XNA Framework，也就是：XNA Framework 的目标是什么，XNA Framework 是什么，还有它可以做什么 在开发的时候我们想到的是实现两个主要目的： XNA Framework 的一个关键目标是实现游戏在Windows 和Xbox 360 分别运行的简易性，以让你可以先在Windows 上开发一个游戏，然后简单的移植到 Xbox360 上去。我们的目标是提供一系列可以涵盖大约95%功能的跨平台APIs。这里要说的是由于某些原因两个环境间仍会有部分的不同，例如有些操作可能只在一个平台上有效。我估计大部分你开发的游戏是100%跨平台的。 制作游戏是一项有难度的工作。从学生和爱好者想要成为专业游戏开发人员更加困难。常常要在如何实现绘图，输入，运动等地方反复试验而浪费大量的时间和代码。XNA Framework 的另一个目的就是使这一切变得容易起来。当我们在进行内部讨论的时候，我们经常提到开发体验的“头五分钟”。我们的想法是使你可以在头五分钟内开始编写你的游戏。你不必要考虑创建窗口，消息事件队列的弹出和处理，你不需要给出图片处理程序甚至掌握显示模式。你不需要创建一个图形设备然后在窗口重新定义大小和最小化的时候管理它。XNA Framework 替你处理了这一切。你要做的第一件事就是为你的游戏逻辑写代码。 另一个问题是处理特定的游戏内容（Content），把一个内容导入到你的游戏中然后使它在运行时为你所用。XNA Framework 的一项特性叫做内容管道（Content Pipeline）。通过它你可以极为简单的把一个内容引入你的游戏。关于这点将会在以后的文章作进一步的说明。不过想象一下，以后你可以像管理代码一样，将游戏的内容作为项目的一部分进行处理。内容管道将会为你处理内容的导入，编译和载入。 实现“头五分钟”的另一个方面在于我们将会提供一些Start Kits，这些Start Kits 将会作为一个项目模版包含完整的游戏操作，以及源代码和媒体文件。在新建项目对话框中你可以使用它们，并在上面进行修改。最终你将可以直接打开一个在编写中的游戏，进行改写和调整之后，按下F5 就可以马上得到反馈。每一个Start Kits 都会有完整的说明文档，还包含一些指导教你如何修改增加游戏的特性。 未来的版本中游戏开发进程的简化还将得到不断改进。而我们总的努力方向就在于不断地降低游戏开发的门槛，使更多的人进入到游戏开发者的行列中来。 Layers 在描述XNA Framework 组成的时候，我们可以认为是一系列层次关系。 Platform 平台是XNA Framework 的最下一层。它由一系列底层的原生代码和托管 APIs 组成。在这一层中有些APIs 就是Direct3D 9, XACT, XInput 和XContent. Core Framework 核心框架是第一层，并且提供核心操作用来给其它层的进行扩展。如果你想要在直接使用托管DirectX，就应该是在这一层。在这一层次中包含了对图像，声音，输入和数据存储的处理。当我们要改进XNA Framwork，附加新的功能我们就要增建这一层。 Extended Framework） 扩展框架主要致力于游戏开发的简化。当前这一层有两个主要的部分：应用模块（Application Model）和内容管道。我们将通过这一层使你可以更容易的开发游戏，同时便于扩展。 游戏部分是最高的层次。这一层包含你的游戏逻辑代码和内容。在这一层将你的游戏逻辑和内容相整合。Start Kits、游戏模版和游戏内容部件就属于这一层。 以上我们谈论了许多关于XNA Framework 的目标以及它所划分的功能层次。但什么是XNA 呢，让我们来看看。 Application Model 应用模块的意图在于抽象你的游戏所运行的平台，让你专注于游戏的编写。你不必关心创建窗口，管理消息队列，创建定时器或时钟和处理窗口消息。我们全都替你进行了封装。我们也提供一个GraphicsComponent（译注：图形组件，是一个类）以极为简单的方法对要绘图的图形设备进行创建和管理。在 Xbox360 上是不需要窗口和窗口消息的，这和Windows 有很大不同，你也不必担心，因为在应用模块上两个平台是完全相同的。我们也提供通用模块让你简单的和其它人在游戏中合并GraphicsComponent，通过这样可以快速的建立可重用模块。 GameComponents （译注：游戏组件集合，也是一个类）在你的游戏中可以由别人所写入。这样的处理在建立和快速运行或实现一个可重用的库的时候是很重要的。这一部分是我亲眼看着完善起来的，我相信我们将看到用户通过它实现许多神奇的东西。 我们的图像APIs 是基于Direct3D 9 APIs 的。它们非常类似于MDX 类型结构，但是经过了精心的重构和清理使它更容易使用，并且和.Net 的设计方针保存一致。这部分和MDX 最大的不同的在于，我们决定取消固定函数式（fixed-function）的管理方式，而使用一种全渲染驱动可编程管道（all shader-driven programmable pipeline） 我们这样做是有原因的。首先，可编程管道是实时计算机图形的未来。 Direct3D 10 和Xbox360 都不再为固定函数提供支持。当我们和一些早期的合作者和客户讨论这些问题的时候，我们还是多少有点惊讶，其实他们对于跨平台的关注大于对原固定函数的关注。由于害怕在Windows 中用固定函数APIs 开发的程序（也许开发人员都不确切知道），在移植到Xbox360 上时立刻得到大量的编译错误。当知道你的代码在一开始就可以确实的跨平台运行，这实在是令人放心不少。 我们还发现掌握渲染和特效是游戏编写中要迈出的一大步。所以我们尝试在托管DirectX 1.1 到 XNA Framework (Beta 1)中提供了一些移植向导式的API。例如BasicEffect 类可以简单的通过设置属性，包含光照、纹理等等就可以在“五分钟”内实现对一个物体的呈现。使用BasicEffect 而不需要直接去编写渲染，就可以很快地在屏幕上显示出一些东西。然后当你开始对渲染和特效较为熟悉，或者可以扩展类BasicEffect 的呈现功能时，你也可以直接用它们来写你自己的渲染和特效。 我们的声音APIs 是建立在Windows 和Xbox360 通用的声音API——XACT 上的。XACT 的理念和Direct3D 的渲染部分类似。声音的制作人员使用XACT 的工具创建好声音效果包（packages），并且配置好音量，重复次数，声道混音（支持5.1）等等。开发人员得到这样的包之后再载入它，然后就可以简单的通过包的名字来调用声音，而无须考虑缓存，流导入等其它管理细节。例如音效人员制作了一个包含几个wav 文件，有LFE 效果并且和其它通道混音的声音包“BigExplosion”。而程序员不需要知道这方面的细节，他只要得到“BigExplosion”，然后对它调用Play。漂亮！简洁！ 输入API 建立在基于一般Xbox360 的控制器（译注：就是手柄）的XInput API 之上，它也是跨平台的。输入提供一个立即模式（immediate mode）API 而不需要初始化。不需要考虑获得或释放设备，设置共享模式等等。你只需在恰当的控制器类型上调用GetState 就行了。我们提供了一个GamePad 类型用来表示 Windows 和Xbox360 上的Xbox360 控制器。同时在Windows 中还有键盘类型和鼠标类型。 存储API 提供了以平台无关方法来读取和保存游戏数据（例如保存游戏状态，高分值等等）的途径。在Windows 中这不是什么问题，因为你可以使用System.IO。并且你可以通过环境（Environment）方法正确的为当前用户定位到存储的数据。在Xbox360 上你需要使用Profile 和存储设备来操作游戏状态，例如硬盘和记忆卡。XNA Framework 的存储处理部分使这些变得很容易，并可以达到跨平台的效果。我们在Windows 上对Xbox360 这些操作进行了模拟，以使你用完全一样的代码在两个平台上读取和写入数据。 数学API 提供了一些游戏中常用的数学类型，例如Vector2, Vector3, Vector4, Matrix, Plane,还有 Ray。我们也提供了一些卷绑定（bounding volume）类型例如 BoundingBox, BoundingSphere 和 BoundingFrustum。我们的绑定类型也包含交集和容积（containment）测试的方法。需要注意的是我们的数学库默认是右序的。这里我指的是在Matrix（矩阵）上的情况。例如我们只提供了一个对矩阵右序查看的CreateLookAt 方法，而不是分别提供CreateLookAtLH 和 CreateLookAtRH。我们这样设计的目的在于使其它外部内容和中间件的整合都较为统一而容易。如果大家都遵守这个约定那么按照这样开发的XNA Framework 和外部的APIs 就可以较容易的联合使用。以上我说的是默认的时候，进行左序操作是无需其它条件的。如果你确实需要使用左序（或者其它方法）操作也可以，你只需要自己写操作代码。 目前我们注意力主要在刚发布到你手上的XNA Game Studio ExpressV1.0 以及XNA Framework 上。但是我们也在考虑未来版本的特性。如前面提过的为了添加新的功能操作，我们将对Core Framework 层进行扩展。同时对Extended Framework 进行增建，使得用XNA Game Studio Express 创建游戏更容易。我们也会推出XNA Game Studio Professional，以使开发者可以用XNA Framework 在 Xbox360 上开发商业游戏。请在下一个月中留意这方面的情况。 我提到XNA Framework 的一个目标在于让编写游戏更容易，使你专注于你的游戏而不是平台。它到底有多简单呢？下面的代码显示了一个可运行的 XNA Framework 游戏应用程序大体框架。 public class SampleGame : Game { private GraphicsComponent graphics; public SampleGame() { this.graphics = new GraphicsComponent(); this.GameComponents.Add(graphics); } protected override void Update() { } protected override void Draw() { this.graphics.GraphicsDevice.Clear(Color.Blue); this.graphics.GraphicsDevice.Present(); } static void Main(string[] args) { using (SampleGame game = new SampleGame()) { game.Run(); } } } 感谢你花时间阅读这篇文章。我希望我已经讲明白了XNA Framework 到底提供什么。Beta 版将会在几天内放出，所以欢迎您下载下来使用。然后告诉我们那些是你喜欢的部分，哪些部分是你不喜欢的或者不清楚的。我们期望能为你做出我们最好的产品。