動的テクスチャとその注意点

パーティクルシステムなどで動的に頂点データを変更する場合、GPUとCPUが競合しないように、DynamicVertexBuffer(動的頂点バッファ)、そしてNoOverwriteとDiscardオプションを使う方法を以前紹介しました。 では、テクスチャを動的頂点バッファのように扱うにはどうしたら良いでしょうか?そもそもDynamicTexture2Dというクラスもないし、Texture2D.SetDataにSetDataOptionsを受け取るメソッドもない……。 その答えは XNA Game Studio 4.0でのTexture.SetDataメソッドはSetDataOptions.Discardを指定した時と同じ振る舞いをする(但し注意点あり) となります。 振る舞い的にはTexture2D/Texture3D/TextureCube、それぞれDiscardオプションを指定した時と同じように、指定したテクスチャがGPUで使われていた場合、内部で自動的に同じサイズ、フォーマットのテクスチャを生成し、その新しいテクスチャへデータを書き込むようになっています。 但し、この時にSetDataに渡されるパラメーターがテクスチャの一部分を書き換える設定になっていると、以前のテクスチャからデータを新しいテクスチャへコピーするようになっています。コピーだけならそれ程時間が掛からないのですが、このコピーする際に以前のテクスチャをGPUが使い終わるまで待ってからコピーするようになっているので、結局はDiscardオプションをつけていない時と同じ状態になってしまいます。 私のところでテストしたところ、256x256のテクスチャの一部分を書き換えた時、以下のような結果になりました。 方法 SetDataに掛かった時間 同じテクスチャでSetData 6.8ミリ秒 テクスチャを切り替えてSetData 0.3ミリ秒   まとめると、 テクスチャ全体を書き換える場合は、パフォーマンス問題は発生しない テクスチャの一部分を書き換える場合、複数のテクスチャを切り替えながら書き込むようにしないと遅くなる となります。 テクスチャを切り替えながらSetDataを呼ぶ方法としては「頂点テクスチャでスキンアニメーション」の記事のサンプルコード内にあるFlipTexture2D.csが参考になるでしょう。

0

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

問題報告をツイッターでつぶやくと…… 以前紹介した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

乗算済みアルファとは? その2: コンポジション

前回の投稿からものすごーく間があきましたが、乗算済みアルファの話がTwitterの方で盛り上がったので、思い出したように続きを書いてみます。 前回は今まで多く使われてきた補間アルファの問題とそれを解決するための乗算アルファの紹介をしました。今回は乗算済みアルファの真骨頂である半透明を使ったコンポジションを紹介します。 コンポジションの使い道 レースゲームでは、ゲーム内で複数の車を購入でき、さらに購入した車の各パーツを変更することができるという機能は一般的なものです。中には自分で描いた絵を車に張るなんて言うこともできるものもあります。こういったレースゲームでは、購入した車の一覧はガレージメニュー内でサムネイル表示され、車を選択すると3Dモデルが読み込まれ、自分がチューンナップした車のモデルを見ることができます。 では、このサムネイル画面はどうやって表示するのでしょうか? こういった3Dモデルをカスタマイズできるゲームでは、あらかじめサムネイル画像を用意するということはできません。なぜなら、その組み合わせは膨大な数になってしまうのと、ユーザーが描いた絵までは用意することはできないからです。そこで良く用いられるのが、3Dモデルを変更した時にセーブデータ領域などに3Dモデルをレンダリングした結果をサムネイル画像として保存し、それをメニュー画面で使用するという手法です。 単に矩形型のサムネイルを用意するだけだったら問題は無いのですが、このサムネイル画像をビルボードとして使い、メニュー画面の背景の上に重ね合わせて描画したい場合、例えば車のボディ部分のような不透明部分は不透明に、車のウィンドウ部分のような半透明部分はメニュー画面が透けて見えたりするといった重ね合わせ処理をコンポジション(Composition、日本語で「合成」)と呼びます。 コンポジションの基本 コンポジョン処理をする場合の基本として、描画するオブジェクトA,B,Cがあった場合、以下の式が成り立たないといけません。 A + B + C = (A + B) + C = A + (B + C) この式のA+B+Cという部分はオブジェクトA,B,Cの順に描画するという意味で、(A+B)+CはAとBをまとめて描画した結果を描画した後にCを描画、A+(B+C)はAを描画した後にBとCをまとめて描画した結果を描画するという意味になります。言い換えると()で囲まれたオブジェクトは別のレンダーターゲットに描画し、そのレンダーターゲットの描画結果を他のオブジェクトの描画と合成(コンポジット)できるということです。もしくは前述のレースゲームの中のサムネイル画像がカッコ内の部分に相当します。 結論から言うと、上記の式は補間アルファでは成り立たず、乗算済みアルファでは成り立ちます。つまり、補間アルファではできなかったコンポジションが乗算済みアルファではできるということです。 実際に上の式に補間アルファと乗算済みアルファのブレンディング計算式を当てはめると証明できるのですが、長くなるし、読んでもつまらないし、本題から外れるので、ここでは割愛します。 コンポジション比較 では、実際に乗算済みアルファと補間アルファでコンポジションした場合の結果を見比べてみましょう。まずは、レンダーターゲットを使わずに背景を描画した後に赤い不透明の四角形、半透明の緑色の四角の順に描画してみましょう。 乗算済みアルファ、補間アルファ、どちらも同じ結果になっていますね。 では、次に赤と緑の四角形をレンダーターゲットへ描画し、その結果をテクスチャとして使って背景を描画した後に描画してみましょう。 補間アルファを使った方は緑の半透明部分がより薄くなっており、不透明であるはずの赤い部分も半透明になってしまっています。対照的に乗算済みアルファの方は全く同じ描画結果となっています。つまり、補間アルファではコンポジッションが上手くいかなかったのが、乗算済みアルファではコンポジションができるということです。   XNA 4.0でコンポジション処理 では、実際にXNA 4.0でコンポジション処理をする時にどんなコードを書くのか見ていきましょう。 まずは、コンポジション用のレンダーターゲットの生成と、そこへ描画するコードです。通常のレンダーターゲットを使った描画と殆ど同じものですが、ここではColor.Transparentでクリアするのがポイントとなっています。このTransparent(透明色)はRGBA値が(0,0,0,0)になっています。 // コンポジション用のレンダーターゲットの生成 RenderTarget2D layer = new RenderTarget2D(GraphicsDevice, 1280, 720); // **** コンポジション用のレンダーターゲットへの描画 **** // レンダーターゲットをグラフィクスデバイスへ設定する…

