プロフィール

Na-7

Author:Na-7
SE(システムエンジニア)として約15年間システム系ソフト会社を勤めあげ、2008年3月退社。現在、ゲーム制作会社設立を目指して活動中。


アクセスカウンター


最新記事


最新コメント


最新トラックバック


月別アーカイブ


カテゴリ


DATE: CATEGORY:スポンサー広告
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
ビルボード07
ビルボードを実装した画面
板ポリゴンが常にカメラを向くようになった。カメラ映りは良くなったが、ユニットの向きが変わってしまうという不都合が発生した。



◎ビルボード用メソッド

前々回のコメントで、HOSSIEさんとyohさんからXNAのビルボード用メソッドを教えて頂きました。

Matrix.CreateBillboard:球面のビルボード
Matrix.CreateConstrainedBillboard :円柱状のビルボード

XNAヘルプの中の「オブジェクトの位置とカメラの位置が近すぎると、行列は正確でなくなります。」という記述が気になりました。そういうものなんですかね?

とりあえず、この便利そうなメソッドを使ってみましょう。



◎やってみよう!

まずは適当にやってみました。

Matrix world = Matrix.CreateScale(10.0f)
  * Matrix.CreateBillboard(pos, mainMap.MapViewPos, Vector3.Up, null)
  * Matrix.CreateTranslation(pos);


ビルボード02

兵士が逆さまですね。板ポリゴンモデルの最初の向きが悪いのかなぁ?

メタセコイアで板ポリの向きを調整します。ええと、Y軸で180度反転させて、X軸で45度…メタセコイアだと、斜め上奥を向いた感じ?

ビルボード03   ビルボード04

おっ!出来たかな?
…いや、常にカメラを向いてくれますが、カメラを地形の端の方に移動すると、モデルの上方向が傾いて横に倒れてしまいますね(右図)。

前々回とちょっと似てるなぁ…「カメラ上方向」の指定がおかしいのかな?或いは球面のビルボードメソッドを使用したのが悪いのか?



◎円柱状のビルボード

円柱状のビルボードメソッドを使用し、メタセコイアでモデルを真上に立てて、奥に向けました。カメラを360度回転させると、モデルが逆光になる角度があったので、BasicEffectのデフォルトライトは切りました。

Matrix world = Matrix.CreateScale(10.0f)
  * Matrix.CreateConstrainedBillboard(pos, mainMap.MapViewPos, Vector3.Up, null, null)
  * Matrix.CreateTranslation(pos);


2009/10/01追記:最下行の座標指定は余計でした

ビルボード05   ビルボード06

今回は、今までの中で一番いいですね。ビルボードのプログラムとしては、成功したのかな?
この画像だといまいち向きがわかりにくいので、板を一色に変えて確認しました。

ビルボード青板

カメラをいろいろ動かしてみましたが、問題ありません。ビルボードプログラミング成功です。



◎近くのオブジェクト

カメラをオブジェクトに近付けていくと、ある地点から急激に回転したり、パッと消えたりします。ははぁ…これがXNAヘルプの「行列は正確でなくなります」というやつかな?

これを対処するために、Matrix.CreateConstrainedBillboardのオプションを指定しました。

カメラの前方ベクトル:注視点 - カメラ位置
オブジェクトの前方ベクトル:カメラ位置 - オブジェクト位置

ところが、オプションに上記の値や固定値などを入れても、現象が変化しません。何か勘違いしてますかね?

参考までにビルボード公式サンプル内を検索してみましたが、Matrixのビルボードメソッドを使用してません。参考にならないなぁ。

まぁ、いざとなったらカメラ位置を制限するという手もあるので、この問題はとりあえず保留とします。



◎ユニットの向きの問題

ビルボードを実装して改めて感じたのは、ユニットがどこを向いているのか分からなくなる、ということです。一応予想はしてましたが、やっぱりそうなるのか…。
このゲームではユニットの向きが重要なので、この問題は何とかしないといけません。

1つ考えたのは、ユニットの向きとポリゴンの角度によって、絵を切り替えるという手法です。この手法ならユニットの向きを表現できますが、カメラの移動中に突然ユニットの絵が切り替わるので、見た目に違和感がありそうです。

違和感を緩和するには、絵のパターン数を増やすことです。例えば、兵士が1度ずつ回転した画像を360枚用意すれば、かなり自然な感じになりそうです。しかし、その調子でアニメパターンを用意したら、画像枚数が膨大になってしまうので、そこまでは出来ません。とりあえず、8方向で試してみましょう。



◎次回予告

ビルボードは実装できましたが、ユニットの向きは何とかしないといけないですね~。

というわけで、次回はその対処を試みます。

スポンサーサイト

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
複数マップ画像05
開発中のメインマップ画面
マップ解像度を数倍大きくしたので、カメラをアップにしてもある程度耐えられるようになった。



◎マップの分割

これまで使用していたマップ画像は、1600×900×1枚でした。これだとマップが狭いし、カメラをズームアップすると画像が粗く見栄えが悪いので、マップ解像度を拡大します。

3D地形モデルは、512×512のパターンテクスチャが縦横それぞれ253枚分(総数64009枚分)で出来ています。つまり、129536×129536ピクセルです。これを巨大な1枚画像として扱うことが可能であれば、話はカンタンです。

