Unity項目中UI美術必須知道的程序要點

>>>  創業先鋒 眾人拾柴火焰高  >>> 簡體     傳統

本文轉載自IndieACE,是開發者DonaldW寫給UI美術同事的一篇文章,原文題為《Unity項目中UI同學需知的程序相關要點》,分享給大家,希望促進程序和美術之間的相互理解。


背景和目的


本文的背景是《獨立防線》(Killer)項目已進行到了一定階段。雖然之前定下了UI制作規范,但中途也更新了規范,但程序和美術沒有具體面對面溝通,也沒有闡述規范的原因和落地方法。


所以,本文目的是為UI美術同事介紹:1.手游性能相關的標準是什么;2.具體制作時需要注意什么;3.什么樣的UI流程是高效的。


注,以下內容并非要求UI美術同學都掌握、或者要求UI美術單獨去處理。而是希望UI美術同學能知道有這些一回事需要考慮。最重要的是:在設計之初,能意識到可能有問題,需要找程序去溝通。


體驗和性能


極端的體驗和極端的性能都不現實。在手游平臺上,我們應該追求的是體驗和性能平衡。


性能評估標準


游戲中,任一元素(UI圖片、特效、模型等)對性能的影響都可以拆分為以下4種影響:CPU消耗、GPU消耗、外存消耗和內存消耗。


現就UI相關的影響進行舉例如下。


CPU消耗


CPU負責把UI界面的邏輯結構進行更新、匯總,并負責把這些數據準備好。最后把這些信息傳給GPU。

UI一般影響CPU的因素包括:


  • 界面結構復雜度

  • 界面結構變化頻率

  • 動畫復雜度


GPU消耗


GPU負責最終畫面的繪制、渲染。因為渲染是復雜的流程、且運算量巨大、且手機GPU固有的硬件限制(核心數少、浮點運算速度慢),手游的性能瓶頸往往都發生在GPU。

也就是說,GPU消耗是性能優化的重中之重。

UI一般影響GPU的因素包括:


  • 繪制次數(drawcall),和單張圖片的數量等因素相關

  • 圖片最終在屏幕所展現的面積

  • 圖片是否透明

  • shader的復雜度

  • 重繪度(overrdraw,單位像素的重新繪制次數)


其中,特別值得注意的是drawcall和重繪復雜度。


drawcall


每一個不同“材質”的東西都需要占用一個drawcall。每多一個drawcall必然帶來額外的CPU消耗和GPU消耗。


可以簡單認為,當兩個東西的材質的shader相同,且紋理相同,則它們是同一個材質,在渲染它們的時候,引擎會進行優化,會合并drawcall為1個。


overdraw


overdraw表示單位像素的重新繪制次數。


右部表示overdraw的程度,越“亮”的區域表示overdraw的程度越高,也就越消耗GPU。


外存消耗


外存消耗指的是資源在用戶“硬盤里占用了多少多少M”。


如果外存過大,可能導致用戶不愿意下載,或者下載安裝后,硬盤空間不夠,安裝不成功。


一般影響外存的因素包括:


  • 圖片數目

  • 圖片的分辨率大小

  • 圖片是否壓縮


另外,優化了外存,內存往往也會從中受益。


內存消耗


內存消耗指的是“游戲在實際運行時,占用多少M”。


如果內存過大,可能會導致用戶游戲體驗不流暢,甚至crash。
一般影響內存的因素包括:


  • 圖片數目

  • 圖片的分辨率大小

  • 圖片的分辨率是否是2的N次方,

  • 圖片是否壓縮


UI制作要點


UI輸出的圖片,可在Unity里設置為新的等比縮放分辨率。


正因如此,UI美術同學在輸出UI貼圖時,一般情況下按美術示意圖的原分辨率輸出即可。


單獨調分辨率的工作,目前是由開發同學進行。最理想的工作流程,是UI美術同學在導圖到Unity的時候,就單獨按需設置分辨率(和特效場景模型同學的工作流程一樣)。


至于什么情況下需要進行降分辨率操作,見下文。


低頻變化的圖片的分辨率可以很小


本方法能為GPU、外存、內存帶來好處


低頻變化的圖片指的是純色的、漸變等變化比較平緩的圖片。


低頻變化的圖片拉伸后仍能表現非常類似的效果,這是因為GPU在圖片采樣時會進行相鄰像素的插值,從而能大概還原之前的平滑度。


