メタセコイア・パイプライン Ver. 1.3

メタセコイア 4.2がリリース メタセコイア 4.2がリリースされました。4.2では作業中のサムネイル画像をMQOファイルにThumbnailチャンクとして保存できるようになりました。 そこで、この変更に対応したメタセコイア・パイプライン、バージョン1.3を公開します。 メタセコイア・パイプラインを使ったサンプル(アセンブリファイルも含む) http://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.3.140718.0-sample.zip メタセコイア・パイプライン: コンテント・パイプライン用アセンブリファイル http://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.3.140718.0-bin.zip メタセコイア・パイプライン: ソースコードとプロジェクト http://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.3.140718.0-src.zip 例によって例のごとく、不具合を見つけたら、お手数ですがご連絡ください。

0

メタセコイア・パイプライン Ver. 1.2

メタセコイア 4.2が出力するMQOファイル読み込みに対応した「メタセコイア・パイプライン Ver. 1.3」を公開しました メタセコイア 4.0がリリース メタセコイア 4.0がリリースされました。4.0でセーブされたMQOファイルではバージョン番号が1.1になり、tripatchチャンクが追加されていることを確認しました。 そこで、この変更に対応したメタセコイア・パイプライン、バージョン1.2を公開します。 メタセコイア・パイプラインを使ったサンプル(アセンブリファイルも含む) http://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.2.131030.0-sample.zip メタセコイア・パイプライン: コンテント・パイプライン用アセンブリファイル http://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.2.131030.0-bin.zip メタセコイア・パイプライン: ソースコードとプロジェクト http://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.2.131030.0-src.zip 例によって例のごとく、不具合を見つけたら、お手数ですがご連絡ください。

5

続・真・簡単(かもしれない)日本語表示

問題報告をツイッターでつぶやくと…… 以前紹介したWPFフォントプロセッサーを使ってくれている人からツイッターの方で不具合報告がありました。 不具合報告は太いアウトライン描画をすると下図のような状態になるというものでした。 これはWPFのアウトライン描画時の使用するペンに線を繋げる時の方法を指定するPenLineJointというプロパティがあり、それがMiterになっていることが原因でした。これをBevel、もしくはRoundにすると問題は解決します。 また、アウトラインを描画するとフォントの上にラインを描画するので、小さなサイズのフォントでは1、2ピクセルの太さのアウトライン描画をすると下図のようにアウトラインが文字に覆いかぶさった状態になってしまいます。 今回、不具合を報告してくれた方がしていた方法として、アウトライン描画をした後にもう一度アウトライン無しで文字を描画することで、小さい文字でも綺麗に見えるようにしていました。同じ方法はAdobe After Effectのテキスト描画の時にアウトラインを先に描画するのか、後に描画するかを指定できるようになっています。     WPFフォントプロセッサーが更新される この二つの機能は便利なので早速WPFフォントプロセッサーに取り入れることにしました。今回追加したのは以下の二つのプロセッサーパラメーターです。 アウトライン形状 アウトライン描画方法 アウトライン形状には、Miter(鋭角)、Bevel(ベベル)、そしてRound(円形)のいずれかを設定できるようになっています。それぞの違いは下図の、特に「W」の文字で違いが分かると思います。 そして、アウトライン描画方法には以下の3つの方法を指定することができます。 StrokeOverFill 文字本体描画の後にアウトラインを描画する FillOverStroke アウトラインを描画した後に文字本体描画する StrokeOnly アウトラインのみを描画する   WPFフォントプロセッサー サンプル いつものように、今回もサンプルプログラムとWPFフォントプロセッサーのソースコードを公開します。 サンプルプログラムはWindows, Xbox 360,そしてWindows Phone 7 (7.1)のプロジェクトが用意されています。このサンプルプログラムでは複数のフォントを使った文字描画をしています。Xbox 360コントローラーのスティック、キーボードの上下キー、マウスのホイールスクロール、そしてタッチとフリック操作で文字をスクロールさせることができます。 サンプルは以下のURLからダウンロードできます。 http://higeneko.net/hinikeni/sample/xna40/WpfFont20120604.zip XNA 4.0で用のWpfFontPiepline.dllは以下のURLからダウンロードできます。 http://higeneko.net/hinikeni/sample/xna40/WpfFontPipeline20120604.zip

