Gamebryo的材質(zhì)系統(tǒng)
一個模型（有一大堆頂點跟索引數(shù)據(jù)組成）描畫的方式，跟材質(zhì)有很大的關系。
Gamebryo提供了一個很強大的材質(zhì)系統(tǒng)。
首先gamebryo使用了一個自定義的Pipeline，這個也是在之前的文章中介紹過的。其實這個Pipeline就是大家最常用的一些Shader。GB幫我們總結(jié)出來了，并做成了一個標準的材質(zhì)。這在GB里叫StandardMaterial。
標準材質(zhì)跟Pipeline是相對應的。但是標準材質(zhì)的實現(xiàn)是非常困難的，可以查閱NiStandartMaterial，大約有5000多行代碼。GB會首先查找一下Shader文件夾下的那些Shader。
這些Shader的文件名是由一對數(shù)字+字母組成的。這些文件都是不重復的，因為GB內(nèi)部通過Hash碼得出這些值。如果在Shader文件夾下沒有，那么GB會把當前的渲染方式記錄到這個Shader中去，作為緩存。
當然你也可以構(gòu)建自己的Material系統(tǒng)，比如GB的NiCommonMaterial里也給出了一些構(gòu)建自己材質(zhì)系統(tǒng)的例子，不過這是非常復雜，基本思想都是需要維護一個Shader樹。
不過自己寫Shader是非常方便的，你可以用RenderMonkey或者ShaderFX，把做好的*.fx文件放到Shader文件夾中，MAX再次打開的時候就會找到這些Shader。讓美工使用起來非常的方便。
關于優(yōu)化的問題總結(jié)
引擎本身做的很好，不會對速度產(chǎn)生太大影響。但是使用者往往會由于開發(fā)經(jīng)驗過低等等因素，導致游戲運行速度太慢。這里有些是因為對Gamebryo系統(tǒng)的不熟悉造成。
美術上：美術如果不熟悉Art文檔，不熟悉圖形技術的話，用任何引擎都是白搭。其實大部分的浪費都是美術造成的。下面先說說美術的優(yōu)化
1.注意Mesh的顆粒度，什么意思呢。就是主要不要有太多小物件。三角面很少的Mesh，如果材質(zhì)相同的話，完全可以合并起來。
1.關于Gamebryo中的update與update select。這是avobject里重要的兩個函數(shù)，也是Gamebryo中更新場景圖最重要的函數(shù)之一。update select是做了優(yōu)化的，也就是說，如果變換矩陣沒有做出變換的話，gamebryo不會更新world信息，這樣會節(jié)省一定的時間，所以如果是靜態(tài)物體，請優(yōu)先使用UpdateSelect.
相反動態(tài)物體，比如人物。如果確定他一定不是靜態(tài)的話，請不要使用UpdateSelect，因為這會多做一次對變換矩陣是否改變的判斷，這是沒有意義的。
gamebryo中的管線
跟開源圖形引擎一樣，商業(yè)引擎的價值在于幫助你做了很多前人的積累。
gamebryo就是這樣的引擎，當然unreal做的更加牛。這是后話了，關于unreal的做法我將以后分析。
先來說說gamebryo，跟Ogre不一樣的是，gamebryo有一個自己所謂的pipeline。
Ogre很靈活，當然靈活的代價是很多東西需要你自己做，gamebryo也很靈活，不過作為商業(yè)引擎，他同時幫你做了很多事情。
Gamebryo中的對象系統(tǒng)之一：智能指針和引用計數(shù)
本文是一系列Gamebryo底層系統(tǒng)的介紹。
Gamebryo除了是一個強大的游戲引擎之外，在研究他的源代碼同時，我驚喜的發(fā)現(xiàn)他提供了很多值得我們在寫代碼過程中學習和借鑒的東西。
本文就是來介紹這些底層系統(tǒng)到底是在穿插在引擎中使用的。
Gamebryo的底層系統(tǒng)運用于他所有的模塊和工具中，他提供了對象管理，引用計數(shù)，對象持久化（有點像Java的東西）以及快速的運行時型別轉(zhuǎn)換等功能。
首先我們來介紹一下引用計數(shù)與智能指針。
在Gamebryo中所有基礎NiRefObject的Object都會被計數(shù)的。這就意味著Object存儲著所有引用他的數(shù)目。如果需要長期的引用一個對象的話，需要聲明一個引用，并在結(jié)束時釋放掉改引用。當引用計數(shù)等于零的時候，對象會自己釋放掉所申請的內(nèi)存區(qū)。不過這樣看起來用起來會比較煩，好在GB提供了“smart pointers”來減輕繁雜的工作。
要注意的是所有繼承NiRefObject的子類都必須通過堆來分配，不用使用于靜態(tài)類型對象或者棧上對象。因為當引用計數(shù)為零的時候，該對象會被刪除，而刪除靜態(tài)對象或者棧上對象都會導致內(nèi)存錯誤或者崩潰。
談談批量渲染
隨著顯卡寄存器數(shù)量越來越多,批量渲染已經(jīng)不是什么稀奇的事情了.
其實,根據(jù)我最近研究發(fā)現(xiàn),暴雪早在DX8時代就做了批量渲染這件事,所以一舉占據(jù)了RTS老大的地位.很湊巧的時候我現(xiàn)在的項目也是個RTS類游戲.所以批量渲染就成了一個亟待解決的問題.
Gamebryo是支持MeshInstancing的，就是模型的批量渲染。
哦，先介紹下DX9支持的幾種Instancing的方式吧，一種叫HardwareInstancing，中文叫硬件批量渲染吧，其實是DX9提供了SetStreamSourceFreq這個接口，讓你可以把一個數(shù)據(jù)源多次使用，比如我們要批量需然一組模型，每個模型有自己的Translation信息，但是他們的頂點和索引數(shù)據(jù)是共用的。例如，你要批量10個這樣的模型的話，只要抽取出他們不同的數(shù)據(jù)上傳到一個數(shù)據(jù)源中，然后頂點和索引數(shù)據(jù)重復使用十次就可以了。
另外一種是ShaderInstancing，所謂Shader Instancing，意思就是，把Instancing數(shù)據(jù)傳到vertex shader里去，在渲染的時候通過一些方法索引到這些Instancing數(shù)據(jù)，用來對頂點數(shù)據(jù)做不同的描畫。
Gamebryo幀渲染系統(tǒng)詳解
如果沒記錯的話，我曾經(jīng)寫過一篇關于Gamebryo幀渲染系統(tǒng)的內(nèi)容。估計當時剖析的不是太詳細。那么現(xiàn)在我在這里重新講一下幀渲染系統(tǒng)，希望能把他將清楚。由于我手頭沒有代碼，而且又是商業(yè)引擎，所以很多函數(shù)我并不是完整的使用gamebryo中的，能使用偽代碼的地方我盡量使用偽代碼。
好，首先再次強調(diào)下幀渲染系統(tǒng)是邏輯系統(tǒng)，嚴格上跟渲染沒有任何關系，就是說如果你可以繞開幀渲染系統(tǒng)，一樣可以畫出想描畫的東西，只不過GB這樣做的目的是使得渲染層次更加清晰，靈活了。
OGRE也有類似的概念，在Ogre中也可以定義自己的層，但是由于沒有幀渲染系統(tǒng)，所以層次上不如Gamebryo靈活，方便易用。
RenderFrame 和RenderStep我就不再贅述了，因為這兩個概念很簡單，里面也沒有實質(zhì)性的內(nèi)容。你想怎么理解都可以，前者是后者的超集，Step又是Click的超集。
詳細說一下RenderClick和RenderView。RenderView可以理解成我們所要描畫的物件。RenderView里有AppendScene這樣的接口，就可以把所有想View的東西都掛接上去。RenderView里還有個重要的工具叫做Culler，Culler是做什么用的呢？是負責裁剪的，這里的裁剪是邏輯上的裁剪，就是精確到幾何體級別的裁剪。（注意不是三角面級別的）。Culler是作為Processor被加進去的，就是一個裁剪的過程。Culler提供了一些抽象接口，來滿足用戶的自定義裁剪。就是說你可以根據(jù)你的需要來在渲染前進行裁剪。
下面說到RenderClick，RenderClick精確的字面意思就是一次描畫，這個類的功能也基本是這樣，知道了要畫的東西，但是要畫到什么上去就需要RenderClick了，每個RenderClick對應了一個RenderTarget。就是要描畫的地方。一個描畫的過程是這樣的，首先找到RenderTarget就是要描畫的地方，因為如果是后期特效，有時候會有多個RenderTarget。
知道了要描畫的地方后就開始描畫了，首先從RenderView里找出要描畫的幾何體（這里的幾何體已經(jīng)是被裁剪過后的幾何體了），然后Click里再做一個處理，這里的處理也是個Processor，就是意味著用戶可以定義。這里處理的目的基本上是對物體做一個排序。這里不會再對幾何體進行裁剪了，而是進行類似Alpha排序等這樣的工作，保證物體被正確的按層次畫出來。最終得到的RenderObjList就是用來描畫的了。
整個過程其實還是比較簡單的，給用戶很多自己選擇的機會。是一個不錯的設計。
GameBryo ---- 模板類
GameBryo提供了一太基本的模板容器類，這些容器在整個庫內(nèi)使用。
Lists
NiTPointerList對象可以包含和管理指針，智能指針，以及其他任何大小小于等于指針的元素，該鏈表可以有效的插入和刪除所有元素，以及正向遍歷和反向遍歷所有元素，同樣可以通過給定值查找元素的實體和所在位置，NiTPointerList的元素的內(nèi)存是從一個共享內(nèi)存中分配的，從而提高類的執(zhí)行速度和內(nèi)存效率，如果鏈表元素大于指針，程序可以使用NiTObjectList.
Array
NiTArray對象實現(xiàn)勒幾乎可以包含所有對象的動態(tài)數(shù)組，該數(shù)組可以縮放，并且可以壓縮(通過轉(zhuǎn)移元素來移除空空間)。內(nèi)置類型(char*, float, int等)使用NiTPrimitiveArray。NiMemObject派生出的類型使用NiTobjectArray。注意NiTArray的元素上限為65535；如果大于該限制，使用NiTLargeArray派生出的類，比如NiTLargePrimitiveArray或NiTLargeObjectArray。
Map
NiTPointMap對象實現(xiàn)勒哈希表的功能，允許任何類型的鍵值來影射到指針，智能指針，以及其他任何大小小于等于指針的元素，并能快速的儲存和查找鍵值對，不過不能使用字符串鍵哈希表，而NiTStringPointerMap對象是專為此設計的，NiTPointMap和NiTStringPointerMap的元素內(nèi)存也是從一個共享內(nèi)存中分配的，從而提高執(zhí)行速度和內(nèi)存效率，如果map元素大于指針，程序可以使用NiTMap和NiTStringMap
StringMap
NiTStringMap和NiTStringPointerMap對象的函數(shù)和NiTMap和NiTPointerMap風格類似，但是允許字符串作為鍵，并且通過字符串比較來進行鍵散列
FixedStringMap
NiTFixedStringMap對象函數(shù)和NiTMap對象風格相似，但是允許NiFixedString對象作為鍵
Queue
NiTQueue實現(xiàn)勒基本所有類型對象的先進先出隊列，但不提供智能指針，需要注意鏈表可以當做隊列來使用
Set
NiTSet實現(xiàn)了基本所有類型的無序集合，也沒提供智能指針，內(nèi)置類型(char*, float, int等)使用NiTPrimitiveSet。NiMemObject派生出的類型使用NiTobjectSet，智能指針則使用NiTObject或者NiTPrimitivePtrSet，這將正確的處理引用計數(shù)。
Pool
NiTPool實現(xiàn)了小型對象的池，使得程序能通過一個池來分配小型對象，并能重復使用，而不是單獨的去分配和釋放一個小型對象
GameBryo ---- 場景圖的幾何更新
一個程序會在需要的時候改變一個節(jié)點的轉(zhuǎn)換，計算該節(jié)點的時間轉(zhuǎn)換，以及該節(jié)點子節(jié)點的其他轉(zhuǎn)換將被延遲，直到應用程序調(diào)用例行的update。
update是高效使用深度優(yōu)先來遍歷子圖計算世界轉(zhuǎn)換和世界包圍球，從而最大限度的減少節(jié)點的訪問，當向下遞歸時，轉(zhuǎn)換被更新，包括所有的自節(jié)點，當矩陣更新后，世界包圍球通過遞歸調(diào)用返回
總之，轉(zhuǎn)換在遞歸中被更新，而包圍球在遞歸返回時得到
通常大多數(shù)的對象都不會移動的，所有只更新只限于小部分可以移動的對象。在場景圖的數(shù)據(jù)處理初始化中，當應用程序使用到場景圖前，至少要對場景圖的根節(jié)點進行一次例行update，這樣保證所有節(jié)點的世界信息及本地信息都是最新的。
在應用程序幀到幀的運行中，當符合下面任何一條時，應用程序必須調(diào)用對象“O”的update。
·O被綁定到父親節(jié)點或者從父親節(jié)點解除綁定
·O綁定了一個新子節(jié)點或者解除了一個子節(jié)點的綁定
·O任何一個轉(zhuǎn)換被改變
注意一下，調(diào)用當前發(fā)父親節(jié)點或者任何祖先節(jié)點的update可以代替當前節(jié)點update的調(diào)用。例如，如果對象A綁定了子節(jié)點B和C，只需要調(diào)用A的update就夠了。沒有必要調(diào)用三個對象的update，應用程序會以批處理的方式更新。
例如，當應承需要改變了一個活動角色的所有的關節(jié)矩陣，他應該推遲update直到所有的改變都完成，并且只需要調(diào)用一次角色根節(jié)點的update。
但是，注意update盡量在場景圖的更下層調(diào)用，如果一個場景圖每幀只有一個葉子被改變，那么調(diào)用根節(jié)點的update就太過分了，這將降低性能。
GameBryo ---- 網(wǎng)格數(shù)據(jù)共享
為了世界中對象只需要少量的頂點，一棵樹可以用來代表場景圖，每個對象被單獨表現(xiàn)為樹中的節(jié)點。但是，在絕大多數(shù)場景圖中，會多次出現(xiàn)一個需要大量內(nèi)存來存儲的復雜對象，絕大多數(shù)的內(nèi)存是消耗在紋理和頂點數(shù)據(jù)上，比如紋理坐標和法線。
如果一個應用程序需要多份這樣一個對象，是有可能通過共享的NiDataStream來分享模型空間的幾何信息，顏色，紋理和其他顏色。換句話說，若干網(wǎng)格對象可能分享NiDataStream對象，在這種情況下，場景圖是有向非循環(huán)圖，而不是一棵樹。
在幾何數(shù)據(jù)共享的情況下，葉網(wǎng)格對象共享NiDataStream對象的模型空間網(wǎng)格。但是,兩個模型數(shù)據(jù)的實例是在世界的不同位置,因為他們代表的多個網(wǎng)格對象,并且每個副本自己單獨的轉(zhuǎn)換。
這些管理是在應用程序的內(nèi)部透明處理的——應用程序只需要建立兩個網(wǎng)格對象使用同一個NiDataStream對象。網(wǎng)格對象甚至要比一套最小的網(wǎng)格數(shù)據(jù)小的多，因為網(wǎng)格對象不像數(shù)據(jù)流，不存在每個頂點的數(shù)據(jù)
下面的圖象是一個典型的情況：
(兩個網(wǎng)格對象使用同一個NiDataStream)
兩個葉網(wǎng)格對象分享一個輪胎NiDataStream對象的頂點位置和法線。一個網(wǎng)格對象對應到自行車的前輪，另一個對應到自行車的后輪。NiDataStream對象自身存儲的網(wǎng)格頂點的位置和法線被共享，兩個網(wǎng)格對象都保存表現(xiàn)自己網(wǎng)格的轉(zhuǎn)換。
注意以下，Gamebryo不為任何類型的NiAVObject提供多父親的功能。綁定一個已經(jīng)擁有父節(jié)點的對象C，會導致C自動脫離原來的父節(jié)點
GameBryo ---- Working with Properties
Gamebryo通過一套相互獨立的渲染性質(zhì)為每個能渲染的葉子對象定義了渲染屬性，每一個渲染屬性都為能渲染的對象定義了某一方面的渲染狀態(tài)，并且都是NiProperty的子類。對個可渲染的對象可以共享渲染屬性。針對一個對象的完整渲染狀態(tài)是所有屬性的完整組合。當屬性狀態(tài)對象存在與NiRenderObject葉子節(jié)點時，這個個體渲染屬性就被綁定在場景圖的任何NiAVObject上。這正式用于每個可渲染葉子對象產(chǎn)生屬性狀態(tài)的每個NiAVObject的屬性。一個屬性被綁定到一個NiAVObject將影響所有子數(shù)上的子對象(包括它自己)，除非在子樹中同樣的屬性類型被其他屬性所替代。如果沒有任何屬性被設置到場景圖的對象上，該對象會通過合適的默認屬性來繪制。每個屬性類型的默認相當于為該類型設置一個默認構(gòu)造，每個NiAVObject都包含了一個綁定與它的所有屬性的鏈表，一個NiAVObject可能沒有任何屬性綁定，也有可能綁定一個或多個屬性。所有的方式達到一個NiAVObject能綁定的每樣屬性的最大值。注意確保應用程序任何時候都不能給單一的NiAVObject綁定一個以上已經(jīng)類型的屬性。一個單一的NiAVObject綁定已經(jīng)類型的一個以上的屬性會導致奇怪的視覺效果和未知的問題。
繪制屬性類型
NiProperty對象在Gamebryo中的數(shù)據(jù)層次如下：
NiObject
NiProperty
NiAlphaProperty
NiDitherProperty
NiFogProperty
NiMaterialProperty
NiShadeProperty
NiSpecularProperty
NiStencilProperty
NiTexturingProperty
NiVertwxColorProperty就如上面討論的，屬性設置從根到葉層次。一個被綁定到NiAVObject對象的屬性會影響該對象及它的子對象。除非在更低的子樹中綁定該類型的其他屬性。因此，一個可渲染葉節(jié)點的當前狀態(tài)是由場景圖中它祖先的鏈所決定的
NiWireFramProperty
NiZBufferProperty
更新屬性到集合物體上
Gamebryo會讓整個場景圖保持綁定屬性，綁定在每個可渲染葉對象的屬性狀態(tài)是包含所有提供的類型的屬性的數(shù)組，這樣，每個可渲染的對象包含一個直接指向用來繪制的渲染屬性的指針。這很重要，因為渲染只涉及可渲染的葉對象，而不是整個場景圖。于是每個可渲染對象的屬性狀態(tài)都是繼承其他可渲染對象的所有屬性的副本。
Gamebryo使用一個系統(tǒng)類似使用NiAVObject::Update函數(shù)來更新這些屬性狀態(tài)對象。這個類似的渲染屬性函數(shù)是NiAVObject::UpdateProperties。當出現(xiàn)下面的情況UpdateProperties必須在obejct"O"或任何一個他的祖先調(diào)用下一次渲染
·一個以O個根節(jié)點的樹剛被創(chuàng)建
·一個屬性被綁定到O或從O移除
·O被綁定到節(jié)點P或從P上被移除
注意，當只改變了一個已有屬性，應用程序不需要調(diào)用UpdateProperties。
要實現(xiàn)最佳性能，這些UpdateProperties的調(diào)用可以以相同的方式進行批處理來執(zhí)行批處理更新,如果應用程序?qū)⒃谧訕渖辖壎ɑ蚪獬壎ㄔS多屬性，它必須調(diào)用所有的綁定或解除綁定函數(shù)，然后在子樹的根部調(diào)用一次UpdateProperties，通常的，因為屬性和子節(jié)點的綁定和解綁沒有每一幀這樣頻繁，所以UpdateProperties要比每幀積累屬性快的多，但是對于程序員。將多出一個額外的小負擔。
GameBryo ---- SoftParticles
軟粒子主要是為了解決粒子廣告牌和場景幾何相交時，產(chǎn)生的生硬邊緣，如下圖煙霧與地面相交時的邊
為了解決上面的情況，我們需要用到場景的深度信息，如下圖：
在一般的渲染管線中，點P3就是產(chǎn)生生硬邊的點，為了改善這種情況，SoftParticles通過改變粒子的alpha值來處理粒子后面的場景，這里使用了自定義的shader常量來決定距離d以便我們調(diào)整alpha值（d為world place中），任何距離原場景深度大于d的粒子相素我們將不處理他的alpha值(對應上圖P1的公式)，
上圖中點P1正好達到該距離，點P1到P3的alpha混合程度會遞增，距離d設置的越小，那效果就越接近于硬粒子的效果，因為P1的條件很容易滿足，對alpha值的修改會減少，但是如果距離設置的過大，那P2就很容易滿足，這樣導致Len/d產(chǎn)生的值很小，讓粒子變的很透明，造成的粒子很稀疏，具體的效果要自己手動調(diào)節(jié)。
這種邊緣軟化的方式只是近似的，當場景的法線于攝像機方向錘子時會失效，當出現(xiàn)這種情況時，隨便粒子與相交面很接近了，但因為攝像機與相交面近乎垂直，而粒子相素的深度檢測是沿與攝像機方向的，從而產(chǎn)生一個很大len值，導致了本來應該成為P3效果的點，成為P1。
DEMO5個類，SoftParticles，MRT_ColorDepthMaterial，SoftParticlesMaterial，SoftParticlesManager，MRT_ColorBlackMaterial
SoftParticles::CreateScene()
負責創(chuàng)建場景，從Nif文件中獲取場景，攝像機及粒子系統(tǒng)，設置alpha排序，剔除，及默認材質(zhì)MRT_ColorDepthMaterial, MRT_ColorDepthMaterial繼承于NiStandardMaterial，重載了函數(shù)bool HandleFinalVertexOutputs()和函數(shù)bool HandleFinalPixelOutputs()，這兩個函數(shù)分別在vertex shader和pixel shader的最后執(zhí)行，通過HandleFinalVertexOutputs函數(shù)，為vertex shader的output結(jié)構(gòu)增加成員NiMaterialResource* pkVertOutViewTexCoord = Context.m_spOutputs->AddInputResource("float4", "TexCoord", "World",
"PosViewPassThrough");作為紋理坐標的格式輸出
NiMaterialNode* pkSplitterNode = GetAttachableNodeFromLibrary(
"PositionToDepthNormal");
kContext.m_spConfigurator->AddNode(pkSplitterNode);
kContext.m_spConfigurator->AddBinding(pkViewPos,
pkSplitterNode->GetInputResourceByVariableName("Input"));
kContext.m_spConfigurator->AddBinding(
pkSplitterNode->GetOutputResourceByVariableName("Output"),
pkVertOutViewTexCoord);
獲得自定義函數(shù)PositionToDepthNormal，將pkViewPos作為傳入?yún)?shù)，把新增的pkVertOutViewTexCoord作為輸出參數(shù)
而HandleFinalPixelOutputs則在輸入結(jié)構(gòu)中增加float4 WorldPosProjected : TEXCOORD6;代碼如下
NiMaterialNode * pkInputResource;
pkInputResource = kContext.m_spConfigurator->GetNodeByName("PixelIn");
NiMaterialResource* pkDepthFromVP = pkInputResource->AddOutputResource(
"float4", "TexCoord", "World", "WorldPosProjected");
然后在輸出結(jié)構(gòu)中增加深度顏色，通過WorldPosProjected來賦值，CreateScene()還將場景中所有的粒子系統(tǒng)添加進SoftParticlesManager，添加完所有的ParticlesSystem后，SoftParticlesManager通過Initialize()函數(shù)，創(chuàng)建默認的粒子材質(zhì)，以及SoftParticlesManager自己的RnderView及click,然后通過InitializeScene()為每個粒子系統(tǒng)設置材質(zhì)，并添加進RnderView,這里要注意執(zhí)行順序
SoftParticles::CreateFrame()
該函數(shù)中，通過獲取后備緩沖的屬性，來創(chuàng)建相同一張texture，用來渲染深度，不過格式要設置為NiTexture::FormatPrefs::SINGLE_COLOR_32，表示32位的單通道顏色，用R通道表示，然后新建一個RenderGroup，要包含原來的后備緩沖以及先建的位圖緩沖，讓場景同時渲染到這兩個緩沖上，并將紋理緩沖作為SoftParticlesManager中創(chuàng)建的click的一個輸入
GameBryo ---- MSAA
MSAA(MultiSampling Anti-Aliasing)
GB中MSAA實現(xiàn)的關鍵代碼基本是直接用的D3D，除了自己的渲染批次系統(tǒng)，DX9不能直接對渲染到紋理啟用MSAA，但是提供了渲染表面surface,可以對surface啟用MSAA。
實現(xiàn)的關鍵步驟大致如下
1。NiRenderedTexture::Create創(chuàng)建一個和背景緩沖一樣大的RenderTexture，NiRenderTargetGroup::Create利用RenderTexture創(chuàng)建RenderTarget，屏幕最終渲染的目標就是該RenderTarget，我們需要的也是將MSAA后的數(shù)據(jù)給RenderTexture
2。通過D3D的CreateRenderTarget按照自定的MSAA級別來創(chuàng)建surface，利用surface的buffer創(chuàng)建另外一個MSAARenderTarget
3。新建一個RenderView，GB中用的NiScreenFillingRenderView，就是D3D中四個頂點組成的矩形，該RenderView綁定一個baseTexture為步驟1所創(chuàng)建的RenderTexture的NiTexturingProperty，創(chuàng)建RenderClick掛接該RenderView，并設置一個CallBackFunc，然后將該click插到mainClick后面，這樣用兩pass來完成MSAA
4。主click將畫面渲染到開啟MSAA的MSAARenderTarget，然后進入新click的CallBackFunc，獲取MSAARenderTarget的buffer，用D3D的StretchRect復制數(shù)據(jù)到RenderTexture，這樣新click就會渲染出進行MSAA后的texture