プロフィール

Na-7

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


アクセスカウンター


最新記事


最新コメント


最新トラックバック


月別アーカイブ


カテゴリ


DATE: CATEGORY:スポンサー広告
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
画像統合後01
開発中のメイン画面
槍兵以外の画像を前回方式に置き換えた。画面内の画像数が一定量を超えると大幅に遅延するようだ。



◎連画の統合

今回は既存オブジェクトの画像を統合し、前回方式で実装します。

まずは連画取得ツールに画像統合機能を組み込みます。実はまだやってなかったのですが(汗)、組み込み前提でプログラム作成済なので、問題なく組み込めました。

連画取得から統合画像まで一発で出力できるようになったので、とても快適です。順次出力しましょう。

SpearMan01_WalkLoop01

槍兵歩行ループモーションを出力したら、こんな感じになりました。無駄な隙間が多くて勿体ない気がしますね。

歩行モーションだけ解像度を上げて隙間を減らすことも可能ですが、モーションによって解像度が変わると見た目に違和感が生じるので、このまま採用します。

しかしそう考えると、最も連画数が多いモーションに解像度を合わせる必要がありますね。槍騎兵も隙間が多いのですが、とりあえず槍兵の解像度に合わせました。木の解像度は高めにしました。



◎実装

画像が準備出来たので、前回方式で実装しました。

槍騎兵画像統合後   木画像統合後01

槍騎兵や槍兵歩行モーションなどは問題なく実装できました。パフォーマンスは以前と同等です。

問題は木です。映像的には問題無さそうですが、これが視界に入るとパフォーマンスが大幅に低下します(30→5fps)。基盤クラスは兵士と共通なのに、何故木だけこのような状態になるのでしょうか?



◎原因調査

いろいろ試していたら、ちょっと不可解な現象を確認しました。

木連画統合fps低下原因調査01   木連画統合fps低下原因調査02

左から右にわずかにスクロールしただけで、40→7fpsまで低下しました。木の種類や本数を変えたりして似たようなパターンが発生しないか試したら、問題点が徐々に浮き彫りになってきました。

木の登録本数が増えるとパフォーマンスが低下しますが、これは以前と全く同じレベルでした。これは画面に表示された本数とは無関係で、ゲーム全体の登録本数に影響します。(400本(&その他モデル)で30fps程度)

問題は、画面上に木が5種類以上表示されると、パフォーマンスが一気に低下する、ということです。

この「テクスチャ数が4以下だと早い」というのは心当たりがあります。昔書いた記事を読み返すと…あれ?この時は「キャッシュ」と結論付けてますね。う~ん…。

でも、「4以下は早い」というのは過去に度々経験したので、ちょっと引っ掛かります。試しに、木の本数を以前と同数に戻して、木の種類を7→4に変更してみました。

木を4種類とした

以前と同じ30fosに戻りました!やはり4という数字がポイントなのかな?(不明)

ちなみに、画面内の本数が20本でも60本でも、ズームアップして拡大してもfpsは殆ど変わりません。



◎テクスチャ切り替え遅延

ところが、木を4種類以下に抑えても、移動ユニットを表示すると遅延現象が発生しました。

木と移動ユニットが表示されると遅延現象発生

ユニット/モデル/テクスチャの関係は以下の通りです。

槍兵 :板ポリA:3モーション(3画像)
槍騎兵:板ポリA:1モーション(1画像)
木  :板ポリB:4種類(4画像)

画面内に表示されているユニット
・槍兵と槍騎兵のみ:遅延現象なし
・木と槍騎兵のみ:遅延現象なし
・木と槍兵のみ:遅延現象発生
・木と槍騎兵と槍兵:遅延現象発生

槍兵のモーションを切り替えると、切り替え中に遅延が発生し、切り替えが終わって1モーションになると遅延しなくなります。

どうやら、カスタムBasicEffectで画面内に描画するテクスチャの総数が4~5あたりが境目のようです。(モデルは無関係?)