5

メタセコイア・パイプライン Ver. 1.1

メタセコイア 4.2が出力するMQOファイル読み込みに対応した「メタセコイア・パイプライン Ver. 1.3」を公開しました メタセコイア 4.0が出力するMQOファイル読み込みに対応した「メタセコイア・パイプライン Ver. 1.2」を公開しました メタセコイア 3.0がリリース メタセコイア 3.0がリリースされたので、早速ダウンロードして軽く以前紹介したメタセコイアサンプルプログラムの動作テストをしてみました。 Mkxエクスポーターはそのまま使えるのを確認しましたが、MQOファイルを直接読み込むメタセコイア・パイプラインはそのままでは3.0から出力したMQOファイルを読み込めませんでした。これは、2.2の時には無かったチャンクが3.0で出力したMQOファイルに存在するのが原因でした そこで、3.0で出力したMQOファイルも読み込めるように修正したバージョン1.1を公開します。 メタセコイア・パイプラインを使ったサンプル(アセンブリファイルも含む) http://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.1.120430.0-sample.zip メタセコイア・パイプライン: コンテント・パイプライン用アセンブリファイル http://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.1.120430.0-bin.zip メタセコイア・パイプライン: ソースコードとプロジェクト http://higeneko.net/hinikeni/sample/xna40/MetasequoiaPipeline-1.1.120430.0-src.zip   メタセコイア 3.0の新機能として彫刻機能があります。下図は球体に1分くらいで適当に彫刻したモデルをメタセコイア・パイプライン Ver. 1.1を使ってXNAで表示したものです。こういった複雑な形状のモデルが直ぐに作ることができ、そのままXNA上で表示できるというのはゲーム制作に大いに役立つことでしょう。   まだメタセコイア3.0はリリースされたばかりなので、これ以外にもパイプラインに不具合があるかもしれないので、もし見つけたら気軽に連絡ください。

0

真・簡単(かもしれない)日本語表示

