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

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

メタセコイアと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日誌の「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

Game Building日詩 その8「最終日、発表会5分前に……」

9月24日(金曜日) 09:30AM 発表当日開始 久々に徹夜したので眠気覚ましにシャワー浴びて出社。早速、同僚を三人呼んで一人ではできなかった4人同時プレイのテストプレイをしました。プレイ終了後、同僚からは「どの照準が自分のか判らない」「スコアが変化しないね」「パンツァードラグーンの用にボタン連打で通常弾で、溜めるとホーミングレーザーの方が良いかも」といった意見を聞く事ができました。 9月24日(金曜日) 11:30AM スコアリングシステムの追加 早速、プレイヤー毎に照準の色を変える処理を追加し、敵を倒したときの点数加算処理を追加、ついでに敵編隊を全部撃破を連続でした時にコンボ数が増えていく簡単なボーナススコアシステムを追加しました。 9月24日(金曜日) 03:55PM 発表5分前、トリガーシステムの追加 スコアリングシステムを追加した段階で「こんなもんで良いかなぁ?」と気が抜けたのと、徹夜の反動で非常に眠くなりました。新しいことを考える余裕が無くなり、テストプレイをしては細かい修正をするというのを繰り返していたら、いつの間にか午後2時すぎ。発表まで後2時間を切ったので、この段階で思い切った機能追加はとても危険です。 と、普通の状態だったら、これ以上の変更は加えなかったのでしょうけど、ふと「爆発欲しいな~」と思い立ち、しかもインポーターに変更を加える必要があるトリガーシステム(ゲーム内で任意のイベントを発生させる時等につかう仕組みのこと)を追加し始めました。 追加したトリガーシステムの仕組み自体は単純で、Lightwave内でNullオブジェクト(モデルデータの無いノードのこと)を追加し、その名前を「trigger-」で始まるようにし、アニメーションデータにX軸のスケール値が0から1に変わったフレームをトリガー発生の時間とし、その時間が来るとアニメーションプレイヤーのイベントオブジェクトを「このノードでイベントが発生」と呼び出すようになっています。 普段だったら、識別子とパラメーターの混同した命名規約や、アニメーションを特定の状態にするといった判りづらい仕組みは後で混乱の元になるので追加しません。変わりにゲーム専用のレベルエディタ上でちゃんとしたトリガーとした仕組みを提供するべきと判断したことでしょう。 ですが、徹夜明けのボーっとした頭ではそこまで考えが及ばずに、これまたボーっとしながら黙々とコーディングし、Lightwave上で必要なデータを生成、ゲームプレイを繰り返しながら爆発の大きさなどを調整し終わったのは実に発表の5分前でした……。 結果的に爆発エフェクトを追加することができたのは良かったのですが、今思い起こすとかなりきわどかったことをしたなぁと思います。 9月24日(金曜日) 04:00PM Game Building 2010 発表会 そして遂にGame Building 2010の発表の時となりました。前回はYouTube版の動画を貼ったので、今回はニコニコ動画の方を貼っておきます。 【ニコニコ動画】XNA 4.0で作ってみた まとめ と、言うわけで8回に渡ってXNAチーム内で行われたGame Building 2010向けに作ったゲーム製作の過程を紹介してきました。Game Buildingの目的としてはゲームを楽しく作ろうという他に、このようにして自分達で作ったフレームワークを使って実際にゲームを作ることでフレームワーク設計時には見えなかった問題や改善点を洗い出し、より良いフレームワークを作ろうという目的があります。 私は今まではフレームワークの新機能のテストを兼ねたゲームを作ってきましたが、今回はゲーム製作におけるコンテント製作の難しさの実態を把握するためにコンテント部分の製作に多くの時間を割くようにしました。改めて実感したのはコンテント製作自体、特にモデリングは楽しい作業だったのですが、作ったコンテントを実際にゲームの中で使えるようにするにはまだまだ時間と労力をかけないといけないということでした。 今回学んだことを将来のXNA フレームワーク開発に役立ていきたいと思います。 今までの投稿へのリンク Game Building日詩 その1「はじめに」 Game Building日詩 その2「3Dモデリングツール選び」 Game Building日詩 その3「1日目、モデリング日和」 Game Building日詩 その4「2日目、モデリング終了?」 Game Building日詩 その5「3日目、プログラム開始」 Game Building日詩 その6「4日目、ゲームシーン製作中」…

