文檔簡介：
提高3D圖形程序的性能是個很大的課題。圖形程序的優化大致可以分成兩大任務，一是要有好的場景管理程序，能快速剔除不可見多邊形，并根據對象距相機遠近選擇合適的細節（LOD）；二是要有好的渲染程序，能快速渲染送入渲染管線的可見多邊形。
我們知道，使用OpenGL或Direct3D渲染圖形時，首先要設置渲染狀態，渲染狀態用于控制渲染器的渲染行為。應用程序可以通過改變渲染狀態來控制OpenGL或Direct3D的渲染行為。比如設置Vertex/Fragment Program、綁定紋理、打開深度測試、設置霧效等。
改變渲染狀態對于顯卡而言是比較耗時的操作，而如果能合理管理渲染狀態，避免多余的狀態切換，將明顯提升圖形程序性能。這篇文章將討論渲染狀態的管理。
文檔目錄：
基本思想 實際問題 渲染腳本文檔內容：
基本思想
我們考慮一個典型的游戲場景，包含人、動物、植物、建筑、交通工具、武器等。稍微分析一下就會發現，實際上場景里很多對象的渲染狀態是一樣的，比如所有的人和動物的渲染狀態一般都一樣，所有的植物渲染狀態也一樣，同樣建筑、交通工具、武器也是如此。我們可以把具有相同的渲染狀態的對象歸為一組，然后分組渲染，對每組對象只需要在渲染前設置一次渲染狀態，并且還可以保存當前的渲染狀態，設置渲染狀態時只需改變和當前狀態不一樣的狀態。這樣可以大大減少多余的狀態切換。下面的代碼段演示了這種方法：
// 渲染狀態組鏈表，由場景管理程序填充
RenderStateGroupList groupList;
// 當前渲染狀態
RenderState curState;
……
// 遍歷鏈表中的每個組
RenderStateGroup *group = groupList.GetFirst();
while ( group != NULL )
{
// 設置該組的渲染狀態
RenderState *state = group->GetRenderState();
state->ApplyRenderState( curState );
// 該渲染狀態組的對象鏈表
RenderableObjectList *objList = group->GetRenderableObjectList();
// 遍歷對象鏈表的每個對象
RenderableObject *obj = objList->GetFirst();
while ( obj != NULL )
{
// 渲染對象
obj->Render();
obj = objList->GetNext();
}
group = groupList.GetNext();
}
其中RenderState類的ApplyRenderState方法形如：
void RenderState::ApplyRenderState( RenderState &curState )
{
// 深度測試
if ( depthTest != curState.depthTest )
{
SetDepthTest( depthTest );
curState.depthTest = depthTest;
}
// Alpha測試
if ( alphaTest != curState.alphaTest )
{
SetAlphaTest( alphaTest );
curState.alphaTest = alphaTest;
}
// 其它渲染狀態
……
}
|
這些分組的渲染狀態一般被稱為Material或Shader。這里Material不同于OpenGL和Direct3D里面用于光照的材質，Shader也不同于OpenGL里面的Vertex/Fragment Program和Direct3D里面的Vertex/Pixel Shader。而是指封裝了的顯卡渲染圖形需要的狀態（也包括了OpenGL和Direct3D原來的Material和Shader）。
從字面上看，Material（材質）更側重于對象表面外觀屬性的描述，而Shader（這個詞實在不好用中文表示）則有用程序控制對象表面外觀的含義。由于顯卡可編程管線的引入，渲染狀態中包含了Vertex/Fragment Program，這些小程序可以控制物體的渲染，所以我覺得將封裝的渲染狀態稱為Shader更合適。這篇文章也將稱之為Shader。
上面的代碼段只是簡單的演示了渲染狀態管理的基本思路，實際上渲染狀態的管理需要考慮很多問題。
消耗時間問題
改變渲染狀態時，不同的狀態消耗的時間并不一樣，甚至在不同條件下改變渲染狀態消耗的時間也不一樣。比如綁定紋理是一個很耗時的操作，而當紋理已經在顯卡的紋理緩存中時，速度就會非常快。而且隨著硬件和軟件的發展，一些很耗時的渲染狀態的消耗時間可能會有減少。因此并沒有一個準確的消耗時間的數據。
雖然消耗時間無法量化，情況不同消耗的時間也不一樣，但一般來說下面這些狀態切換是比較消耗時間的：
-
Vertex/Fragment Program模式和固定管線模式的切換（FF，Fixed Function Pipeline）
-
Vertex/Fragment Program本身程序的切換
-
改變Vertex/Fragment Program常量
-
紋理切換
-
頂點和索引緩存（Vertex & Index Buffers）切換
有時需要根據消耗時間的多少來做折衷，下面將會遇到這種情況。
渲染狀態分類
實際場景中，往往會出現這樣的情況，一類對象其它渲染狀態都一樣，只是紋理和頂點、索引數據不同。比如場景中的人，只是身材、長相、服裝等不同，也就是說只有紋理、頂點、索引數據不同，而其它如Vertex/Fragment Program、深度測試等渲染狀態都一樣。相反，一般不會存在紋理和頂點、索引數據相同，而其他渲染狀態不同的情況。我們可以把紋理、頂點、索引數據不歸入到Shader中，這樣場景中所有的人都可以用一個Shader來渲染，然后在這個Shader下對紋理進行分組排序，相同紋理的人放在一起渲染。
多道渲染（Multipass Rendering）
有些比較復雜的圖形效果，在低檔顯卡上需要渲染多次，每次渲染一種效果，然后用GL_BLEND合成為最終效果。這種方法叫多道渲染Multipass Rendering，渲染一次就是一個pass。比如做逐像素凹凸光照，需要計算環境光、漫射光凹凸效果、高光凹凸效果，在NV20顯卡上只需要1個pass，而在NV10顯卡上則需要3個pass。Shader應該支持多道渲染，即一個Shader應該分別包含每個pass的渲染狀態。
不同的pass往往渲染狀態和紋理都不同，而頂點、索引數據是一樣的。這帶來一個問題：是以對象為單位渲染，一次渲染一個對象的所有pass，然后渲染下一個對象；還是以pass為單位渲染，第一次渲染所有對象的第一個pass，第二次渲染所有對象的第二個pass。下面的程序段演示了這兩種方式：
| 以對象為單位渲染 |
// 渲染狀態組鏈表，由場景管理程序填充
ShaderGroupList groupList;
……
// 遍歷鏈表中的每個組
ShaderGroup *group = groupList.GetFirst();
while ( group != NULL )
{
Shader *shader = group->GetShader();
RenderableObjectList *objList = group->GetRenderableObjectList();
// 遍歷相同Shader的每個對象
RenderableObject *obj = objList->GetFirst();
while ( obj != NULL )
{
// 獲取shader的pass數
int iNumPasses = shader->GetPassNum();
for ( int i = 0; i < iNumPasses; i++ )
{
// 設置shader第i個pass的渲染狀態
shader->ApplyPass( i );
// 渲染對象
obj->Render();
}
obj = objList->GetNext();
}
group = groupList->GetNext();
}
|
| 以pass為單位渲染 |
// 渲染狀態組鏈表，由場景管理程序填充
ShaderGroupList groupList;
……
for ( int i = 0; i < MAX_PASSES_NUM; i++ )
{
// 遍歷鏈表中的每個組
ShaderGroup *group = groupList.GetFirst();
while ( group != NULL )
{
Shader *shader = group->GetShader();
int iNumPasses = shader->GetPassNum();
// 如果shader的pass數小于循環次數，跳過此shader
if( i >= iNumPasses )
{
group = groupList->GetNext();
continue;
}
// 設置shader第i個pass的渲染狀態
shader->ApplyPass( i );
RenderableObjectList *objList =
group->GetRenderableObjectList();
// 遍歷相同Shader的每個對象
RenderableObject *obj = objList->GetFirst();
while ( obj != NULL )
{
obj->Render();
obj = objList->GetNext();
}
group = groupList->GetNext();
}
}
|
這兩種方式各有什么優缺點呢？
以對象為單位渲染，渲染一個對象的第一個pass后，馬上緊接著渲染這個對象的第二個pass，而每個pass的頂點和索引數據是相同的，因此第一個pass將頂點和索引數據送入顯卡后，顯卡Cache中已經有了這個對象頂點和索引數據，后續pass不必重新將頂點和索引數據拷到顯卡，因此速度會非常快。而問題是每個pass的渲染狀態都不同，這使得實際上每次渲染都要設置新的渲染狀態，會產生大量的多余渲染狀態切換。
以pass為單位渲染則正好相反，以Shader分組，相同Shader的對象一起渲染，可以只在這組開始時設置一次渲染狀態，相比以對象為單位，大大減少了渲染狀態切換。可是每次渲染的對象不同，因此每次都要將對象的頂點和索引數據拷貝到顯卡，會消耗不少時間。
可見想減少渲染狀態切換就要頻繁拷貝頂點索引數據，而想減少拷貝頂點索引數據又不得不增加渲染狀態切換。魚與熊掌不可兼得 :-(
由于硬件條件和場景數據的情況比較復雜，具體哪種方法效率較高并沒有定式，兩種方法都有人使用，具體選用那種方法需要在實際環境測試后才能知道。
多光源問題
待續……
陰影問題
待續……
現在很多圖形程序都會自己定義一種腳本文件來描述Shader。
比如較早的OGRE（Object-oriented Graphics Rendering Engine，面向對象圖形渲染引擎）的Material腳本，Quake3的Shader腳本，以及剛問世不久的Direct3D的Effect File，nVIDIA的CgFX腳本（文件格式與Direct3D Effect File兼容），ATI RenderMonkey使用的xml格式的腳本。OGRE Material和Quake3 Shader這兩種腳本比較有歷史了，不支持可編程渲染管線。而后面三種比較新的腳本都支持可編程渲染管線。
| 腳本 |
特性 |
范例 |
| OGRE Material |
封裝各種渲染狀態，不支持可編程渲染管線 |
>>>> |
| Quake3 Shader |
封裝渲染狀態，支持一些特效，不支持可編程渲染管線 |
>>>> |
| Direct3D Effect File |
封裝渲染狀態，支持multipass，支持可編程渲染管線 |
>>>> |
| nVIDIA CgFX腳本 |
封裝渲染狀態，支持multipass，支持可編程渲染管線 |
>>>> |
| ATI RenderMonkey腳本 |
封裝渲染狀態，支持multipass，支持可編程渲染管線 |
>>>> |
使用腳本來控制渲染有很多好處：
-
可以非常方便的修改一個物體的外觀而不需重新編寫或編譯程序
-
可以用外圍工具以所見即所得的方式來創建、修改腳本文件（類似ATI RenderMonkey的工作方式），便于美工、關卡設計人員設定對象外觀，建立外圍工具與圖形引擎的聯系
-
可以在渲染時將相同外觀屬性及渲染狀態的對象（也就是Shader相同的對象）歸為一組，然后分組渲染，對每組對象只需要在渲染前設置一次渲染狀態，大大減少了多余的狀態切換