0

動的頂点バッファのNoOverwriteとDiscard

今まで何度か動的頂点バッファについて触れてきましたが、実際のコードがどうなるのかは記事の中では紹介していませんでした。実は今までに紹介してきたサンプルの中でWritableVertexBuffer<T>というクラスがすでに実装されているので、このクラスを紹介します。 「GPUはいつ描画するのか?」の記事の中でSetDataOptions.NoOverwriteの説明をしました。この記事の中でNoOverwriteというのはプログラムがドライバへ伝えるヒントで、GPUが頂点バッファをアクセスしている領域にはSetDataで上書きすることはありませんよということを述べました。 では、実際にプログラムの中でこの処理をどうやったら良いでしょう?真っ先に思いつくのは以下のようなコードでしょう。 // 動的頂点バッファの生成 DynamicVertexBuffer vb = new DynamicVertexBuffer( graphicsDevice, typeof(MyVertexType), 100, BufferUsage.WriteOnly); // 書き込み先 int currentPosition = 0; int strideSize = vb.VertexDeclaration.VertexStride; // バッファの最後まで来たら、バッファの先頭へ戻る if (currentPosition + myVertices.Length > vb.VertexCount) currentPosition = 0; // 現在の書き込み先へNoOverWriteオプションを使って書き込む vb.SetData(currentPosition * strideSize, myVertices, 0, myVertices.Length, strideSize, SetDataOptions.NoOverwrite); // 書き込み先を更新する currentPosition += myVertices.Length; 考え方としては あらかじめ大きめの頂点バッファを生成する 現在の書き込み先(要素単位)を表すcurrentPosition変数を用意する データの書き込み時にはcurrentPositionから書き込み先のオフセット(バイト単位)を計算して、NoOverwriteオプションを指定して書き込む currentPositionを書き込んだ要素分だけ進める…

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

メタセコイアで作ったモデルをXNAで使う

