【知識補給站】NVIDIA Blast ：高效破壞模擬，打造真實互動場景！

前言

在現代遊戲產業追求真實感與沉浸體驗的趨勢下，破壞效果成為提升遊戲視覺與互動水準的關鍵元素。Blast 作爲 NVIDIA GameWorks 推出的全新破壞函式庫，專為解決 APEX Destruction 的效能與靈活性限制而設計。不僅提供更高效的破壞模擬，還能透過其【簡潔的架構】與【強大功能】，幫助開發者實現次世代遊戲的破壞效果，讓您的遊戲場景更具【震撼力】與【視覺吸引力】。

本篇內容結合了大量官方文檔的【內容翻譯】與【額外補充】，若有任何錯誤或疑問，歡迎隨時與我聯繫。未來我也會持續更新內容，敬請期待！

NVIDIA GameWorks Blast 是什麼？

【知識補給站】深入 NVIDIA GameWorks Blast 技術：高效破壞模擬，打造真實互動場景！

Blast 是 NVIDIA GameWorks 新推出的一個破壞函式庫，旨在取代 APEX Destruction 模組。它從頭開始重新設計，重點是【效能】、【可擴展性】和【靈活性】。

Blast 的設計目的是將物理效果和圖形處理（大多數遊戲已經做得很好的兩件事）留給應用程式。它以簡化的表示方式處理破壞元素，向使用者傳達更新應用程式中的物理和圖形所需的資訊。這種方法使我們能夠專注於核心演算法的效能，並提供具有健壯且透明的功能行為的函式庫。

Blast 由三層組成：底層 API (NvBlast)、高級「工具包」包裝器 (NvBlastTk) 和擴展（以 NvBlastExt 為前綴）。這種分層 API 旨在縮短首次使用的啟動時間（透過 Ext 和 Tk API），同時還允許有經驗的使用者透過底層 API 進行自訂和最佳化。

NvBlast（底層 API）

底層 API 是一個簡潔的介面，供經驗豐富的開發人員使用，這些開發人員希望在其引擎和 Blast 執行的計算之間保留最薄的層級。它具有由無狀態函數組成的 C 風格 API，沒有全域框架或上下文。函數不會產生任務、分配或釋放記憶體。它們只是使用用戶提供的緩衝區來處理輸入。

支援結構和區塊層次結構

支援結構定義如何將破碎的碎片「黏合」在一起形成角色或物件。Blast 支援結構可能包括來自不同破裂深度的支援區塊，這為開發者提供了比 APEX Destruction 更大的靈活性。

此外，單一資產中可能包含多個區塊層次結構。

傷害著色器

損壞行為完全由使用者提供的「著色器」函數以及相關的（特定於著色器的）損壞參數來定義。

常見的著色器可能會遍歷支援區塊之間的鍵結並削弱它們：

或者，可以定義一個著色器，僅削弱想像中「損壞球體」邊界處的鍵結，從而創造一個科幻風格的切割工具。

函數的編寫者可以選擇根據損壞方向和鍵結法線以不同方式處理損壞，從而允許材料展現不同的【剪切強度】與【壓縮強度】。

NvBlastTk（高級工具包）

高級工具包封裝了底層 API NvBlast，並提供了強大的新功能。它具有帶有全域框架的 C++ API，能透過使用者提供的分配回調來管理【物件】和【記憶體】。

群組與平行處理

NvBlastTk 提供了一個 Actor 群組對象，允許包含任意組合的可破壞 Actor。使用者可以根據需要將 Actor 加入或移出群組。群組的設計目的是作為一個處理單元。在處理過程中，群組會產生任務來計算所有累積傷害對其 Actor 的影響，並透過事件回調將結果傳遞給使用者。

這些任務可以並行運行，群組之間也能同時進行處理，充分利用多核心處理器的能力來提升效能。

關節

NvBlastTk 引入了「關節」的表示形式。關節可以被定義於以下情境：

單一 Actor 中的支援區塊之間。
不同 Actor 的支援區塊之間。
Actor 的支援區塊與靜態世界之間。

當透過關節連接的 Actor 發生斷裂時，關節會重新附著到不同的 Actor（或在某些情況下不再連接任何 Actor）。這些變化會透過事件系統傳達給使用者，以便更新物理表示。同樣的 Blast 對於應用程式使用的物理表示仍然保持中立（agnostic）。由使用者決定要創建何種類型的物理關節，以及何時或是否斷開關節。

