《OpenGL ES 3.x遊戲開發（下卷）》一2.7 固定渲染管線與可程式設計渲染管線實作方案的對比

本節書摘來異步社群《opengl es 3.x遊戲開發（下卷）》一書中的第2章，第2.7節，作者： 吳亞峰 責編： 張濤，更多章節内容可以通路雲栖社群“異步社群”公衆号檢視。

本章最開始提到過，在固定渲染管線平台上想高效地實作本章案例中的特效是非常困難的。這是因為在固定渲染管線中，頂點資料一旦送入渲染管線後就不可能對其友善地自定義處理了。是以，在固定渲染管線上想實作本章案例中的特效隻能采用以下兩種政策之一。

提示 回顧一下，opengl es 1.x（含1.0和1.1）采用的是固定渲染管線，從opengl es 2.0開始采用可程式設計渲染管線。

1．初始化時預先計算資料

此種政策的基本思想非常簡單，就是在初始化時将動畫中每一幀畫面的頂點資料都計算出來，繪制每一幀畫面時将與此幀畫面對應的頂點資料送入渲染管線即可。是以，此政策有兩方面明顯的局限性。

動畫中的幀數不能過多，否則會占用大量的記憶體，導緻程式不能正常執行。由于幀數不是很多，是以對于動态範圍大的動畫就會不太平滑，效果一般。

動畫中的每一幀都是預先計算好的，不能夠根據使用者互動情況的變化而變化，靈活性差。

2．繪制每幀畫面前由cpu臨時計算頂點資料

此種政策其實就是将本章案例中由頂點着色器完成的工作改為繪制每幀畫面前由cpu來完成，這可以解決第一種政策的兩個局限，但它本身也有很大的局限性。因為在這種情況下，cpu一方面需要處理頂點資料，同時還承載了很多處理其他業務邏輯的任務，如人機互動、實體碰撞等，這會導緻cpu不堪重負，整個程式運作很慢。

從上述通過固定渲染管線實作本章案例特效可能采用的兩種政策中可以看出，基于固定渲染管線很難完全發揮出gpu強大的處理能力，是以，整個3d開發産業現在都在向可程式設計渲染管線邁進。讀者在以後的開發中也可以多思考、多總結，将能夠由着色器完成的工作都讓着色器去完成，盡量把cpu解放出來。

筆者也是從固定渲染管線走過來的，那時開發的一些進階的特效，一方面代碼很長，開發成本高；另一方面，運作速度慢，不得不做出很多犧牲。現在有了可程式設計渲染管線，原來的很多限制都不複存在了，相信随着硬體的進一步發展，可以開發出更多、更好的3d特效。