1.模型需求

存儲三維模型的文件，通常需要更高效的空間分配，來盡量減少文件的物理體積。

例如一個模型，可能存有position,uv,normal,tangents ... 等等相關信息。

如果簡單的存儲為position數組，uv數組，由于這些數組鐘可能會有重復數據，因此會造成存儲空間的浪費:
?

因此，通過使用一個索引數組，可以更高效的利用有限的存儲空間。

2.渲染需求

在我們使用底層圖形API渲染模型時，首先我們需要將模型讀入內存中。

我們了解到，許多模型通過使用索引來節省存儲空間，而在渲染模型時，我們需要為API提供完整的三角形數據，所以我們需要還原索引為原始的形式。

這樣，某個被周圍三角形公用的頂點有可能會有數份相同的數據在內存中，不僅增加了內存的消耗，也增加了渲染時的消耗。
?

3.解決方案

為了解決模型與渲染需求不一致的問題，我們可以通過在載入模型后，對模型數據進行處理，來使其滿足我們的渲染需求。

在Opengl中，可以通過element_array_buffer來進行Indexed Drawing，即通過一個索引，來減少重復數據，減少帶寬的消耗。
?

接下來，只需要從原始頂點列表中，找出那些擁有相同數據的頂點，將其替換為索引，索引到我們的獨立定點列表，就可以得到符合渲染需求的數據了。

第一時間，我們會想到使用嵌套循環來查找獨立定點數組：
?

不過很顯然，兩個嵌套的循環，其中內循環會隨著時間的推移而增長，賣域名這種方式的CPU消耗非常大。

甚至在發布模式下，處理一個5萬頂點的模型都需要幾秒鐘來完成。

因此我們需要優化其中的內循環，即尋找unique vertex的方法。

如何優化此方法呢？通過查閱知名開源模型解析庫Assimp的相關實現，看到了一個非常巧妙的辦法。

我們可以通過空間排序來解決這個問題，將曾經需要遍歷整個uniqueVertices列表的循環改為一個簡單的查詢操作。

Assimp的實現邏輯大致如下：定義一個隨機平面

• 遍歷原始定點列表
• 存儲頂點到平面的距離，作為排序的key
• 根據距離對處理的定點列表進行排序

這樣，通過這個空間排序的結果，我們可以快速定位到與輸入頂點位置接近的潛在相同頂點列表。

通常情況下，此優化得到的潛在相同頂點列表大小不會超過10個，大大提高了數據處理的效率。

將原本需要數萬此的循環，減少為數十次，成功的完成了我們的渲染需求。

總結

以上是生活随笔為你收集整理的模型解析之独立顶点的筛选的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。