プロフィール

Na-7

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


アクセスカウンター


最新記事


最新コメント


最新トラックバック


月別アーカイブ


カテゴリ


DATE: CATEGORY:スポンサー広告
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
DATE: CATEGORY:Softimage Mod Tool
韓当
韓当
呉将。孫堅旗本四天王の一人。孫子三代に渡って仕え、数多の合戦に参加した。長寿を得て晩年まで戦場で活躍し、数々の武功を挙げた。



◎Softimageのサンプルコード

Softimage付属ランタイムの個別制御サンプルコードをHPに追加しました。

余分なコード(思考錯誤中のコードとか)を整理すると、ここまでシンプルになるんですね…頭の中が整理できたのは良いのですが、20行足らずのコードを導き出すのにかかった時間を思うと、ちょっとショックです(笑)



◎ACLの個別制御

Softimage付属ランタイムの個別制御が出来るようになったので、ACLでも同じ手法で個別制御出来るか適用テストを行います。

まず、ACLでモデルを複数登録し、モデルアニメータとアニメーションコントローラを複製して…

ACLの個別制御.JPG

ハテ?!
まだ何も工夫してないのに、個別制御できてますね?
ということは、ACLで個別制御できないと思っていたのは、私の勘違いってことですか?…ガーン!!

当時はまだC言語始めたばかりだったので、複製した時のコントローラ設定とか間違えたかもしれません。Listどころかインスタンスの概念すら把握しきれてなかったし(汗)

というわけで、ACLでは個別制御の問題は発生しませんでした。ACLでもModelクラスのインスタンスは複製されていないはずですが、アニメーションに必要な情報は、モデルアニメータとアニメーションコントローラに全て納まっているのでしょう。どうもお騒がせしました_O_


ACLの参考用に、今回のプログラムをHPに追加しておきました。Update()とDraw()にコードが無いアニメプログラムって、ちょっと珍しいかも?w



◎性能比較テスト

というわけで、ようやく念願のライブラリ性能比較テストを実施しました。

XNAのアニメーションライブラリを比較検証する

HPを見て頂ければわかると思いますが、XSIXNARuntimeとACLのパフォーマンス測定結果は、3倍の差がありました。

まさかここまで差が出るとは思いませんでしたね~!
プロジェクトファイルをUPしておきましたので、興味がある方はご自分の環境で試してみてください。


パフォーマンスに差が出た原因については、HPの「◎測定結果の考察」に記述しました。

項目だけ転記すると

A:モデルの違いによるもの
B:プログラムの違いによるもの
C:ライブラリの違いによるもの

という推測です。現時点ではBに関する検証アイデアが無いのですが、ACに関しては今後検証作業を進めて遅延原因を追及するつもりです。



◎対策の検討

今までのやり方で続行すると、ACLより3倍遅いゲームになってしまうことが判明しました(笑)
さすがにこれはマズいので、対策を考えます。

一番手っ取り早い対策は「昔のやり方(メタセコイア+RokDeBone2+ACL)に戻す」ですが、そうすると3DCG担当者が見付からない問題に戻るので、これは極力避けます。

次に考えられるのは「Softimageをやめて別のソフト(Mayaなど)に乗り換える」ですが、まだロクに使いこなせていないツールを見限るのは、ちょっと早い気がします。一応、XNA公式認定ツールですし。…疑問は多々ありますがw


というわけで、まだしばらくSoftimageとXNAの連携に拘るつもりですが、今後の対策は2つ考えられます。

1つは「現在の手順の見直し」、もう1つは「XNA公式連携手順以外の手法の模索(例:FBX渡しなど)」です。前者は、遅延原因がABだった場合に有効であり、後者は、遅延原因がCだった場合に有効です。

今後しばらくは「検証作業を進めて遅延原因を追及しつつ、2つの対策を並行的に進めていく」つもりです。



◎次回予告

性能比較テストは前々からやりたいと思っていましたが、この差は驚きですね~。「今のやり方を改める必要がある」と認知できたことは大きいと思います。

まずは検証作業の一環として、他のモデルによるパフォーマンス測定を試みます。FBX渡しについても本格的にチャレンジしていきたいですね。

スポンサーサイト

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

コメント

XNA3.0用のACLサンプルプログラム(複数モデルインスタンス)の
サンプル見させていただきました
ありがたく実装の参考にさせてもらいます

Content.Load<Model>を複数回呼び出す必要があるのですね
一回だけ呼び出し、それを複製する方法があれば
一番いいのですが
(Content.Loadをゲーム中に行うと処理落ちしそうですし)

ご心配には及びません!?

TEAさんこんばんは~