しかし、XNAは最大8000×8000までしか扱えませんし、私のPCはハード制限で4000×4000までしか扱えません。そこで、画像や板ポリゴンを複数に分割し、プログラムで1枚に連結します。



◎複数マップ画像の取得

最も繊細な画像を取得しようと思ったら、6万枚以上の画像ファイルを出力することになります。実際そこまではやりませんが、大量出力をこの先何度か行うことになるでしょう。できることなら、この作業は完全自動化したいものです。

しかしXNAには、表示中の画面を自動的に画像ファイルに落とす機能がありません。
(この機能すごく欲しいです…誰か作って~!)

仕方が無いので、キーを押すと地形の一部を次々表示するプログラムを用意し、FRAPSでスクリーンショットを撮ることにしました。

これでかなり省力化できましたが、それでも256枚とか取得するのは面倒なので、今回は16枚(4枚×4枚)の画像を取得しました。いずれ地形を綺麗に作り直してから、再度取り直す予定です。



◎複数マップ画像を並べる

計16枚の板ポリゴンを用意し、1枚の板ポリゴンに見えるように並べました。

複数マップ画像01   複数マップ画像02

カメラをズームアップした際の画像が細かくなりました。
しかし、板ポリゴン間の境界線が目立ちますね。これは何とかしないといけません。

カメラを手前に引くと、30fpsにまで低下しました(右図)。
えっ?たかが板ポリゴン16枚で30fpsってマジですか?(汗)



◎境界線の謎

1枚の板ポリゴンを拡大して、よく見てみましょう。

板ポリゴンの左端約1ラインに右端の模様

上図のように、板ポリゴンの左端約1ラインに、右端の模様が表示されます。

3D地形モデル作成時も似たような現象が発生しました。この時は小数点演算の誤差かと思い、サンプラステートのアドレスモードをミラーモードに設定して回避した…ような気がします。

しかし今回はシンプルな板ポリゴンにテクスチャを1枚貼るだけです。同じ手は使えないので、原因を探りましょう。



◎パフォーマンス向上?

最初は拡大縮小比率の問題かと思いましたが、等倍でも現象再現しました。しかしテクスチャ解像度を900×900としたら、現象再現しませんでした。

テクスチャの縦横比とテクスチャ貼付面の縦横比が異なると、この現象が発生するのかもしれません。画像1枚あたり1600×900で取得していたので、1000×1000で再度取得しました。

複数マップ画像03   複数マップ画像04

あれ?境界線が消えませんね?

その代わり、パフォーマンスが上がって、テスト飛行が快適になりました。それはそれで疑問だなぁ…。



◎遅延原因

ここで原因が1つ判明しました。ハードエラー対策として、板ポリゴンモデルの
Resize Textures to Power of Two
をTrueに設定していたため、テクスチャ解像度が自動調整されてました。

1600×900が遅かった原因は、多分コレでしょう。便利な機能ですが、パフォーマンスに影響する可能性があるようなので、今後はなるべく使わないようにします。

これをFalseに設定し、画像を1024×1024で三たび取得しました。でも、境界線は消えないなぁ…。



◎境界線の原因

さらに、ちょっとビックリな事実が判明しました。

FRAPSのスクリーンショットで取得した画像(1024×1024)を、WindowsXP付属ペイントツールで開きます。そのまま上書きコピーしてペイントを終了し、再度ペイントを起動して先の画像を開くと…左端に境界線が出現します!

MainMap004

なんだそりゃ~??

プログラムとかXNAの問題じゃなくて、FRAPSのBMP形式とMS社のBMP形式が微妙にズレてるようです。どうせなら、ペイントで最初に開いた段階でズレてくれた方が早く気付けたのに…。



◎境界線の解消

FRAPSのスクリーンショット画像を、一旦GIMPで開いて保存すると、この問題を回避できました(以後、ペイントやXNAで不具合が発生しなくなります)。

複数マップ画像05   複数マップ画像06

やっと境界線が解消できました!
早くて繊細でいい感じです!

(現在のマップ解像度:4000×4000)



◎次回予告

まさかFRAPSとMS社のフォーマット相性問題とは思いませんでした。落とし穴は意外なところにあるものですね。

地形がアップに耐えられるようになり、ヒントも頂いたので、次回はビルボードに再チャレンジします!

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
不完全ビルボード
ビルボード模索中の画面
カメラの角度に応じてモデルの角度も変わるが、よく見ると左右のモデルの角度がおかしい。



◎ビルボードの検証

こちらの記事によると、ビルボードを実装するには、ビュー行列の逆行列を使うらしいです。

XNAのヘルプによると、Matrix.Invertメソッドで逆行列を計算できるので、その結果を槍兵モデルのviewにセットすると、場所も向きも滅茶苦茶に(爆)

「使うのは3x3の部分だけです」というのが関係しているようですが、view行列の中身は全く理解してないので、いまいちピンときません。コード例はDirectXですが、とりあえずXNAで真似てみましょう。

// ビューの逆行列を算出する
Matrix view2 = Matrix.Invert(view);
world.M11 = view2.M11;
world.M21 = view2.M12;
world.M31 = view2.M13;
world.M12 = view2.M21;
world.M22 = view2.M22;
world.M32 = view2.M23;
world.M13 = view2.M31;
world.M23 = view2.M32;
world.M33 = view2.M33;


ビルボード01

場所は良さそうですが、スケールが豆粒のように小さくなってしまいました。スケールの値を変更しても大きさは変わりません。う~む…。