3

Game Building日誌 その7「5日目、ゲームらしくする」

9月23日(木) 12:00PM 疲れ気味 日曜からずっと寝不足なので疲れ気味ですが、Game Buildingも残すところ今日一日、厳密に言えば明日の午後四時までに完成させれば良いのですが、直前でバグが入ってしまって発表中に止まってしまうのは避けたいので、やはり今日中に仕上げるよう頑張ります。 9月23日(木) 02:03PM キューブマップの背景追加 さて、今まで背景にはなにも無かったので、この段階でキューブマップテクスチャを使った背景を追加します。キューブマップテクスチャの作り方の一つとしてはカスタムモデルエフェクトサンプル(4.0版は英語版のみ)についているCubemapProcessor.csを使うことで一枚の背景テクスチャからキューブマップテクスチャをコンテントパイプライン内でコンパイル時に生成することができます。 この方法は反射マッピングなどの見た目の整合性が多少とれていなくても気づかないような用途では問題ないのですが、背景テクスチャとして使う場合には、上下のテクスチャ部分が歪んでいるのが判りやすくなってしまうという問題があります。 そこで、今回はLightwaveを使ってキューブマップテクスチャを作るのに必要な6枚のテクスチャを生成します。やり方は簡単でアスペクト比が1:1になるカメラを作り、6フレームのアニメーションを作ってイメージファイルへ書き出します。   今回の舞台は宇宙なので、星雲とかをパーティクル使って出来たら良いとは思いましたが、時間が無いのでLightwaveのバックドロップ機能を使います。この機能を使うと背景にフラクタルなどを使ったテクスチャを張ることができるので、複数のテクスチャを設定すると簡単に宇宙っぽい背景をつくることができます。 こうして出来た6枚のテクスチャからDirectX SDKに付属するテクスチャツールなどを使ってDDSファイルを生成します。 9月23日(木) 08:52PM 惑星上、キャノンシード突入直前まで完成 さて、キューブマップの背景を追加し終えたのが午後3時頃。この時点で手来ているのはいままで作ってきたシーンを再生するだけでゲームプレイ的なものは全くありませんでした。残り時間が25時間となったので、本来であればゲームプレイ部分を作るべきですが、せっかく半日かけてモデリングしたキャノンシードは見せたいという欲求が勝って最悪ゲームプレイができなくても良いというリスクを承知で最後のシーンを追加することにしました。 最後のシーンは惑星上なので、地上部分のモデリングをしました。カメラから見える部分だけをモデリングしていきます。   岩山は分割数を多くした立方体にfractalizeという機能を使えば、一つ一つの頂点を修正するより手軽にそれっぽいモデルを作ることができます。ただし、やり過ぎると表裏が反対になってしまうこともあるので注意が必要でした。左下の図をみるとポリゴンが重なり合っているのが判ると思います。修正したいところですが、この岩山がゲーム内で表示されるのは一瞬なので気づく人は居ないだろうということで、こままにしておくことで時間節約。 そして、メインディッシュであるキャノンシードと、その前の地上砲台を設置し、カメラパスを作って完成。   9月24日(金) 04:25AM 敵の飛行パス完成 帰宅して夕食をとって午後10時、ここでようやっとゲームプレイ部分を作り始めることになります。敵の移動パターンもLightwave上で作っていきます。敵の飛行経路はワールド座標ではなく、ビュー空間で指定します。つまり、カメラをどんなに激しく動かしても、その動きが敵の飛行経路に影響を与えることはありません。と、書くと変に思えますが、実際に出来たものを見てみると特に大きな問題はないことが判ります。 ビュー空間で飛行経路を作るのにはいくつかの理由があります。第一にツール上で再生したときに実際にゲーム上で動かしているときと同じように見えるのでデザインや調整がしやすいのが一つ。次にカメラの移動に左右されないので使い回しが効くと言った利点があります。もちろん、カメラの移動経路とあまりにもかけ離れたものを作ると見た目が破綻してしまう事に注意する必要があります。また、建物の間を縫って飛ぶような経路を作りたい場合にはビュー空間ではなくワールド空間で作った方が良い場合もあります。 大事なのは短い時間で敵の飛行経路を繰り返し調整が簡単にできることがゲームのクオリティアップへつながるということです。 と、言うわけで幾つかの飛行パターンを作った後はゲーム上で再生するコードを書きます。これもシーンを再生させるコードの再利用で、再生中に撃破されるように変更を加えるだけで済みます。 9月24日(金) 07:42AM ゲームプレイ基礎部分が完成 さて、敵の動きができたので、次は実際に撃ってみたくなります。オリジナルのゲームではゲーム画面上にある照準を移動させてボタンを押すとレーザーがでるというものでした。ですから、堅い敵が出てきたりしたときにはボタンを連打する必要がありました。今時ボタン連打もアレだし、ネットワークプレイに対応したときに大変そうだということで、ホーミングレーザー形式を試してみることにしました。 ホーミングレーザーは今まで何度か作ったことがあるし、XNA上でもWindows Phone 7のマルチタッチのテストする時にタッチした場所に沿って線を描くプログラムがあったので、そのコードを流用して3D用に修正を加えて使いました。 レーザーを撃って、敵が消えるまでできたので、次は爆発エフェクトです。ここまで来たら爆発エフェクトも作りましょう(徹夜でハイになってる)ということで、Lightwaveのパーティクル機能を使って爆発するシーンを作ります。ここでは100個のパーティクルをHyperVoxelsと呼ばれるボリュメトリックレンダリング機能を使ってそれっぽいものを作っていきます。 で、複数のフレームをレンダリングしたものを下図のようにまとめたスプライトシート(4.0用プロジェクトは英語版のみ)を作りました。 そして、パーティクルサンプル(4.0用プロジェクトは英語版のみ)を流用したものを使ってゲームの中に組み込みます。 これで、移動する敵、レーザー発射、撃墜、爆発エフェクトとゲームプレイの基本部分ができました。下のスクリーンショットを見てもだいぶゲームらしくなったのが判ると思います。   この段階で周りはすっかり明るくなってしまいました。 Game Buildingの発表会まであと8時間18分…… つづく

