場景搭建這件事做得越久越會(huì)發(fā)現(xiàn)一個(gè)扎心的規(guī)律好看的畫面人人都想要但性能優(yōu)化的賬如果不從一開始就算最后往往要么砍美術(shù)、要么砍幀率兩邊都不討好。我自己是從“先搭漂亮再調(diào)性能”這條路走過來的后來做移動(dòng)端項(xiàng)目被真機(jī)幀率狠狠教過幾次才慢慢總結(jié)出這套“好看與性能兼顧”的搭建思路。這篇指南不是高級(jí) TA 才能看懂的底層論文而是給搞場景搭建的實(shí)干人看的從一幀的消耗到底花在哪到燈光烘焙怎么選、植被和貼圖怎么控、移動(dòng)端和 PC 端怎么分開調(diào)優(yōu)再到最后怎么把性能檢查變成日常工作的一部分。適合場景美術(shù)、關(guān)卡設(shè)計(jì)師、TA 和獨(dú)立開發(fā)者參考尤其是那些被“明明看起來不復(fù)雜但跑起來就是卡”折磨過的團(tuán)隊(duì)。1. 一幀畫面的預(yù)算賬本先搞懂性能到底花在哪1.1 16.6 毫秒里CPU 和 GPU 都在忙什么大多數(shù)項(xiàng)目里卡頓不是“某個(gè)東西太卡”而是多個(gè)消耗項(xiàng)疊加起來超出了預(yù)算。先說三個(gè)最基礎(chǔ)的單位60 幀每秒意味著每幀只有 16.6 毫秒一些移動(dòng)端項(xiàng)目目標(biāo) 30 幀也就是 33.3 毫秒但無論哪種CPU 和 GPU 都在搶這幾十毫秒。CPU 這邊最常頂著的是“繪制指令提交”和“邏輯計(jì)算”。Unity 里你每掛一個(gè) MeshRenderer 或者一個(gè)帶多個(gè)子物體的模型渲染管線就要記錄一次狀態(tài)切換、綁定材質(zhì)、往 GPU 提交一批數(shù)據(jù)。成千上萬的物體意味著成千上萬條繪制命令。GPU 這邊每一幀要做頂點(diǎn)變換、光柵化、像素著色還有頻繁的紋理采樣。頂點(diǎn)太多、像素填充太狠、貼圖太大、Shader 太重都會(huì)把 GPU 的時(shí)間吃光。很多人搞混一個(gè)概念一個(gè)游戲卡不是因?yàn)椤皷|西多”而是因?yàn)槟硞€(gè)環(huán)節(jié)的瓶頸被打穿了。CPU 和 GPU 是并行跑的兩條流水線CPU 卡并不代表 GPU 忙反過來也一樣。用 Profiler 看數(shù)據(jù)時(shí)要分清當(dāng)前瓶頸到底在 CPU 還是在 GPU否則很容易做無用功——比如你苦心把模型面數(shù)砍了一半結(jié)果發(fā)現(xiàn)瓶頸根本不在 GPU 頂點(diǎn)階段幀率毫無變化白白消耗團(tuán)隊(duì)精力。這個(gè)“瓶頸思維”和 Julia 社區(qū)聊性能優(yōu)化時(shí)常提的內(nèi)存管理很像不考慮分配發(fā)生在哪、發(fā)生在高頻循環(huán)還是低頻初始化就不知道優(yōu)化代碼哪里有效果。場景搭建同理——先搞清楚每幀預(yù)算花在哪個(gè)環(huán)節(jié)比盲目減面、盲目刪東西重要得多。1.2 場景里最常見也最隱秘的消耗項(xiàng)場景性能問題里有三個(gè)經(jīng)常被低估的消耗項(xiàng)。第一個(gè)是 Draw Call 批次。它比面數(shù)更容易成為真正的瓶頸尤其在移動(dòng)端。CPU 提交命令的成本遠(yuǎn)高于 GPU 處理三角形同一個(gè)模型用 10 個(gè)材質(zhì)比 10 個(gè)模型共用 1 個(gè)材質(zhì)更容易卡。美術(shù)層面能做的就是“共用材質(zhì)、共用網(wǎng)格、圖集化”后面會(huì)展開。第二個(gè)是 Overdraw也叫重復(fù)繪制。一個(gè)像素被反復(fù)畫了好幾次畫面看起來沒問題但 GPU 的像素填充率已經(jīng)被悄悄吃沒了。典型場景半透明粒子疊幾層、草地葉片互相穿插、UI 圖標(biāo)的九宮格疊太多層。在 Unity 的 Scene 視圖打開 Overdraw 模式看哪里白得發(fā)亮哪里就是填充率危機(jī)。別小看這個(gè)指標(biāo)移動(dòng)端尤其敏感很多時(shí)候幀率上不去不是三角形太密而是每一片草葉都被畫了兩三遍。第三個(gè)是紋理帶寬和內(nèi)存?，F(xiàn)在高分辨率貼圖很常見4K 甚至 8K 材質(zhì)一拖進(jìn)來顯存或共享內(nèi)存立刻見底。移動(dòng)端 GPU 和 CPU 共享一塊內(nèi)存貼圖越大讀寫帶寬消耗越大手機(jī)升溫越快最后引發(fā)降頻幀率在游戲中途突然掉下來。你看燈的功耗熱本身就是性能的敵人。這個(gè)問題游戲圈天天喊但做場景的往往到中后期才意識(shí)到貼圖尺寸不是“越大越清晰”這么簡單壓縮格式、Mipmap、圖集布局都影響最終體驗(yàn)。除了這三個(gè)還有物理碰撞體、動(dòng)態(tài)陰影、實(shí)時(shí)反射探針、屏幕后處理等都會(huì)在特定場景里成為“隱藏刺客”。排查這種問題時(shí)第一件事不是猜而是把數(shù)據(jù)和指標(biāo)擺出來。1.3 先建一張場景性能預(yù)算表既然每幀是一張預(yù)算賬本搭建前就應(yīng)該先把預(yù)算表定好。預(yù)算表不需要做得很學(xué)術(shù)但要能落地。以下是我在一個(gè)移動(dòng)端項(xiàng)目里實(shí)際用過的模板目標(biāo)設(shè)備是中端 Android 手機(jī)幀率目標(biāo) 30 幀指標(biāo)預(yù)算值說明幀耗時(shí)33.3msCPU 主線程和渲染線程各 6~8msGPU 控制在 16ms 以內(nèi)Draw Call≤300超過這個(gè)數(shù)字CPU 渲染線程壓力明顯上升三角形≤40 萬全場景一幀內(nèi)可見三角形的估算上限Overdraw平均 ≤2后處理區(qū)域之外像素重復(fù)繪制次數(shù)控制在 2 倍以內(nèi)紋理內(nèi)存按項(xiàng)目分配壓縮后單個(gè)場景建議不超項(xiàng)目內(nèi)存預(yù)算的一半真機(jī)溫度≤42℃連續(xù)跑 30 分鐘后的機(jī)身溫度超過就要降負(fù)載具體數(shù)字會(huì)因?yàn)轫?xiàng)目平臺(tái)和美術(shù)風(fēng)格差異很大。重點(diǎn)不是數(shù)字本身而是把預(yù)算寫進(jìn)場景設(shè)計(jì)文檔讓美術(shù)、TA、客戶端開發(fā)都看到。這樣搭建過程中每一步都有據(jù)可依——這個(gè)墻面的貼圖為什么只能給 1024因?yàn)轭A(yù)算表上寫了這棵樹為什么只能用 3 個(gè) LOD因?yàn)轭A(yù)算表就給了這么多。如果一開始沒有預(yù)算表優(yōu)化就會(huì)變成“上線前大家一起挑毛病”美術(shù)改得心煩程序調(diào)得頭大。有了預(yù)算表優(yōu)化的入口就從“事后補(bǔ)救”變成了“事前設(shè)計(jì)”。所以這個(gè)部分寫得再啰嗦都值得。2. 搭建前先定調(diào)燈光、烘焙與氛圍方案的取舍2.1 動(dòng)態(tài)光與烘焙為什么“靜態(tài)優(yōu)先”是大多數(shù)場景的最優(yōu)解“好看和性能兼顧”這句話落到場景搭建里最核心的博弈場就是光照方案。一個(gè)大而化之的經(jīng)驗(yàn)是能不動(dòng)態(tài)就不動(dòng)態(tài)能烘焙就烘焙。實(shí)時(shí)燈光越多每幀要做多次光照計(jì)算再加上實(shí)時(shí)陰影GPU 負(fù)載一下子就上去了。動(dòng)態(tài)光照最低也是每盞燈 Multiple Pass 的疊加而烘焙靜態(tài)光是一次性代價(jià)游戲運(yùn)行期間完全不花 CPU/GPU——這個(gè)差價(jià)在移動(dòng)端尤其明顯。很多人覺得烘焙是“老辦法”不夠酷。但如果你做的場景大部分物體是不動(dòng)的——地面、建筑、道具、植被這些靜態(tài)物體用烘焙光照完全夠效果還因?yàn)閾碛腥止庹招畔⒍岷?。你想?shí)現(xiàn)那種既明亮又有層次的環(huán)境光反射通常不是靠多放幾盞燈而是軟件烘焙替你把光算好了。真正適合實(shí)時(shí)動(dòng)態(tài)光的場景反而是少數(shù)比如大量角色、載具頻繁移動(dòng)的玩法地圖或者有大量可破壞物、需要實(shí)時(shí)光照反饋的關(guān)卡。但動(dòng)態(tài)光照也不是完全不用?，F(xiàn)在 UE/Unity 都支持混合光照模式模型上區(qū)分“固定光”和“僅烘焙”物體可以把動(dòng)態(tài)物體處理好又不至于全場景實(shí)時(shí)計(jì)算。核心原則把實(shí)時(shí)光照用在真正需要?jiǎng)討B(tài)表現(xiàn)的地方其余交給烘焙。2.2 Lightmap、Light Probe 與陰影的落地配置烘焙不是簡單點(diǎn)一下“Generate Lighting”就完了有幾個(gè)參數(shù)直接決定“好看”和“性能”。Lightmap 分辨率是第一個(gè)關(guān)鍵。它是場景精度和內(nèi)存之間的平衡。一片場景用一個(gè) 2048 方塊能保證大面墻的明暗過渡細(xì)膩但內(nèi)存也會(huì)明顯上漲。實(shí)際經(jīng)驗(yàn)是主體建筑和地形用 2048 或 1024小道具、裝飾件用 512 甚至 256。烘焙前要檢查 UV 利用率很多烘焙漏光和技術(shù)瑕疵都源自 UV 排列卷繞、UV 島間距不夠。Light Probe光照探針是動(dòng)態(tài)物體的救星。角色、移動(dòng)平臺(tái)、能被搬動(dòng)的箱子都會(huì)在場景里穿過不同光照區(qū)域。沒有 Light Probe它們只會(huì)收到統(tǒng)一的環(huán)境光看起來像紙片一樣浮在場景上。布點(diǎn)時(shí)沿著角色可能的行動(dòng)路徑放得更密一些在門框、走廊拐角、窗戶旁邊多放幾個(gè)數(shù)值上并不貴但對(duì)畫面完整度提升非常明顯。陰影方案也要提前想。移動(dòng)端項(xiàng)目我不會(huì)輕易開全屏實(shí)時(shí)陰影因?yàn)殛幱吧疃荣N圖生成和采樣都是 GPU 成本。常見的替代方案包括給主要物體加一個(gè)極低透明度的暗面模型或者用貼花式假陰影/Ambient Occlusion 貼圖模擬接觸陰影。PC 端的陰影可以開高一點(diǎn)但也要控制級(jí)聯(lián)陰影的距離與分辨率遠(yuǎn)處可以淡出或退成烘焙陰影。2.3 后處理的加減法氛圍感不等于濾鏡堆疊后處理是拉高畫面“氛圍感”最便宜的手段也是壓垮 GPU 最便宜的“毒藥”。Bloom、Color Grading、HDR 范圍映射、Motion Blur、景深……每加一個(gè)全屏效果等于每個(gè)像素都多跑一遍全屏計(jì)算。對(duì) 1080p 甚至 1440p 的移動(dòng)端來說多個(gè)全屏效果疊加填充率馬上就緊張了。我建議做場景時(shí)把后處理效果分成“必須項(xiàng)”和“加分項(xiàng)”。必須項(xiàng)只有幾個(gè)基礎(chǔ)色調(diào)、必要的光暈、僅作為氛圍的 Bloom。加分項(xiàng)比如景深、徑向模糊、體積光逐平臺(tái)開開關(guān)?？梢宰鲆粋€(gè)“視覺完整性清單”對(duì)某個(gè)場景來說哪個(gè)效果拿掉后玩家會(huì)覺得“畫面變丑了”列入必須項(xiàng)拿掉后大部分人察覺不到的列入加分項(xiàng)。這個(gè)清單再和技術(shù)側(cè)對(duì)齊形成可執(zhí)行的后處理降級(jí)策略比如低端機(jī)自動(dòng)關(guān)掉 Motion Blur、減少 Bloom 采樣層數(shù)。后處理本身不是問題問題在于用加法堆出好看而不是用精準(zhǔn)的減法做高級(jí)感。攝影里講究構(gòu)圖做減法場景搭建和后期調(diào)色也一樣。3. 地編實(shí)操模型、貼圖、植被與擺放策略3.1 用 LOD 和減面拿回幀率但別在錯(cuò)誤的地方較勁LODLevel of Detail是場景搭建里必須掌握的基本功。同一棵樹近處用高模遠(yuǎn)處用低模更遠(yuǎn)處直接換成一個(gè)十字片或者干脆剔除。UE 的 Nanite 能在超高面數(shù)下部分替代手工 LOD但多數(shù)項(xiàng)目還是手工配置 LODGroup。配置時(shí)注意三個(gè)參數(shù)切換距離、每級(jí)面數(shù)、過渡方式。切換距離不是隨心設(shè)的要配合視錐和相機(jī)移動(dòng)速度。移動(dòng)端常見經(jīng)驗(yàn)是近景 LOD0 距離設(shè)成 10~20 米中景 LOD1 在 20~50 米遠(yuǎn)景 LOD2 負(fù)責(zé)填滿視野。面數(shù)梯度別一下砍太狠比如 10000 → 5000 → 1000中間檔保留得細(xì)一點(diǎn)跳變會(huì)小很多。過渡方式上Crossfade交叉淡化效果平滑但會(huì)增加渲染開銷Dither 過渡在某些移動(dòng) GPU 上會(huì)帶來像素著色負(fù)擔(dān)使用時(shí)也要實(shí)測。減面這件事別在錯(cuò)誤的地方較勁。很多時(shí)候你花兩小時(shí)在雕刻軟件里把墻面減了 2000 個(gè)面不如把墻邊放著的那個(gè) 10 萬面裝飾模型砍成正八棱柱。要根據(jù)預(yù)算去掃雷先看場景里哪些模型占的面數(shù)比例最大再?zèng)Q定值不值得減。用 Profiler 或統(tǒng)計(jì)工具按網(wǎng)格面數(shù)排序別靠肉眼感覺。3.2 貼圖壓縮與紋理復(fù)用視覺質(zhì)量不會(huì)騙人內(nèi)存會(huì)貼圖尺寸規(guī)范很容易被美術(shù)忽略。很多團(tuán)隊(duì)文檔里寫著“場景貼圖最大 2048”實(shí)際上文件夾里 4K、甚至 8K 的圖是正常操作。在 PC 上 8K 可能影響不大但放到移動(dòng)端就是災(zāi)難。一個(gè)常用的換算一張 1024x1024 的 RGBA32 紋理占 4MBASTC 4x4 壓縮后約 1MBASTC 8x8 更低。一個(gè)普通場景里幾十上百張貼圖面數(shù)遠(yuǎn)小于貼圖占的內(nèi)存。貼圖壓縮格式要按平臺(tái)選。Android 上優(yōu)先 ASTC低端或老設(shè)備退回 ETC2iOS 全系列基本都支持 ASTC。關(guān)鍵點(diǎn)壓縮會(huì)影響質(zhì)量和色帶表現(xiàn)尤其是天空漸變、灰階高度圖、法線貼圖。經(jīng)驗(yàn)是用“噪聲抖動(dòng)”打破色帶很多引擎后處理或?qū)牍芫€里能加。紋理復(fù)用比“壓縮”更值得花時(shí)間。同樣一塊磚墻貼圖配上不同 Tiling、不同色調(diào)差異就能覆蓋小區(qū)里大半建筑外立面。把公用的磚、木紋、金屬、地面材質(zhì)做成圖集或通用材質(zhì)庫讓地編同學(xué)“拼貼”而不是“每面墻新建一張圖”。這個(gè)習(xí)慣能同時(shí)省內(nèi)存、省帶寬、省制作時(shí)間——好看的場景從來不靠貼圖堆數(shù)量。3.3 植被與重復(fù)物件的實(shí)例化擺放場景里最容易把幀率拖垮的就是植被——樹、灌木、花、草叢幾百上千棵是常態(tài)。同樣一棵樹用“復(fù)制粘貼”的方式擺 1000 棵游戲就在 1000 個(gè)獨(dú)立 Draw Call 里游泳用 GPU Instancing所有同 Mesh 同材質(zhì)的樹被引擎合并成幾個(gè)批次性能差距往往有幾十倍。Unity 里開啟實(shí)例化很簡單把材質(zhì)勾上 Enable GPU Instancing再確保物體共用同一個(gè)網(wǎng)格和材質(zhì)引擎能自動(dòng)合并。UE 這邊常用 HISMHierarchical Instanced Static Mesh或 PCG 生成植被。注意實(shí)例化不等于完全沒有代價(jià)每個(gè)實(shí)例仍然要參與視錐剔除讀它的 Transform 數(shù)據(jù)但總開銷遠(yuǎn)小于獨(dú)立渲染。植被擺放時(shí)還要注意葉片越密、半透明越多Overdraw 越嚴(yán)重。草地的葉片如果疊得很厚即使 Draw Call 很低像素填充也不一定扛得住。我的做法是草叢整體用“貼片式”方式做一片草地由若干個(gè)大葉片模型組成再用稀疏的獨(dú)立草葉點(diǎn)綴近看細(xì)節(jié)不丟遠(yuǎn)看不覺得假Overdraw 可控。3.4 合并與剔除讓引擎替你省掉看不見的活“看不見的物體就不應(yīng)該被渲染”——這句話聽著像廢話但很多場景都做不到。地編擺出來的物件跑起來時(shí)很多在墻后面、在視野外或者遠(yuǎn)到已經(jīng)看不清了引擎卻還在老老實(shí)實(shí)畫它們。三個(gè)手段幫你把這個(gè)浪費(fèi)找回來。第一個(gè)是視錐剔除引擎默認(rèn)做只要模型包圍盒沒問題就不卡。第二個(gè)是遮擋剔除Occlusion Culling針對(duì)室內(nèi)和城市這類封閉場景效果極好。Unity 里需要把場景標(biāo)記為靜態(tài)、烘焙遮擋窗口然后被墻擋住的東西就真的不畫了。第三個(gè)是距離剔除或顯示距離限制。超大場景里半徑幾百米外的建筑和粒子完全可以隱藏。這個(gè)距離閾值可以參考 LOD 的最遠(yuǎn)檔——如果最遠(yuǎn)檔已經(jīng)足夠低調(diào)就不必再渲染。合并與剔除之外還要小心靜態(tài)批處理的內(nèi)存副作用。Static Batching 會(huì)把一堆小物體合并成一個(gè)大的網(wǎng)格緩沖Draw Call 降下來了但內(nèi)存會(huì)漲。物件太多且紋理太雜時(shí)合并內(nèi)存可能超過收益。判斷方法在場景中測完后看 Profiler 內(nèi)存如果 Draw Call 已經(jīng)不是瓶頸就別強(qiáng)行合并。4. 移動(dòng)端與 PC 端的差異化調(diào)優(yōu)平臺(tái)決定手段4.1 移動(dòng)端 GPU 的脾氣帶寬、發(fā)熱與 TBDR移動(dòng)端和 PC 最大的差異不是性能數(shù)字而是架構(gòu)和物理限制。移動(dòng) GPU 大多采用 TBDRTile-Based Deferred Rendering架構(gòu)畫面先在芯片上的一小塊內(nèi)存里渲染完再一次性寫回顯存。這帶來一個(gè)奇特的結(jié)果延遲光照和多 Pass 的渲染方案在某些移動(dòng) GPU 上反而比保存中間結(jié)果更高效因?yàn)?Framebuffer 不用來回寫。但別高興太早——紋理讀取還是要走內(nèi)存帶寬依然極度寶貴。發(fā)熱是移動(dòng)端另一個(gè)隱形的墻。一個(gè)場景在手機(jī)上穩(wěn)定 30 幀跑十分鐘后芯片溫度上來降頻到 15 幀這在移動(dòng)游戲里太常見了。這就是為什么做移動(dòng)端優(yōu)化時(shí)不能只看瞬時(shí)幀率還要看功耗和溫升。很多團(tuán)隊(duì)會(huì)定一個(gè)目標(biāo)某個(gè)場景在真機(jī)上連續(xù)跑 30 分鐘機(jī)身溫度不超過 42 度幀率不低于 30。這個(gè)目標(biāo)逼著你在做場景時(shí)盡量少用重后處理、少拉高分辨率、少開實(shí)時(shí)反射。PC 端相對(duì)寬松有獨(dú)立顯卡的大顯存、高帶寬實(shí)時(shí)陰影和全局光照可以開得更猛高端卡還能硬件光追。但 PC 端的幀率期望也高動(dòng)輒 144Hz、2K/4K 顯示器功耗散熱沒那么大問題但“像素總量”依然對(duì) GPU 填充率有壓力。拿移動(dòng)端的思路硬套 PC 端會(huì)顯得性能冗余拿 PC 端的思路做移動(dòng)端就是災(zāi)難。所以場景方案必須先定目標(biāo)平臺(tái)。4.2 各引擎的性能分析工具怎么用工具使用是另一個(gè)值得寫透的主題。我以 Unity 和 UE 為例但思路通用。Unity 系Unity Profiler看 CPU 主線程和渲染線程耗時(shí)、內(nèi)存峰值、GC 分配。連接真機(jī)時(shí)勾選 Deep Profile 會(huì)顯著影響性能只適合小范圍 Profiling。Frame Debugger逐條查看當(dāng)前幀的 Draw Call 列表。這里的核心用法是可以看到每個(gè)批次消耗在哪里、是否有重復(fù)材質(zhì)、是否命中了 SRP Batcher。UWA 或自建性能平臺(tái)用于真機(jī)批量采樣輸出每幀耗時(shí)曲線。UE 系Unreal InsightsUE5 推出后基本替代了舊的 Profiler能看到 CPU/GPU 時(shí)間線以及每一幀里各系統(tǒng)占用的耗時(shí)。GPU Visualizerr.GPUStats相關(guān)命令可以看到“BasePass、ShadowDepths、Translucency”等階段的 GPU 時(shí)間。抓幀工具方面RenderDoc 能抓取 DX/Vulkan 的一整幀逐 DrawCall 檢查頂點(diǎn)數(shù)、像素?cái)?shù)、資源綁定是深度學(xué)習(xí)“GPU 內(nèi)部發(fā)生了什么”的利器。Android 上 Google 的 Android GPU Inspector 能讀到 Adreno/Mali 等移動(dòng) GPU 的硬件計(jì)數(shù)器直接看填充率、帶寬壓力。這一層的工具光看引擎自帶 Profiler 是不夠的。查清楚是 CPU 瓶頸還是 GPU 瓶頸是頂點(diǎn)瓶頸還是像素瓶頸后面所有優(yōu)化動(dòng)作才會(huì)有方向。4.3 真機(jī)驗(yàn)證清單別拿編輯器幀率騙自己編輯器里的幀率和真機(jī)毫不相干。編輯器用的是桌面 GPU、沒有降頻、沒有共享內(nèi)存爭搶、幀率統(tǒng)計(jì)方式也完全不一樣。所以我給團(tuán)隊(duì)定的規(guī)矩是場景每次進(jìn)入“驗(yàn)證期”必須上真機(jī)看數(shù)據(jù)。一份簡單可執(zhí)行的真機(jī)驗(yàn)證清單大致長這樣跑場景前先確認(rèn)手機(jī)電量在 30% 以上、關(guān)閉后臺(tái)推送和錄屏、開啟飛行模式如果不需要網(wǎng)絡(luò)。用統(tǒng)一的標(biāo)準(zhǔn)檔位記錄幀率比如同一臺(tái)基準(zhǔn)機(jī)、同一種畫質(zhì)檔位、同一段固定路徑。連續(xù)跑至少 10 到 15 分鐘記錄幀率曲線和機(jī)身溫度觀察是否出現(xiàn)降頻后掉幀。用 Profiler 抓若干關(guān)鍵節(jié)點(diǎn)的 CPU/GPU 耗時(shí)看有沒有特定物件進(jìn)場后幀率跳水。最低配機(jī)型、主流機(jī)型、旗艦機(jī)型各跑一遍記錄差異。這里順帶說一句有時(shí)候真機(jī)表現(xiàn)特別差不一定是場景問題。在 Windows 上跑 PC 端預(yù)覽時(shí)如果系統(tǒng)后臺(tái)拖著一堆服務(wù)、電源模式是省電擋、臨時(shí)文件把磁盤占滿幀率數(shù)據(jù)也會(huì)被嚴(yán)重干擾。把系統(tǒng)環(huán)境調(diào)干凈再測至少能保證數(shù)據(jù)可信。也有人喜歡寫一段批處理腳本一鍵關(guān)閉后臺(tái)服務(wù)、切高性能電源、清臨時(shí)文件這個(gè)在測試機(jī)上準(zhǔn)備好一套干凈環(huán)境倒是可以的。不過這種“系統(tǒng)級(jí)搶時(shí)間”只能算是測試環(huán)境的清潔問題真正決定場景好不好看的還是場景內(nèi)部的光照、資產(chǎn)和控制方案。5. 場景優(yōu)化的反直覺案例從坑里長出來的經(jīng)驗(yàn)5.1 降了面數(shù)反而沒提速有次我優(yōu)化一個(gè)室內(nèi)樣板間目標(biāo)是把動(dòng)態(tài)陰影的問題先放一邊單純降模型面數(shù)。美術(shù)同學(xué)花了好幾天把家具、墻面、裝飾品全部做了減面處理三角面總數(shù)大概降了 40%。結(jié)果放真機(jī)上一跑幀率幾乎沒動(dòng)。后面用 Frame Debugger 一查才明白Draw Call 一個(gè)都沒少幾千個(gè)獨(dú)立物件依然把 CPU 的渲染線程塞滿了。瓶頸根本不在 GPU 頂點(diǎn)處理而是在 CPU 的提交開銷。這是個(gè)典型教訓(xùn)看到幀率卡第一個(gè)動(dòng)作不應(yīng)該是“砍面數(shù)”而是先用工具定位瓶頸。降面數(shù)只對(duì) GPU 頂點(diǎn)處理瓶頸有效如果是 CPU Draw Call 瓶頸優(yōu)先做合并材質(zhì)、開啟實(shí)例化、做圖集。5.2 關(guān)掉陰影之后畫面“發(fā)飄”了移動(dòng)端項(xiàng)目實(shí)時(shí)陰影太重我決定把主光源的實(shí)時(shí)陰影關(guān)掉幀率立刻上去了不少。但測試群里反饋“畫面變假了”“東西像貼在地上一樣”。后來分析原因陰影在畫面里承擔(dān)著巨大的“接地感”和空間深度提示尤其物體之間小縫隙的陰影稍微缺一塊視覺上就覺得浮起來。最終方案不是重新開回來而是用三種替代補(bǔ)上給地面和物體接縫做烘焙 AO在貼圖上模擬接觸陰影對(duì)關(guān)鍵角色和交互物件單獨(dú)保留低分辨率的實(shí)時(shí)陰影范圍為角色周邊幾米靜態(tài)物體把陰影信息烘焙成 Lightmap 的一部分動(dòng)態(tài)物體用 Light Probe 補(bǔ)。實(shí)踐下來畫面恢復(fù)了立體感幀率依然保持住了。這個(gè)案例讓我徹底理解了一件事一味硬砍功能不是優(yōu)化優(yōu)化是“砍掉一個(gè)消耗項(xiàng)之后找到另一個(gè)更便宜的方式補(bǔ)回它的視覺職責(zé)”。5.3 貼圖壓縮造成的色帶與烘焙漏光第一次把項(xiàng)目從開發(fā)機(jī)切到移動(dòng)端平臺(tái)時(shí)天空盒和漸變材質(zhì)上出現(xiàn)了明顯的色帶一層一層的橫紋特別難看。原因是 ETC2/ASTC 這種帶損壓縮格式在低碼率下對(duì)漸變不友好差異細(xì)微的顏色被量化成幾個(gè)跳變。解決辦法分幾路關(guān)鍵漸變貼圖單獨(dú)提高壓縮率Shader 里給顏色加一點(diǎn)微小的抖動(dòng)Dither打散色帶天空盒這類超大漸變紋理盡量不壓縮或者用程序化天空替代貼圖。烘焙漏光則是另一個(gè)經(jīng)常被甩鍋的問題場景明明沒有光能進(jìn)來的地方出現(xiàn)了發(fā)亮的縫、漏光的邊緣。排查時(shí)發(fā)現(xiàn)大多是模型的問題——墻與墻之間有微小縫隙、兩個(gè)平面互相重疊、UV 島之間間隙太大。后來我們把“所有體積表面必須閉合、沒有重疊面、UV 留出安全間距”寫進(jìn)地編規(guī)范烘焙前再用腳本批量檢查漏光率大幅下降。這些屬于“光看漂亮渲染圖永遠(yuǎn)發(fā)現(xiàn)不了必須看貼圖、看幾何、看 UV”的底層問題。5.4 LOD 切換的跳變與“優(yōu)化過度”的邊界LOD 切換是另一個(gè)磨人的問題。有時(shí)候 LOD0 到 LOD1 的面數(shù)差太大或者距離設(shè)得太激進(jìn)玩家正常走路時(shí)能看到樹冠和墻體“啪”地變了一個(gè)形狀非常出戲。后來把切換距離拉開、在中間檔多留一檔再加上過渡動(dòng)畫跳動(dòng)基本消失了。另外不同物件的關(guān)鍵程度不一樣——主角身邊的物件、UI 里顯示的道具、劇情鏡頭看得到的裝飾LOD 切換要非?？酥七h(yuǎn)處的填充物則可以大膽減。最后我還要提醒一句“優(yōu)化過度”的反面有些場景優(yōu)化過頭了貼圖全壓小、陰影全去掉、后處理全關(guān)、LOD 距離壓得很近幀率自然好看但畫面也失去了個(gè)性和氛圍。玩家說不上來哪里不對(duì)就是覺得“這個(gè)游戲很便宜”。優(yōu)化的底線是保住視覺完整性和獨(dú)特氣質(zhì)。比較好的做法是維護(hù)一份場景“不可妥協(xié)清單”這個(gè)場景的核心氛圍、關(guān)鍵材質(zhì)質(zhì)感、標(biāo)志性的光影效果無論如何都要保留其他輔助效果按預(yù)算逐級(jí)關(guān)閉。這樣團(tuán)隊(duì)在降級(jí)時(shí)有優(yōu)先級(jí)而不是一刀切。6. 從“搭完再調(diào)”到“邊搭邊驗(yàn)證”的流程化方法6.1 分階段搭建每一層都要過一遍機(jī)器場景搭建如果還停留在“全部搭完再統(tǒng)一優(yōu)化”那后面大概率是災(zāi)難。我現(xiàn)在的做法是分階段搭建每個(gè)階段結(jié)束都跑一次真機(jī)驗(yàn)證白盒布局期用簡單的方塊和灰模搭出關(guān)卡結(jié)構(gòu)、動(dòng)線、空間尺度。這個(gè)階段就要確認(rèn)大場景的物件數(shù)量、可見距離、大體遮擋關(guān)系。資產(chǎn)導(dǎo)入期把真實(shí)美術(shù)資源替換進(jìn)來從灰模過渡到正式場景。每導(dǎo)一批資源就統(tǒng)計(jì) Draw Call、內(nèi)存、三角形看有沒有瞬間超預(yù)算的。精修打磨期做光照烘焙、后處理、氛圍調(diào)整。烘焙重、后處理重、粒子特效重全都集中在這個(gè)階段所以每調(diào)一次都要看真機(jī)。這種流程能讓超預(yù)算的“病灶”在早期暴露比如白盒期就發(fā)現(xiàn)場景太大導(dǎo)致物件數(shù)量必然超預(yù)算那就提前調(diào)整關(guān)卡范圍或拆分場景而不是等幾個(gè)月的資產(chǎn)都做完了才發(fā)現(xiàn)。6.2 把性能檢查變成日常動(dòng)作而不是上線前的大掃除性能檢查和寫代碼跑測試一樣應(yīng)該是日常動(dòng)作不能等到快上線才“大掃除”。在實(shí)際操作中我會(huì)在項(xiàng)目里放一些簡單的編輯器工具腳本幫助地編在搭建時(shí)隨時(shí)自查。這里分享一個(gè) Unity 編輯器小腳本的思路用來統(tǒng)計(jì)當(dāng)前選中場景里的 Mesh 三角形總數(shù)和大致 Draw Call 數(shù)量using UnityEngine; using UnityEditor; using System.Collections.Generic; public static class SceneStatWindow { [MenuItem(Tools/統(tǒng)計(jì)場景負(fù)載)] static void CountScene() { MeshRenderer[] renderers Object.FindObjectsOfTypeMeshRenderer(); int verts 0; int tris 0; HashSetMaterial mats new HashSetMaterial(); foreach (MeshRenderer mr in renderers) { if (!mr.enabled || !mr.gameObject.activeInHierarchy) continue; MeshFilter filter mr.GetComponentMeshFilter(); if (filter ! null filter.sharedMesh ! null) { verts filter.sharedMesh.vertexCount; tris filter.sharedMesh.triangles.Length / 3; } foreach (Material mat in mr.sharedMaterials) if (mat ! null) mats.Add(mat); } Debug.Log($[場景負(fù)載] 頂點(diǎn): {verts} 三角形: {tris} 唯一材質(zhì)數(shù): {mats.Count}); } }注意這個(gè)腳本只做粗估真正的 Draw Call 還要結(jié)合 Static Batching、GPU Instancing、SRP Batcher 看。但日常產(chǎn)出來說它已經(jīng)能救命了——很多地編同學(xué)可能連“我的場景有多少三角形”都答不上來。6.3 誰來為“好看與性能”負(fù)責(zé)流程越往后越會(huì)發(fā)現(xiàn)一個(gè)場景能不能既好看又流暢往往不是某一個(gè)人的事而是一個(gè)機(jī)制的事。團(tuán)隊(duì)里最好有人專門對(duì)場景的整體性能負(fù)責(zé)——通常 TA 或主美帶客戶端程序支持。TA 的職責(zé)是定預(yù)算、寫規(guī)范、維護(hù)資源檢查工具、做平臺(tái)降級(jí)方案主美負(fù)責(zé)守住視覺底線客戶端程序和 TA 一起在真機(jī)上看數(shù)據(jù)。地編同學(xué)是最直接接觸場景的人他們需要懂起碼的性能常識(shí)Draw Call 是什么、LOD 怎么配、貼圖大小怎么選、陰影廣告牌怎么用。不需要看懂底層渲染源碼但要知道自己擺一個(gè)物件、換一張貼圖、加一排燈光會(huì)對(duì)幀率產(chǎn)生什么量級(jí)的影響。這比上線前專門組織一場“性能優(yōu)化突擊”要省太多成本。我最后再分享一個(gè)很小但很實(shí)際的習(xí)慣把團(tuán)隊(duì)定的場景性能預(yù)算表打印出來或者放在場景文檔第一頁每次接一個(gè)新場景任務(wù)第一眼先看預(yù)算。不要低估這種“貼墻上的規(guī)矩”的力量。我見過太多項(xiàng)目性能知識(shí)大家都懂但一到做場景就放飛自我——因?yàn)轭A(yù)算沒有成為設(shè)計(jì)輸入的硬約束。預(yù)算一旦寫進(jìn)文檔和流程大家都按同一套標(biāo)準(zhǔn)干活好看與性能的自然融合就會(huì)發(fā)生。