プロフィール

Na-7

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


アクセスカウンター


最新記事


最新コメント


最新トラックバック


月別アーカイブ


カテゴリ


DATE: CATEGORY:スポンサー広告
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
DATE: CATEGORY:三国志軍記開発
三国志遊戯
三国志遊戯
無料の三国志シミュレーションゲーム。IE必須。兵士を連れて部隊を組み他のプレイヤーと合戦する。三国志登場武将のほか、自作武将も登録可能。



◎改修のポイント

今回は、前々回作成したテストプログラムを改修して、通常PCでのボーン数制限を増やします。これが出来れば、Softimageで標準取得したリグを(シャドウリグ無しで)XNAで動かすことが出来るようになり、モデルを修正する度に試行錯誤していた時間が大幅に短縮できます。

ボーン数:58 → 116ぐらい

プログラミングの視点から改修のポイントを表現すると、ボーンの回転/平行移動をマトリックス型からクォータニオン型+Vector3型に変更することによって、定数レジスタ使用数を半分程度にします。



◎HLSLの改修

私はXNAViewerのコードの全容は把握していないので、この改修が可能なのかまだ不明です。本来はプログラム全体をチェックして改修可否を判断すべきですが、面倒なのでシェーダ(HLSL)からチェックと改修に着手します。

…シェーダが改修できれば多分大丈夫(汗)


SoftimageのHLSLは複数に分かれていますが、まず改修すべきはxsi_defaultvs.hlslですね。

#define MaxBones 58
float4x4 Bones[MaxBones];


これを

// 最大ボーン数
#define MaxBones 108 // 暫定

// ボーンの回転部分
float4 BoneRotations[MaxBones];
// ボーンの平行移動部分
float3 BoneTranslations[MaxBones];

に置き換える所からスタートです。
(最大ボーン数は最後に確認します)

クォータニオンヘルパーメソッドをコピペで追加し、頂点シェーダ内のBones[]を改修します(一個所)。

XNAViewerのxsi_defaultvs.hlsl(改修版)

…うん?これで終わり??

一応他のHLSLファイルもざっとチェックしましたが、多分これでOKです。幸先良いスタートですね!



◎改修不可能?

出力側であるシェーダの改修は完了しました。あとは入力側を改修できれば、中間プログラムは何とかなるでしょう。

QuatSkinningSampleでは、シェーダの他に、本体/ランタイム/コンテントパイプラインを改修しています。入力はコンテントパイプラインに該当しますが、問題は「XNAViewerにコンテントパイプラインプロジェクトは存在しない」という点です。

モデルのコンテンツプロセッサ属性には‘Crosswalk Model Processor’と指定されているので、カスタムプロセッサであることは間違いありません。

Contentの参照設定から‘Softimage.XWImporter’を削除すると、このプロセッサが候補一覧から消えるので、恐らく‘Softimage.XWImporter.dll’ファイルがコンテントパイプラインの実体です。しかしこのファイルのソースコードは非公開です。

つまり「XNAViewerのコンテントパイプラインは改修不可能」ということです。



◎改修対象は?

コンテントパイプラインは改修不可能ですが、必要な全てのデータはメインプログラムで受け取っているので、メインプログラム内でデータ型変換を行うことが出来れば、当初目的を果たせるかもしれません。

例えば、CrosswalkModel.Tagの中のアニメデータであるXSIAnimationDataクラスを流用してNewXSIAnimationDataクラスを作成し、こちらをクォータニオン方式に改造します。LoadContent()の中で、データロード直後にXSIAnimationData型からNewXSIAnimationData型にデータ変換できればOKです。

そこで、XNAViewerのXSIAnimationDataクラスと、QuatSkinningSampleのSkinningDataクラスのフィールドを比較してみました。

○SkinningDataクラスのフィールド
IDictionary animationClipsValue;
IList bindPoseValue;
IList inverseBindPoseValue;
IList skeletonHierarchyValue;


○XSIAnimationDataクラスのフィールド
#if XBOX
#else
    public AnimationContentDictionary AnimationContentDictionary;
#endif
    public Dictionary RuntimeAnimationContentDictionary;
    public List BoneNames;
    public List BoneInvBindPoses;
    public Matrix[] BoneTransforms;
    public List Bones;
    public String Header1;
    public String Header2;
    public String Header3;


うーん…違いすぎて、改修対称がよくわかりません。BoneInvBindPosesとBoneTransformsをQuatTransform型にすれば良いのでしょうか?単純に型変換するだけではダメそうな気がするなぁ…Bonesもこのまま放置で良いのか不安だし…ブツブツ。



◎下流から探る

改修対象を上流(入力)側から絞り込めなかったので、下流(出力)側から探ることにします。

シェーダのBones[MaxBones]に渡す部分をチェックすると、DrawModel()の中の
effect.Parameters["Bones"].SetValue(bones);
でした。つまり、bonesをMatrix型からQuatTransform型に変更すれば良いわけです。

…あれ?もしかして、これだけやればOKかも?

この手法は、Draw()が毎回呼び出される度に型変換を行うので、描画速度が遅延します。モデル数が増えたら遅延しまくりでゲームにならないかもしれません。

でも、三国志軍記ではこのライブラリは使用しない(連画取得ツールでのみ使用する)ので、描画速度を気にする必要はありません。だから、これだけ改修すればOKです。



◎メインプログラムの改修

というわけで改修して実行しました。

