粒子系統是增強開發視覺效果的關鍵工具。然而，過多的粒子數量往往會增加 CPU、GPU 的負擔，導致性能下降和卡頓現象。升級與迭代粒子系統，幫助開發者更好地處理大量粒子成了引擎設計中的重要內容。在 2024 年 Unity User Group 北京站活動中，Unity 中國 DOTS 技術主管李中元、Unity 中國 VFX 團隊工程師陳冰玉向開發者們分享了《10w 量級粒子的模擬與渲染》，介紹團結引擎粒子系統的設計目標與實現思路。

對于一個粒子系統來講，有些典型特點，首先是它數據量大，二是它模擬的對象都是很相似而且很簡單的。它會有非常高頻率的產生和銷毀，伴隨大量相同半透明物體的渲染。這也就意味著粒子系統會同時給CPU、GPU造成壓力，所以粒子系統做得好與不好，對 CPU、GPU 兩方面都有很高要求。

Unity 內置的粒子系統用得非常廣泛，在社區里非?；钴S，在Asset Store約有4000多款插件。所以如果大家想獲得 Unity 粒子系統特效的話，可以直接從 Asset Store 里購買到相應的、需要的資源，微調一下就可以拿來自己用。

因為 Unity 內置粒子系統其實在 Unity 5.X 的時代就已經在開發，一直維護到現在有十幾年的歷史，也就意味著它是背負著一些負擔。比如它是基于 OpenGL ES2.0，而且它的線程模型是個單線程模型。如果說在一個粒子系統內，它整個模擬都是以單線程的方式做的，這也就意味著限制了它模擬的粒子量級在萬的級別。

我們現在做了團結引擎之后有了一個機會，用更現代的方式實現過去粒子系統相似的功能，能夠在實現相似功能的基礎上表現更好。我們提出了新的目標要做 10w 級別的粒子系統。

10w 量級粒子的模擬

粒子系統同時對于 CPU 和 GPU 都有壓力，先看一下 CPU 部分。

我們目標是 10w 量級的粒子，它跟萬量級的粒子由于量變，在很多做粒子系統的時候，我們的決策就會產生一些質變。

這里我會舉兩個例子，首先是粒子的生成和銷毀，二是粒子里非常重要的一個計算，就是它的曲線采樣，我們在這方面也做了比較好的優化。

1.粒子的生成和銷毀

我們來看一下內置粒子系統的內存結構，它在生成和銷毀時的表現是什么樣的。首先 Unity 內置粒子系統有兩種內存模式，一種是數組。PositionX 數組、Y 數組、Z 數組，他們是以 SOA 的方式組織在內存里，就是有 3 個數組。還有一種是模式是RingBuffer，RingBuffer 跟數組非常像，只不過它們在用完之后會復用前面的數據。

創建的時候，數組是固定容量的，當粒子生成到達數組上限的時候，就需要創建一個新的數組，把老的數據進行拷貝，把老的數據進行銷毀，這是非常正常的開銷。但是，當粒子數量越來越多的時候，這個開銷實際上是一個線性增加的。而且大家能看到，這時候內存的增長，在一個瞬間會同時存在老的數組和新的數組，拷貝完了之后才能把老的數組刪掉。也就意味著會有個內存高峰。

RingBuffer 相對比較簡單，用滿之后會直接復用前面的，也就意味著 RingBuffer 粒子數量的上限是固定的，不會再增加了。

再來看銷毀，對于數組模式，比如中間這個被銷毀掉了，我會采用 Swapback 的方式把后面的數據復制到前面來。但是這樣也會有一些奇怪的事情，比如只能在單線程里做這些事情，因為 Swapback 的順序決定了最終數據長得甚至不一樣，比如把最后一個挪到這兒來和倒數第二個挪到前面來得到的結果是不一樣的。

在 RingBuffer 情況下直接選擇了躺平，就意味著它是犧牲了最終模擬的準確度，保證數據不出問題。在 RingBuffer 情況下不會真正刪除數據，比如這里提供兩種模式，一是 Pause，粒子的生成周期到了之后就停在那兒，不再動了，直到它被復用掉；另一個是 Loop 模式，直接在這個位置出生一個新的粒子，其實也是犧牲了模擬的精度，做到不會產生內存的 swapback，其實都是以一種犧牲模擬效果的方式換取更高的效能。