關節允許在可破壞物體上創建各種不同的物理行為，例如從門鉸鏈到釘子，從擺動的枝形吊燈到柔性物體。在我們的範例中，我們在可破壞板材的所有支援區塊之間建立了「內部」關節。當板材斷裂成碎片時，關節變得活躍，並將碎片連接在一起，形成一個類似布料的物體，產生驚人的效果：

NvBlastExt（擴展功能）

Blast 擴展功能是針對【NvBlast】和【NvBlastTk】的實用程式庫。其原始碼旨在作為有用功能的參考實現。這些擴展功能的設計已經足夠成熟，可以直接用於生產環境中的程式碼，但某些使用者可能會根據自己的需求對擴展功能進行修改。

當前的 Blast 擴展功能包括：

ExtPhysX
- 一個基於 PhysX 的物理管理器，能夠在使用者提供的 PxScene 中更新【PxActors】和【PxJoints】。
- 它處理衝擊損壞（透過接觸回調）、包含壓力求解器，並提供一個偵聽器，使多個客戶端能夠保持其狀態同步。
ExtAuthoring
- 一組幾何工具，能夠以分層方式分割網格並建立 Blast 資產。
- 它還支持生成【碰撞幾何】和【區塊圖形網格】，並將這些資源存儲在單獨的檔案中。
ExtConverterLL
- 用於低層資產和 Actor 系列的資料格式轉換器。
- 這個簡單的轉換器允許使用者定義自己的轉換函數進行轉換。
ExtImport
- 提供匯入 APEX 可破壞資產以建立 Blast 資產的功能。
ExtSerialization 和 ExtSerializationLL
- 分別針對 Tk 和底層提供的序列化擴展。
  它使用 Cap'n Proto，能夠在不同平台之間實現穩健的序列化。
ExtShaders
- 範例損壞著色器，可傳遞給低層和 Tk Actor 的損壞函數，用於模擬損壞行為。

應力求解器

ExtPhysX 中的應力求解器是一項強大的功能，其效能（以及功能）顯著高於 APEX Destruction 的對應功能。利用應力求解器，使用者可以結合結構中的內部應力以及來自衝擊和用戶施加的外部應力，確定 Actor 應在哪些弱點位置發生斷裂。

在一面斷裂牆的應力視覺化中，可以看到當施加向上的外力（白線）時，內部應力（彩色線段）的分佈情況。

由於內部應力，桌腳在被彈體擊中後，斷裂的位置出現在其與桌面的連接處，而非撞擊點。

創作與向後相容性

ExtAuthoring 擴展功能提供了強大的 CSG（構造實體幾何）功能，用於分割網格，並提供工具以確定任意網格之間的連接性。這使得使用者可以從任何來源匯入斷裂網格，並在支援區塊之間建立具有適當鍵結的 Blast 資產。

此外 ExtImport 擴展功能可以從 APEX Destructible 資產建立 Blast 資產。

APEX 資產僅包含區塊之間是否連接的數據，但 ExtImport 將進一步確定鍵結表面的【面積】和【法線】，這些數據會由 Blast 儲存，並可供損壞著色器函數存取。

透過導入器，使用者有機會在 Blast 中重複使用 APEX 資產，並且如果需要，還可以繼續在 PhysXLab 中創作可破壞物體。

與 APEX Destruction 的效能比較

為了在 Blast 和 APEX Destruction 之間進行公平比較，我們設置了相同的測試場景，並使用可比的（徑向）損壞，在兩個破壞庫中應用相同的時間和位置。

由於 APEX Destruction 在模擬步驟中管理物理 Actor 的建立和圖形更新，因此我們對這些操作進行了詳細的內部計時，並從模擬計時中減去它們，以獲得更準確的 APEX 效能計時。在實際應用中，物理和圖形的更新是必要的，因此我們也比較了 Blast 和 APEX 在這些操作上的耗時。我們這樣做的原因有兩個：

確認兩個測試場景中的場景複雜度相似。
確保我們考慮了所有與破壞相關的成本，從而進行公平比較。

此外我們還希望測試不同規模的破壞，因為 Blast 的設計目標之一是能更好地處理大規模破壞。所以我們使用了兩種不同的資產：一種具有較低的區塊數量，另一種具有較高的區塊數量。下圖說明了測試設定。

我們的測試場景包含十面牆，排列為兩排，每排五面。我們測試了低細節的牆體資產（左），其斷裂後分成大塊，以及高細節的牆體資產（右），其斷裂後分成更多的小塊。

測試中的牆壁沒有透過擴展支援（APEX 的一項功能）連接。由於 Blast（按設計）不具備此功能，因此我們關閉了擴展支援以進行有效的比較。

