performance

パフォーマンス

少数のオブジェクトなら問題なく動くシーンでも、群衆やパーティクル、大きなマップが加わるとカクつくことがあります。フレームレートは、ドローコール、GPU 処理、フレームごとの CPU 処理／メモリ割り当てという 3 つの予算で決まります。以下の対策は、それぞれ 1 つの予算を対象としています。まず計測し、実際のボトルネックを解消してください。

まず計測する

推測で判断しないでください。vitexec --performance-trace（ホット関数を調べる場合は --cpu-profile も指定）を使って、実行中のゲームをプロファイリングします。フレーム時間の内訳から判定します。フレームごとのスクリプト／JS の処理時間が長く、メインスレッドが忙しい場合は CPU ボトルネックです（「フレームごとの CPU 処理を減らす」を適用します）。メインスレッドの負荷は低いのに GPU／レンダリング時間が長い、ドローコールが多い、またはオーバードローが大きい場合は GPU ボトルネックです（「GPU 処理を減らす」／「ドローコールを減らす」を適用します）。想定していた予算ではなく、トレースで実際に問題が示された予算を改善してください。

ドローコールを減らす

メッシュごとにおおむね 1 回のドローコールが発生するため、メッシュが何千個もあると、CPU が処理を送信する際に停滞します。

• インスタンシング：同じジオメトリのコピー（木、岩、草、弾丸、同一の敵など）を、多数まとめて 1 つの InstancedMesh として描画します。各コピーの位置は mesh.setMatrixAt(i, matrix) で設定し、その後 mesh.instanceMatrix.needsUpdate = true を設定します。このフラグを省略すると、インスタンスは移動しません。
• 静的ジオメトリをマージする：同じマテリアルを使う、動かないメッシュを 1 つのバッファージオメトリにまとめます。ただし、マージしたメッシュは全体をまとめてカリングするか、まったくカリングしないかのどちらかになります。そのため、オブジェクト単位の視錐台カリングが有効な広い範囲に散らばったジオメトリは、マージしないでください。
• マテリアル／テクスチャを共有する：マテリアルとテクスチャのインスタンスを再利用します。アトラスを使えば、異なる小道具でも 1 回のドローコールにまとめられます。

GPU 処理を減らす

• カリングする：画面外のオブジェクトをスキップするため、frustumCulled = true（デフォルト）のままにします。巨大なワールドでは、距離によるカリングも行ってください。
• LOD：遠くにあるオブジェクトを、より軽量なバージョン（THREE.LOD）に切り替えるか、遠方の細かいディテールを完全に非表示にします。
• オーバードロー：大きな透明／加算合成パーティクルや全画面エフェクトの数を制限します。シャドウマップのサイズと、影を落とすライトの数も制限してください。

フレームごとの CPU 処理を減らす

• 割り当てずにプールする：オブジェクトを再利用し、更新ループ内で new を使って生成する代わりに、作業用の Vector3／Quaternion／Matrix4 インスタンスを再利用します。フレームごとのメモリ割り当ては、GC による引っかかりを引き起こします。
• 動的な数を制限する：生存中の敵、パーティクル、飛翔体の数に上限を設けます。オブジェクトを生成／破棄する代わりに、プールから再利用してください。
• 再コンパイルを発生させない：実行中にライトの数やマテリアルの定義を変更すると、シェーダーが再コンパイルされます（lights スキルを参照）。これらは固定してください。
• 処理を分散する：経路探索や AI の再計画など、負荷の高い処理はフレームごとにすべて実行するのではなく、複数のフレームに分散してください。