一つ腑に落ちないのは「以前のテクスチャ差し替え方式は遅延しなかった」ということです。もしや、無意識のうちにマテリアルバッチを適用していたのでは?

…と思って以前のソースを確認したのですが、ModelMesh.Drawで普通に表示してるだけでした。以前のソースにマテリアルバッチを適用したら早くなるのかなぁ?(謎)



◎エフェクト情報の中身

以前と今回のソースを比較して、1つ気付いたことがあります。

以前のソースでは、Content.Load時に、各ModelMeshPart.Effectに固有のエフェクト情報を所持している。
今回のソースでは、Content.Load時に、(2回目以降も)同じエフェクト情報(アドレス)を示している。

ということです。読みだしたエフェクト情報を格納するフィールドはインスタンス毎に保持しているのですが、中身が同じアドレスだと意味無いですねw



◎エフェクト情報の複製

エフェクトファイルのLoad時に複製すべく、カスタムコンテントマネージャで呼び出したら、OutOfMemoryで落ちました。

カスタムコンテントマネージャって、メモリ効率悪いのかなぁ…いやそれ以前に、エフェクトファイルを何百回も呼び出す方が無謀か?(爆)

とりあえずエフェクトを複製したくて
Effect ef = content.Load("MyBasicEffect");
myEffect = ef.Clone(this.unit.GetGraphicsDevice());

としたら、エラーにはなりませんが、何も表示されなくなりました。そこでdraw()内に
myEffect.CommitChanges();
を追加したら、木と槍騎兵がそれぞれ1つだけ表示されました。どうやら、2回目以降に読み込んだエフェクトを.Cloneでコピーしても、無視されるようですね。



◎テクスチャ切り替えのタイミング

というわけで、テクスチャ1~4枚につき1つのエフェクトファイルを用意するよう改修しました。中身の値は全部一緒なので無駄な気がしますが、クローンを何百個もコピーするよりはマシなので、当面は良しとします。

しかし、実際に動かしてみると、遅延現象が発生しました。Draw()内で毎回テクスチャ切り替えすると遅くなるようなので、初期設定とモーション変更時のみテクスチャを切り替えるようにします。

木が2種類になった

遅延現象は発生しなくなりましたが、木が2種類になってしまいました。これは、1~4番の木と5~7番の木でエフェクトファイルを共有させたためです。

そこで、エフェクトファイルを7個別々に用意したら、5種類目から遅延現象が発生しました。



◎モデル情報の中身

改めて考えると、木の板ポリモデルは7種類共通で、Content.Loadで読み込んだ板ポリインスタンスも全部同じ情報(アドレス)を示しているわけです。ということは、各板ポリインスタンスに個別のエフェクト情報を渡しても、最後に設定したエフェクト以外は無効ってことじゃないですか?

試しに、Draw()内の
ModelMeshPart.Effect = myEffect[~]
をコメント化したら、木が1種類だけ表示されました。

木が1種類だけ表示された

木は20本あるはずですが、他の6種類が表示されません。やはり、最後に設定したエフェクト以外は無効なんですね。



◎結果

1テクスチャにつき1モデル1エフェクト用意して実装したら、「◎テクスチャ切り替え遅延」と同じ状態になりました。

ガーン!!

結局、「◎エフェクト情報の中身」以降は見当違いで無意味だったようです…(>_<)



◎次回予告

遅延現象はモデルインスタンシングで解消できるかもしれないし、いざとなったら元の方式に戻せば良いので、どうにもならないという状態ではありませんが、遅延原因不明のままインスタンシングを適用して良いのか迷ってます。

・遅延原因調査の続き
・モデルインスタンシングの下調べ
・いきなりマテリアルバッチ適用

次回は上記の三択で考えています。さてどれになるやら?w

スポンサーサイト

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
槍兵画像統合後03
開発中のメイン画面
UVアニメの実装方式を変更して、前々回のパフォーマンスレベルまで回復させた。



