默認的OpenGL ES映射到屏幕的坐標為左下角（-1.0，-1.0）右上角（1.0，1.0）。如果沒有坐標變換的話，那么我們繪制出的物體坐標以及大小并不能按我們所想。
在OpenGL ES2.0及以后的版本中，都采取可渲染管線編程。好處是可以編程控制GPU處理頂點數據，得到各種牛逼炫酷帥的效果，麻煩的地方就是坐標轉換等等都要自己去編程處理。其實想想也對，目前CPU和GPU的處理速度完全不在一個檔次上，GPU的瓶頸在于每次等待CPU數據傳輸的時間。那么，把大量的數據一次性送入GPU，然后在GPU中實現快速運算就成為理所當然的考慮了。這就是采用GPU編程的好處。
OpenGL采用列向量以及列矩陣表示數據。例如：
因此，OpenGL中都是采取左乘。例如將一個物體先旋轉再移動（這里假設旋轉矩陣為R，移動矩陣為T，物體坐標向量為v），正確的操作順序就應該是
從3D模型到屏幕的成像所經歷的變化是 模型坐標 -> 觀察變換 -> 視圖變換 -> 剪裁 -> 視口變換。其中，需要我們編程處理的是觀察變換以及視圖變換這兩步。
那么，既然x，y，z就可以表示三維坐標，為什么還要有w分量。w分量是用于處理平行的兩條線交于一點的問題。既然平行為什么會相交？因為在透視觀察中，會發現一個有趣的現象就是當兩條平行的直線延伸到很遠的點的時候，看起來就是匯聚于一點的。為了解決這個問題，引入w分量。
另外采用矩陣相乘的形式會引發萬向節鎖的問題。這個問題我沒研究過，就不班門弄斧了。等研究了之后再談這個問題。
一個模型要轉換為屏幕坐標的編程處理過程為：
好了，經過上面的鋪墊，開始進入正題——開啟iOS的深度測試（這部分很短）。
原本以為iOS中深度測試就是一句glEnable(GL_DEPTH_TEST)就可以搞定的。
結果繪制出來的圖像，前后面上下面順序什么的亂七八糟?？傊褪乔昂竺嫔舷旅骓樞蛲耆e了，完全不像有深度測試的感覺。最后意識到是深度測試沒搞定，于是搜了一些資料。處理完成后整理如下：
和顏色緩沖不同的就是使用glRenderbufferStorage()函數進行分配的時候，需要指定緩沖區的寬高。其中第二個參數表示計算精度，值越高越平滑，當然內存也消耗的更大。
接下來關聯深度緩沖到幀緩沖區
完了？
我也以為完了，結果渲染出來不是黑屏就是粉紅色?。?！然后找了一份源碼看了一下，發現后面還有一句
加上，正確渲染了。
不明白為什么，希望高手賜教。
最后渲染結果如下（我加了光照）：
可以在Github上下載到代碼，運行環境為MacOS 10.12.4 Xcode 8.3.1