我們現在想采用分治的想法，以 128 個粒子為單位，組成了一堆內存分組，比如前面的每三格是 128 個 X。當我再去都用完之后，會再生成一組新的內存，把它們連接在一起。比如 10w 粒子大概有 780 段的內存，這樣就可以規避掉前面所說的不管是數組也好，還是 RingBuffer 也好它們的缺點。

這里對內存的分配有個特點，128 個粒子內存永遠是一樣大的，就意味著對內存的管理提出了更高的要求，我需要內存的分配更快。還要付出更加復雜的代碼管理這些內存的分段。這 128 個內存大小是一樣的，大小是 128 個數組，都是以 SOA 的方式存儲的。

為了實現更高效的內存管理，我們自己實現了定制化的內存 Allocator。這是我們測試的性能數據，這三個實際上是 Unity 給我們提供 3 種內置的內存分配器，分別是 Persistoent、Tempjob、Temp，TileAllocator 是我們團結引擎自己實現的內存分配器表現，比 Unity 最快的內存分配器表現還要快一倍左右。從這個層面上，通過自定義 Allocator 就滿足了對于固定分段內存大小分配的性能要求。

這里再介紹一下思路，剛才反復提我們分配的內存是固定大小的，有個非常適合的叫Pool Allocator，它是固定大小段的分配。這是我在網上找到的 Pool Allocator 算法，就是分配一大塊內存，切成固定大小的小段，通過鏈表的形式鏈在一起，這是大家能找到的非常常見的算法。但是它有個問題，它的性能非常不好，通過鏈表，就意味這我們是通過指針把它鏈在一起的。

指針有什么問題？當我把鏈表并在一起的時候，實際每個地方都要訪問一次內存。對于內存分配器來講，訪問內存的代價是非常高的。我們看到剛才統計的內存分配器的時間，它的單位是微秒，對于在微秒級別訪問內存的開銷已經是個很重的操作了。所以對于內存的訪問要盡量減少。

在我們的實現里是通過兩層 Bitmap。通過第一層的 bitmap 查詢上面的 Block 哪個是空閑的。比如第一個位是 1，就意味這第一個 Block 是滿的。第二個這個位置是 0，意味著第二個 Block 是可用的，就直接拿了第二個 Block。第二個 Block 它依然是 bitmap，通過這個 bitmap 我能知道剛才那一段里第幾個、第幾段是沒有被使用的，然后再拿指針的地址，加上偏移量，可以做到在只用訪問兩次內存的情況下就能夠拿到我想用的地址。所以從整體上來講，我們用最大的可能性排除掉了對于內存的訪問。

這個才是我們真正實現的樣子，暴露了更多細節。首先最底下有 64 個 ulong 表達這一塊能夠管理多少 Block，這個 Block 里面有 3 塊內存。為什么是三塊？這里就牽扯到我們進行 Cache line 的對齊。意味著訪問了這塊地址之后，這塊地址往后面的 64 個字節對它們的訪問都是免費的。因為它已經對于 CPU 來講，它的內存訪問是按照 Cache line 訪問的。所以訪問這三塊的時候，訪問速度非常快的。

同時，對于 Bitmap 的操作要訪問到第幾位是 0。這個操作是可以通過 CPU 指令級級別的函數，直接能夠拿到這位是 0。能知道這里有幾個 1，其實也是硬件給我們提供了相應的指令。

同時，我們還實現了多線程的線程安全訪問，對于一個 Allocator 來說，線程安全也是個非常重要的特性。我們通過硬件級別的自旋鎖 +interlocked，實現了非常高效的線程安全。對于整個內存分配器，我們通過 Cache line 的對齊、減少對于內存的訪問、包括對于硬件指令的使用，最大化了 Allocator 的性能。

再來看銷毀，銷毀就比較直觀，因為依然采用 Swapback 的方式，保證前面數據是緊湊的，能夠讓我們最大化使用 SIMD 指令進行運算。但是這里跟 Unity 內置粒子系統不一樣的是我們的內存天生是分段的，意味著對于每一段進行 Swapback都可以進行多線程的操作，對于銷毀來講也可以做非常直觀的加速。

