プロフィール

Na-7

Author:Na-7
SE(システムエンジニア)として約15年間システム系ソフト会社を勤めあげ、2008年3月退社。現在、ゲーム制作会社設立を目指して活動中。


アクセスカウンター


最新記事


最新コメント


最新トラックバック


月別アーカイブ


カテゴリ


DATE: CATEGORY:スポンサー広告
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
DATE: CATEGORY:三国志軍記開発
パフォーマンス再測定(メインPC柵)
パフォーマンス再測定
前回のサンプルやモデルに疑念が生じたので、モデルを入れ替えてパフォーマンスを測定。疑念は払拭されたようだ。



◎パフォーマンス再測定

前回の測定は興味本位だったので、測定結果が妥当か否か判断基準がありませんでした。その上、測定結果にやや不可解な点があったので、「作成したサンプルにミスがあるのではないか?」「モデルのパフォーマンス効率が悪いのではないか?」といった疑念が生じました。

そこで改めて目的と判断基準を明確にして、パフォーマンスを再測定します。


○測定目的

・デモPJの測定値を理想値と捉え、
 今後のパフォーマンス判断基準とする

・前回サンプルがデモPJと同等のパフォーマンス
 であることを確認する
 →10%以上低下した場合、原因を追及する

・モデルを入れ替えて、モデルの違いによる
 パフォーマンスの変化を確認する
 →50%以上低下した場合、モデルの見直しを検討する


○測定結果

パフォーマンス再測定(サブPC板ポリ差し替え)

XNAシェーダインスタンス
パフォーマンス測定結果&比較データ(PDF形式)



○判定

・今回の測定データを
 今後のパフォーマンス判断基準とする

・デモPJと前回サンプルの差は誤差の範囲
 →2つのPJのパフォーマンスは同等

・モデルのパフォーマンスは一部偏りがあるものの、
 全体としては悪くない
 →両面板ポリアニメは、本番ゲーム実装時に
  片面板ポリビルボードアニメとする
 →柵モデルは、両面板ポリに変更することを後日検討する


○その他

・前回サンプルはやや不可解な傾向があったが、
 デモPJでも同じ傾向が見られた
 →パフォーマンスに影響を与えるプログラムミスはない

・デモPJの初期状態(高解像度)では、
 メインPCのパフォーマンスに影響は無かったが、
 サブPCは1000個の時だけ
 CPU負荷が5.8ms(20%)まで低下した
 →原因不明


解像度とパフォーマンスの関係に首を突っ込む余裕は無いので、当面は800×600固定とし、最終段階で高解像度に対応することとします。



◎コンテントパイプライン解析

前回サンプルの疑念が解消されたので、このまま本番ゲームに組み込んでも問題無いのですが、XNAでは数少ない日本語コメントサンプルですので、中のコードをじっくり拝見しましょう。

技術習得のやり方は人によって様々ですが、私の場合は、このようなメモを書きながら何時間もかけてじっくり解析します。(個人的なメモなので内容は気にしないでくださいw)
こうすると、後日必要な時に「そういえば…」と思い当たる可能性が高くなります。難点は、消化に時間がかかりすぎることです(^_^;


参考までに、コンテントパイプラインの概要フロー図を作成しました。入力から出力までの流れが一目で把握できると思います。

シェーダインスタンスサンプル
コンテントパイプライン概要フロー図(PDF形式)




◎MeshPacker

解析してようやく気付きましたが、MeshPackerはシェーダインスタンスのデモに使用されていません。

最も時間をかけて解析したモジュールを使わないのはトホホなので、プログラムを改修してメッシュのパック化にチャレンジします。



◎簡易城モデルのパフォーマンス

MeshPackerの動作確認には複数メッシュモデルが必要なので、簡易城モデルを使用します。まずはモデルの仕様と現状パフォーマンスを確認しましょう。

メッシュオブジェクト数:4(→5)
頂点数:196(→220)
プリミティブ数:138(→138)
マテリアル数:5(→5)
テクスチャ数:2

元の数値はメタセコイア、(→)の数値はModelクラスで読み込んだ場合の数値です。柵モデル等と比べると桁が違いますが、ゲーム内での登場数はMAX36個なので大目に見てくださいw

簡易城モデル36個   簡易城モデル1000個

○簡易城モデル:36個
 メインPC:60fps1.30ms
 サブPC:60fps1.02ms

○簡易城モデル:1000個
 メインPC:40fps18.65ms
 サブPC:20fps40.57ms

これがMeshPacker適用前のパフォーマンスです。メッシュをパックしたら早くなるでしょうか?



◎改修

NodeContentツリーを再帰的に検索し、そのノードがメッシュだったらパックするように改修したのですが、改修前と同じオブジェクトが描画されてしまいます。

MeshContent.Identityの設定など、怪しい点が幾つかありますが、コンテントパイプラインはデバッグ機能が大幅に制限されるので、何が悪いのかはっきりしない状況です。(そもそも、MeshPackerがシェーダインスタンスで利用可能なのか確信が持てません><)

うーん…。
アニメインスタンスと同じやり方でないとダメなのかな?
アニメインスタンスのモジュール解析までやりたくないんだけどなぁ…ブツブツ。



◎次回予告

私は面倒なことがキライなので、再測定や解析をやる前は正直気が重かったのですが、時間をかけて頑張っただけの甲斐はあったと思います。

しかし、調子に乗って軽い気持ちでMeshPackerに手を出したら、簡単に詰まってしまいました。
まだまだ修行が足りないなぁ(ーー;


MeshPackerは成功したとしても多大な効果は期待してないので、チャレンジは一旦諦めて次に進みます。
というわけで、次回はライブラリの解析と本番実装です。

スポンサーサイト

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック


この記事にトラックバックする(FC2ブログユーザー)



copyright © ゲーム制作の舞台裏 all rights reserved.Powered by FC2ブログ
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。