測定基準ビュー

「測定基準」ビューはランタイムにおけるスケルトンのパフォーマンスの詳細を示します。測定基準は視覚化されたスケルトンの総和を表示します。

ボーン

スケルトンのボーンの総数 

ランタイムでボーンのローカルトランスフォームが行われ、(ほとんどの場合アニメーションが適用することで)スケルトンにポーズが与えられると、各ボーンのワールドトランスフォームが計算されます((典型的なコード)。通常これは「Skeleton#updateWorldTransform」が呼び出される時に起こります。

ボーンのワールドトランスフォームの計算はCPUを使用します。負荷はそれほど大きくありませんが、画面に多くのボーンを有するスケルトンが多数存在するとかなりの消費量になります。例えば、それぞれのスケルトンが30ボーンを有し、画面にスケルトンが50個存在すると、1500件数のワールドトランスフォームを計算しなくてはなりません。

一般的にデスクトップでは、数千ボーンは問題ではありませんが、携帯デバイスでは、1-2千本以上のボーンは問題を生じることがあります。例えば、あるテストでは、Nexus 4 はフレームレートが60fpsに落ちる前に約2000ボーンしか取り扱えませんでした。

コンストレイント

スケルトンのコンストレイント総数

 Spineは1~2本のボーンのIKコンストレイントをサポートします。ランタイムにおいて1本のボーンのIKはたいした負荷ではありませんが、(典型的なコード)、2本のボーンのIKはより多数の計算を必要とします(典型的なコード)。 IKコンストレイントの計算はCPUを使用します。2本のボーンのIK自体の負荷はそれほど大きくありませんが、IKを使用するスケルトンが画面に多数存在すると、負荷が大きくなります。

スロット

スケルトンのスロット総数

スロット数はスケルトンの複雑さを示しますが、ほとんどパフォーマンスに影響を与えません。各スロットは0または1つの可視アタッチメントを持つため、ひと時に可視できるアタッチメントの最高数を示すことになります。

タイムライン

現在有効なアニメーションのタイムライン総数。

ランタイムにおいてアニメーションは多くの「タイムライン」により構成されます。各タイムラインにはキーフレームの値リストがあります。アニメーションが適用されると、アニメーションにそれぞれのタイムラインが適用されます。タイムラインはリストの中で現在のアニメーションタイムのキーフレーム値を探し、スケルトンをその値で操作します(典型的なコード)。フレーム0にタイムラインに1つしかキーがない場合でもスケルトンに適用されます。

タイムライン適用はCPUを使用します。単一のタイムライン適用はたいした負荷ではありませんが、それぞれアニメーションを持つスケルトンが全てのフレームに適用されると負荷が大きくなります。また複数アニメーションが各フレームの1つのスケルトンに適用されることがあります。例として走りながら射撃したり、アニメーションがクロスフェーディングのためにミックスされる時があります。

総数

スケルトンのアタッチメントの総数

アタッチメント総数はレンダリングパフォーマンスに影響を与えず、ロードタイムをほとんど影響しません。

可視性

スケルトンの可視アタッチメント数

可視できるだけのアタッチメントはレンダリングパフォーマンスに影響を与えません。例えば境界ボックスアタッチメントには何もレンダリングされません。

頂点

全ての可視領域とメッシュアタッチメントの頂点数。

頂点の数はGPUに送られるジオメトリ数を示します。

頂点トランスフォーム

可視領域とメッシュアタッチメントにトランスフォームされる頂点数

ボーンと同様に領域とメッシュアタッチメントの頂点はローカルからワールド座標にトランスフォームする必要があります。(典型的なコード: regionsメッシュ、およびウェイト付きメッシュ)。

頂点のトランスフォームはCPUを使用します。計算はたいした負荷ではありませんが、画面に多数のスケルトンが存在すると、負荷が大きくなります。

三角形

全ての可視領域とメッシュアタッチメントの三角形数。

三角形の数はGPUに送られる頂点数を示します。

面積

スケルトンが普通のサイズで表示された時の表示ピクセル数。これは透明なピクセルとオーバードロー(overdraw)のために複数回表示されるピクセルを含みます。

表示ピクセル数はスケルトンのレンダリングのために使用されるGPUフィルレートを示します。

選択

1つ以上のアタッチメントが選択されると、測定基準用に2セットの数字が表示されます。斜線の前の数字は選択アタッチメント用です。斜線の後の数字は全てのアタッチメント用です。

パフォーマンス

 面白いことにパフォーマンスはそれほど重要ではありません。最低のハードウェアで実行する最悪のアプリケーションでもパフォーマンスが容認できるレベルなら最適化は必要ありません。原則として、プレーヤーが気が付かないパフォーマンス改善レベルの場合、パフォーマンス改善に費やした時間は完全に無駄になります。時間はプレーヤーが気が付くものに使うことをお薦めします。

開発中にパフォーマンスを無視していいわけではありませんが、パフォーマンスの問題は予防対策として最低限のパフォーマンスを考慮するくらいでいいでしょう。多くの変数が関係する時に取り組みすぎて時間を無駄にすることがあります。

  • アプリケ―ションを実行するハードウェア、
  • スケルトンレンダリングの他にアプリケーションとゲームツールキットで行うこと全て、
  • ゲームツールキットとSpineランタイムが実行するレンダリング方法、
  • レンダリングするスケルトン数、
  • スケルトンの設定方法、
  • ピクセル表示数、
  • その他。

Spineアニメーションを設計する時、アニメーターがこれら全てを考慮してパフォーマンスが優秀な作品を制作することは不可能です。その代りに希望する変形に必要なメッシュ頂点数を使用するなど合理的な努力をするべきです。パフォーマンスの問題が起きた時だけスケルトンをシンプルにする努力をすべきです。

パフォーマンスは多くの変数に依存するため、「測定基準」ビューのどの数字が高すぎるなど一般化するのは不可能です。パフォーマンスを最高にするためには、自分の環境における限界を確認するために、様々なハードウェア上で実際のスケルトンを使用してテストを行う必要があります。CPUやGPUを限界まで推し進めない場合、パフォーマンスを心配して時間を無駄に費やしたり、アニメーションの品質を犠牲にする必要はありません。

パフォーマンス問題が特定されたら、最初のステップは、パフォーマンスに最大の障害を特定します。何に取り組めばよいかが分れば、効果も最大になります。Spineスケルトンをレンダリングする時に最も頻繁に直面する障害はCPU使用量、フィルレート、ドローコール(draw calls)です。

CPU使用量

CPUの使用量が高すぎる場合、アプリケーションがCPUを使用しすぎてレンダリングが許容範囲のフレームレート以下(通常60または30fps)になることがあります。CPU使用量の測定基準で最も重要なものはボーン、タイムライン、頂点トランスフォームとコンストレイントです。1つでも過剰だと問題を生じます。

スケルトンの複雑さを軽減する以外にもオプションがあります。多数のスケルトンがある場合、各フレームにこれらのサブセットだけを順繰りに更新するのもいいかもしれません。少数のスケルトンだけアニメ化し、これらのポーズを多数のスケルトンにレンダリングすることもオプションの1つです。

フィルレート

GPUフィルレートが使い果たされる場合、GPUがフレームレートに表示できる以上のピクセルを表示しようとしているかもしれません。ピクセルが表示される度にフィルレートに不利になります。ピクセルが完全に透明、または同じピクセルが複数回表示されても(「オーバードロー」と呼ばれます)同様です。アタッチメントがオーバーラップする時がその例です。

フィルレート限界に対するソリューションは常に同じです。少量のピクセルを表示することです。メッシュは透明なピクセル表示の予防に使用できますが、より多くの頂点がCPU上でトランスフォームされるかもしれません。完全に透明なピクセルでもフィルレートを使用します。このためアタッチメントはアルファセットをゼロにするのではなく、非表示にすべきです。2つ以上のオーバーラップイメージの代わりに単一の大きなイメージを使用するなど、オーバードローを最小化する方法でアートを構築することも可能です。

ドローコール(Draw calls)

GPUに表示を指示すること負荷が高い操作です。何回も表示を指示すると、GPUは許容範囲のフレームレートでも完全に表示できないことがあります。

ほどんとのゲームツールキットはなるべく多くのジオメトリをバッチ処理するため、GPUは数回表示する必要があります。GPUが他のテクスチャから表示しなくてはならない場合、バッチを消去しなくてはなりません。このためテクスチャアトラスが使用されてテクスチャスイッチが削減されます。またスロットに付加的なブレンディングを使用すると、プリマルチプライド・アルファを用いてレンダリングしないゲームツールキットではバッチが消去されることがあります。

次: アウトライン 前: グラフ