Doc:JA/2.6/manual/Game Engine/Performance/Display/Framerate and Profile
目次
Framerate and Profile
（フレームレートと分析情報）
BGE の「Show Framerate and Profile（フレームレートと分析情報）」オプションや、画面に表示される雑然としたテキストに慣れ親しんでいる人はたくさんいます。ところが、個々の統計値がほんとうは何を意味しているのか、知っている人は多くはいません。この記事の目的は、統計分析の内容やその数値の減らし方について理解を深めることです（消費時間が減るほど性能が上がります）。
FPS を除くと、分析情報は 9種類あります。Physics、Logic、
Animations（最近の Blender で利用できます）、Network、Scenegraph、Rasterizer、Services、Overhead、Outside です。表示をなるべく正確にするには、“Use Frame Rate”をオフにし、グラフィックカードドライバの vsync を オフにすることをおすすめします。
Frametime
ゲーム実行中に Blender が行っているすべての演算時間と、ゲームの描画領域への描画に費やした時間の合計を表します。実際のフレームレートも表示します。
Physics
物理演算に費やした時間を表します。最近の BGE は物理演算に Bullet のみを使うので、ほぼ Bullet で費やされた時間と同じです。時間を減らすには、物理を単純化して Bullet が大きな仕事をしなくていいようにする必要があります。たとえばオブジェクトの物理形状を単純化します。複雑なメッシュを持ったキャラクターの物理を Convex Hull や Triangle Mesh （他の種類が選ばれないときのデフォルトです）にすると、Bullet が複雑なメッシュを使って物理演算をする必要があり、時間の無駄になるだけです。替わりにもっと単純な球や箱でうまくいかないか試してみてください。うまくいかなければ、少なくとも物理演算にはレンダリングに使われる複雑なメッシュを使わず、メッシュを単純化した見えない「代理」オブジェクトを作って、替わりに使います。
Logic
ロジックブリックと Python コードで費やされた時間です（KX_Scene.pre_draw と KX_Scene.post_draw を使った時間を除きます。これらは Rasterizer の時間に表示されます)。時間を抑えるには、ロジックブリックや Python コードを単純化/最適化する必要があります。Python コードの最適化についてはここでは述べませんが、PyOpenGLで 知られる Mike Fletcher が Python コードの分析と最適化のヒントについて記事を書いています。最適化を行う前には必ず、コードを分析することを忘れないでください。最終手段として、Python コードを部分的に C/C++ へ移植する試みもできます。
Animations
BGE が利用する、Blender のアニメーションのコードで費やされた時間です。たとえばポーズデータの参照やキーフレームの補間などがあります。ただし、IK の計算は ボーンの親を計算中、Scenegraph に集計されることがある点に注意してください。また、実際にメッシュの変形にかかった時間はこのカテゴリに含まれず、Rasterizer カテゴリに含まれます。時間を減らすにはアーマチャにあるボーンの数を減らしてみてください。アーマチャの IK Solver に 旧式（Standard）の替わりに iTaSC（set to simulation）を使うこともできます。iTaSC は旧式の Solver より高速です。私が行ったテストでは 1.25 ~ 1.5 倍高速になりましたが、4倍になることもありえると聞いています。
Network
少し驚かれるかもしれませんが、BGE には実際に通信処理のコードがあります。ただ、この機能はあまり開発されておらず、現時点ではほとんどがメッセージを送り返すスタブです。Message アクチュエータとセンサー（および対応する Python API の機能）はこうやって動作しています。このカテゴリが時間を浪費することがあるのか疑問ですが、もし問題が起きていれば、送ろうとしているメッセージの数を調べて、数を減らせないか検討してください。
Scenegraph
Scenegraph ではオブジェクトの位置、方向、サイズの変化（いまは思いつきませんが、他にもいくつかあるかもしれません）を追い続けます。親子関係（例えばボーンの親等）の更新処理も含まれます。以前述べたように、ボーンの親のポーズデータの取得時間が含まれることがありますが、おそらく IK を計算しています。Scenegraph が非常に高い場合は、シーン内のオブジェクトの数を減らしてみてください。iTaSC を使うこともできます（Animations カテゴリで説明しました）。Scenegraph は 錐台/隠面消去（frustum/occlusion Culling)の計算も対象にします。
Rasterizer
Rasterizer は実際のゲーム描画を司ります。具体的にはジオメトリ描画、陰影処理、2次元フィルターです。BGE がダブルバッファを利用するため、Rasterizer もバッファを切り替える必要があり、vsync が有効な場合非常に高い値になることがあります（SwapBuffers() は画面更新を待つ間ブロックされます）。時間を抑えるためには、ジオメトリやマテリアルの単純化を試してみてください。また、動的な影を作る光源が、多すぎないことを確かめてください。影ができるたびにシーンをレンダリングする必要が生じます。影を落とすスポットライトが三つあるとすると、シーンは四回レンダリングされます（影用に三回、実際のシーン用に一回）！ 2次元フィルターもいくらか時間を使う可能性があるので、bloom、depth of field、SSAO がきれいに見えているとしても、取り除くか、サンプル数を減らすような調整が必要になるかもしれません。
Services
さまざまなシステムデバイス（キーボード、マウスなど）による処理が費やす時間です。このカテゴリが時間を浪費するような問題は起こらないでしょう。
Overhead
おそらく一番誤解されやすいカテゴリ名です。「overhead」とは、ゲーム画面の左上隅に描かれるすべてのテキストを指しています。フレームレート、分析情報、デバッグプロパティがあります。ですから、このカテゴリの消費時間はこうした表示情報を減らすことで抑えることができます（たとえばデバッグ/分析情報のテキストを一切画面表示しない、など）。
Outside
BGE のメインループの外で費やされた時間です。言い換えれば BGE 以外の何かが時間を使っています。実際のところ、これを制御する方法はありません。他のプログラムをたくさん実行しているなら、いくつかを終了させてください。
 | このページの内容は Mitchell Stokes (Moguri) のブログからの複写です |
| 原文は こちら（eng） にあります。文書の複写について著者の了解を得ており、著者にはページへのリンクを維持管理するよう頼まれました。 |
_(Framerate_and_Profile_During_Game_Execution)_(GBAFN).png){kind=link}