淺析遊戲引擎的資源管理機制——扒一扒Unity3D中隱藏在背後的資源管理

　　遊戲中一般有大量資源，如網格、材質、紋理、動畫、着色器程序和音樂等，遊戲引擎做爲作遊戲的工具，天然要提供良好的資源管理，讓遊戲開發者用最簡單的方式使用資源。遊戲引擎的資源管理包括兩大部分：離線資源管理和運行時資源管理。本文僅對前者進行簡要介紹，並結合Unity3D和OGRE進行分析。

資源創做與導出

　　遊戲中的資源由各類數字內容創做工具（DCC, digital content creation）進行創做，如：

• 三維模型：3ds Max，Maya等；
• 紋理：Photoshop等；
• 音樂：Sound Forge等；
• ………………

　　DCC每每支持多種導出格式，如：

• 3ds Max：3DS、AI、DDF、DEM、DWG、DXF™、HTR、FBX、IAM、IGES、IPT、LP、LS、MTL、OBJ等；
• Photoshop：PSD、TIFF、EPS、PCX、GIF、JPEG、PNG、PICT、TGA等；
• ………………

　　遊戲引擎通常會支持指定DDC的部分導出格式，例如Unity3D支持3ds Max導出的FBX格式；或者針對特定資源創做工具編寫導出插件，例如OGRE有多種三維建模軟件的導出插件。雖然基本上全部DCC都支持多種導出格式，可是不少狀況下這些格式都不適合遊戲引擎，由於

• 導出的內容過於複雜，遊戲中只用到其部分數據，而遊戲每每對性能的要求比較苛刻，因此須要去除冗餘數據；
• 許多DCC導出的格式讀取比較慢，並且還有一些是封閉格式致使引擎沒法讀取。

　　所以，在DCC導出資源後，須要引擎進一步處理，將資源轉換爲引擎的內部格式，這種處理被稱做Asset Conditioning Pipeling。使用Unity3D的童鞋應該會發現，每次導入資源的時候都要讀條，就是在進行Asset Conditioning Pipeling；OGRE在這方面的支持不夠完善，這部分工做由自定義的導出插件完成。

資源的「編譯」與「連接」

　　因爲導出的資源存在一些問題，須要進行必定的轉換，這個轉換被稱做Asset Conditioning Pipeling，包括2個步驟：

• 資源「編譯」

　　讀取單個資源的數據，將其轉換爲遊戲中能夠直接使用的格式（使用效率最高或較高的格式），例如從新對Mesh的頂點進行排序，或使用BC5等壓縮算法對紋理進行壓縮。這個過程與C語言的編譯有些相似，所以取名爲「編譯」。固然，若是導出的資源能夠直接使用，那麼能夠跳過這一步。

• 資源「連接」

　　在遊戲中，許多資源並非單獨使用的，例如三維模型，它引用的材質和紋理是單獨存在的資源。在上一步中，引擎對單個資源進行「編譯」，將其轉換爲能夠直接在遊戲中使用的格式；這個步驟將全部的資源進行「連接」，使得遊戲在運行時能夠找到每一個資源所依賴的全部資源，例如三維模型能夠正確的找到其須要的材質和紋理。這個過程與C語言的連接有些相似，所以取名爲「連接」。固然，若是導出的資源能夠直接使用，那麼也能夠跳過這一步。

　　

　　Unity3D對這部分提供了比較完善的支持，所以只須要導出引擎所支持的標準資源，並放入Assets文件夾，引擎會對其進行「編譯」和「連接」，結果就在Library文件夾中（裏面亂七八糟的，雖然咱們看不懂，可是Unity3D很喜歡）；OGRE沒有提供專門的Asset Conditioning Pipeling工具，所以全部操做都在資源的導出插件中完成，沒有進行單獨的「編譯」和「連接」。

資源管理數據庫

