文檔簡介：
　　提高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的渲染狀態。