低細節資產的支援區塊層次結構為深度 2，而高細節資產的支援深度為 3。低細節資產具有 81 個深度 2 的區塊，而高細節資產約有 1,000 個深度 3 的區塊。所以高細節支援圖比低細節圖的複雜性高出一個數量級。如上圖所示，額外的支援阻止了許多深度 3 的區塊變為動態並進入模擬（儘管高細節情況下仍然存在顯著更多的剛體）。然而我們的主要關注點在於支援圖的操作複雜性，因為這是損壞計算的核心。

我們的測試僅使用了底層 Blast 的 SDK，未包含任何同時的 Actor 損壞操作，因此不涉及高級 (Tk) Blast 庫中的多執行緒損壞功能。

測量與結果

每次測試會依次對十面牆的中心施加徑向損壞，每隔一百幀損壞一面牆。我們在每一幀中測量以下數據：

破壞函式庫的執行時間
PhysX 模擬耗時
圖形更新耗時
活躍形狀數量
交互形狀對數量

結果如下所示：

小規模

使用低區塊數資產時，Blast 的結果如下所示：

APEX Destruction 的相應結果如下：

大規模

使用高區塊數資產時，Blast 的結果如下所示：

APEX Destruction 的相應結果如下：

分析

對於小規模設定，在第 1,000 幀完成第十次損壞應用後，Blast 和 APEX 測試分別產生約 700 個活動形狀（對應於相似數量的 Actor）和約 2,000 對交互形狀。PhysX 的模擬時間大約為 1.5 毫秒。

在第 1,000 幀後，Blast 的渲染設定耗時穩定在約 250-350μs，而 APEX Destruction 則需要約 400μs。從 APEX 的時序中可以看出，其大部分時間都花在渲染設定上。而 Blast 在損壞幀之間不會被呼叫，因此額外的開銷為零。

但是在損壞幀上，Blast 和 APEX 都會進行大量計算。Blast 在這些幀上消耗約 200μs，而 APEX 則在其模擬步驟中增加了 1.5 毫秒來執行損壞計算。

對於大規模設定，在第十次損壞應用後，Blast 和 APEX 測試分別產生超過 1,000 個活動形狀和超過 7,000 對交互形狀。PhysX 的模擬時間約為 5-6 毫秒。

Blast 的渲染設定時間穩定在約 1.0 毫秒，而 APEX 的渲染設定時間約為 1.2 毫秒。可以看出，APEX 的大部分時間消耗在渲染上，但 APEX 每幀仍存在顯著的額外開銷，約為 1 毫秒。

在損壞幀上，Blast 消耗約 600μs，而 APEX 在其模擬步驟中增加了 6 到 9 毫秒。

我們的結論是，即使在小規模破壞場景中，Blast 的效能表現也遠優於 APEX，且隨著可破壞 Actor 的複雜性增加，Blast 的效能優勢顯著提升。

物理模擬和渲染設定時間的開銷在 Blast 和 APEX 測試中相當，這是預期中的結果。但在 Blast 中，這些操作完全在應用程式內完成，為【用戶優化】和【自訂引擎】提供了更多可能性。

這些測試結果讓我們對提升【效能】、【可擴展性】和【靈活性】的努力充滿信心。

了解更多

請參閱最新的發行說明。
閱讀 Blast API 的詳細資訊。

NVIDIA GameWorks Blast 相關介紹 & 教學影片

參考文獻

【NVIDIA GameWorks Blast】

官方文檔：NVIDIA GameWorks Blast

【探索创新破坏效果：NVIDIA 的 Blast 库】

CSDN - 专业开发者社区：探索创新破坏效果：NVIDIA 的 Blast 库

【NVIDIA 可破坏开源库测评】

UWA 社区：探索创新破坏效果：NVIDIA 可破坏开源库测评

覺得文章有用

給作者鼓勵

收藏這篇文章

本文原創(或整理)於亞洲電玩通，未經作者與本站同意不得隨意引用、轉載、改編或截錄。

特約作家簡介

JamXu

十年遊戲研發

二十年遊戲台主

三十年遊戲玩家

經中華網龍遊戲企劃進入遊戲圈，然後被雷打到去學程式前後端又學了點設計再帶帶幾個研發團隊，見證了 3D 渲染技術及遊戲引擎互相進步，也見證了研發代理的更迭與博弈遊戲的興起，再毅然研究起 SEO 網路行銷與社群廣告投放，深信自研自賣才是最大贏家，期望能為台灣研發重回輝煌時光貢獻一點力量。如果你也有遊戲夢，歡迎交流認識。