0

Game Building日誌 その6「4日目、ゲームシーン製作中」

9月22日(水) 10:30AM またまた仕事発生、5時間のロス そんな訳で、またまたやらなければいけない仕事が発生、午前中はGame Building作業はお休みとなってしまいました。 9月22日(水) 03:20PM 作業再開、60FPSの弊害 仕事を終わらせたので、Game Building作業再開。まずはロウンチシーンから作ります。といっても、ここは友人が作ってくれたシーンを再生するだけなので簡単に済むはずです。 と、思ってたりすると必ず発生するのが問題。このシーンを再生してみると、シーンのところどころでモデルがカクッとなったり、一瞬消えたりすることがありました。LightWave上で再生させると問題ないのですがゲーム内で再生するとこの問題が発生します。 実はこのシーン、戦闘機モデルはひとつではなく、複数あり、そのモデルを切り替えながらアニメーション再生をしています。そして今回の問題の原因はその切り替え方法にありました。例えばモデルAからモデルBに10フレーム目で切り替えたいときにはモデルAのスケールを0~9フレーム目まで1に設定し、10フレーム以降は0に設定します。そしてモデルBの方は逆に0~9フレームまで0、それ以降を1という風に設定するといった感じです。 この1フレームの間にスケール値を極端に変更するというのが原因でした。下図はスケール値が0から1に変更している部分を拡大したものです。この二つのキーフレームの間隔は1フレームなので30FPSで再生しているときには問題がありませんが、60FPSで再生すると間のフレームを補間してスケール値が0.5になってしまうので表示がおかしくなってしまいます。 ですから、キーフレームの補間方法をステップに変更することで修正することができます。また、問題を人の目で見てから修正するのでは無駄な時間が掛かってしまうので、プロセッサ内で1フレームで値が変わっていて、補間方法がステップになっていない場合は警告メッセージを表示するといったことをした方が良いでしょう。 と、言うのが正しい方法なのですが、今回は他の人が作ったシーンを把握して問題のキーフレームを探し出して修正という作業をしないといけないので面倒もとい時間が掛かりそうだなぁと考えたので別の方法を考えることにしました。今回の問題は 「見せたいシーンの中に見せたくない問題が発生」 だったので、見せたくないというのを基点に逆の発想にして 「見せたくない問題が発生するんだったら、問題が発生している場所を見せなければ良い」 と、考えました。幸い、友人からもらったシーンでは母艦内部しか出てこないので、せっかくのカッコいい母艦も表示させたいなぁと思っていました。そこで、母艦内部のシーンと母艦を外から見たシーンのカメラを問題が起きるタイミングで切り替えるようにすることにしました。こうしておけば、見せたい母艦も見せることができ、見せたくない問題部分を隠すこともできる、そして時間の節約にもなると、一石三鳥です。 そんな訳で、母艦外部のカメラパスを設定し、 カメラパスの切り替えタイミングはカーブエディターを使って作りました。 カーブエディターが出力するXMLファイルはそのままプロジェクトに追加でき、読み込みもCurveオブジェクトとして読み込むことができるので、今回のGame Buildingでこのカメラの切り替えの他にも簡易パーティクルシステムで使いました。 9月22日(水) 08:07PM ワープシーンエフェクト完成 ワープシーンのエフェクトはLightWaveで上図のモデルを作ってテクスチャを貼り、UV座標をスクロールさせるシェーダを適用して作ることにしました。これぐらいのモデルだったらプログラムでもできますが、すぐにモデルを作ることができるのと、実際のゲームに近い環境で見た目の修正をリアルタイムできるツール上の方が微調整が効くのでモデリングする方法を選びました。 最初に試したものは下図のようなもので、ちょっと大人しい感じのワープシーンでした。 どうせワープしてるシーンでは他のモデルも出てこないんだから、半透明処理のモデルをもっと重ねてみようということで、元のモデルをコピーして半透明四枚重ねにした結果は下図のようになりました。 ここでも最初に作ったマテリアルバッチの効果がありました。別々のUV座標スクロールさせたいモデルにLightWave上で別々のマテリアルを割り当てておくことでプログラムの方で簡単に処理することができました。 9月22日(水) 10:00PM ワープシーン完成 このワープシーンには隕石がでてくるので、そのモデリングをしました。テクスチャはハイキングに行ったときに撮っておいた岩の写真を以前紹介した方法で加工して使いました。 ワープシーンエフェクトで既に前に進んでいる状態を表現しているので、ここではカメラは固定位置で隕石がカメラの前を通るパスを作るだけで終わりです。 9月23日(木) 12:00AM アステロイドベルトシーン完成 このシーンでは沢山の隕石が出てきますが、一つ一つの隕石が別々に動く必要はないのでモデラー上で隕石一つをコピーして二つにし一方を適当に回転、 出来た二つの隕石をコピーし…というのを6回繰り返して64個の隕石群をひとつのモデルとしてシーンエディターで以下のように配置し、ゆっくりとした移動と回転をさせるとそれっぽいシーンができあがります。 後はDeath Ball(宇宙機雷)を適当に配置し、カメラパスを作って完成です。 9月23日(木) 03:00AM 戦艦シーン完成 このシーンは戦艦が二隻出てきて、その至近距離をすれ違うように飛行するという経路なんで簡単そうなシーンだと思っていました。ですが、オリジナルの動画を見ながら作ってみると二番目の戦艦に接近したときの背景に見える星と戦艦の位置関係を正しくすると、一隻目の戦艦に近づくときに二隻目の戦艦が視界に入ってしまうという問題がありました。 そこで、一隻目の戦艦に近づくにつれ二隻目の戦艦が所定位置に見えないところで定位置にスタンバってくれるようにアニメーションさせるようにしました。 9月23日(木) 04:00AM 空母シーン完成? さて、空母シーンを作るわけですが、既に午前4時を過ぎているので眠い目をこすりながら作ってみるもののカメラパスがかなり怪しい挙動になってしまいました。修正したいところですが、こう頭が回らなくては修正作業もままならないので今日は寝ることにしました。   そんな訳で、今日一日は各シーンの生成に費やしたのでコーディングはお休みの一日でした。 Game Building発表まであと2日………

0

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