
このページで学ぶ内容: モバイルゲーム用にアートアセットを最適化するために役立つヒント集の第 2 部。パート I はこちらです。
モバイル最適化のヒントは他にも多数あります この包括的な e ブック と Unity Learn コースの 3D Art Optimization for Mobile Applications をご覧ください。

コンソールや PC の同じ物理ベースのライティングとマテリアルを、ユニバーサルレンダーパイプライン(URP)を使用してスマートフォンやタブレットにスケーリングすることもできます。
ドローコールをバッチ処理
フレームごとに、Unity はレンダリングする必要があるオブジェクトを決定し、ドローコールを作成します。ドローコールはグラフィックス API を呼び出してオブジェクト(三角形など)を描画するものですが、バッチはまとめて実行されるドローコールのグループです。描画するオブジェクトをバッチ処理することで、各オブジェクトをバッチで描画するために必要な状態変更を最小限に抑えます。これは、オブジェクトのレンダリングにかかる CPU コストを削減することで、パフォーマンスの向上につながります。
SRP バッチング:Advanced の下の URP アセットで SRP Batcher を有効にします。これにより、シーンによっては CPU レンダリング時間が大幅に短縮されます。
モバイルアプリケーションに動的ライトを追加しすぎないことが重要です。動的メッシュ用のカスタムシェーダーエフェクトやライトプローブ、静的メッシュ用のベイク済みライティングなどの代替手段を検討してください。
URP とビルトインレンダーパイプラインのリアルタイムライトの具体的な制限については、この機能比較表を参照してください。
シャドウキャスティングは、MeshRenderer とライトごとに無効にできます。ドローコールを減らすために、可能な限りシャドウを無効にします。
また、キャラクターの下のシンプルなメッシュやクアッドに適用されたぼやけたテクスチャを使用して、フェイクシャドウを作成することもできます。また、カスタムシェーダーでブロブシャドウを作成することもできます。


複数のライトを含む複雑なシーンでは、レイヤーを使用してオブジェクトを分離し、各ライトの影響を特定のカリングマスクに制限します。

ライトプローブは、シーン内の何もない空間に関するベイクしたライティング情報を保存し、(直接光と間接光の両方で)高品質なライティングを提供します。動的ライトと比較して計算が高速な球面調和関数を使用しています。

リフレクションプローブはリアルなリフレクションを作成できますが、バッチのコストが非常に高くなります。低解像度のキューブマップ、カリングマスク、テクスチャ圧縮を使用して、ランタイムのパフォーマンスを改善します。

オブジェクトを透明度でレンダリングすると、不透明なオブジェクトをレンダリングするよりも多くの GPU リソースが消費されます。特に、透明なオブジェクトが複数回重ねられてレンダリングされる場合、これはオーバードローと呼ばれるプロセスです。特にモバイルプラットフォームでは、可能な限り不透明なマテリアルを使用することをお勧めします。オーバードローは、RenderDoc グラフィックスデバッガーを使用してチェックできます。
シェーダーは可能な限りシンプルなもの(Unlit シェーダーなど)を使用し、不要な機能は使用しないようにしましょう。パーティクルなどのシステム専用に設計された Unity の事前構築済みシェーダーを使用します。URP には、モバイルプラットフォーム向けに最適化された軽量の Lit シェーダーと Unlit シェーダーがいくつか含まれています。オーバードローを最小限に抑えるには、ゲーム内のパーティクルの数やサイズを減らします。
パフォーマンス目標のためには、Unlit Opaque マテリアルを可能な限り半分の精度で使用することを検討し、ノードでの複雑な操作に注意してください。シェーダーグラフに関するこのセッションでは、さらに多くのヒントを紹介します。
シェーダーの作成時に、マテリアルが光にどのように反応するかを決めることができます。ほとんどのシェーダーは、lit または unlit に分類されます。Unlit シェーダーは、最も高速で計算コストの低いシェーディングモデルです。ローエンドのデバイスをターゲットにしている場合に使用します。
考慮すべき重要なポイントは以下の通りです。

