Twitter @HigenekoTwitter #XNA
前回はメタセコイアのモデルファイルであるMQOファイルを直接読み込むことのできるインポーターを含んだメタセコイア・パイプラインを紹介しました。
モデルが読み込めたら、次はアニメーションデータを使いたくなります。メタセコイア自体にはアニメーション機能は付いていないのですが、プラグインによってアニメーションを付けてしまおうというのがKeynoteです。Keynoteを使っている時にモデルデータをセーブすると、.mqoファイルと一緒に.mqxというプラグイン用のファイルが出力されます。
理想的には、この.mqxファイルにあるアニメーションデータをメタセコイア・パイプラインで直接読み込めると良いのですが、以下の問題がありました。
これらの情報はKeynote内でモデルデータから生成されているのですが、その生成方法が判らないとインポートすることができません。同じ理由でMqoファイルインポーターでも一般に良く知られているCatmull-Clark曲面は実装できましたが、曲面タイプ1と2は実際にメタセコイアがどのような計算をしているのかが判らないと実装できないので、これらの曲面タイプはサポートされていません。
さて、これは困ったなぁと、数日間試行錯誤することとなりました。幸い、Keynoteには他のプラグインからKeynoteで生成した情報にアクセス出るAPIが提供されていたので、それを使うためにメタセコイア用のプラグインを作り、そこからメタセコイア・パイプラインで読めるファイル形式の形にして出力する方法が使えると言うことが判りました。
ただ、独自ファイルフォーマットを作るには時間が掛かるし、アニメーションデータを読むだけの為にわざわざ新しいファイルフォーマットを作るのには抵抗がありました。そこで、メタセコイア・パイプライン内にはMqoファイルから読み込んだ情報を一旦DOM(データ・オブジェクト・モデル)形式として保持するようになっているので、このDOM自体をXNAコンテント・パイプラインのIntermediateSerializerを使ってデシリアライズする方法をとることにしました。こうすることでMqoファイルを読むときもDOM形式でデシリアライズするときも全く同じ処理をすることができるので作業量が減り、メンテナンス性が上がり、バグの可能性も大幅に減らすことができるようになります。
と、いう経緯でできたのがMkxファイルフォーマットです。MkxはMetasequoia,Keynote,XNAの略でデータの流れを表しています。実際にはXMLファイル形式となっています。
前置きが長くなりましたが、今回はMkxエクスポーターを紹介します。以下のURLからダウンロードできるようになっています。ファイルの使い方に関する情報は付属しているReadme.txtファイルを参照してください。
プラグインのインストール方法はメタセコイアのマニュアルを参照してください。このプラグインはWindows XP SP2以降のOS標準の機能しか使っていないので、プラグインを使用する際はXNA Frameworkランタイムを始め、VC++用のランタイムなどは必要ありません。
Mkxエクスポーター本体(MkxExporter.dll) http://higeneko.net/hinikeni/sample/xna40/MkxExporter-1.0.101222.0-bin.zip
Mkxエクスポーターのソースコード(Visual Studio 2010用プロジェクト) http://higeneko.net/hinikeni/sample/xna40/MkxExporter-1.0.101222.0-src.zip
これらは私個人で仕事時間外に作ったものなので、Microsoft社やXNAチームは一切関与してません。ですから、バグあってもConnectとかに連絡しても相手にしてくれないでしょう。バク報告や要望などがあればAppHub内のフォーラム(XNA開発者によるコミュニティフォーラムです)かsupport@higeneko.comへメールしてください。
Mkxエクスポーターには以下の機能があります。
Keynoteで作成した情報を出力するにはKeynoteをアクティブの状態、つまり「ボーン」コマンドボタンが押された状態で「ファイル/上書き保存」を選び、ファイル種類を「MKXファイル(*.mkx)」を選んで保存することでできます。
Keynoteによる名前変更が原因で名前衝突が起きる場合、Mkxエクスポーターは名前衝突が起きない名前へと変更します。この処理が発生した場合、エクスポート終了後に下図のようなメッセージが表示され、どの名前を変更したのかが表示判るので容易に修正できるようになっています。
また、設定ミスによってできてしまう、どのボーンにも属さない頂点を見つけたときには、XNA側で正しくインポート出来るように孤立した頂点用のボーンを自動生成するようになっています。この場合もエクスポート終了後に下図のようなメッセージが表示され、どのオブジェクトに孤立した頂点があるのかが表示されるので容易に修正できるようになっています。
オブジェクト出力機能は私がデバッグ時に使用していた物で、Keynoteを非アクティブ、もしくはインストールされていない状態でMkxファイルを出力すると、このモードでファイルが出力されます。この時に出力されるのはMqoファイル形式で出力されるものと同じ物が出力されます。メタセコイア・パイプラインにはMqoファイルを直接読み込む機能があるので、必要性は殆どありません。強いて言うならMqoファイルで出力するより15～50%程ファイルサイズが小さくなることくらいです。
Mkxファイルをゲームプロジェクトへ追加する方法は前回紹介したMqoファイルのインポート方法と同じように
だけです、この時、自動的にMkx形式メタセコイア モデルインポーター(MkxImporter)が設定されます。
前回紹介したサンプルの中にはMkxファイルをインポートしてアニメーションさせるサンプルが同梱されています。このプロジェクトを実行すると、下図のようにeynoteに付属しているサンプルのキャラクターアニメーションを見ることができます。
このプロジェクトはAppHubにあるSkinned Modelサンプル(英語版)のコメントを日本語に訳し、以下の２つの変更を加えたものです。
SkinnedEffectはテクスチャなしの状態だと実行時にエラーとなるので、それを回避する為に1x1の白いテクスチャを生成して設定するようにしました。
以上のように既存のサンプルからの変更点は皆無に等しいので、簡単にMkxファイルフォーマットへと移行することが判ると思います。
今回のメタセコイア特集連載(第一弾？)の最後に、この場を借りてメタセコイアの作者である水野様、サンプルで使用したモデル制作者であるKT爺様、そしてKeynoteの作者でありエクスポーター制作時には私の不躾な質問に快く答えてくださったmqdl様に感謝の意を表します。
さて、前々回のまとめではメタセコイアでモデルを出力する際にはFBXエクスポーターを使い、幾つかの注意点に留意する必要があると述べました。この注意点はメタセコイア・パイプラインとMkxエクスポーターの組み合わせを使った場合にどうなるか見てみましょう。
と、なります。私がテスト用にダウンロードした中で曲面タイプ1や2を使っているケースは100個中3個と少なく、キャラクターモデリングの場合はCatmull-Clark曲面を使用する傾向にあるようです。ですから、この注意点が大きな問題となることは殆どないと思われます。また、問題が起きた場合、それはメタセコイア・パイプラインとMkxエクスポーターのバグである可能性が高く、その場合でもソースコードが公開されているのでデバッグ、修正することができます。もちろん、バグが出た場合は私の方でもできうる限りの対応はするようにしますので気軽に連絡ください。
XNAを使って3Dゲームを作りたい、3Dゲーム制作というのはどんな物なのか知りたいという人にとって、初めての3Dゲーム制作の為にいきなり高額な3Dモデリングツールを買うというのは敷居が高すぎます。そんな人達の多くが一度は触れるのがメタセコイアなのではないでしょうか？今までの記事で述べてきたように、以前はメタセコイアで作られたモデルをXNAで使うには細かい注意点が必要でした。この細かな注意点に貴重な時間を奪われてしまうのは勿体ないことです。
メタセコイア・パイプラインとMkxエクスポーターがそんな人達の力に少しでもなれることを願います。
メタセコイア 3.0が出力するMQOファイル読み込みに対応した「メタセコイア・パイプライン Ver. 1.1」を公開しました
前回は「問題箇所を特定するのが難しい」という問題を解決する為にメタセコイアファイルとXNAデータの間に入る変換プロセスはなにか？というところで終わりました。
プロのゲーム開発でもこの「問題箇所を特定するのが難しい」というのは非常に大きな問題です。なぜならこの問題を解決するのに時間が掛かるのはもちろん、いつ問題が発生するのか判らないという、スケジュールへの悪影響があるからです。ですから、ゲーム制作の中で重要な3Dモデルデータの場合、使用するモデリングツール専用のプラグインや変換ライブラリを作ることが多くなります。他社で提供されたものを使う場合でも、慎重に検証するのはもちろん、そのソースコードとコンパイル環境があるかが採用する際の重要な決め手となります。
XNAでは、この「モデリングツール専用の変換ライブラリ」に相当するのがインポーターです。
もちろん、インポーターを作るのにも時間が掛かりますが、一旦完成させると開発効率が飛躍的に向上します。私がGame Buildingの時に５日間でゲームっぼい物を作ることができたのも、自作したLightwaveインポーターによるところが大きいです。
そこで、今回はメタセコイアファイルを直接読み込むことのできるインポーターを含んだコンテント・パイプライン用アセンブリ、メタセコイア・パイプラインを紹介していきます。
今回紹介するメタセコイア・パイプラインは以下のURLからダウンロードできるようになっています。XNA Game Studio 4.0向けに書かれています。ファイルの使い方に関する情報は付属しているReadme.txtファイルを参照してください。
メタセコイア・パイプラインを使ったサンプル(アセンブリファイルも含む) http://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.0.101222.0-sample.zip
メタセコイア・パイプライン: コンテント・パイプライン用アセンブリファイル http://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.0.101222.0-bin.zip
メタセコイア・パイプ��イン: ソースコードとプロジェクト http://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.0.101222.0-src.zip
このパイプライン・アセンブリには以下のインポーターとプロセッサーが含まれています。
メタセコイア モデルインポーター(MqImporter)では以下のメタセコイアファイル内情報をインポートします。
このインポーターはMQOファイルに書かれている文字列をSJISとして処理するので、オブジェクト名、マテリアル名、そしてテクスチャ名全てに日本語文字列を使うことができます。Windows、Windows Phone 7では日本語ファイル名をサポートしているのでMQOファイルやテクスチャファイル名に日本語があっても問題ありません。Xbox 360は日本語ファイル名をサポートしていませんが、テクスチャファイル名はコンテント・パイプライン内ではモデルから参照されているテクスチャファイル名を英数字へ変換するので問題ありません。日本語ファイル名のMQOファイルをインポートする場合、プロパティのアセット名を英数字にするだけで元のファイル名はそのままでインポートすることができる、つまりコンテント生成時にはなにも気にせずに日本語を使うことができるということです。
インポート自体は可視オブジェクトのみをインポートするので、ゲームに関係の無いオブジェクトを不可視設定にするだけで同じMQOファイルをそのままゲームプロジェクトへ追加することができます。
メッシュ分割機能はReachプロファイルでもモデルを表示できるようにするのが主な目的ですが、HiDefでも32Bitインデックスより16Bitインデックスの方が描画効率が良いので常に16Bitインデックスバッファへ変換するようになっています。
MKX形式メタセコイアモデルインポーターの機能については次回説明します。
メタセコイア モデルプロセッサー(MqModelProcessor)は標準のModelProcessorから派生したもので、以下のメタセコイア特有の情報を処理します。
通常、ゲーム内では不透明のメッシュを描画してから、半透明のメッシュを描画するようにして不透明、半透明のメッシュ間での視覚的問題がでないようにします。この処理をする為にはどのメッシュが不透明で半透明なのかが判らないとできません。そこで、このプロセッサー内ではアルファ値の使用状況をマテリアルのアルファ値、頂点カラー、そしてテクスチャのピクセル情報から自動的に判定するようになっています。
半透明処理が必要なアルファ値、つまり255以外の値を使っている場合、このプロセッサーはModelMeshPart.TagへInt32値で1を格納するようになっています。ですから、ゲーム内で(ModelMeshPart.Tag != null)という判別式でこのメッシュが半透明処理が必要かどうかを判定することができるようになっています。サンプルプロジェクト内のDrawModelメソッドではこの処理を行っているので、そのコードが参考になると思います。
サンプルパッケージには以下のものが含まれています。
メタセコイア・パイプライン アセンブリファイルはバイナリパッケージにあるもと同じものです。アニメーションサンプルについては次回説明します。
モデルインポートサンプルでは実際にインポートしたメタセコイアモデルを表示するサンプルとなっています。ここではKT爺様(「萌えろ！CG道場＋」http://ktg.sblo.jp/）からダウンロードしたものを使用させてもらいました。このモデルは見た目も素晴らしく、データ的にもオブジェクト階層構造、ミラーリング、Catmull-Clark曲面、そして透明テクスチャとメタセコイアの主要な機能のデモには最適のモデルでした。この場を借りてKT爺様に感謝の意を表します。
サンプルを実行させると以下のような画面になります。モデルファイルがダウンロードできるページの最後にある画像と比べると、XNA上でも同じものが表示されているのがわかると思います。また、Windows, Xbox 360, Windows Phone 7の全てのプラットフォームで動作し、Windows Phone 7のプロジェクトは実機とエミュレーター上で動作しているのを確認しました。
このサンプルの中では、前述のように半透明メッシュであることを表す(ModelMeshPart.Tag!=null)という判別式を使って、不透明メッシュを描画してから、半透明メッシュを描画するようになっています。この処理で不透明メッシュと半透明メッシュ間の描画順による視覚的問題は解決しています。また、このモデルでは笹の葉部分に半透明メッシュ同士の重なった部分があるので、実行時に半透明メッシュをAlphaTestEffectへと変換することで対応しています。このモデルの場合は特に問題にはなりませんが、AlphaTestEffectにはライティング設定ができないので、実際のゲームではライティングが必要な半透明メッシュと区別する必要があります。
では、実際に自分作ったゲームにメタセコイアファイルを追加するにはどうしたら良いのでしょうか？
だけです。これだけで下図のようにインポーターやプロセッサーがメタセコイア・パイプライン用のものが自動的に設定されます。テクスチャファイルを使っている場合はプロジェクトに追加するのではなく、コンテントフォルダ内へファイルをコピーするのを忘れないでください。
今回はメタセコイア・パイプラインを紹介しました。この60KB足らずのアセンブリファイルを追加するだけで、メタセコイアで生成したモデルを簡単にゲーム内で使えるようになりました。その利点としては
が挙げられるでしょう。
さて、モデルがインポートできるようになったら、次はアニメーションです。
つづく……
それでは実際にメタセコイアで作られたモデルをXNAで使用する場合の注意点を紹介していきます。メタセコイアで生成したモデルをXNAで使う場合、現状では３種類の方法があります。
1はメタセコイアに付属しているXファイル出力機能を使う方法ですが、これには以下の注意点があります。
ファイルサイズが大きくなるという問題ですが私がテストしたケースでは7MBのMQOファイルが165MBのXファイルになるケースがありました。
続いて２のFBXエクスポーターを使う場合の注意点です。
日本語を使わないことにさえ注意しておけば最も安定している方法なのですが、マテリアル情報変換が正しく行われず、モデルの見た目が変わるケースが見受けられました。
透明テクスチャ情報はマテリアルのTextures[“Transparency”]の中に格納されます。
最後にKeynoteに付属しているXファイル出力機能(Direct X with Animation)を使う場合の注意点です。ここではXファイルフォーマットに関する注意点とKeynoteの注意点の二つに分かれます｡まずはXファイルフォーマットに関する注意点としては
最後の注意点ですが、XNAはインポート時にボーンウェイトが設定されているメッシュから参照されているボーンをスケルトン用のボーンとして扱います。この予測は多くの場合は正解なのですが、スケルトン階層のなかにどのメッシュからも参照されていないボーンがある場合に、そのボーンはスケルトンに属するボーンと認識されずにビルドエラーの原因となります。
Keynoteを使う際特有の注意点としては以下の二つがあります。
Keynoteはオブジェクト名にスケルトンに関する情報を格納します。ですから、この命名規約に従わないオブジェクト名を使うとKeynoteによって名前が変更され、場合によっては同じ名前のオブジェクトが複数存在することになってしまい、コンテントビルド時の「ノードに複数の BoneContent の子があります。どれをスケルトンのルートにするか決定できません。」というエラーメッセージの原因となります。
また、Keynoteはどのボーンにも属さない頂点を生成することができ、これは実行時に正しく表示されない原因となります。運良くというか運悪く、この孤立した頂点と通常の頂点が同じポリゴン内に混在していた状態だとコンテントビルド時に「頂点のボーンの重みを正規化しているときにエラーが発生しました。BoneWeightCollection に重みの値が含まれていません。」という謎のエラーメッセージとして表示されます。
この問題の頂点はKeynoteをアクティブにした状態でモデル全体を移動させて発見することができます。どのボーンにも属さない頂点は移動しないので、モデル全体を動かすと下図のように引き延ばされることになります。この移動しない頂点が孤立した頂点だということが判ります。問題の頂点が判れば、ボーンの影響範囲を調整することで修正することができます。
これまでの注意点をまとめる前に、ゲーム内での3Dモデルデータの使われ方について考えてみましょう。この用途には以下のものがあります。
恐らくゲーム用の3Dモデルというと真っ先に思い浮かべるのは1なのは間違いないと思います。ですが、ゲーム制作では実際にゲーム中に描画する以外にも、3Dモデルデータ必要になる場面が多数あります。その主なものが2～3になります。まずは下図を見てください。メタセコイアで3分程で作ったものなのでモデリングのクオリティは気にしないでください(汗)。ゲーム内で実際に描画するのは地面とビルですが、それ以外にも赤い三角錐モデルはプレーヤーのスタート地点、黄色い点は敵の出現ポイント、そして赤い半透明の箱はプレイヤーが触れると次のマップへ移動するトリガーを表しています。
このように図で表すと色んな事が視覚的に判りやすくなります。例えば、このマップでは、プレーヤーのスタート地点は手前で３つの出口があり、敵の数は後になる程多くなり、中にはビルの屋上に出現する敵もいるということが判ります。さて、このゲームデザインをどうやって実装しますか？これらの情報をソースコードに一つ一つ数値として書いていきますか？それともレベルエディターを作りますか？個人や小規模な人数でゲーム制作という視点で考えると、どちらも時間と労力が必要になるのであまり現実的ではありません。ではどうしたらいいでしょうか？
最も簡単な手段はモデルデータにこれらのゲーム特有の情報を追加してファイルにセーブ、後はコンテントパイプラインでモデルデータ処理と同時にゲーム特有の情報を抽出することです。例えば、「敵出現位置」と名付けたマテリアルを使ったオブジェクト位置を敵の出現位置、「出口」と名付けたモデルはそのメッシュデータを判定範囲としたトリガーとして変換することで実現することができます。この方法であればメタセコイアをレベルエディターとして流用することができるので、視覚的にマップデザインすることができ、時間と労力も節約できるのでゲーム本来の部分の作業に集中することができます。
このマップを３分間程度で作ることができたことを考えるとその効率の良さが判ると思います。もちろん、面白いゲームを作るにはもっと時間を費やして優れたレベルデザインに仕上げる必要があります。ですが、ここで重要なのは、短時間でゲーム自体の面白みを出す部分に集中できる作業環境を作り出すことができるかということです。
以上の事から、ゲームで使うことを考えると、名前や透明テクスチャ情報が欠落してしまうXファイルを使うのは避けた方が良いでしょう。となると、残ったFBXエクスポーターを使用することになると思います。この場合、以下の注意点に留意する必要があります。
と、いうのが理論的な結果となりました。
なんですが、理論と実現実は違う物です。私自身、ゲーム開発時にモデルファイルフォーマット変換に起因する問題を多く経験してきたので、実際に試してみないと納得できません。そこでネットでダウンロードできるメタセコイアのモデルファイルを100個程集め、どんなデータになっているのかを実際に調べてみました。
この調査で判ったのは大半のモデルデータが日本語を使用しており、XファイルにしろFBXファイル形式にしろ、日本語を使っているファイルは読み込めませんでした。ですから、仮に日本語問題が解決したとしても、今までは日本語問題で隠れていた他の問題が浮上することもあり得ます。
後はやはり前回の記事で問題点とした「問題箇所を特定するのが難しい」と言うのは、個人や小規模な人数でゲーム制作する人にとって貴重な開発時間を奪ってしまうものでもあります。
理想的なのはメタセコイアで作ったファイルが直接XNAに読み込める、つまり、メタセコイアファイルとXNAのデータ構造の間に１つの変換プロセスしか存在しないという形で、下図のようになります。この場合、何か問題が合った場合は「？」の部分に問題があることになるので、XファイルやFBXファイルへ一旦変換するより効率的に問題点を見つけ出すことができます。
この「？」に入るものとは、いったいなんなのでしょうか？
Game Building日誌の「3Dモデリングツール選び」の時にコメントで「メタセコイアを取り上げて欲しい」というコメントが寄せられました。実はXNA 1.0の時にメタセコイアはLE版を試してみて、シェアウェア版を購入しようとしたのですが、購入するには日本の銀行に振り込まないといけないということでそのままになっていました。今回、改めて見てみるとPayPalでの支払いにも対応していたので購入したのが２ヶ月程前でした。
そこで、今回から数回にわたってメタセコイアを使って作ったモデルをXNA上で使うための情報を紹介していきたいと思います。
XNAは標準でXファイルとFBXファイルから3Dモデルを読み込む事ができます。メタセコイアのモデルファイルフォーマットはMQOファイルに格納されるので、メタセコイアで作ったモデルをXNA上で使用するにはXファイルかFBXファイルへ変換する必要があります。
結論から言うと、メタセコイアに限らず、どの3Dモデリングツールでもツール向けのファイルフォーマット以外へ変換する時には幾つかの問題点があります。それらの問題点は以下の４つに分類されます。
1の日本語問題はネイティブ、特にC/C++で作られている多くのアプリケーションは多言語をサポートしていないという問題に起因します。特に古くからある3Dモデルファイルフォーマットは多言語サポートしていないものが多く、サポートしていても環境依存なマルチバイト文字(SJISなど)のみであったりと、言語の違うOSでは使えないことが多くあります。例えばFBXファイルは多言語サポートしていないので日本語文字を使うことはできません。使えても文字化けするケースがあります。
メタセコイアは日本製ツールでUIも全て日本語なので、自然とオブジェクト名やマテリアル名に日本語を使うことが多くなりますが、そのままでは他の3Dモデルフォーマットへ変換するときに問題となってきます。
2の情報欠落問題はファイルフォーマット変換時には必ずといって起きる問題です。3Dモデルファイルフォーマットにはそれぞれに設計意図があるので、その設計意図が異なるファイルフォーマットへ変換する時にはどうしても変換しきれない情報があります。例えばゲーム系のファイルフォーマットはポリゴンデータを使うことが前提とされているので、3Dモデリングツールでサポートされている曲面データは無視するものが多いのが現状です。
３のアプリケーション未対応データ問題ですが、モデルデータを読み込む側で未対応のモデルデータを使おうとしたときに起きる問題です。XNAの場合、あくまで最近のGPU上で効率的に動作するゲームを作ることを目的としているので、そういった知識が無い状態でモデルデータを作ってしまうと、非効率であり、時にはゲームが実行できない、強制終了してしまうということになってしまいます。よくある問題としてはXNA 4.0のReachプロファイルで3Dモデルに使うテクスチャサイズは2のn乗である必要がありますが、このことを知らないで100x200といったテクスチャを使用するとコンテントビルド時にエラーとなります。
４の問題箇所を特定するのが難しいというのは下図のデータの流れをみると判りやすくなります。例えば、あなたがあるモデルをXNAで表示させたいと思い、メタセコイア標準のXファイル出力機能を使ったとします。これで問題無くXNA上で表示されれば良いのですが、問題はうまく表示されなかった時です。この時、何が原因だったのかを究明するにはどうしたら良いでしょう？
問題になりそうな箇所はいくらでもあります。Xファイル変換にバグがあるのか、Xファイル変換が対応していないデータを作ったのか、Xファイルインポート時の問題なのか、はたまたXNAが対応していないデータだったのか、もしかしたら、単純にモデルデータが悪かったのかもしれません。これらの問題点を探していて原因を見つけたら、単にファイルのコピーし間違いだったなんてことも良くあります。要するにコンテント生成するポイントから実際にコンテントを使うまでの道のりが長ければ長いほど開発効率が下がってしまうことになります。
このように、3Dモデリングツールを使う場合、そのツールの標準フォーマット以外のフォーマットを扱う場合にはいろいろな問題点に注意しないといけません。