◎シェーダー改修

今回はシェーダーを改修して、以前の速度に戻るか試してみます。

まず、メタセコイアで板ポリのUV設定を画像1枚分に調整します。
メタセコイアで板ポリのUV設定を画像1枚分に調整

次に、BasicEffectカスタマイズサンプルにアニメテクスチャ左上座標計算を追加し、座標をBasicEffect.fxに渡します。
Vector2 TexCoord1 = new Vector2(tx1, ty1);
myEffect.Parameters["TexCoord1"].SetValue(TexCoord1);


最後に、BasicEffect.fxのテクスチャ座標設定を書き換えます。
// vout.TexCoord = vin.TexCoord;
vout.TexCoord = vin.TexCoord + TexCoord1;


シェーダー改修による頂点データの動的変更

動きました!
見た目は以前のサンプルと全く一緒ですが、今回はModelMesh.Drawによる表示ですので、頂点バッファやインデックスバッファが使用されて前回の方式よりも早くなった(以前のパフォーマンスに戻った)はずです。



◎パフォーマンス計測

前回の表示方式と今回の表示方式で、パフォーマンスがどの程度違うか計測しました。

板ポリアニメ大量表示テスト(シェーダー改修方式100枚)   板ポリアニメ大量表示テスト(シェーダー改修方式1000枚)
板ポリアニメ100枚(左図)、同1000枚(右図)

       前回方式 → 今回方式
板ポリアニメ 100枚:60 → 60(fps)
板ポリアニメ1000枚:59 → 59(fps)
板ポリアニメ1500枚:30 → 40(fps)
板ポリアニメ2000枚:30 → 30(fps)
板ポリアニメ3000枚:20 → 20(fps)
板ポリアニメ5000枚:12 → 15(fps)



2/14追記
この計測データはデバッグ付きで実行したものです。
デバッグ無しで計測したデータはこちら



1500枚と5000枚以外のfpsは一緒でした。
エーッ!?何で?理解できない…(>_<)

前回方式もバッファは使用されていたということでしょうか?
それとも、両方式共にバッファは使用されていないということでしょうか?

1500枚の時だけ10fps差が出る理由もよくわかりません。
プログラムや計測方法がどこか間違っているのでしょうか?



◎実装

この様子だと、実装してもパフォーマンスは変わらないかもしれませんが、一応試してみます。

槍兵画像統合後04

前々回まで:20fps
前回方式実装後:12fps
今回方式実装後:20fps

前回の方式よりも早くなった…というか、以前のパフォーマンスに戻りました。

最初の予想通りの結果になったわけですが、逆にパフォーマンス計測テストの結果と合わないような気がします。前回方式は1500枚の時に10fps低下しているので、それと似たような現象が発生してたのかなぁ?



◎サンプルプロジェクト

今回の方式をHPにまとめてUPしました。

XNA3.1でUVアニメーション(シェーダー改修方式)

メインプログラムはわりとシンプルですし、少なくとも前回方式よりは早いので、こちらの方をお勧めします。



◎次回予告

今回の目標(以前のパフォーマンスに戻す)は達成したものの、いまいち釈然としませんね。

パフォーマンス向上への道を踏み外していない自信はありますが、パフォーマンス計測の自信はちょっと揺らいできました。今後モデルインスタンシング適用時は計測が重要なんだけどなぁ…。

とりあえず次回は槍兵以外の既存オブジェクト画像を統合し、今回と同じ方式にします。

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
槍兵画像統合後01
開発中のメイン画面
統合画像によるUVアニメーションを実装したが、パフォーマンスは低下してしまった。



◎UVアニメーション

前回はテクスチャ座標を動的にずらす方法を習得したので、今回はまずテクスチャ座標とタイミングを合わせて、槍兵アニメを作ってみました。



最近気付いたのですが、今回やってるのがUVアニメですよね?