頂点シェーダーはすべての頂点で機能し、ピクセル(またはフラグメント)シェーダーはすべてのピクセルで実行されます。通常、レンダリングされるピクセル数は画面上の頂点の数よりも多くなります。これは、ピクセルシェーダーが頂点シェーダーよりも頻繁に実行されることを意味します。このため、可能な限り計算をピクセルシェーダーから頂点シェーダーに移すことをお勧めします。いつものように、最適化に取り組んだ後は、さらにプロファイリングを行い、特定の状況に最適なソリューションを決定する必要があります。
加算や乗算などの基本的な演算の処理が高速化されています。より遅い演算の回数はできるだけ少なくするのがベストです。GLES 2.0 を使用するような古いデバイスでは、使用される複雑な計算の量を低く抑える必要があります。
SRP Batcher をオンに切り替えるときは、Profiler ビューの Statistics ウィンドウと Rendering Section の頂点グラフを確認してください。FPS の隆起を除けば、処理される三角形と頂点の数は劇的に減少します。オブジェクトは URP と互換性のあるシェーダーを使用しているため、レンダーパイプラインは関連するすべてのジオメトリデータを自動的にバッチ処理して、処理されるデータ量を削減します。
デフォルトでは、Unity はアニメーション化されたモデルを Generic リグでインポートしますが、開発者がキャラクターをアニメーション化するときは Humanoid リグに切り替えることがよくあります。ヒューマノイドリグは、インバースキネマティクスとアニメーションのリターゲティングをフレームごとに計算するため、同等のジェネリックリグよりも 30 ~ 50% 多くの CPU 時間を消費します。
スキンメッシュのレンダリングにはコストがかかります。SkinnedMeshRenderer を使用するすべてのオブジェクトに必要です。ゲームオブジェクトがアニメーションのみを必要とする時間がある場合は、BakeMesh 関数を使用してスキンメッシュを静的ポーズで固定し、実行時によりシンプルな MeshRenderer に切り替えます。
主にヒューマノイドキャラクターを対象とした Unity の Mecanim システムは非常に洗練されていますが、単一の値(UI 要素のアルファチャンネルなど)をアニメーション化するためによく使用されます。アニメーターを使いすぎないようにしましょう。特に、UI 要素と組み合わせてトゥイーン関数を作成したり、シンプルなアニメーション(DOTween や LeanTween など)にサードパーティ製のライブラリを使用することを検討してください。

フレームごとに特定の時間予算で作業する
各フレームには、目標とする 1 秒あたりのフレーム数(fps)に基づいた時間予算があります。理想的には、30fps で動作するアプリケーションでは、1 フレームあたり約 33.33ms(1000ms / 30fps)が許容されます。同様に、60 fps を目標にすると、1 フレームあたり 16.66 ミリ秒になります。
デバイスは短時間(カットシーンやロードシーケンスなど)はこの予算を超えることがありますが、長時間は超えられません。
プリセット
デフォルト設定に依存せず、プラットフォーム固有のオーバーライドタブを使用して、テクスチャやメッシュジオメトリなどのアセットを最適化します。設定を誤ると、ビルドサイズが大きくなり、ビルド時間が長くなり、メモリ使用量が少なくなる可能性があります。特定のプロジェクトを強化するベースライン設定のカスタマイズに役立つプリセット機能の使用を検討してください。
カメラの使用を制限する
各カメラには、意味のある仕事をしているかどうかにかかわらず、ある程度のオーバーヘッドが発生します。レンダリングに必要なカメラコンポーネントのみを使用してください。ローエンドのモバイルプラットフォームでは、各カメラは最大 1ms の CPU 時間を使用できます。
フルスクリーンエフェクトを避ける
グローなどの全画面のポストプロセッシングエフェクトは、パフォーマンスを劇的に低下させる可能性があります。タイトルのアートディレクションでは慎重に使用してください。
Renderer.material には注意する
スクリプトで Renderer.material にアクセスすると、マテリアルが複製され、新しいコピーへの参照が返されます。これにより、マテリアルがすでに含まれている既存のバッチが壊れます。バッチ化されたオブジェクトのマテリアルにアクセスする場合は、代わりに Renderer.sharedMaterial を使用します。