2012年6月4日追記 新しい機能を追加したものを投稿しました  いままで、ひにけにXNAではXNAで日本語表示する為の投稿を複数回してきました。 続・簡単(かもしれない)日本語表示: ツールによる日本語文字の追加 簡単(かもしれない)日本語表示: プロセッサー・パラメーターを使った日本語文字の追加 Content Pipeline その3 そのカスタマイズ: XNA 1.0時代のコンテント・パイプラインのカスタマイズの例として紹介 こうやって見返すと、今までの投稿ではいかにして簡単に日本語文字を追加するのかということを紹介してきました。 XNA標準のフォントプロセッサーでは、これ以外にも以下の基本的な問題があります。 OpenTypeフォントが使えない 大量の文字を処理させると時間が掛かる これらの問題を解決するには新しいフォントプロセッサーを作ることですが、独自のフォントプロセッサーを作ってしまうと、それに伴って独自の表示プログラムも用意しないといけません。XNAで用意されているSpriteFont描画に慣れている人達が多く居るなかで、似たような、だけどちょっとだけ違う文字表示APIを作るというのには抵抗がありました。 ですが、XNBファイルフォーマットが公開され、Silverlight 5のToolkitの中ではXNA 4.0のコンテント・パイプラインをそのまま使用し、Windows用のXNBファイルから直接3Dモデルなどを読み込んで、Silverlight 5で表示することができると知ったときに思いついたのが「同じデータを出力してSpriteFontになりすまことができれば、実行時にXNAの文字描画APIをそのまま使うことができるかも?」というアイディアが浮かんだので試してみたら、思ったよりも良い物ができたので公開することにしました。 WPF フォントプロセッサー 今回紹介するのはWPFを使用したWPFフォントプロセッサーです。WPFを知らない人の為に補足しておくと、WPFはWindows Presentation Foundationの略で今までのGDI/GDI+を使ったUIフレームワークとは違い、GPUアクセラレーションを利用した新しいUIフレームワークです。SilverlightはWPFのサブセットでWindows Phone 7でも使われいて、Windowsの後継OSであるWindows 8の新しいアプリケーションモデルの1つであるXAMLアプリケーションはこのWPFが元となっています。 WPFフォントプロセッサーはその名の通り、WPFの文字描画を使用したフォントプロセッサーです。特徴としては以下の3つがあります。 OpenTypeフォント対応 処理速度の高速化 JIS漢字追加機能 文字装飾 WPFは今までのようにTrueType、そしてOpenTypeフォントに対応しています。OpenTypeフォントはOpenの名が示すとおりOSに依存しないフォントフォーマットで、現在広く普及しているフォントフォーマットです。OpenTypeフォント対応によって、これらの多くのフォントをXNAで作られたゲームでも簡単に使えるようになりました。 そして、処理速度の高速化ですが、XNA標準のフォントプロセッサーは生成したテクスチャをできるだけコンパクトにまとめる為のアルゴリズムを採用しています。ですが、文字数の増加に対して指数関数的に処理時間が掛かってしまうという問題があります。ゲーム内で使われる文字だけを抽出して生成する場合は1,500文字程度で収まるので大きな問題とはならないのですが、常用漢字やJIS漢字といった2千文字を超えてくると極端に時間が掛かるようになり、場合によっては20分近く掛かってしまうということがありました。 そこで、WPFフォントプロセッサーでは漢字などの大量の文字を処理するのに適したアルゴリズムを採用して処理速度の高速化をしています。以下は私のPCで測定した結果です。 文字数 XNAフォント プロセッサー WPFフォント プロセッサー 速度差 常用漢字を含む2,331字 3分20秒 0.6秒 333倍 JIS第1水準漢字を含む3,438字 10分28秒 0.82秒 765倍 JIS第2水準漢字を含む6,974字 N/A 1.63秒…

0

メタセコイアとKeynoteとXNAとMkxエクスポーター