以前HPに「XNAでUVアニメーション(テクスチャアニメーション)」という記事をUPしたんですが、中身はテクスチャ差し替えアニメでした。「これはUVアニメではない」といった指摘を受けたこともありましたが、当時は違いがよくわからず、そのまま放置してました(汗)

ようやく本当のUVアニメが出来るようになったので、HPの記事を訂正&追加しました。

XNA3.1でUVアニメーション



◎メタセコイアの頂点フォーマット

メタセコイアのXファイル出力オプションに「頂点カラー」チェックボックスがあります。私は普段あまり考えずにこのチェックボックスを付けてました。

メタセコイアXファイル出力オプション

このチェックボックスを外せば、カスタム頂点フォーマットをわざわざ定義しなくてもVertexPositionNormalTexture構造体でアクセスできるかと思ったのですが、試してみるとテクスチャがおかしくなりました。

データのフォーマットを確認すると、Position、TextureCoordinate、Normalの順番で、XNAの構造体と順番が合いません。結局、メタセコイアモデルの頂点データにアクセスする際は、カスタム頂点フォーマットが必要なんですね。



◎実装

槍兵のUVアニメを実装しました。

槍兵画像統合後02

ちゃんとアニメしますが、fpsは低下しました。ガーン!

20 fps → 12 fps


この結果から推察すると、

・ModelMesh.Drawは、
 頂点バッファとインデックスバッファを使用する

・DrawUserIndexedPrimitivesは、
 頂点バッファとインデックスバッファを使用しない

ということかもしれません。

しかしモデルインスタンシング未実装とはいえ、解像度を下げてまで1枚にまとめたのに、ここまで遅くなるなんてショックです…。



◎今後の方針

このままだと遅くて話になりません。
シェーダー改修なりモデルインスタンシング適用なりで高速化を図るか、高速化は保留として以前の状態に戻し、ゲームの本題を進めるか思案しました。

パフォーマンスの話は正直うんざりしてきたので、一旦保留にして本題を進めたいという欲求が強いのですが、「理想を全部詰め込んでみたけど、遅すぎてゲームにならない」なんてことになったら意味がありません。(今最も危惧していることです)

どうしてもパフォーマンスが出ない場合、
・アニメと方向を諦める
・一人称視点を諦める
・モデルの数を制限する
といったことも考えなければなりませんが、どれがどの程度パフォーマンスに影響するかわからないようでは取捨選択もままなりません。

今すぐ実装するかはともかく、「これぐらいのパフォーマンスは出るはずだ」といった見当が付かないと、企画の見直しすらできなさそうです。



◎次回予告

画像は統合したものの、パフォーマンスは低下してしまったので、次回のテーマは「パフォーマンスの向上」です。

シェーダー改修かモデルインスタンシングに踏み込む予定です。

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
DrawUserIndexedPrimitives
テクスチャ座標書き替えテスト
Modelインスタンスに格納された頂点データを書き換えるテスト。これが出来れば1枚のテクスチャでアニメも可能。



◎テクスチャ統合公式サンプル

本題に入る前に、前回コメントでHOSSIEさんからスプライトシートのコンテンツパイプラインサンプルを教えて頂いたので触れておきます。

スプライトシートサンプル

大量のテクスチャファイルを1ファイルに結合してファイル名でアクセスできるようにしてくれるとのことで、とても便利そうなサンプルです。

今回は3D連画取得から画像統合まで1つにまとめたかったので使用しませんが、今後画像を統合する際は積極的に活用したいと思います。



◎境界線の原因

私は以前(地形モデル用のパターンテクスチャを統合したり、地形を板ポリ化して正射影画像を張り付けたりした際に)、「テクスチャの端に境界線が生じる」という問題に直面しました。

この問題が発生する度に、自分のプログラムミスではないかと散々悩んできましたが、その原因が上記サンプル付属ドキュメントに記述されてました。

サンプル付属ドキュメント(一部抜粋)