ボーン数増加テスト07

あれ?上下逆だし、アニメしません。失敗です。


上下逆はワールド座標の問題かと思ったのですが、そうではなくて、if文を修正したら直りました。

XNAViewerのGame1.csのDrawModel()の改修箇所

ボーン数増加テスト08

動きました!

ロボットやキャプテンもきちんと表示されますしアニメもOKです。但し、槍兵モデルは何も表示されません。多分階層の問題でしょう。


ちなみに、サブPCで動作確認しようとしたら、OSが起動しませんでした。引っ越しの影響かもしれませんが、ちょっとショック…(T-T)



◎まとめ

○改修箇所(2箇所)

・シェーダ(xsi_defaultvs.hlsl)
 →共通インクルードファイルなので全モデルに適用される

・Game1.cs内のDrawModel()


○特記事項

・改修は簡単だが、Draw()呼び出し毎に全ボーンDecomposeするので描画処理が遅い。

・描画速度を向上させたい場合は、XSIAnimationDataのBoneTransformsをQuatTransform型に変更する必要がある(今回は省略)。


○その他

・XNAViewerでワールド座標を指定する場合は、Draw()内のDrawModel()の直前で以下のように記述する。
// ワールド座標変換行列を指定する
Models[CurrentModel].CrosswalkModel.Bones[0].Transform = Matrix.CreateTranslation(0, -10, 0);



◎次回予告

事前の準備や勉強にやたら時間かかりましたが、改修は意外とあっさり出来ましたね。いつもこれぐらいスマートにいくといいなぁ(苦笑)

今後は下記事項を進めます。

・サブPC再構築&動作確認
・今回記事をHPにまとめる
・連画取得ツール改修
・旗手モデル作成
・槍兵モデル再作成

順番は未定なので、次回は上記事項のいずれかを実施する予定です。

スポンサーサイト

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

コメント

パイプラインを弄らなくとも、データを受け取ったランタイム側で行列をクォータニオン&移動ベクトルに変換してエフェクトパラメータに渡せば十分だったわけですね。

データ構造が分からないのですが、Load()直後にあらかじめ行列を分解してどこかに退避させておければ、負荷的にも問題ないかも知れません。もっとも、1モデル行列分解100回程度なら、毎回計算しても案外、何とかなったりして…まあ、そこの解析に時間をかけても仕方ないですか。

毎回研究心溢れる内容で興味深く拝見しております。ただ気になるのですが、開発完了の目処はついているのでしょうか?また、XNA製のソフトを販路に載せられるか、採算がとれるのか、についてよい見通しはあるのでしょうか?実は私もXNAに挑戦してはいるものの、やってることが無駄になるのではないかという不安が拭えないので、質問させて頂きました。

コメントありがとうございます

しばらくぶりにコメント頂いたので嬉しいです^^

yohさん:
>パイプラインを弄らなくとも
仰る通りです。ひにけにXNAの記事を読んだ時は気付きませんでしたが、実装段階で気付けて良かったです。

>Load()直後に
私も同意見です。

>解析
PIXで行列分解時間を計測し、ゲーム全体のパフォーマンスに占める割合を考慮して結論を出すのが理想的ですね。今回は不要なのでやりませんが。


XNA挑戦中さん:
>興味深く拝見しております。
ありがとうございます!^^

>開発完了の目処
開発完了時期は目処がたたない状況です(ーー;

>販路
ネット通販、同人誌即売会、店頭委託などを考えています。販路に関してはあまり心配していません。

>採算
全く見通しが立ちません(爆)
大手商業メーカーでも、国内だけで採算が見込める所は少ないと思います。同人ゲームの中には売上好調なところもありますが、それでも時給換算するとバイトやパートの方が割高で収入も安定します。

>無駄になるのではないか
無料ゲームが氾濫する昨今、ゲーム開発はビジネスとして手を出すべきではないと思います。趣味として手を出すなら、「趣味に金がかかるのは当然!」と開き直った方が気楽かもしれません^^;

いずれにしても、採算割れを覚悟の上で「それでも俺は作りたいんだ!」という人だけが手を出すべきかと思います。

あれっ、XBLIGは考えていないんでしたっけ? あれだと海外でも売れるので、多少は採算が取れる可能性があがると思いますよ。

一応、海外のインディーズゲームで1本1,000万円稼いだケースはあるようです。
http://www.gamebusiness.jp/article.php?id=988
240MSPで配信して7割貰えるとすれば、約170円。日本で1,000本、全世界で20,000本で売れるとすればまあ人間1人が何とか食っていけるでしょう。ちなみに360の売れ行きは全世界トータルで日本単独の約30倍くらい。
http://www.vgchartz.com/home.php

Win用のゲームだとSteamというしくみもありますが、こちらはちょっと調査不足。


※あと、CPU速度についてはPIXだと測れないような。

先は長い?

>XBLIG
将来的には考えています。最初はPC版を作るので、Xbox移植後ですね。

>Steam
これは大手メーカーオンリーかと思ってました。開発が終わったら改めて調査します。

ちなみに、XNAでは珍しく日本語バリバリで国内PC専用版から作るので、Xbox移植や海外向け翻訳までやらないとXBLIG海外収入は見込めません。何年先になるやら^^;

>PIX
イベント毎にStartTimeが記録されるので、これで測定できるかもしれません。(未確認)

コメントの投稿


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

トラックバック


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



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