　　在資源經過Asset Conditioning Pipeline以前，引擎須要存儲處理該資源的方式，通常使用metadata（元數據）來描述，例如指定某個紋理應該是以何種方式壓縮。引擎經過資源數據庫來管理metadata，資源數據庫既能夠簡單的使用XML文件進行描述，也可使用MySQL等數據庫。遊戲開發者經過引擎提供的接口實現資源的從新配置，例如在Unity3D編輯器中能夠修改Mesh的壓縮方式，選擇是否優化Mesh等。

　　遊戲引擎的資源數據庫通常要提供以下功能：

• 建立和刪除資源；
• 查看和修改現有資源；
• 將資源移動到其餘路徑；
• 支持資源的相互引用，而且在被引用資源移動路徑後，保證引用有效；
• 提供多種便捷的查找資源的方式。

　　使用Unity3D的童鞋能夠發現，Unity3D提供了比較完善的資源管理的功能，使用起來比較輕鬆。

資源讀取（運行時）

　　在開發過程當中，全部原始資源以單個文件形式進行保存，以方便修改，可是在遊戲運行讀取資源的時候，爲了加快讀取速度，通常會將資源打包成一個或多個文件。打包的緣由很簡單，從硬盤中讀取文件的時間中，主要由三部分組成：

1. 硬盤尋道時間；
2. 打開文件的時間；
3. 讀取文件的時間。

　　最後一項是不可能改變了，除非使用速度更快的存儲介質；可是將多個文件打包成一個文件，能夠縮短前面兩項的時間。Unity3D在發佈遊戲的時候，會將資源進行打包；OGRE沒有自定義打包資源的方式，通常打包爲一個或多個ZIP文件，或不打包資源。

實例分析

Unity3D

　　拷貝Unity3D工程的時候，必定要拷貝「Assets」、「Library」和「ProjectSettings」文件夾。資源都在「Assets」，設置都在「ProjectSettings」，「Library」是來打醬油的？非也！若是不拷貝「Library」，打開工程之後你必定會大吃一驚，以前的設置全沒了？！並且場景文件裏的東西也是亂成一團！結合上文，則很容易理解這種詭異的現象，明白爲何少不了這個「打醬油」的「Library」。

　　將資源放入「Assets」文件夾，切回Unity3D，則進入Importing Assets狀態（進行Asset Conditioning Pipelining），以下圖

導入資源

　　在這個步驟中，Unity3D針對全部的資源生成metadata，並進行「編譯」、「連接」，轉換爲遊戲能夠直接使用的資源。轉換前的資源保存在「Assets」中，轉換後的資源保存在「Library」中，全部的資源在Inspector面板中能夠修改metadata的數據，以下圖

「Library」文件夾

Inspector

　　若是使用SVN等版本控制器，須要同步全部資源及其metadata。打開Edit->Project Settings->Editor，將Mode修改成「Meta Files」（默認「Disabled」），以下圖

選擇「Meta Files」

　　Mode修改成「Meta Files」後，回到資源文件夾，會發現每一個資源都多了***.meta文件，以下圖，而這些.meta文件保存了這些資源將如何被Asset Conditioning Pipeline處理。

帶metadata的資源文件

　　如今Assets文件夾中不只有全部的資源，並且還有對應的metadata，「Library」完全打醬油了，此時在拷貝工程或使用SVN同步工程時才能夠忽略「Library」文件夾。

　　在發佈的遊戲中，資源文件以下圖所示。能夠發現，Unity3D對資源進行了打包，以減小資源載入時間。

發佈後的遊戲資源

　　總的來講，從導入資源，生成metadata，「編譯」、「連接」資源，再到發佈遊戲時打包資源，Unity3D都封裝好了，以最簡單的方式提供給咱們使用，極大的提升了遊戲開發者的工做效率。雖然可能第一次在用的時候只是感受Unity3D用的比較簡單，但它確實在背後作了不少工做，只是咱們沒注意而已。

OGRE

　　OGRE在這方面的支持與Unity3D相比差距比較大，只提供了資源的導出插件；發佈的遊戲中，可使用ZIP對遊戲資源進行打包，未提供自定義資源打包方式。固然，整體來講，它是一個至關不錯的圖形引擎，最重要的一點是，它是開源的。