特效優化2 效果與效能的博弈

2021-10-13 12:46:18 字數 2226 閱讀 3743

在上一期《特效優化:發現絢麗背後的質樸》中,我們主要針對uwa本地資源檢測中和特效相關的知識點做了講解。這些看似細小的知識點,很容易在大家的開發和學習過程中被疏忽,而長期的問題積累最終都會反映到專案的效能表現上。為此,我們將這些規則列出,並且以乙個個知識點的形式向大家逐一解讀。

本條規則面向的核心其實是專案開發中最常見的一對矛盾:效果與效能。為了實現更為複雜、更為絢麗的展示效果,研發團隊會新增各種粒子系統。在帶來效果提公升的同時,也會產生非常明顯的效能消耗和渲染壓力。所以我們需要科學地做減法,減少particlesystem元件數量,以降低部分特效效果的代價來達到和專案效能之間的平衡。

這裡需要說明的是,規則給出的預設閾值是乙個比較嚴苛的標準,研發團隊可以根據自己專案的實際需求去設定符合現階段效能承受範圍的閾值。

本條規則和我們之前在文章《【效能黑榜】掌握了這些規則,你已經戰勝了80%的對手!》中提到的「粒子數上限超過30的粒子系統」的這條規則很相近。

合理的粒子數會使得特效的表現效果恰到好處,但過多的粒子數會給cpu和gpu的計算帶來更大壓力。在複雜的粒子特效下,由於大量各種粒子的存在,處理特效所帶來的效能開銷也會大幅度地增加。

天平的兩端是特效總體效果和效能,所以我們的視角要提高到總粒子數上。在實際操作中,開發團隊要盡可能精確地基於特效總體展示效果,對每乙個粒子系統的最大粒子數都進行合理的規劃與調整,這樣才有可能在保證降低粒子特效更新開銷的同時,依然能夠接近或維持原有的特效效果。

本條規則從另乙個維度為開發團隊提供特效相關的檢測規範。貼圖涉及的方面很多,在之前的文章《材質優化:如何正確處理紋理和材質的關係》和《粒子系統優化:mesh模式下的優化策略》內我們曾簡單介紹過,shader對紋理的取樣、材質對紋理的引用以及粒子系統對紋理的應用等,如果在使用時不細緻,就會導致特效內的貼圖資源**,從而帶來記憶體和計算上的額外消耗。

所以本條規則從「貼圖總數」的角度,為大家統計出這些包含貼圖數過多的特效資源,以供開發團隊對其進行進一步的優化,來為特效做**。

在之前的文章《紋理優化:不僅僅是一張那麼簡單》中,我們對紋理的過濾模式有過介紹,簡單來講是為了降低紋理到模型表面的這個過程中發生的「失真」現象。

相比於之前提到的各種過濾模式,紋理「貼」到物體表面時,各向異性過濾多考慮了紋理貼合與視野觀察角度的關係。在這個前提下,如果在u、v方向上,紋理畫素對應到物體表面的關係不是1:1時,它會按比例在各方向上進行取樣不同數量的點,並進行計算以得到最終的對應關係。

在紋理的過濾模式中選擇bilinear(雙線性過濾)或者trilinear(三線性過濾)時,我們就可以對aniso level進行調整,範圍是從0到16。

當我們把攝像機調成與紋理表面成一定角度時,aniso level的作用就會顯示出來。如下圖是nisolevel設定為0或1時的紋理的表現(即不進行各向異性過濾):

下圖是anisolevel設定為9時(這時候進行了各向異性過濾)的貼圖情況。對比兩張圖就能很明顯地發現視野遠端的清晰程度是完全不一樣的。

開啟各向異性過濾,在這種要考慮視野角度的情況下,可以很顯著地提公升紋理的表現效果,但代價是更高的gpu效能開銷。而且各向異性過濾主要適用於大面積的地面與地形設定,對場景內的物體來講,開啟相關紋理的各向異性過濾就有「殺雞用牛刀」的浪費之嫌了,表現效果上的提公升並不足以抵消或平衡由此帶來的效能消耗和渲染壓力。

所以本條規則篩選出這些紋理後,開發團隊要根據實際情況,在充分考量使用場景、表現效果和效能消耗的多方平衡後,再去決定是否需要保留開啟各向異性過濾。

萬行**屹立不倒,全靠基礎掌握得好!

《uwa學堂訓練營|遊戲自動化測試》

《那些年給效能埋過的坑,你跳了嗎?》

《那些年給效能埋過的坑,你跳了嗎?(第二彈)》

《掌握了這些規則,你已經戰勝了80%的對手!》

flash特效原理 螺旋效果 (2)

經過上面的測試,現在對原先程式進行一些改造可以建立出不錯的效果,你會發現每次改動一些引數很多有趣的效果就會出現了。現在我們嘗試做乙個調節工具對他們的半徑,高度,圈數,視角進行創造。這次會主要借助到flash裡面 元件包。slider 元件來幫助我們完成這一次的嘗試。製作過程知道 包括slider 元...

移動語義帶來效能優化效果

移動語義是c 11中的新特性,它的核心理念是所有權的轉移,而非傳統意義上的複製。許多c 11模板庫,例如string,vector都支援移動語義,都包含移動建構函式。移動語義通常和右值引用一同討論,下面語句中 string s,s1,s2 s s1 s2 如果不考慮編譯器做的優化,在c 11之前,s...

python 效能優化(2)

第二部分 有益的提醒,靜態編譯的 仍然重要.僅例舉幾例,chrome,firefox,mysql,ms office 和 photoshop都是高度優化的軟體,我們每天都在使用.python作為解析語言,很明顯不適合.不能單靠python來滿足那些效能是首要指示的領域.這就是為什麼python支援讓...