GPUInstance又分為AutoInstance及ManualInstance，前者是透過MeshRender或Graphics.DrawMesh的方式，材質有勾Enable GPU Instancing來渲染，後者是透過手動在MonoBehavior裡呼叫Graphics.DrawMeshInstanced來渲染，
相關細節可以參考我這一篇：
Unity Batching與GPU instance效能分析
而不管是用那種方式，view frustum culling處理的部份都不是很理想，皆會造成送進去的triangles數量過多，如果是像草這種quad，就還好，但是像這種幾百幾千面的物件性能就不行…
這裡針對俯視視角進行相關的culling處理，所以採取了斜視口剔除（Oblique Bound Culling）的做法，相關細節可以參考我這一篇：
使用斜視口剔除(Oblique Bound Culling)來做大量物件剔除
雖然使用page切割已經達到大量剔除的目標，但是物件數巨量的話，這樣的剔除的結果還是太多，但如果直接用frustum對這些物件進行檢測的話，數量太多，會造成CPU bounds，所以這裡採用了Unity的Job System的方案，使用多執行緒來優化這部份。
相關結果如下：
使用.Dynamic batching（without GPU Instance）沒有view frustum culling的狀況，可想而知整個場景有6250000個，當然性能不好…
使用.Dynamic batching + frustum culling，性能
是有提升，但還是不理想…
使用.Dynamic batching + job system frustum culling，性能又提升了，但還是不夠…
使用AutoInstance但沒有沒有view frustum culling的狀況，性能很差，所以重點還是在View Culling…
使用AutoInstance + frustum culling，跟dynamic batching差不多，沒什麼好談的…
使用AutoInstance + job system frustum culling，還是跟dynamic batching差不多，基本上沒用Manual Instance，GPUInstance效果都看不太出來…
使用ManualInstance但沒有沒有view frustum culling的狀況，明顯在沒做view frustum culling的狀況下，還是比前面兩個方案比好很多，值得注意的是雖然drawCalls及triangles都增加，這裡主要是節省了傳輸triangles的頻寬所造成的…
使用ManualInstance + frustum culling，效能提升有限，看來都是卡在view frustum culling的CPU bounds…
使用ManualInstance + job system frustum culling，在processing triangles count明顯降下來後，又有多執行緒做大量culling的加持，效能非常理想…
culling運作狀況…
在S8上手機最終成果畫面…
沒有留言:
張貼留言