>一回だけ呼び出し、それを複製する方法があれば
HPに<プログラムの補足解説>を追記しました。
http://tkina.web.fc2.com/kaihatu/siryou/XNA-SkinAnimation3/XNA-SkinAnimation3.htm

詳細はそちらを読んで頂きたいのですが、要約すると「2回目以降は瞬間的な早さで読み込まれるので心配には及ばない」ということです。


逆に、遅いプログラムを作ってみました。
(直接クリックでエラーになる場合は、URLをコピペしてください)
http://tkina.web.fc2.com/BlogData/20090828/ACLTest.zip
このプログラムは、Content.Loadをオーバーライドして、2回目以降も普通に読み込むようにしたものです。たった10体でも、普通に読み込むとかなり遅いことが体感できます。

このプログラムに関しては、ContentManager.ReadAssetの「解説」欄が参考になると思います。
http://msdn.microsoft.com/ja-jp/library/bb313963.aspx

回答ありがとうございます
なるほど、これならモデルを順次追加しても問題なさそうですね
参考にさせていただきます

先生、質問!

実行ハードは360ということでよろしいですか(汗)。あと、出来れば解像度も…。

このテストはライブラリ比較のために行われたようですが、気になったのはむしろ「この頂点数のモデルで1画面10体超辺りから既に60FPSを切っている」という点です。XNA、厳しいのかなあ。

自分は「既にゲームとして面白いことが保証されている」という意味で最初はスポーツゲームを作る予定だったのですが、野球やアメフトはダメでテニスの方がいいのかも知れません。


人手がなくてやむなく自分で組んだMetasequoiaモデル(ざっと1,200頂点)を用いて、セルシェーディングを実装しています。

前にXImporterを解析して気付いたんですが、XNAの内部だと同じ座標の頂点でも法線や頂点カラーが異なると別の頂点扱いですね(ただし座標についてはインデックス化されていて、重複してもそんなにメモリは食わない)。負荷を考える上では、重複分もカウントした方がいいかと思います。

HP更新しました

yohさんこんばんは~

