可編程實時圖形

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 版將會在幾天內放出，所以歡迎您下載下來使用。然後告訴我們那些是你喜歡的部分，哪些部分是你不喜歡的或者不清楚的。我們期望能為你做出我們最好的產品。