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