這個系列前面聊過不少給手機降負載的手段但真正讓我覺得一勞永逸、性價比極高的還得是光照烘焙這張牌。光照烘焙解決的是移動端發(fā)燙優(yōu)化里最核心的一塊把每一幀都要做的光照計算提前換成一次貼圖采樣。很多團隊對發(fā)熱的直覺是“手機散熱不行”“芯片太激進”但從項目可控度來看真正能改的是渲染成本。光照烘焙就是那個能在不犧牲觀感的前提下把GPU負載實打實砍掉一大截的操作。這篇我結合自己做過的一個移動端場景改造把光照烘焙為什么能降溫、接入時要注意什么、實測數(shù)據(jù)能到什么水平以及烘焙過程中容易踩的坑全部捋一遍。適合正在做發(fā)燙治理的客戶端開發(fā)、技術美術也適合第一次接觸烘焙的新人。1. 發(fā)熱的賬本實時光照是GPU負載里的重頭開銷1.1 移動端發(fā)熱的本質是芯片持續(xù)高負載手機發(fā)燙表面上是外殼熱本質上是SoC里的GPU長時間處于高功耗狀態(tài)。移動端設備散熱面積小沒有主動風扇熱量一旦積累起來芯片就會觸發(fā)降頻然后表現(xiàn)為幀率波動、畫面變卡玩家體感就是“又燙又卡”。這個循環(huán)一旦形成體驗基本很難救回來。所以做發(fā)燙優(yōu)化思路不應該是“想辦法給手機降溫”而是“想辦法讓芯片不需要做那么多事”。只要每一幀的渲染負載降下來功耗就會降溫度自然跟著降。這也是為什么所有發(fā)熱治理方案最后都會落到渲染開銷上——要么減少繪制量要么減少單個像素的計算量要么減少帶寬占用。光照烘焙屬于第三種思路里最典型的代表把本來逐幀動態(tài)計算的光照信息提前離線算好運行時只需要讀數(shù)據(jù)。它跟LOD、合批這類優(yōu)化還不一樣LOD是在砍幾何復雜度合批是在砍Draw Call光照烘焙直接砍的是著色器里最貴的那部分數(shù)學運算。1.2 一幀畫面里實時光照到底在算些什么要理解烘焙為什么省電得先看清實時光照在一幀里做了多少事。假設一個室內場景有一個平行光當太陽兩盞點光當裝飾燈再有個動態(tài)角色在走動平行光會對所有接收光照的物體產(chǎn)生漫反射和高光計算每個像素都要跑一遍光照模型。兩盞點光意味著每個像素還要額外疊加兩次光源貢獻Shader里就要多算兩遍漫反射高光衰減。平行光要投射陰影就必須以光源視角額外渲染一張Shadow Map這本身就是一次全場景深度渲染。動態(tài)角色要跟地面有接觸陰影角色身上通常還要單獨開實時陰影再疊加一層陰影貼圖采樣。如果場景里有間接光純實時渲染基本算不動通常只能靠環(huán)境光或者各種近似方案湊合。這些運算疊加在一起GPU的時鐘周期和帶寬都在瘋狂消耗。我在低端機上測過一個不算復雜的中型場景光平行光和兩盞實時點光光柵化加陰影采樣就能吃掉8到12毫秒的GPU時間。對移動端來說這個數(shù)字已經(jīng)意味著幀率頂不上60幀發(fā)熱也很明顯。1.3 為什么優(yōu)先動光照而不是先調Shader有人會問Shader里加一些分支優(yōu)化、減少Overdraw不也能省電嗎能但收益量級完全不同。Shader微調通常是在5%到15%的范圍內摳而光照烘焙是無縫切換到另一條成本曲線把逐像素光照計算變成一次紋理采樣省掉的是80%以上的光源相關開銷。尤其是場景里靜態(tài)物體占比高的情況下烘焙的收益最大。一個典型的游戲關卡地板、墻體、道具、建筑這些靜態(tài)元素通常占到90%以上的畫面面積這些物體如果都走實時計算GPU大部分時間都在做無用功。把它們轉換成烘焙光照等于讓GPU退掉大部分重復性的加班只保留少數(shù)真正需要動態(tài)計算的部分。2. 光照烘焙的省錢原理把“逐幀現(xiàn)做”變成“查表拿結果”2.1 Lightmap的本質是提前算好的光照結果烘焙之后生成的Lightmap光照貼圖說白了就是一套紋理紋理里每個像素存的是對應物體表面接收到的光照結果包括直接光和間接光。運行時Shader不需要再計算光源方向、衰減、遮擋只需要采樣這張貼圖把顏色疊加到材質上。舉個生活化的例子實時渲染就像每天中午去廚房現(xiàn)切菜、現(xiàn)炒菜一道菜要忙活半小時烘焙相當于提前把菜做好打包放進冰箱吃飯的時候微波爐加熱三分鐘就端上桌。觀感上還是那份飯但后廚的工作量完全不是一個量級。具體到引擎實現(xiàn)里Unity和Unreal都提供了完整的光照烘焙管線。開發(fā)者把物體標記為靜態(tài)、把光源設置為烘焙模式、設置好分辨率然后就交給引擎離線計算。引擎會算出每個物體表面的光照結果并排成一張或者多張Atlas貼圖。運行期間引擎會把這張貼圖自動綁定到材質上原本幾十上百條GPU指令的運算變成幾次UV采樣和一次插值。2.2 不只是漫反射Light Probe、Shadowmask、Reflection Probe一起配合如果只是靜態(tài)物體表面有烘焙光動態(tài)角色站在場景里會顯得“浮起來”——因為角色身上沒有正確的環(huán)境光反饋。所以完整的烘焙方案不是一個Lightmap單打獨斗而是一套組合Lightmap負責靜態(tài)物體表面的直接光和間接光。Light Probe光照探針在場景里布一些采樣點記錄該位置的入射光信息。動態(tài)物體運行時通過周圍探針插值得到光照讓角色融入烘焙場景。Reflection Probe反射探針用來給金屬、玻璃這類高光物體提供環(huán)境反射信息彌補烘焙貼圖不包含高光反射的問題。Shadowmask模式把靜態(tài)物體的陰影烘焙到貼圖里的同時預留一些實時陰影能力讓動態(tài)物體也能在場景里投射正確的影子。這套組合的重要性在于光照烘焙不是把整個場景打回“沒有陰影的貼圖感”而是把靜態(tài)信息用貼圖保存動態(tài)信息用探針和實時陰影補足。畫面層次和動態(tài)交互都能保留但計算的絕對量大幅下降。2.3 移動端尤其劃算的另一個原因分辨率感知不高在PC大屏上烘焙貼圖的細節(jié)差距可能通過走近看還是能發(fā)現(xiàn)但在手機上屏幕尺寸和PPI決定了玩家不會貼著一個物體去看光照過渡。中等分辨率的Lightmap在手機上已經(jīng)足夠平滑勞動成本卻比高精度烘焙低一個數(shù)量級。這個特性讓移動端成了光照烘焙收益最大的平臺你付出離線計算的成本換來的是運行時幾乎為零的光照開銷同時畫質觀感損失很小。3. 實戰(zhàn)接入Unity和Unreal里把光照“烤”熟的標準動作3.1 Unity側從標記Static到出圖在Unity里做烘焙第一步是把需要烘焙的物體標記為靜態(tài)。選中場景里的模型在Inspector面板右上角點開Static下拉菜單選擇Lightmap Static或者直接在Mesh Renderer組件里勾選Contribute GI。這里要注意物體必須是靜態(tài)的烘焙結果才能被正確生成如果物體沒有標記即使你再怎么調光源烘焙出來它也都是黑的或者實時計算。光源的設置同樣關鍵。需要全局定向光就選平行光組件的Light Mode有三種選擇Realtime繼續(xù)實時計算適合玩家交互產(chǎn)生的動態(tài)光。Baked完全烘焙運行時沒有任何光照計算代價適合裝飾燈、氛圍燈。Mixed混合模式靜態(tài)物體的陰影烘焙但Shadowmask和Light Probe還能對動態(tài)物體產(chǎn)生投影適合主光源。移動端我個人的習慣是主平行光用Mixed普通裝飾光全部Baked只有真的跟隨角色或者表現(xiàn)特效動態(tài)變化的光源才保留Realtime。這樣既保留了動態(tài)物體最基本的影子反饋又不會把實時光源數(shù)量拖起來。設置完成后打開Window Rendering Lighting面板在Scene標簽里把Lighting Mode選好然后點擊Generate Lighting。Unity默認的Progressive GPU Lightmapper會逐步顯示烘焙進度方便你邊烤邊看效果。3.2 Unreal側Static光源與Build LightsUnreal的流程思路一樣但入口不太一樣。UE中網(wǎng)格體要標記為Static光源則設置為Static或Stationary。對于移動端項目我的做法是主平行光用Stationary因為Stationary光源保留了動態(tài)物體投射陰影的能力但靜態(tài)物體依然走烘焙結果點光源除非是關鍵交互對象否則一律Static完全烘焙。在World Settings里有一個經(jīng)常被人忽略的參數(shù)Static Lighting Level Scale它控制間接光照的體積分辨率。默認值是1烘焙細節(jié)高但內存和時長也跟著高。移動端我一般調到0.3~0.5畫面觀感下降不多Lightmap和VLM體積占用卻會明顯減少烘焙時間也快不少。設置完成之后點擊Build菜單下的Build Lighting Only或者直接按快捷鍵引擎就會調用Lightmass開始烘焙。Unreal的好處是烘焙結果會直接在視口里反饋光影質量很直觀。3.3 移動端專項參數(shù)建議很多項目第一次烘焙直接沿用PC的配置結果烘焙完一看包體和內存爆了低端機也扛不住。移動端烘焙參數(shù)要單獨調我的常用基線是這樣Lightmap Resolution每單位世界距離的像素密度移動端建議10~20中小型房間15左右足夠大型野外場景可以降到8~10。Directional Mode優(yōu)先選Non-Directional能省一半內存。只有場景里明顯需要法線方向光影變化時才考慮Directional。CompressionUnity里開啟Lightmap壓縮Android選ETC2或ASTCiOS選ASTC。壓縮能顯著減小包體和運行時內存但注意壓縮程度太高會產(chǎn)生漏光或顏色斷層要平衡。Lightmap Padding單一圖集內不同UV島之間的間距太小時相鄰物件容易互相滲色移動端建議保持在4~8像素左右。Bounces間接光反彈次數(shù)Unity和Unreal默認2~3次足夠再高畫面已經(jīng)看不出差異純純增加烘焙時間。這幾個參數(shù)如果場景不是特別復雜基本能讓烘焙結果在容量和畫質之間達到一個比較穩(wěn)的平衡點。調試階段可以先調低分辨率快速出圖看構圖確定燈位和氛圍沒問題再回到高分辨率做最終烘焙。4. 實測數(shù)據(jù)一個中等場景烘焙前后的性能與溫度對比4.1 測試場景和方法這部分的數(shù)據(jù)來自我之前做的一個移動端室外街區(qū)加室內小場景的改造。場景里有街道、房屋、綠化、室內家具等靜態(tài)物體實行動線固定角色在街道和房間里穿行。手機測試機選用一臺驍龍8系中端機系統(tǒng)亮度固定50%開啟飛行模式關掉后臺進程每人同一視角路線跑3次取平均。記錄工具上Unity側用Profiler里的GPU模塊看單幀GPU耗時整機功耗和溫度用PerfDog配合第三方腳本讀取。溫度測量放在30分鐘連續(xù)跑圖之后記錄機身最熱位置的紅外溫度。4.2 關鍵數(shù)字對比改造前場景里有一個Realtime平行光外加三盞Realtime點光所有靜態(tài)物體都有實時陰影。改造后平行光切成Mixed點光全部Baked靜態(tài)物體全部成為Lightmap對象動態(tài)角色保留Light Probe和Shadowmask。指標烘焙前烘焙后變化GPU單幀耗時低負載場景12.3 ms5.8 ms下降約53%GPU單幀耗時復雜街區(qū)19.6 ms9.2 ms下降約53%平均FPS4259穩(wěn)定提升整機功耗4.8 W3.3 W下降約31%30分鐘后機身最高溫度43.1 ℃38.9 ℃下降4.2 ℃Lightmap內存占用無約5 MB換取大幅運算下降這個數(shù)據(jù)不是絕對的但它能反映出光照烘焙的真實量級GPU耗時直接腰斬整機功耗下降約三成30分鐘后機身溫度從“明顯燙手”回到“溫溫的”狀態(tài)。對玩家而言這種溫度差異已經(jīng)能從握持手感上明顯感知出來。4.3 數(shù)據(jù)要這么讀先看瓶頸再看指標同類項目如果想復現(xiàn)這個流程我建議先把測試目標拆開。第一優(yōu)先級是看GPU耗時是否成為瓶頸如果項目瓶頸在CPU端烘焙效果會被其他因素蓋住。第二步看GPU耗時下降后整機功耗是否跟著下降很多時候Shader省了但CPU還在忙幀率沒變溫度也沒變需要配合其他優(yōu)化一起做。另外要控制變量環(huán)境溫度差幾度、手機亮度差10%、后臺多跑一個App甚至手機殼的導熱性能都會影響溫度讀數(shù)。最好是同一天測試同一臺設備跑同一個場景路徑才能得到有說服力的對比數(shù)據(jù)。5. 烘焙實戰(zhàn)中最容易踩的坑從“烤不熟”到“烤糊了”的排查鏈路5.1 場景里總有物體是黑的或實時計算的最常見的現(xiàn)象是烘焙完某面墻黑得離譜或者某個裝飾物看起來跟周圍環(huán)境格格不入。究其原因基本就是物體沒有被正確標記為Static或者光源里還殘留Realtime模式。排查鏈路我一般是這么走的先選中那個物體看Inspector里的Static標記是否勾上。然后在Lighting窗口刷新后直接Generate Lighting烘焙完看一眼Lightmap列表里有沒有生成該物體的圖集。如果是物體本身UV2不對Unity會把它單獨放進一個很小的圖集表現(xiàn)為烘焙結果特別糊。一個很容易被忽略的細節(jié)是模型導入時如果沒勾選Generate Lightmap UVsUnity會提示需要第二套UV。對有高級UV技巧的建模師來說這是基本功但很多時候從美術手里拿到的模型只有一套UV這時可以勾選引擎自帶的自動展UV功能并把Pack Margin調到0.05左右避免UV島之間相互滲色。5.2 接縫、漏光和顏色斷層烘焙完最常見的視覺瑕疵就是接縫——在兩個相鄰物體的交界處看到一條明顯的亮線或暗線。原因通常是光照貼圖的UV島之間沒有足夠Padding或者不同物體用了不同分辨率導致采樣跳變。漏光的根源大多是Lightmap分辨率不夠或者各向異性壓縮太狠。ASTC 6x6壓完之后顏色過渡變粗糙燈光在模型邊角處的漸變就會出現(xiàn)斷裂。解決辦法是先看看是不是分辨率問題調到更高分辨率再試如果分辨率已經(jīng)夠高還漏則多半是壓縮格式問題改成ASTC 4x4或者ETC2會好很多。還有一類發(fā)黑的問題跟Lightmap無關是后處理里的AO疊加太猛。烘焙自帶AO通常已經(jīng)很柔和再疊加屏幕空間AO會把墻角、邊緣壓得太黑。移動端我建議烘焙時把AO信息放在Lightmap里后處理關掉或降強度畫面反而更干凈。5.3 動態(tài)角色到了烘焙場景里發(fā)灰烘焙場景里角色顯得跟環(huán)境脫節(jié)通常是Light Probe沒布好。烘焙之后動態(tài)物體的實時光照不能直接用需要通過探針插值。如果場景里探針數(shù)量不足、位置放得太密或太疏角色走到一些區(qū)域就采不到有效光照整體發(fā)灰發(fā)悶。正確布法是沿著玩家動線、門前、轉角、房間中心這些關鍵位置放置探針密度以“兩米左右一個”為基準再根據(jù)場景明暗變化加密。探針千萬不要塞進墻體或大型物體內部測出來的一幀光照會污染整片插值結果。布完探針之后在Game視圖里讓角色走一圈動線檢查明暗過渡是否順滑。5.4 烘焙時間太長、Lightmap圖集過大烘焙時間會隨著GI雙反彈、Lightmap分辨率和場景面積飛速膨脹。美術這邊調一版燈光跑去烤一次兩小時這基本沒法迭代。我的做法是迭代階段用低分辨率加僅直接光模式只看光影構圖確定最終燈光氛圍后再開完整烘焙一次出最終結果。圖集過大的問題則要從“圖集復用”的角度解決。把場景分成多個區(qū)域用Lighting窗口里的Lightmap Parameters分別控制不同區(qū)域的烘焙分辨率。比如核心戰(zhàn)斗區(qū)用20 texels/m邊角堆放區(qū)用10 texels/m能有效控制最終貼圖總量。同時圖集盡量控制在2048或1024以內移動端超過4096不僅內存高GPU采樣帶寬也會成為新的瓶頸。5.5 一個容易忽略的坑動態(tài)光源沒清干凈烘焙完靜態(tài)物體很完美但只要角色進入場景某個地方就會突然出現(xiàn)一道黑影或高亮的色斑。排查到最后往往是場景里還殘留著某個并非需求必選的實時點光。這種光在運行時一進入照射范圍就會實時計算不僅成本高還容易跟烘焙結果產(chǎn)生雙重照明。處理方式非常粗暴把不需要動態(tài)的光源全部切成Baked保留的最少兩盞交互光設置為Mixed并控制照射半徑。開Frame Debugger看一下每個像素的光照貢獻來源能清清楚楚看到哪個光源在干活。6. 別把烘焙當萬能藥適用邊界與組合拳6.1 哪些玩法不能只靠靜態(tài)烘焙光照烘焙的前提是場景光照基本不變。如果游戲有實時晝夜循環(huán)、動態(tài)天氣、可破壞墻體、玩家可制造光源等玩法純烘焙方案就沒辦法滿足——Lightmap是離線算好的運行時不會跟著晝夜變化。這種項目我建議采用“分層烘焙微量實時”的混合思路把結構場景整體烘焙為基調晝夜變化用環(huán)境光和Directional Light的旋轉、顏色、強度來模擬配合后處理調色。動態(tài)光源嚴格控制在個位數(shù)其余全部靠烘焙和探針提供基礎光照。這樣既保留了核心玩法需要的動態(tài)光照反饋又不會讓實時光照成本失控。6.2 跟其他移動端優(yōu)化手段怎么銜接光照烘焙應該排在渲染優(yōu)化的第一梯隊但它不能替代所有工作。它跟LOD、遮擋剔除、紋理壓縮是互補關系烘焙負責砍逐像素光照計算LOD負責減少頂點數(shù)遮擋剔除負責減少可見物體數(shù)量紋理壓縮負責降低帶寬。四者疊加起來才能把一個場景的渲染成本壓到很低的水平。一個比較成熟的移動端組合是靜態(tài)物體全量Lightmap 角色/特效少量實時光 陰影貼圖僅作用于近處 反射探針預烘焙。這樣場景在任何角度看都有穩(wěn)定光影動態(tài)交互點也不至于干癟。再疊加上Streaming Mipmap和Lightmap的紋理流送內存也能控制在可接受范圍內。6.3 我落地時的幾條經(jīng)驗項目做發(fā)燙治理時我把“GPU耗時、整機功耗、峰值溫度”三個指標固化成每次構建的必測項每次改動光照配置后都跑一次這三項數(shù)據(jù)而不是只看幀率。幀率快被垂直同步卡住時根本看不出性能變化功耗和溫度才是真正反映發(fā)熱的鏡子。另外烘焙迭代的流程養(yǎng)成習慣后效率會高很多。前期先用最低分辨率快速出圖定調中期開中等分辨率檢查美術細節(jié)最后只保留高分辨率出包。不要每一次都在高分辨率下反復重烤那會把團隊的心態(tài)和迭代節(jié)奏全拖垮。最后分享一個小技巧只要條件允許把Lightmap的最終結果單獨用一個目錄管理版本變動時通過Asset Bundle只更新貼圖資源。這樣美術調整燈光后程序不需要重新構建整個場景移動端補丁體積也能控制在很小的范圍內。這套流程跑順了光照烘焙不只是一次性能優(yōu)化更是整個項目提效的一部分。