これによると、境界線の問題はグラフィックカードのフィルタリングによるものでした。原因が判明してちょっとスッキリしましたw



◎境界線問題の回避策について

上記ドキュメントはスプライトシート用のものなので「周囲に1 ピクセルのパディングを含めること」を回避策として挙げていますが、これは私のケースでも適用可能でしょうか?

改めて考えてみましたが、答えはNoです。スプライトの場合は、描画の開始座標と終了座標を持っていますが、モデルの場合は、1頂点につき1テクスチャ座標しか持っていないからです。

結局のところ、頂点データを4倍にするか、1頂点につきテクスチャ座標を4つ持たせて、パディングを指定可能とするしかありません。シェーダー(HLSL)内で現在描画中の頂点番号を参照できればシェーダー側で回避できそうですが、私が以前試した限りでは不可能でした。



◎BasicEffectのカスタマイズ

前置きが長くなりましたが、そろそろ本題に入りましょう。前回は連画を1つのファイルにまとめたので、今回はその画像ファイルを読み込んで表示します。

読み込みはContent.Load()で普通に読み込めば良いのですが、問題は表示ですね。XNA標準のBasicEffectではテクスチャ座標を指定することが出来ないので、テクスチャ座標を指定可能なシェーダーを用意する必要があります。

シェーダーを1から作るのは大変なので、BasicEffectのソースをカスタマイズしましょう。ソースはこちらで公開されているのですが、これを自作モデルに適用する方法がよくわからなくて、しばらく試行錯誤してしまいました。

最終的にはシンプルなコードで適用できるようになったので、サンプルコードをこちらにUPしておきました。



◎まとはずれ