◎日本語版公式サンプル?

XNAのサンプルを探そうとしたら、ビルボードの公式サンプルを見付けました。いや、英語版は昔からあったのですが、日本語化されてる…?

今年7月からXNA CREATORS CLUB ONLINEの日本語公式サイトがスタートしたのは知ってましたが、最初に見た時は、日本語サンプルが無くてがっかりしました。いつの間にか、日本語サンプルが増えたようですね。

しかしサンプルをダウンロードすると、ソースは英語版のままでがっかり。紹介記事だけじゃなくて、コメントも日本語化してくれるとありがたいのですが…。

ちなみに、ビルボードの公式サンプルは、私のPCだとハードエラーになります。モデルを入れ替えれば動くでしょうが、どうせコメントは英語だと思うと、ちょっと気力が…(萎)

他のサンプルを探しましょう。



◎ビルさん?

こちらにビルボードのサンプルらしきものがありました。画像を一目見てニヤリ!w

しかしコードをざっと見ると、最初のDirectXの時とかなり違うようです。3x3以外を初期化してるし、逆ベクトルを2回かけてるようですが、なぜ2回?これが3x3の入れ替えに相当するのかなぁ?

…これは、ちゃんと基礎から勉強しないとダメってことですかね?とりあえず画面の様子を確認したいだけなので、どっかのコードをパクッて出来ると良かったのですが…。



◎スケールの修正

コードを眺めていたら、Matrixの掛け算は順序が影響することを思い出しました。もしかしたら、掛ける順番を変えればスケールが反映されるかも?

逆回転

とりあえず、スケールは直りました。カメラの角度と連動してモデルの角度が変わり、横から見ても平べったくなりません。

しかしカメラを左に向けたらモデルが右に回転し、カメラを右に向けたらモデルが左回転するので、モデルが寝転んでしまいます。回転が逆のようですね。



◎逆回転の修正

逆回転と言えば、ビルさんのサンプルで触れてましたね。そこでビルさんの最初のソースや最後のソースを真似てみると…逆回転は直りました。

しかしdAng1とdAng2が0のままだと、カメラに対してモデルが垂直になり、殆ど表示されません。そこで、dAng1=45とすると、表示はされましたが、位置がおかしくなりました。

空中に配置された兵士

静止画だとわかりにくいですが、空中に配置されています。dAng1で向きが変わるのはわかりますが、位置が影響されるのはおかしい気がするのですが…。

結局、ビルさんの最初のソースをベースに、ちょっと手直ししました。

float dAng1 = 45;
float dAng2 = 0;
Matrix mWang;

Matrix viewInvert = Matrix.Invert(view);
viewInvert.M14 = 0.0f;
viewInvert.M24 = 0.0f;
viewInvert.M34 = 0.0f;
viewInvert.M41 = 0.0f;
viewInvert.M42 = 0.0f;
viewInvert.M43 = 0.0f;
viewInvert.M44 = 1.0f;

mWang = Matrix.CreateRotationX(dAng1) * Matrix.CreateRotationY(dAng2);
Matrix world = Matrix.CreateScale(5.0f) * viewInvert * mWang * Matrix.CreateTranslation(pos);


スケールと位置はOKです。逆回転も直りました。
これで出来たかな?と思ったのですが、よく見ると左右のモデルの角度がカメラに平行ではありません(冒頭図参照)。

うーん、まだ不完全なようですね。



◎次回予告

ここ1週間ばかり、用事がいろいろ重なって時間が取れずにいましたが、どれも一段落したようなので次回から通常ペースに戻ります。

ビルボードはちゃんと理解しないとダメっぽいですね。カメラの向きを逆にするだけだから、パクるだけでいけるかと思っていたのですが、甘かったです。勉強し直して最後まで追及すべきか悩みどころですが、今はペースが掴めないので一旦保留とします。

次回は、マップ画像を複数化したり、ユニットの方向転換をスムーズにしたりする予定です。

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
カメラと同じ角度
開発中の画面
板ポリゴンに移行した状態。ビルボードまでは実装してないが、カメラ固定ならこれで十分かもしれない。



◎CGギャラリー終了

前回通知するのを忘れてましたが、冒頭の顔CGギャラリーは前回の諸葛亮で終了です。他の顔CGも準備出来てますが、それはゲームが出来てからのお楽しみということでw

今は鳳雛さんにイベントCGを描いてもらってます。こちらもブログで少しだけ紹介するつもりですのでお楽しみに!



◎拡大縮小時の位置ずれ

ラスタースクロールで拡大縮小すると、ユニットの表示位置がずれます。表示位置がずれるということは、ユニットをdrawする際のpositionがおかしい、ということです。しかしpositionの計算式を変更すると、地形スクロールと同期しなくなってしまいます。

:拡大縮小時の表示座標補正ミス?
 →表示座標は地形とユニット共通なので、
  地形とユニットがずれる理由にはならない

:画像の原点(origin)までの距離が拡大縮小に影響?
 →いろいろ試したが気にしなくて良さそう

:画面のアスペクト比の問題?
 →いろいろ試したが関係なさそう

:浮動小数点演算の誤差?
 →ずれの量が多すぎるので誤差とは思えない

:やっぱりユニット位置(position)の計算ミス?
 →Excelで計算式をシミュレートすると、XNAプログラムが
  おかしい様子。しかしXNAのプログラムを修正すると、
  拡大縮小だけでなくスクロールまでずれてしまう。
  もしかして、地形表示プログラムもおかしい?