>実行ハードは360ということでよろしいですか(汗)。
すみません、まだ360持ってません(爆)
PC版が完成したら360に移行したいのですが、いつになるやら…(^^;
とりあえず、HPに実行環境を追記しました。

>既に60FPSを切っている
私の環境では、RokDeBone2付属サンプルモデル+ACLでも同程度の結果になると思います。
但し、360ではどうなるかわかりません。何も工夫しなければさらに遅い可能性もありますが、360に特化したプログラミング(vFetchなど)をすれば、かなり速くなるかもしれません。

>XNA、厳しいのかなあ。
アニメーションライブラリが標準提供されない時点で厳しいと思います(笑)

一般的に言うと、XNAはC#のテンプレートにすぎないので、プログラマーの実力次第で速くも遅くもなるはずですが…私はこれはXNA開発チームの「逃げ(言い訳)」と思ってます。
下手に提供して「XNAは遅い」と言われるのが恐いのでしょう(笑)
提供しなければ「遅いのはプログラマーが未熟だからであって、XNA自体が遅いのではない」と言えますからね。

>野球やアメフトはダメでテニスの方がいいのかも知れません。
最初はテニスの方が無難と思います。人数が多い場合は、予め最大人数を動かしてパフォーマンスを確認しておくことをお勧めします。

>セルシェーディング
アニメ調のレンダリングですよね?見た目は単調でも、負荷は通常の3Dと同等かそれ以上だそうですね。頂点数は同等だから、負荷は槍兵モデルと同等かそれ以上??

>別の頂点扱いですね
これは、腕と胴体が別のオブジェクトだった場合、境界上の共有頂点は別々に計上される、という解釈でよろしいでしょうか?

>重複分もカウントした方がいいかと思います。
なるほど…HPの頂点数の記述を更新しましたが、この解釈で正しいでしょうか?

ちょっとアニメーションから離れて別のことやっていたのですが
360実機でやたらとFPS低下したので調べてみたら
Draw中のXSISASContainer.ComputeModel() がメッチャ重いことに気づきました
これないとアニメーションしないみたいなんですが
かといって改善しようにもブラックボックスなのでいやんでした

解析調査中です

HOSSIEさんこんにちは~

>メッチャ重いことに気づきました

次回記事のラストに書きましたが、サンプルプロジェクトを見付けて解析中です。もしかしたら改善できるかもしれないので、しばらくお待ちください。

性能テスト

よかった、360実機ではなかったのですね。掲載されたデータはあくまでアニメーションライブラリの性能比較のためということで理解しました。


「XNAにはアニメーションライブラリがない」ということですが、作りたいゲームによって「ボーンをいくつにするのか」「ボーン毎に4x4行列が必要なのかクォータニオンのみか」「シェーダ定数はいくつ必要なのか」といったもろもろの制約が全く異なってくることを考えると、統一ライブラリを作ることは難しいような気もします。ACL等も、シェーダに色々制約がありそうですが、どうですか?


>セルシェーディング
やはりと言うか、ピクセルシェーダが重いようです。モデルをアップにすると速度が落ちますから。これにスキンを組み合わせる必要がありますが、そっちは頂点シェーダの負荷なのが救いかと。


>別の頂点扱い
ちょっと長くなりますが、まず先に。Metasequoia上でスムージングONの表示にすると法線が自動計算されるようになります(OFFだと1ポリゴンに含まれる頂点は全て同じ法線と見做されフラットになる)。ただし設定したある角度以上の2面はスムーズになりません。それら2面に共有される頂点は、1つにつき複数の法線が割り振られることになります。

試しに立方体を法線出力ありで、スムーズなものと(1つの頂点に1法線)スムーズでないもの(1つの頂点に3つの法線)を作成してXNAでインポートし、頂点バッファを覗いてみると、前者は192バイト(1頂点は24バイトだから8頂点)、後者は576バイト(24頂点)扱いになりました。※ちなみに立方体は12ポリゴンなのでインデックスバッファはどちらも36頂点。

で、本題。本来1,152頂点なのにMetasequoia上で888頂点と表示されるのは、じつはオブジェクト間で共有される頂点云々ではなく、単に1つの頂点に複数の法線が割り当てられているからだったりしませんでしょうか?

頂点数の謎が解けました!

yohさんこんばんは~

>アニメーションライブラリの性能比較のため
そのとおりです。360はまだ希望ありますよ!w

>統一ライブラリを作ることは難しいような気もします。
説明不足ですみません。
私の希望は、統一規格や標準規格(スタンダード)を目指すということではなく、XNAが最初に提供するライブラリ群にアニメーション機能を含めて欲しい、ということです。

>ACL等も、シェーダに色々制約がありそうですが
ACLにも不満はあります。ですが、この際ACLと全く同じ物でも構いません。とにかくXNA標準でアニメーションをサポートし、初心者の敷居を下げて、XNA普及率の向上を図るべきです>MS社

中上級者は自作したり他のライブラリに置き換えれば良いでしょうし、他者とコミュニケーションをとる場合でも、標準機能があった方が話が早いと思います。

>セルシェーディング
やっぱり大変なんですね。それでいて2Dっぽく見えると、苦労がいまいち報われない気がしませんか?

>Metasequoia上でスムージングONの表示にすると
なるほど、スムーズな方がデータ量が少ないのですね。勉強になります。

>じつはオブジェクト間で共有される頂点云々ではなく
ご指摘通り、この考え方は間違いでした。Metasequoiaでは異なるオブジェクト間で頂点を共有できませんでした。

>単に1つの頂点に複数の法線が割り当てられているから
うーん…もしそうだとすると、2面の角度を変える度に頂点数が変わるってことになりませんか?
それはちょっと違うと思うんですよね。yohさん御自身の例でも、データ量は変わるけど「どちらも36頂点」ということですし。

…というわけで、詳しく調べ直したら、原因が判明しました!
Metasequoiaの頂点数は「ミラーリング先の頂点数を計上しない仕様」だったのです。Softimageにはこの機能が無いため、コンバート時に頂点数が増加され、頂点数に差が出たのでした。
(HP修正しました)

お陰さまで謎が1つ解決できました。
ありがとうございました&お騒がせしてすみませんでした_O_

解析終了

サンプルプロジェクトの解析が終わりましたが、パフォーマンスの改善には繋がりませんでした。
期待させといてごめんなさい>HOSSIEさん

ワールド座標指定方法は改善したので、次々回のブログかHPをご覧ください。

あ~

ミラーリングONだったのですね。解決してよかったです。ちなみにミラーリングは製作中は便利ですけど、仕上げ段階ではちゃんと左右複製した方がよさそうです。どうやらX=0の頂点について法線が2つ割り振られるらしく、そこで陰影がパッキリ割れてしまいます。

>トゥーンシェーディング
今しがた、ようやく納得の行くものができました(汗)。確かに静止画だと当然1枚絵のイラストにも見劣りするし、3Dにも見えないのですが、それがリアルタイムで動くと間違いなく3Dだと感じられるのですよ。なかなか新味のある映像です。あとリアル志向だと、大手ベンダのゲームと真っ向勝負になりますから…。

>そこで陰影がパッキリ割れてしまいます。
心当たりあります!当時はどうしても直せなくて不思議に思っていたのですが、そういうことだったんですね~!

>大手ベンダのゲームと真っ向勝負になりますから…。
なるほど、そういう観点もありますね。私も少しは考えるようにします。

コメントの投稿


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

トラックバック


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



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