モバイルゲーム向けローポリモデルの作り方：ポリゴン予算、ワークフロー、最適化
モバイルゲームには厳しいポリゴン制限があります。モバイル向けに最適化されたローポリ3Dモデルの作成方法を学びましょう。デバイスごとの三角形制限、Blenderを使ったリトポロジ作業のワークフロー、LOD設定、iOSとAndroid向けのドローコール最適化といった内容を含みます。
2026年7月28日
キャラクターをモデリングし、Unity にエクスポートして Android 向けにビルドした結果、Pixel 6 でフレームレートが 22fps まで落ちました。ポリゴン数はわずか 8,000 枚でした。
それが誰も教えてくれない部分です。8000ポリゴンのキャラクターは少ないように思えるかもしれません。デスクトップゲームでは、実際その通りです。しかしモバイルでは、ポリゴン数は注目すべき指標ではありません。トライアングルカウントが問題になるよりずっと前に、ドローコールとフィルレートがシーンのボトルネックとなります。モデルには、単にポリゴン削減以上の対策が必要です。モバイル向けに設計されたパフォーマンス予算と、設計段階から組み込まれたエクスポートパイプラインが必要なのです。
この記事を読み終えるまでに、すぐに使えるポリゴン予算表、ステップバイステップのBlenderからエンジンへのワークフロー、そしてモバイル向けビルドとデスクトップ向けビルドを区別する具体的なLODとマテリアルバッチングの基準を習得できます。
モバイルにおけるローポリの計算ロジックの変化
モバイル環境において真に重要な3つの指標
トライアングル数は初心者が注目しがちな数字ですが、モバイルのパフォーマンスを決定づけるものではありません。
フィルレートはピクセル処理量の予算のことです。ミドルレンジの Android GPU は、フレームあたりの処理能力がデスクトップ GPU の約 4 分の 1 です。RTX カードで正常にレンダリングされる同じモデルでも、モバイル GPU ではオーバーシェード（過剰な描画）を引き起こし、ピクセルあたりの処理サイクルが予算を超えてしまいます。モデル自体が複雑すぎるわけではありません。問題なのは、レンダリングされているピクセル数が多すぎることです。
ドローコールは、CPUからGPUへのコマンドです。モバイルCPUはクロック速度ではなく、電力消費によって制限されます。デスクトップGPUに送信するのと同じ数のドローコールを、モバイルGPUに送信することはできません。メッシュ上の各固有のマテリアルが、ドローコールを発生させます。5つのマテリアルスロットを持つヒーローキャラクターは、環境の描画負荷に加算される前に、すでに5回のドローコールを消費しています。
SetPass コールは、モバイル環境では描画コール（draw call）よりも深刻な問題です。Unity がシェーダーを切り替える際に SetPass が発生し、そのコストは標準的な描画コールの 3〜4 倍にもなります。Android デバイスでは、12 回の SetPass で 80 回の描画コールを発行するシーンは、2 回の SetPass で同じ数の描画コールを行う場合と比べて、フレームレートが 10 FPS 低下します。ポリゴン数が問題になる以前に、マテリアル数を減らし、バッチングを行うことで、この問題を解決できます。
モバイルパフォーマンスバジェット（性能目標）
初心者のモバイルゲーム開発者が犯す最大の間違いは、スマートフォンのハードウェアを一律に扱うことです。Pixel 7とエントリークラスのSamsung Aシリーズでは、端末のスペックは大きく異なります。パフォーマンスレベルに合わせた段階的な予算を設定する必要があります。
資産種別 | 低価格スマホ（$200未満） | ミッドレンジ（200～500米ドル） | フラッグシップ（600 ドル超） |
モブNPC | 300～500 ポリゴン数 | 500～1,000 三角形 | 1,000–2,000 ポリゴン |
脇役 | 1,000–3,000 TRIS | 約3,000–5,000 三角形 | 5,000–10,000 トリス |
ヒーロー | 5,000～10,000 トライアングル | 10,000～20,000 トライアングル | 20,000–30,000 TRIS |
小型の小道具 | 50–150 トライス | 100〜300トライ | 200～500トリス（tris） |
環境パーツ | 200–1,000 トライアングル | 500～2,000 トライアングル | 1,000–4,000 TRIS |
Android開発者チームは、GAMESConで発表されたArmories demoにおいて、実用的な実世界のベンチマークを示しました。そのデモの群衆キャラクターは、1キャラクターあたり約360ポリゴンで描画され、中程度の性能のハードウェア上でシーン全体が60fpsを維持しています。これは極端な低ポリゴンの基準ではありません。これは、予算が最初に設定され、それに合わせてアートワークが構築された場合の実際のモバイルゲームシーンがどのようなものかを示しています。
フレームバジェットはシンプルです。60 fpsの場合、1フレームあたり16.6ミリ秒が割り当てられます。GPUにはシーンのレンダリングにそのうちの約半分が割り当てられます。頂点シェーダーの呼び出し、ピクセルシェーダーの実行、テクスチャフェッチのすべてがこの制限時間内に収まる必要があります。モデルのマテリアル数が多すぎると、GPU側の処理が始まる前にCPU側の処理が間に合わなくなります。
モバイルゲーム開発のためのローポリゴンモデリングの作業工程
モバイルエクスポート用の Blender セットアップ
Blenderを起動し、Unit Scaleを確認します。シーンプロパティを開き、Unit Scaleが1.0、単位系がMetricに設定されていることを確認してください。モバイルエンジンはデフォルトでメートル単位で動作するため、Blenderとエンジン間でスケールが一致していないと、100倍スケールのモデルでは極端なテクスチャフィルタリングが発生し、気付かないうちにフレームレートが低下します。
FBXエクスポートプリセットを対象エンジンに合わせて設定してください。[Geometry]の[Smoothing]を[Face]に設定すると、インポート時の頂点の分割を防ぐことができます。[Apply Scalings]にチェックを入れ、[FBX Units Scale]に設定してください。Unityの場合は、Forwardを-Z、UpをYのままにしてください。
エクスポート前に法線を厳しくチェックする必要があります。Auto Smooth をオンにして角度を 30 度に設定します。これにより、明確な稜線がきれいに保たれ、エッジが不必要に分割されるのを防ぎます。モバイルモデルには Bevel modifiers を使用しないでください。各ベベルエッジはトライアングル数を増やし、インポート時にさらに多くのエッジ分割を引き起こします。代わりに sharp edge flag を使用し、ビルド時にエンジンがそれらの頂点を統合するようにしてください。
三角形数の制限内でメッシュを構築
モバイルのキャラクタートポロジはデスクトップと同じルールに従いますが、マージンが狭いです。変形用にクアッドでモデルを作成し、エンジン用に三角形でエクスポートします。すべてのクアッドはインポート時に2つの三角形に分割されるため、実際のポリゴン数は三角形分割後に始まると考えてモデルを構築してください。
補助的な NPC を 3,000 トライアングルで設計する場合は、頭、胴体、四肢の比率で考えるのが基本です。頭部は約 500 トライアングル、胴体が 1,200、腕は片側 300、脚は片側 350 です。これは厳密な分割ではなく、詳細をどこに配置するかを決めるための指針です。顔に 300 トライアングル、体に 100 という配分ではバランスが悪く見えます。画面での表示サイズに応じて詳細度を配分しましょう。
プロップは、初心者が最も多くのトライ予算を浪費する部分です。単純な木箱、手提げ灯、樽、どれも150トライアングル以上は必要ありません。それぞれをボックスモデリングで作成しましょう。プレイヤーから見て円柱のように見える場合は、水平辺ごとに32個ではなく6個の頂点(バーテックス)を追加してください。
環境パーツはモジュール化して動作させるべきです。同じマテリアルを共有する壁セクション、床タイル、柱の基部を作成します。1つのマテリアルを共有する壁パーツ200個で構成された寺院は、ドローコールが1回で済みます。同じ寺院で10種類の異なるマテリアルを使用して200の壁パーツを構成すると、ドローコールが10回発生します。ゲームはその差をロード時間やフレームレートに反映します。
モバイル用UV展開
モバイル向けUVには一つのルールがあります：メッシュごと、マテリアルごとに一つ、UVアイランドを設けることです。クリーンなトポロジーのメッシュに関するベストプラクティス（UVアイランド戦略を含む）については、専用の解説をご覧ください。UVアイランドをテクスチャ上に散りばめないでください。顔用の単一アイランドと体用の単一アイランドにより、テクスチャアトラスを効率的に詰め込むことができます。
モバイルでは、同じプロップの 2 つのコピーがテクスチャ空間を共有する場合、UV の重複は問題ありません。これはメモリを節約しますが、2 つのオブジェクトが頂点が完全に一致している場合にのみ機能します。同じ場所に配置して回転させた岩を 20 個複製した場合、UV 空間を共有できますが、スケールや歪み（squash）が適用された岩では共有できません。
モバイル環境では、デスクトップ環境よりも2のべき乗（POT）のテクスチャサイズが重要です。背景オブジェクトには512x512、脇役には1024x1024を使用し、主要キャラクターにのみ2048x2048を使用してください。GPUのテクスチャサンプラーは2のべき乗のブロックで動作するため、非POTテクスチャはパディングによりメモリ帯域幅を無駄に消費します。
品質を損なうことなくモバイル向け 3D モデルを最適化する方法
マテリアルバッチングによる描画コールの低減
ドローコールは、ポリゴン数の記事でほとんど言及されないモバイルパフォーマンスのボトルネックです。単一のメッシュが 5 つのマテリアルを持つ場合、5 つのドローコールが発生します。一方、5 つのメッシュが 1 つのマテリアルを共有する場合、ドローコールは 1 つだけです。計算はそれほど単純です。
まず、マテリアルの数を確認することから始めましょう。シーンに残るすべての PBR マテリアルは、フレームごとに描画呼び出しとなります。テクスチャの差異が小さい場合はマテリアルを結合してください。異なるブラウンノイズテクスチャを使用する 2 つの岩でも、単一のノイズテクスチャを持つマテリアルに共通化できます。プレイ距離からはその違いは判別できません。
Unity の Static Batchingは、静的としてマークされたメッシュを統合し、ビルド時に単一の大きなメッシュにまとめます。移動しない壁、床、環境の大型パーツなどはすべて Static Batching に含めるべきです。ビルドには数秒余計にかかりますが、フレーム時間の短縮が即座に実現されます。
GPU インスタンシングは、同じメッシュの複数のインスタンスを効率的に処理します。頂点データを結合する代わりに、単一のコマンドで「指定された各位置にこのメッシュを描画する」とGPUに指示します。同じメッシュを使い、回転やスケールを変えて配置された木、岩、箱などはGPUインスタンシングを使用します。Unityは、これをサポートするシェーダーではデフォルトで有効にしています。マテリアルインスペクターで「GPU インスタンシングを有効化」がチェックされていることを確認してください。
ミドルレンジのモバイルゲームにおける現実的な目標は、1 フレームあたりのドローコールを 100 コール未満に抑えることです。デスクトップで 300 コールで現代的な見た目を実現できるゲームでも、モバイルでは同じシーンを 80 コールに削減する必要があります。Unity Profiler でドローコール数が 150 を超えている場合、最優先の対策はポリゴン数の削減ではなく、マテリアルの統合です。
モバイル向けのテクスチャ最適化
テクスチャ圧縮は、モバイルとデスクトップのパイプラインが完全に異なります。3D ファイル形式の比較（テクスチャアトラス戦略やプラットフォームネイティブのエクスポートを含む）については、関連ガイドをご覧ください。デスクトップでは BC7 と BC5 が使用されます。モバイルハードウェアは ASTC（Android 8 以降および iOS）または ETC2（以前の Android デバイス）に対応しています。形式の詳細は、Android テクスチャ圧縮ガイドをご覧ください。エクスポート時は BC7 ではなく、プラットフォーム固有の形式で出力してください。
テクスチャ解像度を許容できる最低限の品質に設定してください。カメラとの距離が最も近い状態で画面で 200 ピクセル分を占めるプロップには、2048x2048 のテクスチャは必要ありません。256x256 で済みます。これはフルミップチェーン付きの 2048 テクスチャと比べ、メモリ使用量は 99% 減ります。
法線マップの解像度はベースカラーテクスチャの半分であるべきです。1024x1024 のベースカラーマップには 512x512 の法線マップが対応します。これによりメモリが節約され、GPU は画質の低下を感じ取らないためです。なぜなら、法線マップはピクセルシェーダー上で既に補間処理が行われているからです。
モバイルゲームにおけるLODの設定方法
モバイルでの LOD を利用する場面
LODは無償ではありません。CPUは毎フレームLODの遷移を計算します。5体のキャラクターがいるシーンでは、計算コストが節約効果を上回ります。50本の木や30体のNPCが存在するシーンでは、LODは一貫して効果的です。
LODを使用するタイミング: 以下の場合: シーン内に20体以上のキャラクターやプロップが同時に表示される、ゲームプレイ中にカメラの距離が大きく変動する、またはターゲットハードウェアが低価格帯スマートフォンである。
LODを考慮する必要がないのは、以下の場合です：カメラが固定されている、キャラクターがほとんどシーンに入らない、または最高詳細度でも予算内に収まっている場合。
ほとんどのモバイルゲームでは、キャラクターLODよりも環境LODの方が効果が早く得られます。50本の木がある森では、2段階のLODを使用します：近くの木は完全な詳細で、遠くの木は4トライアングル（4ポリゴン）のビルボードとして表現します。これにより、典型的なカメラアングルから見て画質の低下を目立たせることなく、50回のドローコールを2回に圧縮できます。
モバイル特有の注意点: LOD切り替えはGPU上でメッシュのリバインドを強制し、切り替えごとにほぼ1回のドローコールが発生します。20回の同時切り替えが集中するとフレーム時間が急上昇することがあります。最低要件のターゲットデバイスでプロファイリングを行ってください。Unityエディタの計測値は信頼できません。
UnityとUnrealでのLODグループの仕組み
LODシステムは、遠くのメッシュを自動的に簡略化されたバージョンに置き換えます。UnityではこれをLODグループと呼びます。Unrealも同じ名称を使用します。このシステムは、キャラクター、プロップ、環境オブジェクトに対して同様に機能します。
UnityのLOD Groupは、デフォルトで4つのレベルを定義しています。
レベル | 三角形数 | 作動時 |
LOD 0（詳細度レベル 0） | 100%（完全メッシュ） | カメラに一番近い |
LOD 1 | 50% | 中距離 |
LOD 2 | 25% | 遠く離れた距離 |
LOD 3 | 10–12％ | 最も遠くに見えるもの |
LOD グループコンポーネントでスクリーン高さの比率を設定し、各レベルがいつアクティブになるかを制御します。Unreal には 階層型 LOD（HLOD） が追加されており、これは距離が離れた場合に複数のメッシュを 1 つの結合メッシュに置き換えます。設定手順については、Unreal HLOD ドキュメント を参照してください。これはモバイル環境で有用であり、地平線付近にある 30 棟の建物からなる村全体を、単一のメッシュにまとめることができます。Unity ではこの用途に GPU インスタンシングを採用しており、セットアップがより容易です。
エクスポート設定とエンジン設定のインポート
6ステップでBlenderからモバイル最適化FBXを書き出す方法
間違ったFBX設定でエクスポートするとメッシュファイルサイズが増大し、マテリアル参照が切断されます。以下の正確な手順です：
- ファイル > エクスポート > FBX (.fbx)。詳細については公式 Blender FBX エクスポートガイド完全なオプション参照については、こちらをご覧ください。[Include] で「選択したオブジェクトのみ」にチェックをオンにし、メッシュ以外のオブジェクトタイプのチェックを外してください。
- [トランスフォーム] で、スケールを 1.0 に設定し、[スケールの適用] をオンにします。Unity 用には、フォワードを -Z、アップを Y に設定します。
- 「ジオメトリ」の下で「モディファイアを適用」をチェックします。これによりミラー、サブディビジョン、アレイモディファイアがエクスポートに適用されます。「Smoothing」は「Face」に設定します。
- スタティックメッシュにはアニメーションのチェックを外してください。静止状態のクラートには、インポートファイルサイズを2倍にするデフォルトのアニメーショントラックは必要はありません。
- 接線空間を生成するよう設定します。FBXで接線を生成すると、インポート時の計算ステップが省略されます。メッシュごとの差は小さく、アセット数が多いと累積的に大きくなります。
- Unity にインポートします。モデルが正しいサイズで表示されている場合は、Model Scale Factor を 1 に設定してください。100 倍大きい、または小さい場合は、Blender に戻り、適切な単位設定でエクスポートしてください。
キャラクターのバッチをインポートする前に、単位立方体テストでスケールを確認してください。Blenderシーンに1mの立方体を配置し、FBXとしてエクスポートしてUnityにインポートします。シーン上で1mの幅として表示されるはずです。100mと表示される場合は、単位スケールが誤っており、バッチ内の全メッシュの修正が必要となります。
Unity へのモバイル用プロジェクトのインポート
Project パネル内のFBXを右クリックし、モデル タブを開きます。モデルが正しく見える場合は、スケールファクターを1に設定します。モデルが100倍も大きすぎる場合は、Blenderに戻り、適切な単位スケールでエクスポートしてください。
Mesh Compression の設定を「High」にします。これにより、大きなメッシュには64ビットインデックスが、小さなメッシュには16ビットインデックスが使用されます。GPUのインデックスバッファのメモリ帯域幅の使用量が少なくなるため、モバイルでのドローコールのパフォーマンスが向上します。
読み取り/書き込みを無効にしてください。Unityはメッシュデータをロード時にGPUメモリへコピーします。読み取り/書き込みがオンの場合、UnityはCPU側のコピーも保持します。実行時に一切変更されない静的メッシュの場合、CPUコピーは無駄なオーバーヘッドとなります。
［最適化］で「メッシュを最適化」をチェックします。Unity は頂点を並べ替えて、GPU のキャッシュ効率を最適化します。頂点キャッシュが小さいモバイル GPU では、この並べ替えによってピクセルシェーディングの処理時間を 10〜15 パーセント削減できます。
モバイル向けローポリ制作のよくある間違い
ヒーローキャラクターの描写過多
ヒーローキャラクターは、初回のモデリングでは常に三角ポリゴン数が多くなりがちです。プラットフォームごとにローポリとハイポリのポリゴン割り当てがどのように異なるかについては、ローポリ・ハイポリ 3Dモデル比較ガイドをご覧ください。
シャープな頬骨、一本一本のまつげ、チュートリアルのチェーンメイルリングを備えた顔は、ボディ制作の前に15,000ポリゴンに制限されます。モバイル環境では15,000ポリゴンの予算しかないため、シーンには他の要素を入れる余地がなくなります。
モデリングの前にヒーローキャラクターのポリゴンバジェットを設定し、それを厳守してください。バジェットが10,000ポリゴンの場合、頭部に3,000、胴体に4,000、四肢にそれぞれ500を配分します。内訳をメモし、ハイポリのスカルプトからではなく、割り当てられたポリゴン数から作業を開始してください。
素材数の除外設定
10種類のマテリアルを使用したローポリのヒーローキャラクターは、2種類のマテリアルを使用したハイポリのヒーローキャラクターよりも処理負荷が高くなります。モバイルGPUは、ドローコールよりも三角形の処理に優れています。三角形の数が3倍であっても、エンジンが発行するドローコールが10回ではなく2回で済むため、2種類のマテリアルを使用したヒーローキャラクターの方が高速に動作します。
対策はテクスチャアトラスの活用です。キャラクター全体のディフューズ、ノーマル、およびパックマップを1枚のテクスチャにまとめます。単一マテリアルを使用した 2048x2048 のアトラスでは、キャラクターのレンダリングが1回のドローコールで完了します。5つのマテリアルに割り当てられた5つの別々の 1024x1024 テクスチャでは、5回のドローコールと5回のSetPass呼び出しのオーバーヘッドが発生します。ゲーム対応品質が実践的に何を意味するのかの完全なチェックリストについては、ゲーム対応3Dモデルガイドをご覧ください。
ターゲットハードウェアでのテスト未実施
Unityエディターはデスクトップハードウェアで動作します。デスクトップGPUはモバイルGPUとは別物です。エディターで120 fpsで動作するシーンが、実機では22 fpsで動作することがあります。
Unity のプロファイラーは、CPU 使用時間、GPU 使用時間、およびメモリに基づくフレームごとの内訳を示します。Android デバイスを ADB で接続し、プロファイラーのターゲットドロップダウンでデバイスを選択してシーンを実行した後、「レンダリング」セクションを確認して、描画呼び出し、SetPass コール、バッチをチェックしてください。
AndroidのGPUプロファイラーは、フレームごとの頂点シェーダーとピクセルシェーダーのタイミングを計測します。キャラクターがカメラの方を向いたときにピクセルシェーダーの時間が急増する場合、そのフレームの描画過多（オーバードロー）が高すぎます。修正方法として、マテリアルの数を減らすか、シンプルなシェーダーを使用することであり、三角形を減らすことではありません。
Triverse AIでローポリ モバイル ゲームアセットを生成
コンセプトの試行錯誤は、モバイルゲームプロジェクトで時間がかかりやすい箇所です。キャラクターのブリーフが「光る腕を持つスチームパンク風の鉱夫」であっても、アーティストはデザイナーが気に入らないものをモデリングするのに2日間費やしてしまいます。モデル自体はゲーム実装可能な状態ですが、見た目が意図と異なるため没になります。
Triverse AIの アーティストメッシュ ワークフローは、本格的なパイプラインが開始される前に、コンセプトのシルエットを正確に取得します。
ステップ1： 参考画像または下書きスケッチをアップロードしてください
Open Triverse Studioして、Artist Mesh を選択します。PNG、JPG、JPEG、または WebP 画像をドラッグ＆ドロップするか貼り付けてください。ラフなコンセプトスケッチでも、クリーンなシルエット写真でもどちらも同様に機能します。
ステップ2：頂点数を選択して生成する
～を選択してください：トライアングルまたはクワッドトポロジ。モバイルターゲットに適合する頂点数のプリセットを選択してください：背景用小物には 1K、標準用小物には 2K、メイン用小物や詳細なキャラクターには 4K。「生成」をクリックしてください。25 クレジットの生成は通常 1 分以内に完了します。
ステップ3：必要であれば確認とテクスチャの調整
Artist Meshが、プロポーション、ポーズ、全体の形状を即座に判断できるメッシュを返します。シルエットが間違っている場合は、削除して再生成してください。コストはわずか25クレジットと数秒で済み、手動モデリングにかかる2日間が不要になります。
ステップ4：エクスポートして、Blenderで調整すべきか確認する
概念をGLBまたはOBJとしてエクスポートし、Blenderにインポートして適切なエッジフローと変形を実現するため、これまでのセクションの最適化ルールを適用します。アーティストメッシュの結果は最終的なゲームアセットではなく出発点ではありますが、概念段階を数日から数時間に移行させます。
モバイルゲーム向けローポリゴンモデルに関するFAQ
モバイルゲームのキャラクターに推奨されるポリゴン数はいくらですか？
ミドルレンジのAndroidスマートフォンにおける群衆NPCは500〜1,000トライアングル（三角形）で動作します。脇役なら3,000〜5,000に収まります。主人公キャラクターは、シーンの残りの部分で描画コマンド数の上限に余裕がある場合に限り、ミドルレンジハードウェアで最大10,000〜20,000まで使用可能です。
モバイルゲームでは1フレームあたり何回のドローコールを目標にすべきですか？
ミドルレンジのモバイルデバイスでは、1フレームあたりのドローコール数を100未満に抑えることを目標にしてください。重いシーンや多数の固有マテリアルを使用するゲームでは150まで許容される場合もありますが、100を超えるドローコールについては、すべてターゲットデバイスからのプロファイリングデータに基づき妥当性が確認されている必要があります。
メッシュを結合せずにモバイルゲームのドローコールを削減するにはどうすればよいですか？
共有マテリアルでGPUインスタンシングを有効にしてください。静的な環境オブジェクトにはUnityのStatic Batchingを使用します。どちらもBlenderでのメッシュ結合は不要です。両方とも、頂点データを結合するのではなく、実行時にドローコマンドをバッチ処理することでドローコールを削減します。
モバイルゲームの3Dモデルに最適なファイル形式は何ですか？
FBXはBlenderからエンジンへ受け渡す際の標準フォーマットです。Apply Scalingsにチェックを入れ、SmoothingをFaceに設定して、FBX 7.4バイナリ形式でエクスポートします。最終ビルドでは、エンジンがメッシュをネイティブ形式に圧縮します（UnityはFBXではなくランタイム圧縮形式を使用します）。
LODはモバイルデバイスのパフォーマンス向上に実際に役立ちますか？
LODは、シーン内に20体以上のキャラクターが同時に表示される場合に効果的です。小規模なシーンでは、LOD遷移を計算するCPUコストがGPUの節約分を相殺してしまいます。ほとんどのモバイルゲームにおいて、環境LOD（ビルボード化された木々や遠くの建物）の方がキャラクターLODよりも安定したパフォーマンス向上をもたらします。
ローポリゴンのモバイルゲームモデルでノーマルマップを使用できますか？
はい。ノーマルマップはローポリゴンモデルの視覚的品質を向上させる主要な要素です。ベースカラーの半分の解像度（1024x1024に対して512x512）でノーマルマップを使用してください。対応するAndroidデバイスおよびiOS上でASTC圧縮されたノーマルマップは、ベースカラーテクスチャと同じメモリ予算で使用できます。
実機のAndroidデバイスで3Dモデルのパフォーマンスをテストするにはどうすればよいですか？
UnityのBuild SettingsでDevelopment Buildにチェックを入れてゲームをビルドします。AndroidデバイスをUSB接続しADB経由で接続します。Unity Profilerを開き、ターゲットのプルダウンメニューからデバイスを選択して、シーンを実行します。Renderingセクションでドローコール、setpassコール、バッチ数を監視します。Android GPU Profilerでは、フレームごとの頂点シェーダーおよびピクセルシェーダーの実行時間を確認できます。
結論
モバイル 3D における最大の教訓は、三角形は敵ではなく、ドローコールこそが敵です。Blender を開く前にポリゴン予算を設定し、その予算に合わせて構築し、頂点数を減らすことより、マテリアルの統合に注力しましょう。LOD は、CPU オーバーヘッドが見合うほどの多数のオブジェクトがシーンに存在する場合に役立ちます。デスクトップエディタではなく、想定される最下位のターゲット端末でテストしてください。この記事のその他の内容は細部に過ぎません。これらの優先順位が枠組みです。さらに、Triverse AI のArtist Mesh機能を直接使用して、ワンクリックでカスタムでスタイライズされたローポリゴンのゲームモデルを生成でき、期間限定でモデルのダウンロードが無料となります！