2.曲線采樣

另外一個粒子系統里比較重的操作就是曲線采樣，右邊是大家使用粒子系統的時候經常用到的界面。它有幾個特點：

它的 Key 比較少，底下是 3 個上面也是 3 個，估計 5-10 個就已經很多了，因為純粹是人做出來的曲線。

它的采樣頻率很高，10w 個粒子去采樣曲線，這里是兩個曲線，意味著會有 20w 次的采樣操作。

Unity 為了優化這個東西提供了Optimize的選項，Optimize 是做什么的？它有一些限定，首先它只允許 key 是 3 個以內，就是 2 個或者 3 個 Key，它的限定必須是 [0-1]，也就是說至少頭上那個 Key 是 0，尾上 Key 是 1，還限定了 Clamp 模式，必須是兩頭裁掉的模式。所以它的限制是比較大的，如果不滿足這些條件，就會降級到 AnimationCurve 采樣。

我們來看一下 AnimationCurve 是什么樣的。這個就是最簡單的動畫的曲線，很復雜。但是它有一些很明顯的特點，首先曲線很多，Key 也很多，但是它所有曲線的 Key 共享 Segments。能發現如果我們用 AnimationCurve 算法去采樣上面的曲線，其實是有點大材小用了，因為算法對應的場景是不太一樣的。所以我們就針對上面粒子系統的特點，做了算法層面的優化。

這個是我們最終得到的效果，AnimalionCurve 大概是 6ms 左右，在最后一行，我們自己實現的 Curve 采樣大概在第四行，是 0.06ms，最短的是 0.03ms。也就意味著在粒子系統里，用新的OptimizedCurve實現采樣的話，10w 次基本上 0.03，幾乎可以認為是免費的過程。如果不是 OptimizedCurve，也是個非常短的時間。

我們是怎么做的？曲線采樣的本質就是對下面的公式進行多項式求解，這是算法的本質。abcd 我也不知道，先把 abcd 求出來，然后是 x，x 就是采樣的時間 t，先求出 abcd，然后把 t 帶進去，就得到了最終采樣的結果。

求 abcd 的過程實際上是可以被預計算的，意味著我不需要采樣的時候才計算 abcd，而是創建一條曲線的時候把 abcd 算出來。采樣的時候不需要再把 abcd 重新算一遍，這樣節省了大量時間。在 AnimationCurve 里，實際上它是每個 abcd 都要求的。我不是說它實現得不好，而是它是為了它的那個場景做的。因為它的 Key 特別多，如果預計算的話，一開始就計算出來成本受不了。但是在我們場景里，我們完全可以把 abcd 預計算出來。

采樣的過程也做了優化，ax3+bx2+cx+d =[(ax + b)x + c]x + d，這兩邊是等價的，但右邊的式子乘法會少一半。上面是左邊的式子代碼，下面是右邊式子的代碼。我們優化出來會發現同樣的代碼，用不同的寫法，速度就會快3倍，這是非常神奇的地方。

為什么乘法少一半，速度會快了 3 倍？是因為 mad 函數，它就是乘加函數，它在硬件里也有對應的指令。所有的計算都是硬件里有對應指令的，所以它不是快了 1 倍，而是快了 3 倍，整體做下來優化效果還是非常棒的。所以有很多細節能夠讓整體粒子系統的采樣速度或運算模擬速度都會變得更快。

曲線采樣 Tradeoff，我們需要預計算 abcd，這樣預計算會導致 Curve 創建開銷更高一點。我們測下來 3000 條曲線創建需要 2.57ms，目前看下來我們可以接受這個成本。因為 3000 條曲線同時被創建是少見的場景。

10w 量級粒子的渲染

上面講到了怎樣在 CPU 中高效地組織內存，來做到更快地創建和銷毀，以及怎么優化 Curve 采樣。剩下的部分就是怎么樣把 10w 粒子更快地畫出來。