結局地形表示プログラムの抽出元画像領域の計算もおかしかったようです。地形とユニットはちゃんと同期スクロールしてたのに、実は両方とも間違ってました(>_<)

両方修正して、拡大縮小すると…まだ少しずれます。
もう勘弁して~!(泣)



◎拡大縮小時の位置ずれ(決着編)

さらに悩まされましたが、結局の表示座標補正ミスでした。つまり、表示プログラムが3つとも間違ってたわけです(爆)

メインマップクラスのコード

Update()の中で、PキーとLキーをチェックして拡大縮小させています。

問題は、画面中央を中心に拡大縮小するよう表示開始座標(mapViewPos)を補正する計算式です。

表示開始位置 += 拡大前の中央座標 - 拡大後の中央座標

このようにして拡大後も中央を表示するよう補正しているのですが、たかが画面中央を算出するだけで、これほどややこしい計算式が必要とは思いませんでした。



◎残課題の進捗状況

位置ずれの問題が一段落した段階で、前回の残課題のうち3つが解決しました。

・拡大縮小すると、兵士の表示位置がずれる
 →前記表示座標補正プログラムの修正により解決

・描画範囲の右端が表示スケールによって変動する
 →前記地形表示プログラムの修正により解決

・特定の表示スケールにすると、
 画面中央に黒い横線が一本入る
 →浮動小数点演算の誤差による問題であった
 →地形表示プログラムの改善により解決



◎ラスタースクロールのちらつき

目の前の課題を一通りクリアすると、今度は縦スクロール時のちらつきが気になりだしました。

最初はモニタの水平帰線期間中に描き切れないのかと思いましたが、そうではなくて、画像拡大時に色の境界が微妙にぼやけるのが原因でした。色の組み合わせや拡大率によって、ちらつきが目立ったり目立たなかったりします。そういえば、昔の市販ゲームでちらつくのがあった気がするなぁ…。

これは多分高解像度のマップ画像を用意すると回避できますが、逆に言うと、画像の解像度より拡大した場合はちらつきを回避できません。

縦スクロール中はアンチエイリアスを解除し、スクロール終了時にアンチエイリアスを設定すると、回避できるかなぁ?

そんなことを考えていたら、yohさんからビルボードのご提案を頂きました。



◎ビルボードとは?

ビルボードとは、3Dの中に2Dを埋め込む方式で、球体のようにポリゴン数を必要とする物体を綺麗かつ高速に表示するための技法です。私はビルボードという用語を知らなかったのですが、こちらの記事で勉強させて頂きました。

既に2D化したのでこれ以上早くはなりませんが、座標計算はかなり楽になりそうです。地形も板ポリゴンで表示すれば、ラスタースクロールのちらつきを無くせそうです。



◎表示テスト

ビルボードを実装する前に、軽く表示してみましょう。メタセコイアで平面ポリゴンモデルを作成し、マップ画像を張り付けてXNAで表示します。

平面ポリゴンマップ

ちゃんと3Dっぽく見えますね。ラスタースクロールより拡大縮小が綺麗ですし、スクロールのちらつきも心配ありません。ついでにフォグも使えます。やっぱり板ポリゴン最強!(笑)


で、兵士も板ポリゴンで表示してみました。

カスタムコンテントマネージャ使用前

あら?バックの地形も兵士に変わってしまいました。同じ板ポリゴンをロードしたので、モデルインスタンスが複製されなかったようですね。ワールド座標は複製されたようですが、テクスチャはマテリアルだから共通なのか…。

というわけで、XNAViewerランタイム評価時に確立した手法でモデルインスタンスを複製しました。この手法はメモリを浪費するので、エフェクトのコピーを作成する方が効率的と思いますが…まぁ板ポリゴンだし、とりあえずいいか。

カスタムコンテントマネージャ使用後

無事表示できました。見た目は問題無さそうですね。



◎板ポリゴンの展開

表示テストはOKだったので、ラスタースクロールの簡易デモプログラムを板ポリゴンに置き換えました。

板ポリゴンに置き換え

単純に地形の上に置くだけだと、両端がかなり歪みますね。

とりあえず、カメラと同じ角度に立てて、アスペクト比率の設定を外してみました(冒頭図参照)。

カメラの向きが固定であれば、これで十分かもしれません。今回は静止画のみですが、拡大縮小やスクロールはラインスクロールよりも滑らかな感じです。プログラムもシンプルになったし、今後はこれでいきましょう!



◎次回予告

とりあえず板ポリゴンへの移行が完了しました。

ビルボードまで実装した場合、ユニットの向きがおかしく見えないか不安ですが、成功すればカメラの向きも変えられるようになるかもしれないので、ともかく試してみましょう。

というわけで、次回はビルボードの検証です。

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
諸葛亮
諸葛亮
蜀の軍政家。劉備に三顧の礼で迎えられ、天下三分の計を献策する。放浪中の劉備を助けて荊州と蜀を抑え、漢中王に祀り上げるが、関羽北上の失敗により荊州を失う。劉備没後にその志を継いで北伐を敢行するが、漢王朝再興は果たせなかった。演義後半の主人公。



◎正射影マップ画像の取得

ラスタースクロールに挑む前に、まず正射影マップ画像を取得したいのですが、XNAではどうやれば良いのでしょうか?

