Source 2 把 BSP 變成 mesh 流程

我以前看 Source 地圖，最煩的不是畫圖，是 compile。brush 一多，BSP 一卡，整個流程像在跟老引擎磨性子。等我翻到 Source 2 的說明，我才知道那股不對勁從哪來：它根本不是沿用舊腦袋在做事。

Source 2 把 Source 時代的 BSP brush 思維換成 mesh 和 octree 分割。

這篇的觸發點是 Valve 官方開發者維基的 Source 2 頁面。那頁沒有包裝話術，直接寫了幾何模型的變化：BSP 和 brushes 被 meshes 取代，空間分割則改成 .vwnod_c 這種 octree 格式。這句話很短，但夠我把整個理解框架翻掉。

我接下來要拆的不是「新引擎很厲害」這種空話。我只看一件事：幾何怎麼表示、空間怎麼切、這會怎麼影響我做 level、看效能、跟團隊溝通。這些才是開發者真的會撞到的地方。

我不再把 Source 2 當成 Source 1 的升級包

BSP and Brushes ... has been replaced with meshes, and BSP is replaced with octree (.vwnod_c) for geometry partitioning.

翻譯一下就是：Source 2 不是把舊 brush 流程換個皮而已，它直接換掉了底層幾何的思考方式。以前你會先想 brush、再想 compile、再想 BSP 的後果；現在這條路徑被打散了，幾何更偏向 mesh，空間切分則交給另一套結構。

我以前最常犯的錯，就是看到熟悉的引擎名字，就自動套用舊習慣。結果一進工具、流程就開始卡：為什麼這招不靈？為什麼我以為能省事的做法，最後反而更麻煩？答案通常很無聊：因為底層模型早就變了。

實操上，我現在看 Source 2 專案，第一個問題不是「這裡有沒有 brush 對應物」，而是「mesh 是怎麼進來的，partition 是怎麼切的」。這個順序很重要。你先抓住幾何與分割，才不會把老 Source 的肌肉記憶硬套到新架構上。

• 不要先找 brush 翻版。
• 先看 mesh 的輸入、生成、更新流程。
• 把 partition 當成獨立系統看，不要把它當成 brush 的副產品。

BSP 不是檔案而已，它一直在管你的腦袋

很多人講 BSP，好像只是 map container。其實不是。它一路影響的是設計方式、編譯方式、除錯方式，甚至你怎麼想一張地圖的結構。Source 和 Quake 系列把這件事綁得很緊：你先用 brushes 搭世界，再把世界丟進 BSP 邏輯裡處理。

Valve 在 Source 2 頁面直接把這條老路線換掉，這件事很誠實。它等於在說：舊 brush-first 的限制，現在不想再背了。這對我這種常碰 level pipeline 的人很有感，因為很多「明明很簡單卻很難做」的問題，根本是幾何表示法自己在找麻煩。

我以前做老 Source 內容時，常遇到一種很煩的狀況：editor 裡看起來很單純的空間，compile 後卻變成一堆維護成本。不是你設計差，是 brush、vis、compile artifact 這些東西一起把你拖住。Source 2 把 mesh 拉上來，就是在減少這種拖曳感。

實操寫法很簡單：如果你在做 Source 2 相關工作，先把「外觀長什麼樣」跟「引擎怎麼切空間」分開想。這兩件事在舊系統裡常常綁一起，在新系統裡最好不要再混在一起。

• 用 mesh 思維去看形狀，不要先想 brush 拼法。
• 不要把舊 Source 的 compile 經驗當成萬用答案。
• 讀文件時，把 partition 規則當成第一級資訊。

Mesh 讓作者壓力從編輯器轉到資產流程

mesh 的好處不是「比較現代」這種廢話。真正的差別是，它比較接近很多美術和技術美術本來就熟的工作方式。你不用一直把一個空間想像成 editor primitive 的拼圖，而是更像在處理一個可控的資產。

也就是說，壓力會從「怎麼把 brush 搭對」轉成「資產流程乾不乾淨」。拓樸、命名、collision、import 規則、後續可不可以安全修改，這些都會變成更核心的問題。這不是比較輕鬆，只是麻煩換了位置。

我以前看過團隊花很多時間，想把 brush 流程硬做得像 DCC 工具。很彆扭，真的很彆扭。Source 2 這種 mesh 取向，至少承認了一件事：很多空間幾何本來就比較適合用資產管，而不是用一堆原始 brush 去拗。

實操上，如果你在做工具或內容，我會先把下面幾件事問清楚：

• 上游接受哪些 mesh 格式？
• 匯入時會生成什麼資料？
• collision 和 visual geometry 要不要分開？
• 匯入後哪些東西還能改，哪些一改就炸？

Octree 才是我看效能時會先盯的東西

Source 2 頁面提到 BSP 被 .vwnod_c 的 octree 分割取代。這句話對我來說，比「新引擎支援更多功能」重要多了。因為 partitioning 決定的是空間怎麼被組織、哪些東西該先算、哪些東西可以先略過。