Built-in Particle System 的渲染方案在 1w 數量以下的粒子圖表現上是非常好的。如果我強行用它畫 50w 的 cube 它只能在二三幀跑了，已經卡成 PPT 了。

這個粒子的配置，CPU 是 i5 的 13600，GPU 用的 4070，在 Direct3D 12 跑的，開了 11 Modules，shader 用的 lit 類型。其中一個比較大的原因是受限于它本身的渲染方案，因為 Built-in Particle System 它是通過把一個粒子系統的所有粒子拼成一個大的 Mesh，它有計算大的 Mesh 的過程。計算每個頂點的位置、上傳數據這些，都是在一個單線程跑的。當粒子數量增加的時候，這就會成為一個卡點。

所以我們選擇了完全不同的渲染方案。我們是基于BatchRendererGroup，BatchRendererGrpup API 可以從 C# 層高效生成繪制命令，生成 GPU instance drawcall，相比傳統的 SRP Batching，能夠帶來更少的批次和更少的 drawcall。ECS 中的 entities.graphics 包也是基于 BRG 構建的，熟悉 DOTS 的同學應該對它不陌生。它對于我們當前這種需要渲染大量相似物體的需求來說，這是一個非常好的選擇。

所以我們用了一個 RendererManager 來組織場景，所有需要渲染的對象，包括粒子、所有的 Trails，讓它來組織數據穿傳，裁減、DrawCommand 等所有工做，它最核心的任務就是讓各個階段的工作能夠并行調度起來。

我們先來看看對于粒子系統來說，哪些選項會影響合批。

這邊紅框里可以設置材質和 mesh，不同材質和 mesh 一定是不同的 darwCommand，這個是共識，而藍框中是一些是否生成陰影，是否生成 Motion Vectors ，不同 layer 等設置，這些 filterSettings 也會影響合批。

BRG 為了避免將類似的 filterSettings 參數復制到多個 darwCommand 中，它其實提供了range 和 batch 兩層結構，range 用來描述了一組連續的擁有相同 filterSettings 的 batch。

而對于一個粒子系統中的所有粒子來說，藍框中的設置都是一樣的，而紅框中的 mesh 有 1-4 的限制，所以它們一定是同一個 range，最多 4 種 batch 就能描述了。

那再換一個思路，也就是說，當參數確定的時候，最佳批次也就隨之確定了，只有當參數發生修改的時候，我們才需要去重新維護這個結構，然后再根據這個結構去生成 drawcommand。

我們再來看一下 GPU 內存管理，BRG 要求我們自己管理 GPU 內存，定義各種屬性的分配和偏移 。在這里我們以 SOA 的方式組織數據，并且使用持久的 GPU 內存。也就是說，當粒子的數量上限確定時，這段內存的 Layout 就確定了，每幀只更新需要更新的部分。

而為了進一步減少上傳 GPU 的數據量，我們區分了 Shared 數據和 Instance 數據，Shared 數據是每個粒子系統一份，而 Instance 數據是每個粒子一份。所以真正的 GPU 內存大概是這個樣子的，所有 Shared 數據會放在所有 Instance 數據的前面。

當然這里只是舉了幾種屬性作例子，由于粒子系統允許用戶自定義上傳到 GPU 的屬性類型非常之多，所以我們也提供了一套結構能夠去靈活地修改這個布局。

我們還將部分模擬轉移到 GPU，包括矩陣變換、UV 動畫、Random。這樣做的好處有很多，一方面自然是加速計算，通常粒子數量是遠大于頂點數量的，粒子的速度也是更快的。

另一方面呢，我們可以用更少的數據來描述更多的屬性?？梢詮膱D片里直觀地感受一下這件事情的重要性，這里的 CustomData 和 CustomVertexStream 都是允許用戶在shader里讀到的屬性。而正是由于我們把一部分計算轉移到了 GPU 上，這里的很大一部分屬性也可以在 GPU 上直接計算得到了。

上面我們花了一番功夫去盡可能地減少 CPU 到 GPU 需要上傳的數據量。而為了避免 GPU 需要的數據在 CPU 這里又重復地多存一遍，比如說 color，我們將計算的結果直接寫入 GPU。又因為我們數據都是以 SOA 的方式存放，而 GPU 的內存也是以 SOA 級別排列的，那么我們就可以很自然地做到多線程并行寫入。