実際にBasicEffectを改修しようとソースを解析した段階で、ようやく気が付きました。今回修正すべきはシェーダーではなく、頂点データだったのです。
私は何を考えていたのでしょうね、ハハハ…(^_^;;;

まぁ、いずれBasicEffectをカスタマイズする日が来ると思うので、後々の布石と言っておきましょう(汗)



◎頂点データの書き替え

板ポリモデルには4つの頂点があり、各頂点がテクスチャ座標を持っています。その値を変えるだけで、アニメーションが実現できるはずです。

問題は、Modelクラスに読み込んだ頂点データを書き換える方法です。以下の手順で試してみます。

1 頂点データフォーマットを確認する(参考はこちら
2 カスタム頂点構造体を作成する
3 頂点バッファデータのコピーを取得する
4 取得したデータを書き換える
5 書き替えたデータを頂点バッファにセットする

サンプルコード
(文字化けする場合は、ブラウザのエンコードを「日本語」に指定してください)

実際にやってみると、1~4まで出来ました。しかし5で書き替えたデータをセットすると、狙い通りにテクスチャ座標がずれた画面が瞬間的に表示され、直後エラーになりました。

InvalidOperationException
操作は中断されました。デバイスで設定されているリソースは変更できません。また、タイリングブラケット内で使用した後に変更することもできません。




◎エラーの原因

VertexBuffer.SetDataのヘルプを見ると、Xbox360に関する注意事項がいろいろ書いてあります(難しすぎてよくわかりません)が、x86系に関する記述はありません。しかし、

・狙い通りの画面が一瞬だけ表示される
 (初回のSetDataは成功したが、二回目で失敗する?)

・エラーはSetDataの箇所で発生するが、
 ModelMesh.Draw()をコメント化するとエラーにならない

これらの現象を考慮すると
「GPUがフレーム描画中にSetDataコマンドを発行して描画内容を変更しようとするとエラーになる」
ということではないでしょうか?



◎頂点データ書き換えテスト

ヘルプは(Xbox360の場合)DrawUserPrimitives等の使用を推奨しているので、そちらで試してみましょう。

サンプルコード

DrawUserPrimitives

テクスチャ座標の書き換えテストは成功しました(左上隅をずらした)が、三角形が1つ足りませんね。modelMeshPart.PrimitiveCountの値は2ですが、PrimitiveTypeをTriangleListにするとエラーになります。

この板ポリモデルはインデックス描画が必要ですね。DrawUserIndexedPrimitivesで表示してみましょう。

サンプルコード

DrawUserIndexedPrimitives

板ポリが正常に表示されました。テクスチャ座標の書き換えテストも成功しています。これでバッチリですね!



◎次回予告

ここまで来ればあと一息ですが、長文になってしまったので今回はここまで。

次回は最終実装です。このシリーズがここまで長引くとは思いませんでしたw

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
槍兵32方向アニメパターン(80×80)

統合した画像ファイル
画像解像度を調整して、槍兵の全アニメパターンを1枚の画像ファイルに統合した。読み込み速度と表示速度の向上が期待できる。



◎新規作成?機能追加?

前々回からの続きで、画像ファイルの統合を行います。
今回はA案に取り組みます。

A案:画像ファイルを結合するツールを作成する

以前はこのように書きましたが、よく考えると次の2通りの方法が考えられます。

A1案:既存のツールとは別に、画像統合ツールを作成する
A2案:既存のツールに、画像統合機能を追加する

A1案の場合、使用者は2つのツールにそれぞれパラメータを設定することになるので管理が面倒です。
連画出力ツールから画像統合ツールにテキストファイルでパラメータを渡す方法も考えられますが、XNAはシリアライズの問題があるので、プログラムがややこしくなりそうです。

A2案の場合、使用者は中間の連画ファイルを意識せずに画像統合ファイルを手軽に入手できます。

使い勝手が良いA2案を目指しましょう。



◎XNA使用不可

A2案は既存のXNAプログラムを改修するものですが、実装にあたり1つ厄介な問題があります。

「一度出力したPNG画像ファイルは、 XNAで再度読み込むことはできない(XNAが読み込めるのはXNBファイルのみ)」

既存の連画出力プログラムはXNAですが、今回追加する機能はXNAで実装できないので、C#で実装する必要がある、ということです。

XNAとC#(正確には.NET Framework クラス ライブラリ)が混在するプログラムは一度作ったことがありますが、注意事項がかなり多かったと記憶してます。

既存プログラムにいきなりC#のコードを追加するとハマりそうな気がするので、まず空のXNAプロジェクトを作成し、これに今回の機能を実装してから、最後に既存プログラムに移植しましょう。



◎混乱の要因

C#で画像を扱う場合、通常はSystem.Drawing.Bitmapクラスを利用します。

まずSystem.Drawingの参照設定を追加し、using System.Drawing;を追記すると…早くもエラーが出ました。

GraphicsDevice.Clear(Color.CornflowerBlue);

空のXNAプロジェクトは、Color.CornflowerBlueで画面を初期化しているので、Colorクラスがバッティングしたのです。

GraphicsDevice.Clear(Microsoft.Xna.Framework.Graphics.Color.CornflowerBlue);

こんな感じで名前空間のパスを記述するとエラーは解消されますが、既存プログラムまたは新規プログラムでColorを使う度に記述する必要があります。プログラムが把握しにくくなる上に、引数や返却値も違うので、混乱しないよう注意しましょう。



◎表示状態の確認

System.Drawing.BitmapクラスのGetPixelとSetPixelを利用して、アニメパターン画像ファイルを作成しました。

槍兵3方向アニメパターン(256×256)

保存ファイル解像度:2048×2048
1枚あたりの画像解像度:256×256
方向数:3(←不足)
1方向あたりの動画枚数:20


全部で32方向分必要ですが、従来の条件では2048×2048に3方向分しか入りません。足りない場合はアニメパターン画像ファイルを複数化することも考えたのですが、それでは画面表示パフォーマンスを最大限に引き出せません。

全アニメを1枚にまとめようとする場合は、解像度を大幅に下げる必要があります。見た目が心配なので、試しに64×64に落として表示状態を確認しましょう。

槍兵画像解像度を下げる表示テスト(カメラバック)   槍兵画像解像度を下げる表示テスト(カメラズームアップ)

カメラをズームアップするとちょっと荒いようですが(右図)、ゲーム中にここまで近付けるのはまれなので、今後は解像度を落として画像ファイルを1枚に集約します。



◎調整

槍兵32方向アニメパターン(64×64)   槍兵32方向アニメパターン(80×80)

64×64だと効率が悪い(左図)ので、80×80(右図)に調整しました。

保存ファイル解像度:2048×2048
1枚あたりの画像解像度:80×80
方向数:32
1方向あたりの動画枚数:19


1枚あたりの画像解像度は2の累乗ではありませんが、保存ファイルの解像度は2の累乗なので、未対応グラボでもエラーになりません。



◎次回予告

ようやく1枚の画像ファイルにまとめることができましたが、これだけでは意味がありません。この画像ファイルで槍兵を表示するように、プログラムを改修する必要があります。

というわけで、次回はこの画像を表示するシェーダーを実装します。

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
満寵の説得
満寵の説得
三国志軍記のイベントCG。于禁の七軍が壊滅してしまい、樊城脱出を思案する曹仁(左手前)に対し、満寵(右奥)が籠城続行を強く主張した。



◎12月の目標達成度

・活動時間月160時間以上

実績:128h(達成率:80%)

 (中間目標:12/15迄に70h以上)

実績:71h(達成率100%)


・森モデルの作成/表示(40h)

実績:31hで完了(達成率:100%)


・企画見直し(24h)
・全体スケジュール見直し(12h)
・マップオブジェクト属性読込、表示(24h)

実績:未着手(達成率:0%)


・ブログ更新/HP更新(50h)

実績:42h(達成率:84%)


・その他(10h)

実績:10hでCG監修等実施(達成率:100%)


・予定外の作業

実績:13hでプログラム整理 完了
実績:19hで槍兵モーション作成/表示 完了
実績:6hで複数モーション登録/制御 完了
実績:7hで画像ファイルの統合 作業中



活動時間が前の月よりさらに低下してしまいました><



◎作業時間分析

作業時間集計2009年12月(PDF形式)


○良かった点
・活動時間の中間目標は達成した
・予定外の作業にも着手した

○悪かった点
・活動時間が少ない(特に後半)
・ブログの月間登録件数が過去最低
・HPが全く更新されていない


年末の忙しい時期に、大戦略Webで大規模連合に加盟してしまったため、後半の活動時間が全く伸びませんでした。
中間目標が無かったら、もっと酷いことになってたかもしれません(汗)



◎引退宣言

大戦略Webのオープンベータテストは、本日(1/13)全データリセットされます。私はここで引退し、以後制作活動に専念します。

明日以降は、以前のペースで更新していくつもりですのでよろしくお願いします。



◎進捗状況チェック

スケジュールは凍結中です。

マップやモデルなどの登録/表示機能はとりあえず一段落したので、画像ファイルの統合が完了したら、企画とスケジュールの見直しを行います。



◎1月の目標

・活動時間月120時間以上
 (中間目標:1/20迄に60h以上)

・画像ファイルの統合(10h)

・企画見直し(24h)

・全体スケジュール見直し(12h)

・マップオブジェクト属性読込、表示(24h)

・ブログ更新/HP更新(40h)

・その他(10h)

正月休みを多く取ってしまったので、今月は活動時間目標を少なめに設定します。



◎次回予告

次回は前回の続きです。

最近停滞気味でしたが、その原因である大戦略が終わったので、気合いを入れ直して頑張りますw

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
画像ファイル統合失敗
統合試行中の画像
アニメのコマ割りのように少しずつ変化させるつもりが、全て同じ画像になってしまっている(失敗)。



◎ごあいさつ

大変遅くなりましたが、あけましておめでとうございます。

年末年始や大戦略Webの影響でしばらく更新をサボってしまいましたが、ぼちぼち再開しますので今年もよろしくお願い致します。



◎統合方式の検討

今回は画像ファイルを統合します。読み込み速度の向上が当面の目的ですが、後日モデルインスタンシングで画面表示パフォーマンスを高めるための布石でもあります。
(マテリアル数を減らした方が効果的)

画像ファイルを統合するには、下記の方法があります。

A案:画像ファイルを結合するツールを作成する
B案:連画出力ツール内で結合するように改修する

A案の方が簡単に作れそうですが、画像出力時に2つのツールを動かすことになります。使う際の手間を極力減らしたいので、B案にしましょう。



◎グラフィックデバイス管理

連画出力ツールの改修を始めたものの、予想通り難航しました(--;

RenderTarget2Dで画像を1枚ずつキャプチャし、これを配列に保存する所まではできたのですが、RenderTarget2Dのインスタンスをもう1つ作成し、これに縦横16枚ずつ画像を並べて1枚の大きな画像を取得しようとすると、出力されたキャプチャ画像には、槍兵が1体大きく表示されました。

大きな槍兵

このような画像ファイルが出力されたので、最初は画像を並べる部分を失敗したか、或いはレンダーターゲットの切り替えに失敗したかと思ったのですが、それ以前にグラフィックデバイス管理の概念が予想と異なるようです。

どうやら1度のDraw()内で2回以上切り替えても無意味らしいので、個別画像キャプチャと統合画像キャプチャのタイミング(scene)を分けることにしました。



◎ドはまり

全ての画像のキャプチャを終えてから、それらの画像を縦横に並べて表示すると、全て同じ画像になってしまいました。

画像ファイル統合失敗

アニメのコマ割りのようになって欲しかったのですが、何故全て同じ画像なのでしょうか?

画像を並べるプログラムがおかしい?
レンダーターゲットの制御ミス?
Softimageランタイムの影響?
そもそも画像が取得できていない?
……

正月ボケした頭には難しすぎて長期間ハマってしまったのですが、ようやく原因が判明しました。



◎原因

レンダーターゲットから画像を取得し、配列に格納します。

private Texture2D[] capturedTexture = new Texture2D[1024];
……
(省略)
……
capturedTexture[nowPic] = renderTarget.GetTexture();


このように格納した画像配列のハッシュコードを表示すると、全て同じ値になってました。

i = 0 GetHashCode = 35191196
i = 1 GetHashCode = 35191196
i = 2 GetHashCode = 35191196
i = 3 GetHashCode = 35191196
……


どうやら、1つのレンダーターゲットから取得した画像は全て同じ参照値で返されてしまうようですね。



◎試行その1

取得したい画像の数だけレンダーターゲットを用意できればこの問題は解消されますが…500枚の画像を取得する場合、500個のレンダーターゲットを用意する必要があります。そんなことが可能でしょうか?

試しにレンダーターゲットを500個作成しようとしたら、47個目あたりで OutOfVideoMemoryException エラーになりました。ビデオメモリが足りないようです。無理もありませんね(^^;



◎試行その2

次に考えたのは、予め退避&保存用のレンダーターゲットを作成しておき、画像を1枚取得する毎にそちらに書き込む、という方法です。

・画像取得用レンダーターゲット
・退避保存用レンダーターゲット
・バックバッファー

上記3つのレンダーターゲットを切り替えて、取得した画像を退避保存用レンダーターゲットに書き込んだのですが、保存したファイルには何も描かれませんでした。

画面には描き込んだ場所にだけ一瞬表示されるので、退避保存用レンダーターゲットが毎回自動消去されるようです。



◎次回予告

ようやく原因を特定したものの、取得した画像データをメモリ内に退避する方法が思い付きません。仕方がないので、B案は諦めてA案にしようと思います。

1月になったので、次回は「12月の総括と1月の目標」です。

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

| BLOG TOP |

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