前回はメタセコイアのモデルファイルであるMQOファイルを直接読み込むことのできるインポーターを含んだメタセコイア・パイプラインを紹介しました。 モデルが読み込めたら、次はアニメーションデータを使いたくなります。メタセコイア自体にはアニメーション機能は付いていないのですが、プラグインによってアニメーションを付けてしまおうというのがKeynoteです。Keynoteを使っている時にモデルデータをセーブすると、.mqoファイルと一緒に.mqxというプラグイン用のファイルが出力されます。 理想的には、この.mqxファイルにあるアニメーションデータをメタセコイア・パイプラインで直接読み込めると良いのですが、以下の問題がありました。 Keynoteが出力する.mqxにはアニメーションのキーフレーム情報しか出力されない ボーン情報が.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エクスポーター 前置きが長くなりましたが、今回は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エクスポーターの機能 Mkxエクスポーターには以下の機能があります。 日本語完全対応 Keynoteで作成したボーン情報、スキニング情報、複数アニメーション出力 Keynoteを使っている時におきる問題の検出と対処方法の表示 オブジェクト出力モード Catmull-Clark曲面やミラーリング使用時のボーンウェイト生成(インポート時) Keynoteで作成した情報を出力するにはKeynoteをアクティブの状態、つまり「ボーン」コマンドボタンが押された状態で「ファイル/上書き保存」を選び、ファイル種類を「MKXファイル(*.mkx)」を選んで保存することでできます。 Keynoteによる名前変更が原因で名前衝突が起きる場合、Mkxエクスポーターは名前衝突が起きない名前へと変更します。この処理が発生した場合、エクスポート終了後に下図のようなメッセージが表示され、どの名前を変更したのかが表示判るので容易に修正できるようになっています。 また、設定ミスによってできてしまう、どのボーンにも属さない頂点を見つけたときには、XNA側で正しくインポート出来るように孤立した頂点用のボーンを自動生成するようになっています。この場合もエクスポート終了後に下図のようなメッセージが表示され、どのオブジェクトに孤立した頂点があるのかが表示されるので容易に修正できるようになっています。 オブジェクト出力機能は私がデバッグ時に使用していた物で、Keynoteを非アクティブ、もしくはインストールされていない状態でMkxファイルを出力すると、このモードでファイルが出力されます。この時に出力されるのはMqoファイル形式で出力されるものと同じ物が出力されます。メタセコイア・パイプラインにはMqoファイルを直接読み込む機能があるので、必要性は殆どありません。強いて言うならMqoファイルで出力するより15~50%程ファイルサイズが小さくなることくらいです。   Mkxファイルの使い方 Mkxファイルをゲームプロジェクトへ追加する方法は前回紹介したMqoファイルのインポート方法と同じように MetasequoiaPipeline.dllをコンテントプロジェクトの参照設定で追加する インポートしたいMkxファイルを追加する だけです、この時、自動的にMkx形式メタセコイア モデルインポーター(MkxImporter)が設定されます。   アニメーションサンプル(SkinningSample) 前回紹介したサンプルの中にはMkxファイルをインポートしてアニメーションさせるサンプルが同梱されています。このプロジェクトを実行すると、下図のようにeynoteに付属しているサンプルのキャラクターアニメーションを見ることができます。 このプロジェクトはAppHubにあるSkinned Modelサンプル(英語版)のコメントを日本語に訳し、以下の2つの変更を加えたものです。 SkinnedModelProcessorをModelProcessorではなくMqModelProcessorから派生させた 実行時、テクスチャが指定されていないSkinnedEffectに白いテクスチャを設定 SkinnedEffectはテクスチャなしの状態だと実行時にエラーとなるので、それを回避する為に1x1の白いテクスチャを生成して設定するようにしました。 以上のように既存のサンプルからの変更点は皆無に等しいので、簡単にMkxファイルフォーマットへと移行することが判ると思います。   まとめ 今回のメタセコイア特集連載(第一弾?)の最後に、この場を借りてメタセコイアの作者である水野様、サンプルで使用したモデル制作者であるKT爺様、そしてKeynoteの作者でありエクスポーター制作時には私の不躾な質問に快く答えてくださったmqdl様に感謝の意を表します。…

11

メタセコイアのモデルファイルをXNAで直接読み込む「メタセコイア・パイプライン」

