簡而言之： 巨大比例的玩家在樸素硬體上——筆電、Steam Deck 之類的掌機、更老的 GPU——而一個只在高階機器上跑的環境把他們 排除在外。好消息：大多數環境效能丟在幾個可預測的地方（過繪製、繪製呼叫、密集植被、過大貼圖），並用幾個自律的習慣奪回。這是一份 不掏空你美術就命中低幀預算的實用手冊，外加用固定相機在回退發貨前抓住它們的方法。
這是最貴的一類場景來跑——層層透明葉片、成千上萬實例、沉重過繪製。一旦你知道幀時間去了哪，它也是最大、最容易的勝利所住之處。
先定一個預算，以毫秒計
在你最弱的受支援硬體上挑一個目標幀時間——60 fps 用 16.6 ms，30 用 33.3 ms——並把它當作硬限。「以後最佳化」意味著「以 後重建」；預先做預算便宜得多。
沒有數字的最佳化只是憑感覺。在你的地板硬體上——Steam Deck、一台中階筆電、無論你的最低配是什麼——決定你瞄準的幀，並把它換成毫 秒，因為毫秒會累加而百分比會撒謊。然後在你建置時把每個場景都守在那，而非在末尾。那些在低階上流暢發貨的團隊並不最佳化得更狠；他們只 是從一開始就絕不讓一個場景撐爆預算，這只是美術做完、一切都依賴它之後再把效能摳回來的成本的一小部分。
知道時間去了哪
環境幀時間通常被過繪製（透明植被）、太多繪製呼叫（未批次處理物件）、過大貼圖（記憶體頻寬）以及昂貴的光照/陰影所吃掉。在盲目 最佳化前，做剖析以找出你的瓶頸。
猜測最佳化浪費數天。打開一個剖析器，找出你是 CPU 受限（通常是繪製呼叫）還是 GPU 受限（通常是過繪製、著色或頻寬），並攻擊真正的瓶 頸。話雖如此，環境以可預測的方式失敗，而幾乎總是其中之一：來自層層透明植被的過繪製；來自成千上萬未實例化物件的繪製呼叫；來 自過大或過多貼圖的貼圖記憶體/頻寬；以及來自太多動態光或高解析度陰影圖的光照/陰影開銷。本手冊其餘部分按其慣常影響的次序逐一 處理它們。
植被與過繪製：慣常的反派
透明植被卡片相互重疊並把同一批像素重新著色許多次——那就是過繪製，也是低階頭號殺手。減少葉片卡片重疊，使用激進的 LOD，並 狠狠剔除遠處植被。
密集植物是大多數低階幀預算死亡之處，因為每張半透明葉片卡片都逼迫 GPU 去著色它隨後會在其上重畫的像素——在厚密樹冠裡有時每像素十次以 上。修復：使用更緊湊、浪費透明區域更少的葉片卡片，隨植被退遠快速跌到更便宜的 LOD，並設硬剔除距離，好讓遠處的草與灌叢乾脆停止繪製。 在掌機上，「草到地平線」與「草在合理距離剔除」之間的差別，可能就是 25 與 40 fps 之間的全部差別。把植被烘焙成原生實例，好讓 GPU 能批次處 理它，並讓引擎的實例化去幹重活。
繪製呼叫與實例化
每個單獨提交的獨特物件都是一次繪製呼叫，成千上萬個會讓 CPU 停頓。把重複網格實例化，好讓數百份拷貝只花一次呼叫；在有意義 之處合併靜態雜物。
若你 CPU 受限，繪製呼叫通常就是原因。你請引擎渲染的每個不同的東西都攜帶開銷，而一個用一千塊個體岩石與灌叢手放的場景，會把 CPU 淹在 提交成本裡。實例化是解藥：作為實例繪製的重複網格把數百份拷貝坍縮成單次呼叫，這正是那些烘焙成原生引擎實例的散佈工具對效能要緊的 原因——看著像一千株植物的散佈，花費卻像一小把。在實例化不適用之處，把小的靜態雜物合併成組合網格也削減呼叫數。這是一個像 [Numivo] (/features) 那樣的工作流——繪製密度，然後烘焙成樸素的實例化網格——在弱硬體上直接見效之處，因為輸出正是 GPU 想要的那件便宜東西。
並非每個場景都得最大限度地密集。安靜、開闊的空間幾乎不花什麼，也給硬體與玩家雙方一份歇息——為你的密度做節奏本身就是一種最佳化。
LOD、剔除距離與貼圖尺寸
給每個重要網格 LOD，好讓遠處拷貝便宜；設剔除距離，好讓螢幕上極小的物件停止繪製；並把貼圖解析度封頂到相機在距離上能分辨的 程度。這三樣以小力氣奪回很多。
三個不起眼的習慣扛起剩餘預算的大頭。LOD：遠處網格應切換到更低模版本，因為在一棵 20 像素的樹上放全細節是浪費。剔除距離：任何 在螢幕上小到注意不到的東西都應完全停止渲染——小道具、卵石、細草——按物件類型調。貼圖尺寸：把解析度封頂到在玩家距離上實際可分辨的 程度（見紋素密度邏輯——遠處的東西需要少得多的紋素），因為過大貼圖會燒掉低階 GPU 擠不出的記憶體頻寬。調對了這些都不傷觀感；它們只是讓你 停止為沒人看得見的細節付錢。
用固定相機找出回退
定義幾台「預算相機」——你最差的遠景、最密的戰鬥空間、最忙的室內——並在每個 build 檢查它們的幀時間。隨機飛掠會藏起回退；每次 同樣殘酷的視角會把它們暴露出來。
隨著內容加入，效能悄悄腐爛，而你隨意在關卡裡溜達是抓不到它的。相反，釘死你那一小把最差的視角——密林眺望點、擁擠的市集、特效沉重的 戰鬥——並對著預算，在每個 build 精確測量那些。當一個數字變紅，你就知道是最近一次改動造成的，以及大致在哪。這就是一個在末尾才發現效能 危機的團隊，與一個在 2 ms 回退出現當天就修好的團隊之間的差別。在低階目標上，讓其中一台相機跑在真實的 Steam Deck 或最低配機器上，而 不只是編輯器估算。
值得偷的現場數字
- 幀預算：16.6 ms（60 fps） / 33.3 ms（30 fps）——在你的地板硬體上設定
- 慣常的低階殺手：植被過繪製——更緊湊的卡片、快速 LOD、狠剔除
- 重複網格 → 實例：數百份拷貝一次繪製呼叫
- 把貼圖尺寸封頂到相機可分辨的細節——遠處需要少得多的紋素
- 用固定預算相機抓回退，每個 build 測量
迷你問答
我得在好看與低階之間選嗎？ 比你以為的少。大多數低階開銷是浪費——過繪製、未批次處理的呼叫、過大貼圖——而非可見品質。砍掉浪費，美術 就活下來；弱硬體上的玩家很少想念你曾付錢、他們卻看不見的那份細節。
動態光照在 Steam Deck 上是禁區嗎？ 不是禁區，而是有預算。限制動態光與投影者的數量，在場景靜止之處倚靠烘焙光照，把動態開銷留給要 緊之處。這是一條預算線，不是一道禁令。
在掌機上單個改動幫助最大的是什麼？ 通常是馴服植被：更緊湊的葉片卡片、激進的 LOD，以及草與灌叢上的硬剔除距離。過繪製是最常見的掌 機瓶頸，而植被正是過繪製所住之處。
我該多早在目標硬體上測試？ 從第一個縱切片起。強力開發機上的編輯器估算，恰恰藏起掌機將有的那些問題。早早在真實的最低配設備上弄到一 個 build 並把它留在迴圈裡。
在馬鈴薯上跑，不是把你的遊戲弄醜——而是不為玩家看不見的細節付錢。以毫秒做預算，殺掉過繪製，把重複實例化，剔除不可見，並在每個 build 盯 住你最差的相機——你的環境就會既好看又為那龐大的、不在高階機器上的觀眾跑起來。