總而言之,低頻變化的圖片的分辨率可以很小。


實例如下。


低頻變化圖片:




低頻變化圖片:輸出給程序的圖片縮小為32x32:




低頻變化圖片:程序在使用時將32x32拉伸為512x512:



“好”的UI可以拉起“不好的”UI的表現


本方法能為GPU、外存、內存帶來好處


“好”的UI可以拉起“不好的”UI的表現這句話可以有以下的理解:


  • 不壓縮的UI可以拉起壓縮的UI表現

  • 高分辨率的UI可以拉起低分辨率的UI表現

  • 高頻率變化的UI可以拉起低頻率變化的UI表現


如上圖的放射線部分,它實際是由兩張不同的放射線圖上下疊加而成。下層的放射線順時針轉動,上層的放射線逆時針轉動。


由于上層的放射線作為表現的主體所以采取了“好”的設置(分辨率高、非壓縮),那么作為表現的襯托部分的下層圖,就算采用比較“不好”的設置(分辨率低,壓縮),也不容易察覺。


所以,針對這種多UI同時或同位置出現的情況,可以酌情調低某些UI的設置。


當然,這個例子中,上下兩層采取同一張高品質的圖也是解決方案之一。


輸出圖片的分辨率可以酌情低于視網膜的分辨率


本方法能為GPU、外存、內存帶來好處


從iPhone4開始興起了視網膜級別的PPI。這讓手機的任意App的任意界面的任意一幀,都看不出任何像素感,提高了App的用戶體驗。


但在游戲中,游戲有以下特點:


  • 游戲的UI資源是獨立原創的(App的UI資源有可能直接使用操作系統自帶的資源,節省外存),會帶來非常客觀的外存、內存消耗

  • 游戲是動態的

  • 游戲的一幀內,最吸引玩家眼前的往往是一個局部

  • 再根據上面提到的“好”的UI可以拉起“不好的”UI的表現


所以在游戲中,可以酌情將特定非重點的UI圖片的分辨率降低。


游戲中具體處理的例子:表現的主體是視網膜分辨率的,而它下面的彈出框背景作為表現襯托,采取了低于視網膜分辨率也察覺不出。


去除UI圖片中不必要的通道、不必要的區域


本方法能為GPU、外存、內存帶來好處


如上圖。地球UI圖片是沒必要有透明通道的,因為它一直以整張底圖的形式存在于游戲。


地圖UI圖右部是可以斟酌是否需要存在的,因為它在游戲中一直都被帶有背景的排名列表UI擋住。


UI圖片一般情況下都不需要mipmap


本方法能為外存、內存帶來好處


mipmap會生成多張小圖來避免縮小圖片時沒必要的GPU采樣消耗。但使用mipmap的圖片會比不使用的圖片多占用約三分之一的外存和內存。


由于《獨立防線》項目以iPhone4作為目標分辨率進行制作,且認為此分辨率是需支持的最小分辨率,也就是說,UI圖片很少有縮小的情況出現,所以《獨立防線》項目的UI圖片都不需要mipmap,減少沒必要的外存、內存消耗。


其他項目如果需兼容更低分辨率的設備,則要按需選擇mipmap。


多張UI圖片可以打包在一起


本方法能為GPU帶來極大好處,但可能為外存、內存帶來壞處


操作很簡單,選擇需要打包的圖了之后,在屬性面板里鍵入任意同一英文字符串即可。


這樣了之后,多張圖被打包在一張圖里面。


由于多張圖片打包在了一起,根據上面提過的合并drawcall的原因,會大幅減少這些圖片帶來的GPU消耗。


打包之后,會產生多余的透明區域,所以打包可能帶來的壞處就是增大了外存、內存。


所以,關鍵是選擇哪些圖片進行打包。來規避透明區域的出現。選擇規則如下:


  • 不用的圖不打包。因為打包的圖,就算從不使用,也還是會進入到最終的ipa或者apk里;

  • 小的圖盡可能打包

  • 大圖(比如大于512x512,常見的有UI底圖)不打包。因為大圖會很有可能產生透明區域;

  • 降低需要打包中的分辨率最大的圖。


不打包的單張UI圖片分辨率必須是偶數、很有可能需要是2的N次冪


本方法能為GPU、外存、內存帶來好處


按照上面的多張UI圖片可以打包在一起做了之后,不打包的圖應該是少量的。