メタセコイア 4.2が出力するMQOファイル読み込みに対応した「メタセコイア・パイプライン Ver. 1.3」を公開しました メタセコイア 4.0が出力するMQOファイル読み込みに対応した「メタセコイア・パイプライン Ver. 1.2」を公開しました メタセコイア 3.0が出力するMQOファイル読み込みに対応した「メタセコイア・パイプライン Ver. 1.1」を公開しました   前回は「問題箇所を特定するのが難しい」という問題を解決する為にメタセコイアファイルとXNAデータの間に入る変換プロセスはなにか?というところで終わりました。 プロのゲーム開発でもこの「問題箇所を特定するのが難しい」というのは非常に大きな問題です。なぜならこの問題を解決するのに時間が掛かるのはもちろん、いつ問題が発生するのか判らないという、スケジュールへの悪影響があるからです。ですから、ゲーム制作の中で重要な3Dモデルデータの場合、使用するモデリングツール専用のプラグインや変換ライブラリを作ることが多くなります。他社で提供されたものを使う場合でも、慎重に検証するのはもちろん、そのソースコードとコンパイル環境があるかが採用する際の重要な決め手となります。 XNAでは、この「モデリングツール専用の変換ライブラリ」に相当するのがインポーターです。 もちろん、インポーターを作るのにも時間が掛かりますが、一旦完成させると開発効率が飛躍的に向上します。私がGame Buildingの時に5日間でゲームっぼい物を作ることができたのも、自作した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 これらは私個人で仕事時間外に作ったものなので、Microsoft社やXNAチームは一切関与してません。ですから、バグあってもConnectとかに連絡しても相手にしてくれないでしょう。バク報告や要望などがあればAppHub内のフォーラム(XNA開発者によるコミュニティフォーラムです)かsupport@higeneko.comへメールしてください。   メタセコイア・パイプライン(MetasequoiaPipeline.dll) このパイプライン・アセンブリには以下のインポーターとプロセッサーが含まれています。 メタセコイア モデルインポーター(MqImporter) MKX形式メタセコイア モデルインポーター(MkxImporter) メタセコイア モデルプロセッサー(MqModelProcessor) メタセコイア モデルインポーター(MqImporter)では以下のメタセコイアファイル内情報をインポートします。 日本語を含んだオブジェクト名、マテリアル名、そしてテクスチャファイル名 オブジェクト(階層構造、可視、スムージング等) マテリアル情報(模様、透明、凸凹テクスチャ情報を含む) メッシュデータ(頂点、UV座標、頂点カラー) Catmull-Clark曲面(インポート時にポリゴン面へ変換される) ミラーリング(分割、接続、接続距離制限、ローカル座標) 回転体 メッシュ分割機能(16Bitインデックスバッファに収まるようにする) このインポーターはMQOファイルに書かれている文字列をSJISとして処理するので、オブジェクト名、マテリアル名、そしてテクスチャ名全てに日本語文字列を使うことができます。Windows、Windows Phone 7では日本語ファイル名をサポートしているのでMQOファイルやテクスチャファイル名に日本語があっても問題ありません。Xbox 360は日本語ファイル名をサポートしていませんが、テクスチャファイル名はコンテント・パイプライン内ではモデルから参照されているテクスチャファイル名を英数字へ変換するので問題ありません。日本語ファイル名のMQOファイルをインポートする場合、プロパティのアセット名を英数字にするだけで元のファイル名はそのままでインポートすることができる、つまりコンテント生成時にはなにも気にせずに日本語を使うことができるということです。…

0

メタセコイアはじめました