翻譯一下就是：如果你不懂空間怎麼切，你就很容易把效能問題怪錯地方。你可能去怪燈光、怪道具、怪材質，但真正的問題可能是幾何分區的方式跟你想的不一樣。這種坑我踩過，凌晨兩點還在盯 profiler，最後才發現自己一直看錯層。

我不會假裝單靠這一頁就能把 Source 2 的 octree 實作講完，官方也沒寫那麼細。但它已經夠我知道一件事：不要再用老 BSP tree 的直覺去猜整個空間結構。那樣很容易誤判。

實操寫法是：你在看 Source 2 場景效能時，先看空間分割，再看資產疊太多還是光源太多。若 partition 本身就不乾淨，後面再怎麼微調都只是補洞。

• 把相關幾何盡量放在合理的空間群組。
• 不要把無關且重的東西硬塞同一區。
• 效能怪異時，先查 partition，再查其他項。

舊 Source 的老招，到了這裡很容易失靈

我最怕的，就是大家把引擎換成 Source 2，腦袋卻還停在 Source 1。這種情況很常見：檔名、工具名、專案名都變了，但你還在用舊時代的假設做決策。結果就是，很多看似合理的做法，在新系統裡根本不成立。

這篇 Source 2 的幾何說明，其實就是在提醒你這件事。BSP 和 brushes 不再是中心，代表你原本那套 level 直覺只能部分沿用。你還是可以帶走一些經驗，例如閱讀空間、控制動線、判斷複雜度，但實作層面不能再偷懶。

我自己也吃過這種虧。人一熟悉某個引擎家族，就會以為自己懂了。直到某個架構改動把半套習慣打碎，你才發現自己根本是在拿舊地圖找新出口。Source 2 這頁至少把這件事講明白了，沒跟你演。

實操上，我會在開工前先做一輪假設盤點：

• 我是不是還在用 brush 時代的限制想問題？
• 我是不是在優化 compile，而不是看 runtime partition？
• 我是不是把 imported mesh 當成 editor primitive？
• 我是不是用 Source 1 的肌肉記憶在讀 Source 2？

如果是我帶團隊，我會先把這份契約寫死

假設我今天加入一個 Source 2 團隊，我會很快把 level design、technical art、engine 這三邊拉到同一張桌子。因為 mesh、octree、collision、import 規則這幾件事，只要有一個人自己腦補，後面就會開始各做各的。

我不想聽「之後再對齊」。這種話通常代表沒人真的定義清楚。對我來說，最實際的做法是先把內容契約寫出來：哪些是 mesh，哪些是生成物，哪些是 runtime 才會決定，哪些一進匯入就不能亂動。

這樣做有點煩，但很值得。因為你一旦把規則寫清楚，很多莫名其妙的問題會直接少一半。不是因為世界變簡單了，是因為大家終於知道自己在交什麼東西。

實操寫法：做一份短版 pipeline 文件，先不要求漂亮，只求能用。內容至少要能回答：

• 誰負責建 mesh？
• 誰負責 partition 相關設定？
• collision 怎麼來？
• 哪些資料是 bake 後固定的？

可抄的模板

# Source 2 geometry pipeline brief

## 1. 幾何原則
- Level geometry 以 mesh 為主，不以 brush-first 工作流為主。
- 空間分割視為獨立系統，不跟視覺幾何混成一團。

## 2. 資產流程
1. 由 DCC 或 mesh-aware 工具建立空間與結構。
2. 保持拓樸乾淨，避免不必要的碎片化。
3. Visual geometry 與 collision 分開管理。
4. 依專案規範輸出 mesh。
5. 匯入後確認 partition 與 bake 結果。

## 3. 上線前要先回答的問題
- 哪些幾何是人工 author 的？
- 哪些幾何是工具生成的？
- partition 資料從哪裡來？
- collision 從哪裡來？
- 哪些資料在 bake 後就不該再改？

## 4. 團隊檢查清單
- [ ] 沒有把 brush-era 假設寫進新文件
- [ ] mesh import 規則有明確定義
- [ ] partition 期待值有寫清楚
- [ ] collision 規則有寫清楚
- [ ] 有針對空間複雜度的 profiling 計畫

## 5. 送給團隊的一句話
Source 2 需要 mesh authoring 與 octree partitioning 的共同紀律，不能只靠舊 Source 習慣硬撐。

上面這段不是 Valve 官方流程，是我根據官方 Source 2 說明整理出來的可執行版本。原始來源給我的是架構線索，我把它翻成團隊可以直接拿去開會的格式。

原始資料先看 Valve 官方頁面：https://developer.valvesoftware.com/wiki/Source_2。如果你想補背景，我也會一起看 BSP、Octree、Quake 這幾個頁面；本文的拆解是我自己的整理，模板是我衍生出來的工作版。