Blender Studio 進行遊戲專案的核心目標之一是驗證並熟悉開源遊戲開發的現狀。由於我們決定使用 Godot 作為引擎(當然,Blender 也作為我們的 DCC),我們必須圍繞這兩個工具建立一個流程,以便一個八人團隊能夠處理遊戲檔案。 在本文中,我將概述我們的想法。
從專案開始,我們就構思了一個理想的流程。其中一個挑戰是,我們的工作室是為電影製作而設立的。我們的工具、基礎設施和團隊的技能組合都面向電影製作。我們越是堅持自己熟悉的領域,就越能有更好的成果。
理想情況下,我們能夠盡可能地利用 Blender,並建立一個流程,使我們能夠在 Blender 中進行資源創建、場景組裝、動畫庫以及基本的遊戲特定定義(例如碰撞)。 Godot 真正被觸及的地方,只有在驗證遊戲內的實際效果時才會用到(當然,除了實現整個遊戲邏輯之外)。
為了實現這一點,我們需要能夠在 Blender 中預覽資源在遊戲中的實際效果。由於我們大部分時間都採用標準的 PBR 工作流程,因此開箱即用,效果非常好。
這種以 DCC 為中心的工作流程在遊戲開發中並不常見。但對我們來說,這是一種正確的方法,讓我們能夠充分發揮自己的優勢。
為了使我們的資源在遊戲文件中可用,我們選擇了 glTF 作為交換格式。這對我們來說是一個顯而易見的選擇,原因如下:
Godot 也支援直接匯入 .blend 文件,但我們決定不使用它。直接匯入資源意味著沒有明確的匯出/發布步驟。因此,工作文件和遊戲資源文件之間沒有區別。這通常可以行得通,但在多人協作時,我們發現明確地將變更推送到生產環境中會很有用。
由於 Godot 的這個功能本身就使用 glTF 作為交換格式,因此將導出步驟明確地納入我們的流程並讓我們更好地控制該流程是一個更好的解決方案。
自動化匯出流程的關鍵方面是使用 Blender 的匯出集合功能。這意味著我們可以設定專用集合來匯出多個單獨的資源,而無需匯出整個檔案。因此,所有資源的匯出設定都可以提前設置,並且可以一次單獨匯出文件中的所有資源。
它還允許將各種附加資料保存在 .blend 檔案中以供參考,而不會污染匯出資料。
棘手的部分在於如何實作資源的嵌套,而不會重複匯出嵌套資源。這就是一些額外自訂程式碼的用武之地。
為了賦予我們必要的控制權,使美術團隊能夠輕鬆地將資源發送到 Godot 並從 Blender 中進行迭代,我們在兩端都編寫了自訂程式碼。
Blender 有一個擴展,可以處理資源的設定和匯出,並提供所有必要的資訊。此外,還有一個 Godot 插件,可確保每次匯入時,使用提供的資料正確地重新建立資源並產生所需的遊戲資料。
您可以在本文末尾找到該程式碼的(非常)初步版本,這對我們來說已經足夠好了,但還不是一個完整的工具。
設定的一個核心原則是,美術師匯出到遊戲檔案的每個資源都只包含自己的直接資料。如果其中嵌套了其他資源(例如集合實例),則應將其替換為引用,並在匯入時在 Godot 中重新建立該引用。
這樣,樹資源及其各個部分就可以在一個檔案中定義(可能每個分支都有一個資源集合),並且樹的實例化和位置可以在單獨的設定檔中定義。集合、樹和分支都是獨立的資源,每個資源的資料只會匯出一次,而 .blend 檔案之間存在的參考會在 Godot 中的匯出檔案之間重新建立。在這種情況下,設定資源實際上只包含其他資源的參考和變換。
我們的實際工作流程如下:
以下是場景設定流程的簡要概述:
以及更詳細的分解:
我們有不同類型的資源,需要根據專案的特定匯出設定進行選擇。這些類型包括角色、資源和動畫。
為了能夠以正確的設定導出到正確的位置,導出擴充功能中有一個初始化按鈕,可以自動設定集合導出器的輸出路徑和所有其他設定。對於任何工作文件,藝術家只需按下初始化按鈕,即可導出。這僅僅依賴於使用正確的命名約定。
{附件 10720} 初始化一個庫文件,其中包含多個嵌套的庫資源,這些資源的集合名稱以“LI-”為前綴。
包含「.blend」檔案的工作目錄結構和包含 glTF 匯出檔案的遊戲檔案是兩個獨立的檔案結構,它們基本上是彼此的副本。
每次匯出之前,Blender 擴充功能都會處理一些必要的事項:
.json 檔案中,以便在 Godot 中透過 ID 找到它。匯出後,擴充功能會將資料重設為可用狀態,以便還原實例化資料。
匯出材質所使用的紋理也會移動到遊戲檔案目錄中正確的相對路徑,以確保重複使用相同紋理的資源不會在整個專案中重複使用。
這一切都是使用一些基本的導出鉤子完成的,導出過程會自動運行。
關於許多可用導出掛鉤的信息,可以在這裡找到。
導入流程完全自動化。 Godot 會自動偵測資源是否有變化,並匯入新的/變更的檔案。
每次發生這種情況時,都必須執行確保資料正確導入的程式碼。
導入插件最重要的任務是:
最終,我們得到了一個 .tscn 檔案的層級結構,每個檔案代表一個資源。這些 .tscn 檔案包含一個引用 Blender 匯出的 glTF 檔案的節點,因此任何變更都會自動取得。它們還允許我們在 .tscn 檔案中分配額外的節點和腳本,以便在 Godot 中手動指定每個資源的遊戲邏輯。
所有材質都已去重,並引用外部資源 .tres 文件,這些文件會在匯入時自動更新。因此,我們 Blender 著色器支援的所有設定都可以在 Blender 中調整並在導入時更新。所有其他僅在 Godot 端生效的設定都在此控制。
我們與一個由多名藝術家組成的團隊合作完成了這個計畫。版本控制也是我們管線中至關重要的一部分。 Godot 會在匯入時產生大量資料。因此,如果一位藝術家提交了導出的 glTF 檔案就完事了,那麼在其他藝術家的機器上,Godot 會自動匯入該檔案並產生匯入資料。
對於獨立開發遊戲的單人來說,這不算什麼問題,但對我們來說,這確實是一個問題。因此,在提交更改之前,每個人都必須在 Godot 中打開遊戲,以便 Godot 有機會創建導入數據,然後將其與新的匯出數據一起提交,這一點非常重要。
我們的方法存在一些問題。如果重新開始的話,我會採取不同的做法。
中央資源索引是一個很大的摩擦點,經常導致合併衝突,因為這是一個需要多人不斷寫入的檔案。
在新版本中,我不會將資源索引寫入需要版本控制的集中位置,而是根據客戶端的資源層次結構動態建構。
另一個問題是,複製資源意味著它們的 ID 也會被複製。我們經常遇到這樣的問題:透過複製索引中已經列出的另一個資源,所建立的多個材質會發生衝突。到目前為止,解決這個問題的唯一方法是在複製後手動刪除 ID。自動化這個過程很棘手,因為我無法連接到複製過程本身,而且之後很難確定哪個是真的,哪個是假的。
如果 Blender 像 Godot 一樣引入 UID,這也可以用於更好地在程式之間進行映射。 (純屬假設…)
材質的匯出方式,導致我們在遊戲檔案中沒有一個統一的材質設定基準。屬性取決於導入的順序。這通常不是什麼大問題,但未來我會將材質的匯出資料分離到它們各自的專用 glTF 檔案中,就像我們對其他資源所做的那樣。
除了我們自己的專案之外,當然還有其他正在進行的努力,旨在實現 Blender 和 Godot 之間流暢的工作流程。其中很大一部分是基於 Khronos Group 領導的 glTF 交換格式的開發,以及該格式在遊戲開發中的各種擴展。
例如,其中一項開發是 用於複雜場景的 glTF。這將取代我們在建置管線時所依賴的大量功能,從而實現不同 glTF 資源的巢狀。
Godot 基金會的各位好心人一直非常熱心地幫助我們,讓計畫成功。即使在專案結束後,我仍然真誠地希望我們能抽出時間聚在一起,找到一種方法來解決我們在製作過程中遇到的一些小問題。
當然,記錄我們的工作固然很好,但實際分享程式碼又是另一回事。
我想確保大家清楚,這只是我們內部為管線構建的一個原型,我們只是以此為原型進行分享,而不是像我們的 Blender Studio Tools 那樣將其作為一個可用的產品進行分享。
要使其成為一個功能齊全、易於使用且足夠靈活以整合到管線中的工具,還需要大量額外的工作。目前,我們更願意將精力投入確保 Blender 和 Godot 支援原生流暢的開箱即用工作流程。
目前還沒有文檔,我們也無法提供支援或使用。
話雖如此,查看程式碼可能對某些人仍然有用,或者您甚至可以親自運行它。
以下是完整的生產程式碼庫,包含匯出 Blender 擴充功能和匯入 Godot 的流程設定。插件:
Blender 檔案 - 9.9 GB - CC-BYdogwalk-repo.zip
加入 並發表評論。