Game Building日誌の「3Dモデリングツール選び」の時にコメントで「メタセコイアを取り上げて欲しい」というコメントが寄せられました。実はXNA 1.0の時にメタセコイアはLE版を試してみて、シェアウェア版を購入しようとしたのですが、購入するには日本の銀行に振り込まないといけないということでそのままになっていました。今回、改めて見てみるとPayPalでの支払いにも対応していたので購入したのが2ヶ月程前でした。 そこで、今回から数回にわたってメタセコイアを使って作ったモデルをXNA上で使うための情報を紹介していきたいと思います。 3Dモデルデータ変換の問題点 XNAは標準でXファイルとFBXファイルから3Dモデルを読み込む事ができます。メタセコイアのモデルファイルフォーマットはMQOファイルに格納されるので、メタセコイアで作ったモデルをXNA上で使用するにはXファイルかFBXファイルへ変換する必要があります。 結論から言うと、メタセコイアに限らず、どの3Dモデリングツールでもツール向けのファイルフォーマット以外へ変換する時には幾つかの問題点があります。それらの問題点は以下の4つに分類されます。 日本語問題 ファイルフォーマット変換による情報欠落問題 アプリケーション未対応データ問題 問題箇所を特定するのが難しい 1の日本語問題はネイティブ、特にC/C++で作られている多くのアプリケーションは多言語をサポートしていないという問題に起因します。特に古くからある3Dモデルファイルフォーマットは多言語サポートしていないものが多く、サポートしていても環境依存なマルチバイト文字(SJISなど)のみであったりと、言語の違うOSでは使えないことが多くあります。例えばFBXファイルは多言語サポートしていないので日本語文字を使うことはできません。使えても文字化けするケースがあります。 メタセコイアは日本製ツールでUIも全て日本語なので、自然とオブジェクト名やマテリアル名に日本語を使うことが多くなりますが、そのままでは他の3Dモデルフォーマットへ変換するときに問題となってきます。   2の情報欠落問題はファイルフォーマット変換時には必ずといって起きる問題です。3Dモデルファイルフォーマットにはそれぞれに設計意図があるので、その設計意図が異なるファイルフォーマットへ変換する時にはどうしても変換しきれない情報があります。例えばゲーム系のファイルフォーマットはポリゴンデータを使うことが前提とされているので、3Dモデリングツールでサポートされている曲面データは無視するものが多いのが現状です。   3のアプリケーション未対応データ問題ですが、モデルデータを読み込む側で未対応のモデルデータを使おうとしたときに起きる問題です。XNAの場合、あくまで最近のGPU上で効率的に動作するゲームを作ることを目的としているので、そういった知識が無い状態でモデルデータを作ってしまうと、非効率であり、時にはゲームが実行できない、強制終了してしまうということになってしまいます。よくある問題としてはXNA 4.0のReachプロファイルで3Dモデルに使うテクスチャサイズは2のn乗である必要がありますが、このことを知らないで100x200といったテクスチャを使用するとコンテントビルド時にエラーとなります。   4の問題箇所を特定するのが難しいというのは下図のデータの流れをみると判りやすくなります。例えば、あなたがあるモデルをXNAで表示させたいと思い、メタセコイア標準のXファイル出力機能を使ったとします。これで問題無くXNA上で表示されれば良いのですが、問題はうまく表示されなかった時です。この時、何が原因だったのかを究明するにはどうしたら良いでしょう? 問題になりそうな箇所はいくらでもあります。Xファイル変換にバグがあるのか、Xファイル変換が対応していないデータを作ったのか、Xファイルインポート時の問題なのか、はたまたXNAが対応していないデータだったのか、もしかしたら、単純にモデルデータが悪かったのかもしれません。これらの問題点を探していて原因を見つけたら、単にファイルのコピーし間違いだったなんてことも良くあります。要するにコンテント生成するポイントから実際にコンテントを使うまでの道のりが長ければ長いほど開発効率が下がってしまうことになります。   このように、3Dモデリングツールを使う場合、そのツールの標準フォーマット以外のフォーマットを扱う場合にはいろいろな問題点に注意しないといけません。   つづく……

0

XNA Game Studio 4.0のエフェクト・コンパイラーとコンテント・パイプライン・オートメーション

今までのXNAにはEffect.CompileEffectFromSourceメソッドがありました。Xbox 360上ではランタイム時にシェーダーのコンパイルは使えず、Windows上でのみ使えるメソッドでXbox 360とwindows用のシェーダーをコンパイルすることができました。しかし、この方法では以下の問題がありました。 ランタイム用のAPIのように見えるのに、すべてのプラットフォームで使えない Windows再配布コンポーネントにはXbox 360用のシェーダーコンパイラーが含まれている。これはWindows専用のゲームを作っている人達にとってはスペースの無駄遣いになる 新しいプラットフォームを追加するたびに、正規のバージョンとは別のパッケージを追加してきました。これはバージョン管理としては良い方法ではなく、無関係のプラットフォームのシェーダーコンパイラーをアップデートする度にWindows版のフレームワークDLLを更新しないといけません。 Game Studio 4.0ではシェーダーコンパイラーをWindows版 XNAフレームワークからコンテント・パイプラインへと移しました。Effect.CompilerEffectFromSourceの代わりにEffectProcessorを使うようになりました。 コンテント・パイプライン内でエフェクトをコンパイルするには幾つかの方法があります。 .fxファイルをコンテントフォルダに追加してF5でコンパイル。簡単、でも柔軟性がない .fxファイルをMSBuildプロジェクトに追加(別の機会で紹介します)し、コマンドラインからmsbuild.exeを使う。この方法はとても便利なのですが、活用している人が少なくて残念です。 MSBuild APIを使ってプログラム的にプロジェクトをメモリ内に作って実行する。これはレベルエディタなどの大きなプロジェクト向けの方法ですが、設定するのに手間が掛かります。 XNA Game Studio 4.0の新機能: MSBuildのプロセスを使わずに直接インポーターとプロセッサーをC#コードから呼び出す。これ以降は、この新しいやり方を紹介します。 ContentPipelineの機能を使うにはMicrosoft.Xna.Framework.Content.Pipeline.dllを参照する必要があります。しかし、参照追加のダイアログを開いても、このアセンブリは表示されないでしょう。どこへ行ったのでしょうか? .Net Framework 4.0にはClient Profileと呼ばれるものがあります。これは.Net フレームワーク全体ではなく、クライアント向けアプリケーション用に最適化されたサブセットとなっていて、フレームワークのダウンロードサイズが小さいなどの利点があります。XNA Game Studio 4.0ではWindows向けのゲームを作った場合、デフォルトでClient Profileを使うようになっています。コンテント・パイプラインのアセンブリを参照するには対象プラットフォームを.Net Framework 4にする必要があります。 やり方は以下のとおりです。 Visual Studio上でプロジェクトのプロパティを開く アプリケーションタブを選択 対象のフレームワークを「.Net Framework 4 Client Profile」から「.Net Framework 4」に変更する 参照の追加を選択 .Netタブを選択 Microsoft.Xna.Framework.Content.Pipelineを選択。必要に応じて他のアセンブリファイルも追加する。(ここではMicrosoft.Xna.Framework.Content.Pipeline.TextureImporterを追加しています) インポーターを呼び出す まずはテクスチャをインポートするサンプルを紹介します。まず最初にusingステートメントを記述します。 using Microsoft.Xna.Framework.Content.Pipeline; using Microsoft.Xna.Framework.Content.Pipeline.Graphics; using Microsoft.Xna.Framework.Content.Pipeline.Processors;…

