メタセコイア・パイプライン 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

XNA Game Studio 4.0 Refreshに更新しよう

XNA Game Studio 4.0 Refreshに更新しよう 去年の10月にXNA Game Studio 4.0 Refreshが公開されました。これは、Windows Phone SDK 7.1の中に含まれる形でリリースされ、内容もWindows Phone 7.1の新機能追加が主だったので私もツイッターの方でつぶやく程度で済ませてました。 ですが、Windows Phone向けの新機能以外にもVisual Basic対応やバグフィクスが含まれているので、WindowsやXbox 360で開発している人でも更新する価値は十分にあると思うのでここでも紹介します。 まず、新機能としてVisual Basicに正式に対応したこと、これはWindows Phoneはもちろん、Xbox 360やWindowsでもXNA Game StudioをVisual Basicを使って開発できるようになりました。 そして、バグフィクスの中で比較的重要だと思われるのが「固定更新時、速いPCやフレーム内の処理量が少ない時に更新時間計算の誤差が大きくなり、見かけのフレームレートが下がってしまう」という問題が修正されていることです。 また、Refreshという名前の通り、既存APIからの変更は無くバイナリ互換となっているので3.1から4.0へ更新の時とは違って既存のプロジェクトやコードはそのままコンパイル、実行することができるので現在4.0で開発中の人でも安心して更新することができます。   XNA Game Studio 4.0 Refreshへ更新する 幾つかのケースがあると思うので、それぞれのケースでXNA Game Studio 4.0 Refreshをインストールする方法を紹介します。   Windows Phone SDK 7.1をインストールしている なにもする必要はありません。前述のようにXNA Game Studio 4.0 RefreshはWindows Phone SDK 7.1に含まれています。 Windows Phone Developer…

0

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

パーティクルシステムなどで動的に頂点データを変更する場合、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

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

以前、カスタム・コンテント・プロセッサーを使って日本語表示する方法を紹介しました。 XBLIGやWindows Phone 7に配信することを考えてゲームを作る場合、カスタム・コンテント・プロセッサーを作ることが殆どなので、この方法でも問題無いのですが、初めてXNAをさわり始めた人や、ちょっとしたサンプルを作るときに 「ようこそ、XNAの世界へ♪」 と、いった一文を表示するだけのプログラムなのに、カスタム・コンテント・プロセッサーを使うのは初心者には難易度が高いし、プロジェクトが複雑になってしまいます。 そこで今回はカスタム・コンテント・プロセッサーを使わずに日本語表示をする方法を紹介します。 CharacterRegionsを手動で変更する XNAで文字を表示する場合、プロジェクトにSpritefontファイルを追加しますが、このSpritefontファイルには使用するフォントの種類やサイズ、そしてテクスチャへ変換する文字を指定できるようになっています。この文字の指定はファイルの最後の方にあるCharacterRegionsエレメントで行います。Spritefontを追加した場合、あらかじめ英数字のコードが指定されています。 <CharacterRegions> <CharacterRegion> <Start>&#32;</Start> <End>&#126;</End> </CharacterRegion> </CharacterRegions> この中のStartとEndエレメントに使用する文字の開始と終了文字コードをユニコードで指定されています。 CharacterRegions内にはCharacterRegionエレメントを複数宣言できるので、ひらがなを表示したい場合、ひらがなのユニコードはこうなっているので、以下の様なCharacterRegionを追加します。「&#x番号;」と言うのはXMLファイル内で16進数を指定する方法です。 <!– ひらがな –> <CharacterRegion> <Start>&#x3041;</Start> <End>&#x3096;</End> </CharacterRegion> カタカナや全角英数字なども同様にして追加することができます。以下はそれぞれのユニコード表PDFへのリンクです。 ひらがな: http://www.unicode.org/charts/PDF/U3040.pdf カタカナ: http://www.unicode.org/charts/PDF/U30A0.pdf 全角英数: http://unicode.org/charts/PDF/UFF00.pdf 全角記号(全角スペースや句読点など): http://www.unicode.org/charts/PDF/U3000.pdf この方法でひらがなやカタカナといった、あらかじめ文字コード領域がハッキリしているものを追加することができます。 では、漢字の場合はどうでしょう?ユニコードではCJK、つまり中国語、日本語、そして韓国語の文字が混合して定義されているので、ひらがなと同じように指定することはできないし、コード表から一文字毎にコードを探し出すのは現実的ではありません。 実はSpritefontファイルには直接文字を指定することができます。例えば「日本語」という文字を表示したい場合、以下のようにして表示したい文字を追加することができます。 <CharacterRegions> <CharacterRegion><Start>日</Start><End>日</End></CharacterRegion> <CharacterRegion><Start>本</Start><End>本</End></CharacterRegion> <CharacterRegion><Start>語</Start><End>語</End></CharacterRegion> </CharacterRegions> この方法を使うことによって、カスタム・プロセッサーを書かずに日本語を表示することができます。   やっぱり面倒 確かに、上記の方法でも文字数が少なければ手動で良いのですが、やはり一文字づつコードを指定するのは面倒です。 そこで、今回は入力した文字列から使用している文字を抜き出してCharacterRegions宣言部分を生成するツール、ChracterRegionジェネレーターを作ってみました。 実行ファイル: http://higeneko.net/hinikeni/tool/CharacterRegionGenerator-bin.zip ソースファイル: http://higeneko.net/hinikeni/tool/CharacterRegionGenerator-src.zip このツールはWPF 4.0を使って作られています。XNA Game Studio 4.0をインストール時に.Net…

1

動的頂点バッファの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