但由于這些圖是獨立存在于內存,所以有更嚴格的要求:


  • 單張UI圖片分辨率必須是偶數。

  • 單張UI圖片當有以下任一特點時,分辨率必須是2的N次冪

    • 需壓縮的單張UI圖片。

    • 需tiled的單張UI圖片。tiled即圖片平鋪,常用于四方連續UI圖。

    • 需mipmap的單張UI圖片。即多層圖片。一般情況下,UI的圖片都不需mipmap,所以不用考慮這個。


@程序同學:現在大部分移動設備GPU是支持非2的N次方的。即NPOTSupport.Full或者Restricted的。Full的GPU對任意分辨率的紋理都能直接訪問;Restricted的GPU,一般情況下對任意分辨率的紋理都能訪問,但對于mipmap、tiled的紋理會把它pad成POT。


所以,mipmap、或tiled的非打包單張紋理需強制POT。


筆者身邊的紅米、三星、華為等手機,都支持NPOTSupport.Full,只發現小米3支持NPOTSupport.Restricted,小米3W支持NPOTSupport.Full。


@程序同學:ETC1(4bit/pixel)成功壓縮的要求是POT且不帶透明通道,否則將以16bit/pixel的方式壓縮保存;PVRTC成功壓縮的要求是POT且方形,否則將以true color(32bit/pixel)不壓縮保存。常用的方案是,把UI圖片打包到一張大圖,且大圖同時滿足ETC1和PVRTC的要求,即POT、且透明通道拆分到大圖的下半部、且方形。


這需要有特殊的shader對這張大圖進行采樣:RGB取原本uv、A取uv向下偏移0.5。下半部的Alpha部分可以把Alpha值除以3平均分部到RGB通道,采樣時把RGB相加作為Alpha,這樣有利于ETC1壓縮的效果。


因大圖的制作需要上半部是UI圖片的RGB部分、下半部是UI圖片的Alpha部分。所以需要自研或獲取適合的atlas算法對UI圖片進行排版。此時上面提到的Unity自帶的Sprite Packer方法將不再適用。


排版后的大圖的可容忍浪費分辨率是原圖的16bit/4bit=4倍,或32bit/4bit=8倍。


打包的UI圖片的分辨率可以是任意的


但依然推薦輸出偶數分辨率,避免未來帶來不可知的麻煩。


UI最好能用九宮格+局部裝飾實現


本方法能為GPU、外存、內存帶來好處


九宮格已經是非常常用的UI制作方法。

九宮格UI幾乎是百利無一害,所以希望UI同學能用九宮格的盡量用九宮格。


使用九宮格有以下幾個值得注意的技巧:


  • 九宮格UI圖片可以做得很小只給正方形的圖,而并非上面一個長條形的圖

  • 如果UI圖片內部是低頻變化(人話:比較平滑的紋理),依然可以使用九宮格

  • 如果UI圖片內部是高頻變化(人話:比較細的復雜紋理),一般情況下就不能使用九宮格了

    • 但可以把這些高頻變化的紋理設計成只在邊緣出現,讓九宮格十字架內依然是低頻變化,那這種UI圖依然可以九宮格

  • 切九宮格時,邊緣部分應盡量細、內部十字架部分應該盡量飽滿。這樣可以確保這個UI能夠使用于非常小的場合而不穿幫


字體選擇方案


本方法能為外存、內存帶來好處,可能為GPU帶來好處


在選擇游戲字體的時候,除了確保美觀程度之外,還需考慮:


  • 字體種類:應當保持在2類以內:用于標題的中文偏設計的字體、用于正文的中文偏正式的字體。如需,可額外加入英文偏設計的字體;

  • 字體編碼類型:如果是中文字體,需考慮是否GB2312編碼甚至是GBK編碼。避免字體出現有些常用中文字沒有的情況;

  • 在選擇字體時,應留意在手機上的表現。比如一些字體比較細,在手機上看不清,到后面需要都加粗加描邊,帶來沒必要的消耗,也帶來了之后額外的繁瑣的字體相關工作。


游戲葡萄 2015-08-23 08:48:45

[新一篇] IGF China倒計時94天 八天點亮綠光

[舊一篇] 只要799!動捕“黑科技”帶回家(這不是廣告)|游戲葡萄
回頂部
寫評論


評論集


暫無評論。

稱謂:

内容:

驗證:


返回列表