而對于寫入的時機，我們也做了優化。對于一些比較苛刻的情況，Built-in Particle System 會有大量的重復寫入。上面這張圖是我在 Editor 下同時開了兩個窗口，一個 SceneView 一個 GameView，并且啟用了粒子系統的 shadow 選項的一張 profiler 的截圖。這里的每一根白色的豎線就是 Built-in Particle System 在向 GPU 上傳數據。這主要是因為 Built-in 通過 vbo 來上傳數據，矩陣變換計算頂點位置這些放在 CPU 上去做。

那么窗口不同，相機信息就不同，計算得到的頂點位置就不同，所以就會出現這樣的重復寫入。而我們是不需要的，我們通過 GraphicsBuffer 上傳必要的精簡的數據，對于不同的窗口，shadowMap，Edior 下的描邊來說，這些數據都是一樣的。所以我們有機會做到一幀內只有一次上傳。

這里我們用 10w 個 billboard，一個 billboard 四個頂點，來簡單對比一下，相比 Built-in Particle System 我們究竟省了多少？對于 Shared 數據來說這是 40w 和 1 的區別；對于 Instance 數據來說是 40w 和 10w 的區別。由于轉移了部分計算到 GPU，所有可能上傳到 GPU 的 Instance 數據類型減少40%。由于優化了上傳數據的時機，在啟用陰影的狀態下數據總量減少50%。

那么我們這套新的實現中有沒有什么瓶頸呢？有的，就是裁剪。Built-in Particle System 受限于 CPU 生成 Mesh 的方式，一個粒子系統的所有粒子作為一個完整的 Mesh，只會進行一次裁剪。對于部分粒子在視野外的情況處理地并不好，給GPU 帶來了多余的負擔。

我們 DrawInstance 的渲染方式有機會對一個粒子系統逐粒子級別地進行裁剪，但 10w 次裁剪和 1 次裁剪的差別還是非常大的。這里我列了一些數據展示一個粒子一幀內究竟需要和多少個裁剪面求交。我們要對相機的視錐體求交，也就是 6 次。當啟用 shadow 的時候，還要對燈光的裁剪面求交，特別是點光源和直射光，這個數量已經飆到幾十個了。而當 Editor 上不只有一個窗口時，上面四項的和還需要再乘窗口的數量。如果這個數字還要再乘 10w，這個代價就有點大。而我們希望在既保證精度的同時又能把速度提上去，所以我們對裁剪進行了加速。

裁剪的雙方分別是裁剪面和粒子，我們從這兩個角度去考慮如何加速。對于裁剪面來說，我們通過SIMD 加速，將裁剪面打包成 4 個 x，4 個 y，4 個 z，4 個 distance，這樣就可以利用 burst 編譯器，將每 4 個裁剪面的裁剪算法變成一條指令。而對于粒子來說，它本身具有兩個特點：首先，絕大部分粒子都是動態的，每幀都會發生變化。其次，粒子之間經常重疊，很難用某個平面將它們劃分開。所以像 kdTree 等空間劃分的思路并不適合的。

回到加速的核心需求，是要將數據組織成某種結構，分層去做裁剪。而我們的數據天然就是分層的，我們可以利用數據本身的結構來加速裁剪。我們分成了粒子系統，page，粒子三層，由于粒子之間的裁剪結果并不會相互影響，所以這個過程是多線程并行的。而除了裁剪之外，還有別的模塊也會涉及求交運算。比如說 collision，trigger 等物理相關的模塊。這些模塊也同樣可以利用這個結構來做加速。

最后，回到我最開始的例子，在對完全相同的配置下，去畫 50w 個 cube。在我們新的渲染方案下，有個更好的合批，更精簡的數據上傳，并行計算，裁剪加速，它會表現得更好嗎？是的，可以看到幀率能夠穩定在 40 幀以上，整體還是比較流暢。當然現在還是開發中的狀態，后面還是需要繼續優化和修改的。

Unity 官方微信

第一時間了解Unity引擎動向，學習進階開發技能

每一個“在看”，都是我們前進的動力