4

新しいエフェクトとコンテントパイプライン

今までのXNAではコンテント・パイプライン内では以下のようにしてマテリアルを読み込んでいました。 もし、FBXかXファイルモデルが.fxファイルを参照している場合、EffectMaterialContentとしてインポートし、ゲーム内ではカスタム・エフェクトとなります。 それ以外であれば、BasicMaterialContentとしてインポートして、実行時にはBasicEffectとなります。 BasicMaterialContnetのテクスチャ、ディフューズカラー、スペキュラ係数といったプロパティはFBXやXファイルのマテリアルの値を設定します。 もし、BasicEffectがサポートしていないプロパティがあった場合は、BasicMaterialContent.OpaqueDataに格納されます。このデータはカスタムプロセッサー内で使用することができます。 モデルデータがエフェクトファイルを参照していない時にカスタムエフェクトを使いたい場合は以下の二つの方法があります。 カスタムプロセッサーを使用してエフェクトを適用する(このサンプルで使用) もしくはランタイムで設定する(このサンプルのChangeEffectUsedByModelメソッドのように) Game Studio 4.0も同じですが、新しいプロセッサー・パラメーターを追加してあり、ビルトイン・エフェクトの中から選ぶことができます(ただし、元のモデルが.fxファイルを参照していない場合)。 これに加えて、コンテント・パイプライン内の型として、SkinnedMaterialContent、EnvironmentMapMaterialContentなどの型が追加されています。 選択するエフェクトによって以下の追加作業をする必要があります: SkinnedEffectの場合はSetBoneTransformsを呼んで現在のアニメーションステートを設定する必要があります。 EnvironmentMapEffectの場合は、キューブマップテクスチャを用意する必要があります。これはランタイム時か、カスタムプロセッサー内で指定できます。Default EffectプロセッサーパラメーターにEnvironmentMapEffectを指定しても、この処理はしてくれません。なぜなら、どのキューブマップテクスチャを使うのか判らないからです。 DualTextureEffectを使っている場合、二番目のテクスチャはFBXのマテリアル情報から自動的に取得します。もしFBXに二番目のテクスチャがない場合はランタイム時か、カスタムプロセッサー内で指定する必要があります。(このサンプル内(英語)のDutalTextureProcessorが参考になります) 原文: http://blogs.msdn.com/b/shawnhar/archive/2010/05/03/new-effects-in-the-content-pipeline.aspx

2