試しに、Projection行列の視野角を極端に小さく…1度や5度に設定したら、地面の1部が極端に拡大されました。

視野角5度

正射影は遠近感が無くなるそうですが…目的のイメージとは全く違います。ぐむむ。


…ちゃんと調べたら、正射影行列を作成するメソッドがMatrixにありました。
Matrix.CreateOrthographicOffCenter()

正射影マップ

おお、これです!目的の正射影マップ画像が取得できました!

別にわざわざラスタースクロールさせなくても、このままで十分な気もするなぁ…予想より綺麗だし、疑似3Dと相性が良いし、奥のユニットを選択しやすいというメリットもありますね。

でも、距離感はありませんし、奥側ユニットのサイズや移動速度も不自然になりそうです。やはりラスタースクロールが成功するに越したことはないか。



◎ラスタースクロール描画テスト

マップ画像は準備出来ましたが、これをラスタースクロールさせると、本当に3Dっぽく見えるのでしょうか?

まぁ、とりあえずやってみましょう…エイッ!

ラスタースクロールのサンプルコード

ラスタースクロール01

おお~!ちゃんと3Dに見えますね!

昔はマシン語必須で憧れの技法だったのですが、spriteBatch.Drawだけで実装できるとは…XNAやっぱ凄いかも(笑)



◎酔っぱらいスクロール

ここまで来れば、勝ったも同然!

