要するに： プレイヤーの巨大な割合はつつましいハードウェアにいる（ラップトップ、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 のようなワークフロー（密度を塗り、それから素のインスタンス化メッシュにベイクする）、が弱いハードウェアで直接報われる場所 だ。出力がGPUの欲しい安いものだからだ。
あらゆるシーンが最大限に密である必要はない。静かで開けた空間はほとんど費用がかからず、ハードウェアにもプレイヤーにも休 息を与える。密度をペーシングすること自体が最適化だ。
LOD、カリング距離、テクスチャサイズ
遠いコピーが安くなるよう、あらゆる重要なメッシュにLODを与え、画面上で微小なオブジェクトが描画をやめるようカ リング距離を設定し、テクスチャ解像度をカメラが距離で解像するものに上限を設けよ。この三つは少ない労力で多くを取り戻す。
三つの華のない習慣が残りの予算の大部分を担う。LOD：遠いメッシュは低ポリ版に切り替わるべきだ。20ピクセルの木に完全な ディテールは無駄だから。カリング距離：画面で気づくには小さすぎるものはすべて完全にレンダーをやめるべきだ（小さなプ ロップ、小石、細かい草）、オブジェクトタイプごとに調整。テクスチャサイズ：解像度をプレイヤーの距離で実際に解像可能なも のに上限を設けよ（テクセル密度の論理を見よ。遠いものははるかに少ないテクセルで足りる）。大きすぎるテクスチャはローエンド GPUが割けないメモリ帯域幅を焼くからだ。どれも正しく調整すれば見た目を損なわない。ただ、誰も見ないディテールに払うのを止 めさせるだけだ。
固定カメラで回帰を見つけよ
少数の「予算カメラ」を定義せよ（最悪のビスタ、最も密な戦闘空間、最も忙しい室内）、そしてそれらのフレーム時間 を毎ビルド確認せよ。ランダムなフライスルーは回帰を隠す。毎回同じ残酷なビューがそれらを露わにする。
コンテンツが追加されるにつれパフォーマンスは静かに腐り、レベルをのんびり歩き回ってそれを捕らえることはできない。代わり に、あなたの一握りの最悪のビューを固定せよ（密な森の見晴らし、混雑した市場、エフェクトの重い戦い）、そしてまさにそれら を、毎ビルド、予算に対して測れ。数字が赤くなったら、最近の変更がそれを起こしたと、そしておおよそどこかを知る。これは、 パフォーマンス危機を終わりに発見するチームと、2 msの回帰を現れた日に直すチームとの差だ。ローエンドターゲットでは、それら のカメラのひとつを、エディタの推定に頼らず実際のSteam Deckまたは最低仕様マシンで走らせよ。
盗む価値のある現場の数字
- フレーム予算：16.6 ms（60 fps） / 33.3 ms（30 fps）。あなたの床ハードウェアで設定せよ
- おなじみのローエンドキラー：植生オーバードロー。締まったカード、速いLOD、硬いカリング
- 繰り返しメッシュ → インスタンス：一ドローコールに数百のコピー
- テクスチャサイズをカメラで解像可能なディテールに上限。遠いものははるかに少ないテクセルで足りる
- 回帰を固定予算カメラで捕らえよ、毎ビルド測定
ミニFAQ
見栄えとローエンドの間で選ばねばならないか？ 思うより少ない。ローエンドコストのほとんどは無駄だ（オーバードロー、バ ッチされていないコール、大きすぎるテクスチャ）、見える品質ではない。無駄を切ればアートは生き残る。弱いハードウェアのプレ イヤーは、あなたが払っていたが彼らには見えなかったディテールをめったに恋しがらない。
動的ライティングはSteam Deckで禁じ手か？ 禁じ手ではないが、予算立てられる。動的ライトとシャドウキャスターの数を制限 し、シーンが静的なところでベイクライティングに頼り、動的コストを重要なところに取っておけ。予算の一行であって、禁止では ない。
携帯機で最も助かる単一の変更は？ たいてい植生を飼いならすこと：締まった葉カード、積極的なLOD、草や茂みの硬いカリング 距離。オーバードローは最も一般的な携帯機のボトルネックで、植生はオーバードローが住む場所だ。
ターゲットハードウェアでどれくらい早くテストすべきか？ 最初のバーティカルスライスから。強力な開発機でのエディタ推定 は、携帯機が持つまさにその問題を隠す。実際の最低仕様デバイスでのビルドを早く手に入れ、ループに保て。
ジャガイモで動かすのはゲームを醜くすることではない。プレイヤーが見られないディテールに払わないことだ。ミリ秒で予算立て、 オーバードローを殺し、繰り返しをインスタンス化し、見えないものをカリングし、毎ビルド最悪のカメラを見よ。そうすればあな たの環境は素晴らしく見え、かつハイエンドリグにいない巨大な観客のために動く。
