文章出處:
一 如何進行有效的效能評測
對於任何乙個3d應用程式來說，追求場景畫面真實感是乙個無止盡的目標，其結果就是讓我們的場景越來越複雜，模型更加精細，這必然給圖形硬體帶來極大的負荷以致於無法達到實時繪製幀率。因此，渲染優化是必不可少的。在渲染優化之前，我們需要對應用程式效能進行系統的評測，找出瓶頸,對症下藥。對於3d應用程式來說，影響效能的十分多，同時不同的硬體配置條件下，瓶徑也會有所不同。因此，對應用程式進行有效的效能評測，不僅需要對整個渲染管線原理有深入地了解，此外借助一些評測工具能讓我們的工作事倍功半。
我們知道渲染流水線的速度是由最慢的階段決定首先，因此對乙個3d應用程式進行評測，首先要分析影響渲染效能的瓶頸是在cpu端還是gpu端，由此來絕對我們優化的物件。由於目前的圖形加速硬體都具有強大的，這個瓶徑往往出現在cpu端，我們可以通過一些工具獲得這個資訊，如nvidia的nvperfhud。在評測選項中，我們可以檢視cpu和gpu繁忙度這項，當cpu繁忙度是100%時，gpu還不是時，我們知道效能的瓶頸在cpu端，我們必須cpu端的操作，同時盡量的「餵飽」gpu，把一些費事的計算移值到gpu上，例如硬體骨骼蒙皮。當gpu端是瓶頸時，說明gpu超荷負載，有可能是因為有過多的渲染填充，也就是多邊形數量太多（當前強大的gpu使得這種情況並不多見。
cpu上的瓶頸產生有兩個方面，一是因為複雜ai計算或低效的**，二是由於不好的渲染批處理或資源管理。對於第一種情況，我們可以利用vturn這類的工具，把應用程式中所有函式呼叫時間從大到小的排列出來，我們就很容易知道問題所在。對第二種情況來說，同樣利用nvperfhud，我們可以檢視每幀的dp數目，看看批的數量是否過多（有乙個具體的換算公式），檢視紋理記憶體的數目，是否消耗了過多的視訊記憶體。利用這些工具，我們基本上能夠定位應用程式的瓶頸。在應用程式內部，編寫乙個內嵌的profiler功能，能更加便利的進行評測，此外利用lua這樣的指令碼程式，讓我們執行時除錯，也能提高評測的效率。
二 靜態場景優化
靜態場景包括了地形、植被、建築物等一般不改變位置的實體集合，對它的優化是場景優化中最重主要的內容。本文就靜態場景優化的常見問題進行了**。
1 批的優化
批是場景優化中的最重要的概念之一，它指的是一次渲染呼叫（dp），批的尺寸是這次渲染呼叫所能渲染的多邊形數量。每個批的呼叫都會消耗一定的cpu時間，對於顯示卡來說，乙個批里的多邊形數量遠達不到最大繪製數量。因此盡可能將更多的多邊形放在乙個批里渲染，以此來減少批的數目，最終降低cpu時間，是批的優化基本原則。然而事情往往不盡如人意，有些情況下原有的批會被打破，造成額外的開銷，如紋理的改變或不同的矩陣狀態。針對這些問題，我們可以採用一些方法來盡量避免它，已達到批尺寸的最大化。
（1）合併多個小紋理為一張大紋理 在某個場景中，地面上有十多種不同的植被，它們除了紋理不同外，渲染狀態都是一樣。我們就可以把它們的紋理打包成乙個大紋理，再為每個植被模型指定uv，這樣我們就可以用乙個渲染呼叫來渲染所有的物體，批的數量就從十多個降為乙個。這種方法比較適合對紋理精度要求不高，面數不會太多的物體。
（2）利用頂點shader 來統一不同矩陣的情況 即使場景中的所有物體材質都一樣，如果它們的矩陣狀態不同（特別是場景圖管理的引擎），也會打碎原有的批。利用頂點shader技術可以避免這種情況，因為可以把要乘的變換矩陣通過常量暫存器傳到shader程式中，這樣統一了物體的矩陣狀態，可以放在乙個批里渲染。
2 渲染狀態管理
渲染狀態是用來控制渲染器的渲染行為，在d3d中是setrenderstate,通過改變渲染狀態，我們可以設定紋理狀態、深度寫入等等。改變渲染狀態對顯示卡來說，是個比較耗時的工作，因為顯示卡執行api必須嚴格按照渲染路徑，當渲染狀態變化時，顯示卡就必須執行浮點運算來改變渲染路徑，因此給cpu和gpu帶來時間消耗（cpu必須等待），渲染狀態變化越大，所要進行的浮點運算越多。因此將渲染狀態進行有效的管理，盡可能 減少其變化，對渲染效能影響巨大。（新六代的顯示卡geforce8系列中將一些常見的狀態引數集儲存在顯示卡核心中，當渲染狀態狀態發生變化，可以直接讀取儲存的引數集，以消除不必要的開銷）。絕大部分的3d引擎都會按照渲染狀態對pass進行分組渲染。
3 lod
lod這個已經被人討論爛掉的技術我就不多廢話了，簡單談談一些實際應用。地形的lod我就不多說了，方法太多了，不過感覺目前情況下最實用的還是連鎖分片的方法。對於模型lod，自動減面的演算法，如vdpm（漸近網格子）並不少見，但是效果都很一般。常規的做法還是讓美工做低模進行替換，對於複雜場景來說，模型lod的效果還是比較明顯的。材質lod就需要一些技巧，例如可以將霧後的物體，包括地形等統一成一種材質，採用霧的顏色，這樣就統一了渲染狀態，至於是否要打包成乙個dp就要看具體情況了（這個統一的材質最好把光照影響關掉，這也是比較費時的）。至於角色模型的lod和普通模型lod相類似，低模減少了頂點數，自然減少了蒙皮計算量。個人認為骨骼lod不是特別的必要，看具體的情況。
4 場景管理的優化
場景管理的優化包括場景分割，可見性剔除等，有很多的參考文章，這裡就不多說了，談些個人的心得。現在的室外場景一般採用quadtree或octree，當我們在效能評測時發現遍歷樹的過程比較慢時，有可能有兩個原因。一是樹的深度設定的不合理，我們可以很容易尋找到乙個最佳的深度。另乙個原因可能是我們為太多數量 眾多，但體積很小的物體分配了結點，造成結點數量的冗餘。解決方法是把這些小物體劃分到他們所在的大的結點中。
可見性剔除是最常見優化方法，我們常用的是視錐裁減，這也是非常有效的。視錐裁減也是許多優化方法，這裡就不詳說了。遮擋裁減也是經常被用到的方法，常見的有地平線裁減。但是在有些情況下，遮擋裁減的效果並不明顯，如當cpu使用率已經是100%時,cpu端是瓶頸，這時進行遮擋裁減計算消耗cpu時間，效果就不明顯。但是有些情況下利用一些預生成資訊的方法，降低遮擋裁減計算的複雜度,提高遮擋裁減計算的效率,對場景效能會一定的改善。
如何理解3D渲染引擎
框架的支援 3d引擎只是動力 在外層需要有完整的框架負責輸入輸出，網路通訊等，平台差異性 物件導向設計 外掛程式擴充套件機制，主要是功能擴充套件，引擎只負責3d效果的展出，實際的產品應用要考慮輸入輸出 網路通訊 其他媒介的支援 其中輸入輸出主要是滑鼠鍵盤，kinect等體感式外設 網路通訊主要是遊戲...
3D引擎中的渲染模組
渲染是3d引擎不可缺少的模組，這兩天在思考如何把這個部分設計好。首先明確需求，最起碼的因該是把圖形api進行抽象風裝，這樣引擎只呼叫經過抽象的渲染介面，這樣便於擴充套件到其他圖形api上，簡單來說就是把gl gles d3d的通用的api抽象出來到crenderbase上，再由此派生crenderg...
3D渲染管線流程
首先用一張圖來回顧一下渲染管線的各個階段，目前為止我們接觸的著色器有頂點著色器和畫素著色器，而接觸到的渲染管線階段有 輸入裝配階段 頂點著色階段 光柵化階段 畫素著色階段 輸出合併階段.可以看到，幾何著色器是我們在將頂點送入光柵化階段之前，可以操作頂點的最後乙個階段。它同樣也允許我們編寫自己的著色器...