…と勇んで簡易デモに組み込もうとしたのですが、やってみるとなかなか思い通りにいかず、結局丸1日かかってしまいました。落ち着いて考えれば、難しいプログラムじゃないはずなんですが(^_^;

で、実際に画面をスクロールさせてみると、横方向は綺麗にスクロールしますが、縦方向はどこか違和感を感じます。
アスペクト比の問題かもしれないと思い、縦横の拡大縮小率の調整を図りましたが、違和感を完全にぬぐい去ることはできませんでした。

滑らかなのに不自然なスクロールを見ていると…走行中の電車や車から至近距離を長時間見て、乗り物酔いしたような感じになります(ー_ー;

昔「ラスタースクロールは酔う」と聞いた気がしますが、これのこと?いゃでも、気分が悪くなる縦スクロールシューティングなんて無いよねぇ?しかし、3D系のモデリングやプログラミングをしていると、たまに違和感感じることもあるしなぁ…。

どうもよくわからないので、ユニットも同時にスクロールさせることにしました。一緒に流れる画面を見れば、はっきり判るかもしれないし、プログラミングの途中で何か気付くかも。



◎地形とユニットの同期スクロール

というわけで、地形スクロールに疑念を残したままユニットスクロールの実装に入りました。実際にやってみると、全然合わない…しかも単純なズレじゃなさそう。ヤなかんじ~!


結論から言うと、2日がかりでようやく同期するようになりました。同期がズレていた原因は、

:地形スクロールが間違っていた
:ユニットスクロールは地形と異なるプログラムが必要
:ユニット画像の原点を中央に合わせる必要がある

の修正中にの問題に気付いたため、の修正は後廻しとしたのですが、この順番は結果的に失敗でした。
の修正はspriteBatch.Drawの引数に指定するだけなので、先に直しておけば混乱要因を減らすことができたのですが…まぁ今となってはどうでもいいことですね。



◎拡大縮小機能の実装

マップ画像は現在1600×900×1枚を使用していますが、最大8000×8000の画像を使用したり、複数画像の組み合わせも(技術的に)可能です。現在のユニット画像は844×555なので、カメラをアップにしても十分耐えられるはずです。

但し、画像ファイルがデカいとネット配信が厳しくなりますし、カメラの角度を変えられないので、凝った演出は出来ないという欠点があります。マップとユニットの画像サイズは後日調整するとして、とりあえず拡大縮小機能を実装しましょう。


しかしいざ始めると、地形とユニットのスクロールがズレたり、画面左上を基準に画面が拡大縮小したりで予想外に大変でした。

ラスタースクロールで画面が歪んでいるので、画面中央を基準に拡大縮小させるだけで半日以上かかりました。実はまだちょっとズレます。頭がパンクしそうです(>_<)



◎簡易デモ

というわけで、以前の簡易デモにスクロールを実装しました。



いかがでしょう?
ユニット移動は前回と一緒ですが、画面がスクロールするとゲームっぽくなった気がしませんか?



◎今後の課題

作り始めたら、課題がいろいろ出てきました。

・拡大縮小すると、兵士の表示位置が微妙にずれる

・特定の倍率にすると、画面に黒い横線が一本入る

・描画範囲の右端が表示スケールによって変動する

・大きなマップ画像を取得する

・マップ画像の複数化対応

・ユニットの移動切り替えをスムーズにする
 →方向を切り替える際に、途中のコマを入れる



◎次回予告

ラスタースクロールの座標計算は予想以上にややこしいものでしたが、とりあえず形になって良かったです(^^)

ゲームの基本システムは、これでほぼ確定ですね。次回は「今後の課題」を順次対応していく予定です。

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
劉備
劉備
蜀の君主。宿敵曹操を漢中で破り、漢中王を名乗る。荊州と漢中の両面から曹操を圧迫するが、同盟国である呉の裏切りにより荊州と関羽を失う。劉備は激怒し関羽の弔い合戦を決行するが、夷陵にて大敗。後事を諸葛亮に託して崩御した。演義の主人公。



◎今回のお題

カメラの距離を一定と決めたので、メイン画面の選択肢が増えました。今後幾つかの方式を試していく予定です。今回は、3D画像を取り込んだ2D方式です。

2Dは3Dよりパフォーマンスが早いという利点がありますが、3Dのような存在感や迫力を表現することが難しいという欠点があります。この方式は両者の長所を併せ持つことを目指すものです。



◎ユニット画像の準備

3Dスキンアニメを2D画像に変換します。手順は既に確立済みです。

1.RokDeBone2の連番BMP出力機能でアニメ画像を出力

2.GIMPで背景色を黒に変換

3.「ドラッグ&ドロップ画像変換(フリーウェア)」で
  黒を透過色としてpngファイルに変換

枚数が多いと2の手作業が結構手間です。もし今回の方式を採用するに至った場合、2の手順は一括変換プログラムを作成しようかな。

…いやいや、最終的にはRokDeBone2じゃなくてSoftimageの連番画像出力を目指すべきでしたね(^^;

最終的には8方向の画像を用意したいのですが、今はテストなので1方向だけ用意し、プログラムで反転して2方向だけ表示します。向きを変えると右利きと左利きが変わってしまいますが…細かいツッコミは無しってことでw



◎コンポーネントの実装

連番2D画像を準備したので、アニメーションプログラムを実装します。2Dアニメのコードは作成済みですが、今回はコンポーネントとして実装し、複数ユニットを簡単に管理できるようにします。

…実を言うと、XNAのコンポーネントプログラミングの存在は最近知りました(爆)

こちらのサイトを参考に、2Dユニット管理コンポーネントを実装。特に難しいこともなく、コードが少しすっきりしました。



◎実行結果

3D地形モデルも2D画像に落とし、背景として実行しました。

3D画像取込方式01

おお!結構いい感じじゃないですか~!
静止画ですが、ちゃんとアニメーションします。ユニットと背景の違和感を懸念していたのですが、現段階では見た目の遜色を感じませんね。

ユニットは200体、位置はランダムです。1600×900のフルスクリーンモードで12~15fpsぐらいです。全体のユニット数よりも、手前に大きく表示する数の方がパフォーマンスに影響するようです。



◎パフォーマンスの改善

最終段階で15fpsならともかく、ユニットだけで15fpsは遅すぎるので、条件を変えてパフォーマンスの改善を試みます。

1600×900/FullScreen/200体/画像サイズ1.0:12~15fps
800×600/FullScreen/200体/画像サイズ1.0:15~18fps
800×600/FullScreen/200体/画像サイズ0.5:20~22fps
800×600/Windows/200体/画像サイズ0.5:20~22fps
800×600/Windows/100体/画像サイズ0.5:20~60fps

3D画像取込方式02

う~ん…最後の条件は数十回試した結果、バラツキが激しいことが判明しました。ユニットが重なって描き変える範囲が減ると、fpsが向上するのかもしれませんが、ちょっとイマイチですねぇ…。

試しに画像枚数を半分に減らしたら(40→20)、60fpsで安定しました。あれ?この画像枚数はアニメーションの細かさであって、速度には影響しないと思っていたのですが…まぁ速くなる分にはいいか(^_^;
ただ、このままだとモーションが倍速再生状態なので、再生速度も0.1ミリ秒から0.15ミリ秒としました。

3D画像取込方式03

画像枚数半減前と比べると、アニメが粗くなった分、再生速度を早めてごまかしたような感じです(笑)

この状態だと、200体で35~40fpsぐらいです。メイン画面に同時に表示される部隊数は通常30~50程度と思いますので、現段階におけるパフォーマンステストは合格ですね。画像枚数や再生速度は最終段階で再調整しましょう。



◎部隊ユニットの作成

ユニットを2D画像とした場合、1ユニットの人数を増やして部隊を表現してもパフォーマンスが低下しないという利点があります。これはすなわち「規模(兵数)」と「陣形」の絵画的表現を可能とし、このゲームに大きなメリットをもたらします。

それでは、部隊ユニットを作成し、簡単な移動デモを作りましょう。槍兵には移動用モーションが無いので、槍騎兵の画像を用意します。槍騎兵は複数のモーションがありますが、画像変換が面倒なのでとりあえず1種類2方向だけ(^_^;

さて、複数の槍騎兵の連続画像を取得したいのですが、RokDeBone2では出来ません。Softimageなら出来そうな気がしますが、槍騎兵モーションをSoftimageで作成するのはかなり手間なので、今回は使用しません。というわけで、XNAで複数モデルにモーション付けて、1コマずつハードコピーを取得します。

部隊ユニットの作成



◎移動デモ

簡単な移動デモを作成しましたのでご覧ください。



いかがでしょう?プログラムは2Dですが、3Dのような迫力があると思いませんか?

土煙りが巻き上がるエフェクトや、ドドドーッという地響きの効果音があるとさらに迫力が増すと思いますが、今回はそこまでやってません(笑)

部隊移動の際、方向が変わる時の切り替えが不自然です。これを自然に見せようとしたら、部隊ユニット方式をやめて1体ずつ動かさねばなりません。できればそこまでやりたいのですが、残念ながらパフォーマンス不足なので諦めます。

ラストの「大軍」は、ちょっとやりすぎましたかね…。XNAでは私のPCでもまともに動くんですが、録画が追い付かないようです。雰囲気だけでも感じてください(^_^;



◎地形画像の縦スクロールについて

今回の画面を見て「地形はどうするんだ?」と思った人がいるかもしれません。今回のように奥行き感のある地形画像の場合、縦方向のスクロールは画像を縦方向に移動させただけではダメです。

ではどうするかと言うと、ラスタースクロールとかラインスクロールと呼ばれる手法(若しくは、それに似た手法)で奥行き感を出そう、と考えています。
極端な話、縦1ライン毎に伸縮率を変更し、奥(画面上方)の方は画像を縮小して表示する、というものです。

正射影で用意した画像の奥側を縮小すれば、今の状態に近い画像になるのではないかという期待をこめた案ですが、正直やってみないとわかりません(ー_ー;

…まぁ、ダメだったら正射影方式ってことで(爆)



◎次回予告

開発当初からパフォーマンスを気にしていた最大の理由は「大量に出したかったから」です。今回のデモ動画で、私がこだわっていた理由を何となく感じて頂けたら嬉しいです(^^)

今回の方式は、ビジュアル/パフォーマンス/製作コストのいずれも合格です。メイン画面のアニメモデルに関しては、この方式で確定しても良さそうな気がしますが、何か見落としは無いかなぁ?


…開発が一気に進んだような気がしますが、気のせいじゃないよね?(^_^;
次回は、正射影やラスタスクロールについて調査します。

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
曹操
曹操
魏の君主。大国魏の基礎を作ったが、天下統一を目前に赤壁で大敗した。関羽北上の際はその勢いを恐れて遷都を建議するが、司馬懿・蒋済の提案を採用して呉と同盟を結び、関羽を撃退した。



◎8月の目標達成度

・活動時間月150時間以上

実績:150h(達成率:100%)


・ライブラリ選定(30h)

実績:65hで複製モデル制御、性能評価等実施(達成率:70%)


・地形モデル描画(40h)
・マップオブジェクトモデル描画(30h)
・マップデータ調整(6h)
・シナリオ概要作成(6h)

実績:未着手(達成率:0%)


・ブログ更新/HP更新(38h)

実績:77hで「Softimage付属ランタイムをXNAに組み込みスキンアニメする」と「XNAのアニメーションライブラリを比較検証する」を作成(達成率:100%)



◎作業時間分析

作業時間集計2009年8月(PDF形式)

○良かった点
・後半は休み無しで追い上げ
・1日も休まず走った(活動じゃないけど(^^;)

○悪かった点
・前半は暑くてダレ気味
・ブログやHPの比率が50%に達している


今回はHPのボリュームが大きく、更新も何度か行ったので、HP時間は仕方無いと思います。でもブログ時間が毎回多いのは悩みのタネです。30%以下にしたいなぁ…。

ブログ時間には、次の作業の検討や試行錯誤中の記録なども含まれます。試行錯誤中の記録をやめて、成果のみ記述すれば時間を短縮できますが、(それはHPでやってるので)このブログの存在意義が無くなります(爆)

とりあえず9月一杯様子を見て、また30%を上回るようであれば対策を考えます。


ジョギングはすっかり定着しました。それにしても、二か月間雨休みすら無いってのはスゴイなぁ。雨が降る時はドバーって降って、すぐ止みます。



◎ライブラリ選定の誤算

作業時間の内訳は以下の通りです。

ワールド座標指定:6h
複製モデルの個別制御:45h
ライブラリの比較検証:7h
FBX渡しの模索:7h

個別制御に多大な時間を要したわけですが、8月の目標を立てた時点では、この問題は未認識でした。しかしこれは避けられない問題なので、そのまま打開できるまで粘りました。これが目標と実績が大きくずれた最大の原因です。

45hもかかった理由:
・スキル不足
・より効率的な方式を追求したため

成果:
・スキル向上
・Softimage個別制御方式を2通り確立
・ACLでの個別制御方式確立

時間はかかりましたが、個別制御の目的は達成できたので「よく頑張った」と自分で自分を一言褒めてやります。

しかし、性能テストの結果はガッカリです。今のままじゃ遅くて使い物になりません。



◎パフォーマンスとズームアップ

モデルの複製&個別制御が出来るようになったので、(地形も含めて)私がこのゲームに必要と考えていた機能は一通り出来るようになりました。CGデザインは最初から他人任せの予定なので、あとはパフォーマンス(速度)だけなんですが…想像以上に厳しい世界ですね。

私が地形モデルやスキンアニメに何か月もこだわっていたのは、「メイン画面をアップで表示したいから」です。これができれば様々な演出が可能となり、プレイヤーをゲームに引き込みやすくなります。しかし計測テストで示されたスタートラインは予想を遥かに下回ってました。

○メイン画面で表示するモデル
・地形モデル
・天球モデル
・静止モデル:100体以上
・アニメモデル:100体以上(できれば何百も)

あのスタートラインから、上記全てを内臓グラボで30fps以上で描画するのは、今の私には無理です。勉強してスキルを上げるにしても「いつになったら出来るんだ!」ってカンジです。

「三国志11」や「信長の野望 革新」で、3Dなのにズームアップしない理由がよくわかりました(-_-;

というわけで、メイン画面をアップで表示するのは諦めます。メイン画面はスキンモデルを使用しません。地形もパターンテクスチャにこだわりません。

ここまでやってきて残念ですし、未練もありますが、現実を受け入れた上で先を考えねばなりません。



◎今後の方針

スキンモデルは一騎討ちや演出のみの使用となります。一騎討ちは基本2体だけですし、演出シーンはいざとなったらビデオにしてしまえば、パフォーマンスの心配は殆どありません。製作の順番は後回しなので、スキンモデルの調査や性能検証は一旦凍結します。


問題はメイン画面ですが…戦略シミュレーションゲームにありがちな‘上空から見下ろした視点’とし、地上とカメラの距離を一定に保ちます。これならスキンなしの簡易モデルでも問題ありません。

でも待てよ?この条件なら選択肢がいろいろありますね。
2D(疑似3D)でもいいし、2D(3D画像取込)という手もあります。

BBSanimation

コレ↑は、3Dモデルを取り込んで2Dアニメ画像にした例です。カメラの距離が一定ならこの方が負荷が低いし、簡易モデルを作るコストも不要です。でも実際に3Dモデル地形に乗せたら、違和感があるかも…いっそのこと、地形も同じ方式にするとか?
3Dモデルを動かさずに置くだけって手もあるなぁ…。

頭の中で考えただけじゃ結論出そうもありませんね。実際に試しながら、見た目とパフォーマンスと開発コストのバランスを考えて決めましょう。



◎進捗状況チェック

メイン画面の構想が崩れたので、スケジュールは一時凍結します。メイン画面の仕様を決定してから、スケジュールを見直します。



◎9月の目標

・活動時間月160時間以上

・メイン画面の模索(70h)

・全体スケジュールの見直し(12h)

・契約手続き関連(8h)

・その他(10h)

・ブログ更新/HP更新(60h)

メイン画面の模索中に作ったものの1つが、そのままプロトタイプに繋がるといいなぁw



◎次回予告

とりあえず、2D(3D画像取込)あたりから試してみましょう。
地形はどんな感じになりますかね?

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

| BLOG TOP |
DATE: CATEGORY:Softimage Mod Tool
孫権
孫権
呉の君主。赤壁で曹操を撃退した後、劉備と荊州の領有権で争った。荊州を半分に割譲することで同盟関係は一旦回復したが、関羽北上の隙をついて荊州を奪い、関羽を捕えて処刑した。後に呉の初代皇帝となった。



◎サンプルプロジェクトを動かす

こちらのサンプルプロジェクトをダウンロードして実行すると、エラーになります。XSIXNARuntimeを自分で追加しないと動作しません。

プログラムはXNA2.0用なので、まずXNA3.0用に変換し、既存のXSIXNARuntimeプロジェクトを同フォルダにコピーし、プロジェクトに追加します。そしてGuitarMateyプロジェクトとContentの参照にXWImporterとXSIXNARuntimeを追加します。

XWImporter:
C:\Softimage\Softimage_Mod_Tool_7.5\Addons\XNAGSE\Application\References\XNA 3.0\Softimage.XWImporter.dll

XSIXNARuntime:
追加したXSIXNARuntimeプロジェクト\bin\x86\Debug\XSIXNARuntime.dll

すると「テクスチャが見つからない」とエラーになりました。そういえば、Softimageモデルのテクスチャは絶対パスで格納されてました。仕方がないので、パス指定を置換します。

…とまあ、意外に面倒な手順を踏んで、ようやく動きました。

GuitarMatey

ボタンを押しながらレバーを押すと、海賊モデルがモーション付きで上下に動きます。236MBでこれだけ?という気もしますが、まぁ殆ど音楽データなので仕方ないですね。ちなみにXNA3.0から音楽データも圧縮できるようになりました。



◎ワールド座標指定方法

それでは、ワールド座標指定方法から解析しましょう。

このプログラムではPirateクラスが、XNAViewerのModelAssetクラスに相当します。そして_worldMatrixや_positionなどにワールド座標が格納され、Update()内のCalculateWorld()メソッドでワールド座標を算出しています。

注目したのはCalculateWorld()メソッド内のこの行です。
_model.Root.Transform = _worldMatrix;
_modelはModelクラスです。つまりModel.Root.Transformにワールド座標をセットしています。ワールド座標はここにセットすべきだったのですね。



◎モデルの管理方式

このサンプルは、同じ形で色違いの5つのPirateモデルファイルを用意しています(アセット名が異なるため、content.Loadは毎回新しいコピーを作成します)。

Pirate_Blue.xsi
Pirate_Green.xsi
Pirate_Orange.xsi
Pirate_Red.xsi
Pirate_Yellow.xsi

残念ながら、同一モデルインスタンス個別制御の参考にはなりませんね。このテーマに関しては、別のサンプルを探した方が良さそうです。



◎自作プログラム修正

解析で得たノウハウを自作プログラムに適用しました。主な修正点は以下の通りです。

・ワールド座標指定方法を変更
・シェーダー(.fx)を未修正状態に戻す
・Updateの内容をModelAssetクラスに移行

ワールド座標指定方法変更後

ううむ…全然早くなってません(修正前は20fps)。
Updateが変わったので、少しは早くなるかと期待したのですが、ちょっとガッカリ(ー_ー;



◎次回予告

とりあえず月が変わったので、次回は「8月の総括と9月の目標」です。

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

| BLOG TOP |

copyright © ゲーム制作の舞台裏 all rights reserved.Powered by FC2ブログ
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。