メタセコイアで作ったモデルをXNAで使う時の注意事項 それでは実際にメタセコイアで作られたモデルをXNAで使用する場合の注意点を紹介していきます。メタセコイアで生成したモデルをXNAで使う場合、現状では3種類の方法があります。 標準のXファイル形式出力機能を使う FBXエクスポーターを使用してFBX形式で出力する(要シェアウェア版) Keynoteに付属しているアニメーション付きXファイル出力を使う(要シェアウェア版)   1はメタセコイアに付属しているXファイル出力機能を使う方法ですが、これには以下の注意点があります。 マテリアルやオブジェクト名は出力されない テクスチャ名に日本語は使えない(文字化けするケースがある) 透明テクスチャ情報は欠落する メタセコイアが出力するのはテキスト形式なのでファイルサイズが大きくなり、メモリ不足でインポートできなくなることもある ファイルサイズが大きくなるという問題ですが私がテストしたケースでは7MBのMQOファイルが165MBのXファイルになるケースがありました。   続いて2のFBXエクスポーターを使う場合の注意点です。 日本語を使わないこと(FBX SDKが多言語サポートしていない) ミラーリングや曲面を使っている場合はエクスポート前にフリーズする必要がある Keynoteと併用する場合はその注意点に留意する必要がある 日本語を使わないことにさえ注意しておけば最も安定している方法なのですが、マテリアル情報変換が正しく行われず、モデルの見た目が変わるケースが見受けられました。 透明テクスチャ情報はマテリアルのTextures[“Transparency”]の中に格納されます。   最後にKeynoteに付属しているXファイル出力機能(Direct X with Animation)を使う場合の注意点です。ここではXファイルフォーマットに関する注意点とKeynoteの注意点の二つに分かれます。まずはXファイルフォーマットに関する注意点としては マテリアルやオブジェクト名はインポートされない テクスチャ名に日本語は使えない(文字化けするケースがある) 透明テクスチャ情報は欠落する ミラーリングや曲面を使っている場合はエクスポート前にフリーズする必要がある Xファイル内ではオブジェクト用のボーンとスケルトン用のボーンを区別できない。 最後の注意点ですが、XNAはインポート時にボーンウェイトが設定されているメッシュから参照されているボーンをスケルトン用のボーンとして扱います。この予測は多くの場合は正解なのですが、スケルトン階層のなかにどのメッシュからも参照されていないボーンがある場合に、そのボーンはスケルトンに属するボーンと認識されずにビルドエラーの原因となります。 Keynoteを使う際特有の注意点としては以下の二つがあります。 オブジェクト名に「:」「-」「|」といった文字がある場合、Keynoteによって名前が変更され、名前衝突の原因となる どのボーンにも属さない頂点を生成することができ、ビルドエラーの原因となる Keynoteはオブジェクト名にスケルトンに関する情報を格納します。ですから、この命名規約に従わないオブジェクト名を使うとKeynoteによって名前が変更され、場合によっては同じ名前のオブジェクトが複数存在することになってしまい、コンテントビルド時の「ノードに複数の BoneContent の子があります。どれをスケルトンのルートにするか決定できません。」というエラーメッセージの原因となります。 また、Keynoteはどのボーンにも属さない頂点を生成することができ、これは実行時に正しく表示されない原因となります。運良くというか運悪く、この孤立した頂点と通常の頂点が同じポリゴン内に混在していた状態だとコンテントビルド時に「頂点のボーンの重みを正規化しているときにエラーが発生しました。BoneWeightCollection に重みの値が含まれていません。」という謎のエラーメッセージとして表示されます。 この問題の頂点はKeynoteをアクティブにした状態でモデル全体を移動させて発見することができます。どのボーンにも属さない頂点は移動しないので、モデル全体を動かすと下図のように引き延ばされることになります。この移動しない頂点が孤立した頂点だということが判ります。問題の頂点が判れば、ボーンの影響範囲を調整することで修正することができます。   ゲーム制作ではどんな情報が必要なのか? これまでの注意点をまとめる前に、ゲーム内での3Dモデルデータの使われ方について考えてみましょう。この用途には以下のものがあります。 キャラクターや背景などのゲーム中に描画されるもの 当たり判定メッシュ ゲーム内オブジェクト配置情報 トリガー 恐らくゲーム用の3Dモデルというと真っ先に思い浮かべるのは1なのは間違いないと思います。ですが、ゲーム制作では実際にゲーム中に描画する以外にも、3Dモデルデータ必要になる場面が多数あります。その主なものが2~3になります。まずは下図を見てください。メタセコイアで3分程で作ったものなのでモデリングのクオリティは気にしないでください(汗)。ゲーム内で実際に描画するのは地面とビルですが、それ以外にも赤い三角錐モデルはプレーヤーのスタート地点、黄色い点は敵の出現ポイント、そして赤い半透明の箱はプレイヤーが触れると次のマップへ移動するトリガーを表しています。 このように図で表すと色んな事が視覚的に判りやすくなります。例えば、このマップでは、プレーヤーのスタート地点は手前で3つの出口があり、敵の数は後になる程多くなり、中にはビルの屋上に出現する敵もいるということが判ります。さて、このゲームデザインをどうやって実装しますか?これらの情報をソースコードに一つ一つ数値として書いていきますか?それともレベルエディターを作りますか?個人や小規模な人数でゲーム制作という視点で考えると、どちらも時間と労力が必要になるのであまり現実的ではありません。ではどうしたらいいでしょうか? 最も簡単な手段はモデルデータにこれらのゲーム特有の情報を追加してファイルにセーブ、後はコンテントパイプラインでモデルデータ処理と同時にゲーム特有の情報を抽出することです。例えば、「敵出現位置」と名付けたマテリアルを使ったオブジェクト位置を敵の出現位置、「出口」と名付けたモデルはそのメッシュデータを判定範囲としたトリガーとして変換することで実現することができます。この方法であればメタセコイアをレベルエディターとして流用することができるので、視覚的にマップデザインすることができ、時間と労力も節約できるのでゲーム本来の部分の作業に集中することができます。 このマップを3分間程度で作ることができたことを考えるとその効率の良さが判ると思います。もちろん、面白いゲームを作るにはもっと時間を費やして優れたレベルデザインに仕上げる必要があります。ですが、ここで重要なのは、短時間でゲーム自体の面白みを出す部分に集中できる作業環境を作り出すことができるかということです。   まとめ 以上の事から、ゲームで使うことを考えると、名前や透明テクスチャ情報が欠落してしまうXファイルを使うのは避けた方が良いでしょう。となると、残ったFBXエクスポーターを使用することになると思います。この場合、以下の注意点に留意する必要があります。 日本語を使わないこと(FBX…

2

Game building日誌 その4「2日目、モデリング終了?」

  9月20日(月) 11:20AM モデリング開始 月曜の朝は週末に溜まったメールに目を通すので、これに1時間程の時間を費やしてから作業開始です。 まずは曲面のモデリングですが、NURBSとか使った曲面モデリングはMayaでやったことがあるのですが、LightWaveではやったことがなかったので例によって例のごとくトレーニングビデオを観て勉強しました。 Introduction to the Bend Tool(ベンドツールの紹介) Adding thickness to single-sided geometry(板ポリゴンに厚みをつける方法) 今回はポリゴンで作った板をベンドツールを使って曲げることにしました。 9月20日(月) 04:00PM Doldvaの外観が完成 外観が大体できたのですが、このシーンは巨大空母の内部に入っていくというシーンなので中に何もないと非常に寂しいので内部のモデリングすることにしました。 ここら辺の資料は殆どないので何度もビデオを観ながら、こんな感じかな?という感じに手探りでモデリングしたので時間が掛かりました。 プログラマーの葛藤、その1: ここへ来てマテリアル数が増えてきたので、ひとつひとつマテリアルを追加する度に「ああ、DrawIndexedPrimitiveの呼び出しがまた増える…」と悩むようになりました。テクスチャにして一つのマテリアルでごまかすという手もありますが、テクスチャを貼る、特にUV座標の編集は非常に時間が掛かるのでマテリアル数を追加することを選びました。「まぁ、実際のゲームではもっとマテリアル数があったりするから、これくらいでいいか」というようにプログラマー脳を眠らせながらモデリングしていました。 9月20日(月) 07:22PM Doldva完成 とりあえず、中身もそれっぽいものがモデリングできました。もちろん、時間を掛ければもっと細かい部分を追加できますが、今日中にモデリングは終わらせておきたかったので、ここで一旦終了して家に帰りました。 9月20日(月) 11:11PM モデリング夜の部開始 帰宅して、夕食を摂り、少し休んだ後にまたモデリング開始です。次のモデルは非常に形状が複雑な上に参考になる資料が少ないという状態だったのでモデリングするのが大変でした。 何度も何度もビデオを観て、複雑だと思ってた形状も八角形の形で、二種類のパーツを回転コピーさせるとできるということがわかってから黙々とそのパーツ郡をモデリングしていきました。 9月21日(火) 05:41AM Cannon Seed完成?   モデリング開始してから5時間以上経って、ようやくそれらしい形になりました。本当は内部のモデリングをしないといけないのですが、朝6時前で気力がないのと、これ以上モデリングに時間を費やしたら間に合わなくなりそうだったので、ここで切り上げることにしました。 これでGame Building二日目の作業を終えました。 明日からはこの二日間で作ったモデルを実際にゲームの中に組み込んでいくプログラミング作業を開始します。 つづく……

0