プロフィール

Na-7

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


アクセスカウンター


最新記事


最新コメント


最新トラックバック


月別アーカイブ


カテゴリ


DATE: CATEGORY:スポンサー広告
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
山岳地帯の索敵範囲の表示問題08
開発中のメイン画面
山の反対側の索敵範囲が表示されない問題が解消された。いかなるテクが使われたのか?



◎シャドウボリューム

前回保留にした

『地形モデル(平面モデル)のうち、球モデルの内側全域のステンシルバッファをオンにする』

に関して、yohさんから「シャドウボリュームという技術の応用で何とかならないでしょうか。」とヒントを頂きました。
yohさん、いつもありがとうございます!^^

シャドウボリュームがどんなものか調べると、こちらにとてもわかりやすい説明がありました。
…なるほど、これは使えるかも!

しかしこちらの記事を読むと…あれ?記事内の‘ステンシルシャドウボリューム’と、前述の‘シャドウボリューム’は、同じ技法なの??

…ああ、同じ技法ですね。前述の記事は表面と裏面の描き分けまで説明してますが、後述の記事は細かい説明を省いているので、別物の印象を受けてしまいました(^^;



◎サンプル作成

本来のシャドウボリューム技法は

『3Dオブジェクトの輪郭となる頂点を光源方向に引き延ばして「シャドウボリューム」(影領域)を生成』

する所から始めるそうですが、今回はシャドウボリュームを固定化して負荷を軽減します。

というわけで、まず2種類の八角柱モデルを作成します。

八角柱の表面モデル   八角柱の裏面モデル

側面表側8面+上面のモデル(上左図)と、側面裏側8面のモデル(上右図)を作成しました。続いてサンプルプロジェクトを作成します

シャドウボリュームサンプルの表面モデル描画テスト   シャドウボリュームサンプルの裏面モデル描画テスト

左上図が表面モデル、右上図が裏面モデルの描画テストです。これを
表面モデルをStencilOperation.IncrementSaturation、
裏面モデルをStencilOperation.DecrementSaturationで
ステンシル領域に描画します。

シャドウボリュームサンプルの描画テスト

八角形になりました。地形が平面モデルなのでわかりにくいかもしれませんが、成功です。



◎実装

サンプルコードをメインプログラムに実装します。まずは深度バッファを無効で試してみましょう。

シャドウボリューム実装01

八角形の索敵範囲が描画されました。シャドウボリュームのコードは正常に実装されたようですね。

では、山の反対側の索敵範囲が表示されないようにするために、深度バッファを有効にします。

シャドウボリューム実装02

山の反対側の索敵範囲が表示されなくなりましたが、地形モデルの起伏と八角柱モデルの接合部分だけが明るく表示されました。

これでは前回の方式と同じです。ガーン!!

何故内側が塗り潰されないのか、こちらの記事を確認すると

『フレームバッファやZバッファには何も操作しません。』

…肝心な記述を見落としてました(泣)



◎ちょっと待てよ?

深度バッファ操作(書込)禁止の記述はありますが、参照禁止の記述はありません。よく考えたら、深度バッファを参照し、書込のみ禁止すれば良いのでは?

GraphicsDevice.RenderState.DepthBufferEnable = true;
GraphicsDevice.RenderState.DepthBufferWriteEnable = false;


山岳地帯の索敵範囲の表示問題06

おお!山の反対側の索敵範囲が表示されなくなりました!
これで山岳地帯の表示もバッチリです!

ということは、前回方式と今回方式どちらでもOKということです。前回方式の方がステンシルへの書き込みが1回で済むので、前回方式に戻しましょう。

山岳地帯の索敵範囲の表示問題07

ふむぅ…。前回方式は、索敵範囲の円系が若干潰れるというか、球状になりますね。球モデルだから当然ですが^^;
今回方式の方が歪みが少なくて綺麗な気がしますが、この程度なら速度優先でやはり前回方式がいいかな?



というわけで、結果的には前回方式にDepthBufferWriteEnableを追加しただけで解決しました。

でも今回はいい勉強になりましたよ!^^



◎次回予告

山岳地帯の問題が解消出来たので、心置きなく新年を迎えることができます。

次回は「12月の総括と1月の目標」です。


yohさん、ブログ読者の皆さん、一年間ありがとうございました!

皆さんもよいお年をお迎えください^^

スポンサーサイト

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
山岳地帯の索敵範囲の表示問題05
開発中のメイン画面
索敵範囲が円形で表示され、色や深度の問題なども解消された。山岳地帯の表示に関してはまだ課題があるらしい。



◎深度バッファの有効無効

ユニットが森の手前に描画される問題について調査を進めると、以下のことがわかってきました。

『ある処理(索敵範囲内のステンシル領域を塗り潰す処理)内で深度バッファを無効にすると、その後深度バッファを有効にしても有効にならない』

この処理は、深度バッファを無効にしないと例のチラチラ現象が発生します。どうしたものかと悩んでいたのですが、この処理内の深度バッファ制御をやめて、呼び出し元で深度バッファを無効にしたら、その後深度バッファが有効になりました。

なんだかよくわかりませんが…解決したからいいのかな?(汗)


というわけで、アルファ制御やステンシル制御は各処理内に記述し、深度バッファ制御だけ呼び出し元に記述するという中途半端な状態になりました。いまいち気に入らないのですが、問題は他にもあるので、とりあえず先に進めましょう。



◎アルファブレンドの有効無効

次はユニットや森の色が変わった問題です。

最初はエフェクトの問題かと思っていたのですが、結局これもレンダーステート管理の問題で、アルファブレンドの有効無効をきちんと制御したら元に戻りました。

深度バッファとアルファブレンドのバグ修正

とりあえず深度とアルファの問題は解決しました^^



◎山岳地帯の表示問題

次は山岳地帯の索敵範囲の表示が良くない問題です。現象は以下の通りです。

山岳地帯の索敵範囲の表示問題01

・山の反対側で、こちらから見えない部隊の
 索敵範囲が表示される
 →‘索敵範囲内のステンシル領域を塗り潰す処理’で
  深度バッファを無効にしているため

・山の複雑な起伏を無視して四角形の領域が表示される
 →索敵領域を平面モデルで描画しているため


試しに、深度バッファを有効にすると、こんな感じです。

山岳地帯の索敵範囲の表示問題02

山の反対側の索敵範囲が表示されなくなるのは良いのですが、平原地帯の索敵領域がチラチラします。また、山岳地帯の索敵領域は、上図のように線や不定形で表示されますが、これは地形モデルの起伏と索敵領域描画用平面モデルの接合部分だけが明るく表示されているからです。



◎ステンシル描画モデルの変更

索敵範囲のステンシル描画用モデルを、平面モデルから球形モデルに変更します。

球モデル   山岳地帯の索敵範囲の表示問題03

おお!索敵範囲が円形になりました!
パフォーマンスも、fpsには影響しないレベルです。
(1.04ms→1.24ms)
最初からこうすれば良かったのか(^^;

これで山の複雑な起伏が無視される問題を解消すると同時に、索敵範囲を円形とする課題もクリアできました。



◎山の反対側の索敵範囲

残るは、山の反対側の部隊の索敵範囲が表示される問題だけです。試しに、深度バッファを有効にすると、こんな感じになります。

山岳地帯の索敵範囲の表示問題04

山の反対側の索敵範囲が表示されなくなったのは良いのですが、地形モデルの起伏と球モデルの接合部分だけが明るく表示されています。接合部が球状になったので、平原地帯でのチラチラはなくなりました。

こうして見ると、

『地形モデル(平面モデル)のうち、球モデルの内側全域のステンシルバッファをオンにする』

ことができれば問題を解決できそうですが、これって可能なんでしょうか?

うーん…ネットで調べてもヒントが見当たらないですね。この問題に関しては、とりあえず保留とします。



◎次回予告

年末で忙しくなってきたので、今年のブログ更新は今回が最後になりそうです。

というわけで、次回は「12月の総括と1月の目標」です。

今年1年を振り返るとアレですが、とりあえず12月は頑張ったかな、と(^_^;


それでは皆さんよいお年を!

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
索敵範囲明暗描画02
開発中のメイン画面
索敵範囲が明暗でわかるようになって、ゲームらしい雰囲気が出て来た。



◎サンプル作成

今回は、索敵範囲内を明るく、索敵範囲外を暗く表示します。まずはサンプルプログラムの作成。

以前のサンプルを流用して、アルファブレンド設定コードをライト設定コードに変更します。

索敵範囲明暗描画01

以前のサンプルを少し改修するだけで簡単にできました。



◎技術資料

HPにサンプルプロジェクトをUPしましたので、技術面に興味ある方はご覧ください。

索敵範囲を描き分ける



◎実装

サンプルをメインプログラムに実装します。
と言っても、前回から少し改修するだけですがw



いかがでしょう?
ゲームっぽくなってきた気がしませんか?

ステンシルバッファ描き込み処理のインスタンシング化も考えていたのですが、パフォーマンスは今の所許容範囲内なので保留とします。



◎当面の課題

画面を見ていると、気になる課題が次々と湧いてきましたw

・ユニットや森の色が変わった
 →未調査

・ユニットが森の手前に描画される
 →調査中(苦戦中(^^;)

・山岳地帯の索敵範囲の表示が良くない
 →検討中(どうしたものやら(汗))

・索敵範囲外の敵が表示されている
 →未着手(検討済)

・索敵範囲を円形にする
 →検討中

検討済のものは実装を待つだけなんですが、先に他の課題を何とかしないとぐちゃぐちゃになりそうですw



◎次回予告

なんか急にゲームっぽい画面になってきたのでちょっと嬉しいです^^

年末まで日がありませんが、出来れば年内にもう一度ブログ更新したいので、次回は当面の課題をやれるだけやって、30日か31日に更新します。

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
索敵範囲半透明描画実装03
開発中のメイン画面
前回作成したサンプルを実装し、部隊の周囲を明るく、離れた場所は暗く表示した。遠くの山が霞んで見える?



◎どこか懐かしいチラチラ

前回作成したサンプルをメインプログラムに実装します。
従来は、

マップ描画 → ユニット描画

となっていた描画フローを、

半透明マップ描画 → ユニット描画 → 不透明マップ描画

とし、ユニット描画時にステンシルの描画処理を加えました。

索敵範囲半透明描画実装01

索敵範囲がチラチラするし、ユニットが描画されたりされなかったりするので、まるで初代ファミコンのスプライトオーバー現象のようです(苦笑)

5ms以上のマップ描画処理が2回になったので、パフォーマンスが確実に低下したわけですが、それでも25fpsぐらいで安定しているので、処理落ちではない気がします。

うーん…レンダーステート管理の問題かなぁ?



◎原因調査

しばらく悩んでいたら、ユニット描画後に不透明マップを描画するのが悪い気がしてきました。そこで、

半透明マップ描画 → ユニットのステンシル描画 →
 → 不透明マップ描画 → ユニット描画

というフローに変更したのですが…現象変わらず(ーー;

その後もあれこれ試して、ほどなく原因が判明しました。最初の半透明マップ描画前に、深度バッファをオフにしてなかったことが敗因でした(汗)

また、ユニットが表示されたりされなかったりする問題は不透明マップの高さによる問題でした(不透明マップは半透明マップより若干高くする必要があるのですが高過ぎでした)。



◎半透明地形の実装

部隊ラベルや索敵範囲描画時に、地形の高度を考慮してなかったバグを発見したので、ついでに修正しました。

索敵範囲半透明描画実装02

チラチラは完全に解消されて、索敵範囲とユニットが正常に表示されました。部隊の移動と共に、部隊周辺の明るい範囲も移動します。特に平野部の表示は私のイメージ通りでいい感じです^^

しかし、まだ問題が幾つかあります。

・ユニットや森の色が変わった
・ユニットが森の手前に描画される
・山岳地帯の表示がおかしい

ユニットの表示はレンダーステートの設定で直るかもしれませんが、問題は山岳地帯の表示です。



◎山岳地帯の半透明表示

地形が半透明なので、山岳地帯は山の向こうがうっすらと透けて見えます。遠くの山々が霞がかった感じでちょっと幻想的で綺麗なので「これはこれでアリか?」と思ったり(笑)

しかし、見た目が良くても立体感や距離感が掴めないので違和感を感じます。背景や演出効果として使うならアリかもしれませんが、高山地域が散在するゲームマップとしては問題です。

ということは、索敵範囲外を‘半透明’にしたのが間違いで、単に暗くすれば良かった、というわけです。

…うわ~何やってんだオレ!(>_<)



◎次回予告

「半透明で表示する」という方針が間違っていたので、方針を「暗く表示する」に変更します。

というわけで、次回は暗く表示するサンプルの作成と実装です。

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
索敵範囲を描き分ける01
索敵範囲の描画テスト
ステンシルバッファを利用して索敵範囲を描き分けるテスト。重複領域の描画が1度で済むのでパフォーマンスが良い?



◎索敵範囲の描画

履歴画面について考えていたら、その前に重要な問題があることに気付きました。

中級ルールでは味方部隊から離れた敵部隊が見えず、上級ルールでは自部隊から離れた敵が見えないようにしたいのですが、これはつまり「索敵範囲内は部隊と地形を通常表示、索敵範囲外は地形のみ半透明表示」ということです。これはどのように実装すれば良いのでしょうか?

私が考えたのは以下の手順です。

1.ステンシルバッファを初期化する

2.全体地形を半透明で描画する

3.索敵範囲内のステンシルバッファをオンにする

4.ステンシルバッファを参照しながら
  全体地形を不透明で描画する

問題は3番です。できれば索敵範囲を円形領域にしたいのですが、可能でしょうか?



◎アルファとステンシル

ステンシルバッファの円形領域をオンにしたいので、透明度付きの円形テクスチャをステンシルバッファに描画しましょう。

まず、GIMPで透明度付きの画像を作成しようとしたのですが、描画色に透明度を設定する方法がわかりません。結局、「レイヤー>色を透明度に」で特定の色を透明度に置換しました。

circle
(↑透明度付きPNG画像)

テストプログラムを用意して試したのですが、

・アルファ機能の描画テスト
 →円形領域が表示される
 →成功

・ステンシル機能の描画テスト
 →三角領域が表示される
 →成功

・ステンシル描画時に上記画像を描画するテスト
 →四角領域(=テクスチャ領域全体)が表示される
 →失敗

レンダーステートをどのように変更しても円形になりません。もしかしたら、ステンシルバッファへの描き込みの際には、アルファブレンディング無効かも?

こちらのフローチャートを確認すると、アルファブレンドよりもステンシルテストの方が先でした。やはり、ステンシルバッファへの描き込みの際には、アルファブレンディングは無効ということですね。他の方法を探しましょう。



◎四角形で描き分け

しばらくネットで探ったり、ちょこちょこ試したりしましたが、いまいち良い方法が思い付きません。ポリゴンで円形を作れば可能でしょうが、ここで頂点数を増やして負荷を上げるのは効率が悪いと思います。

とりあえず四角形で作っておいて、良い方法が見付かったらステンシル処理を差し替えましょう。良い方法が見付からなかったら、そのまま四角形とするか、ポリゴンで八角形を作るか考えます。

索敵範囲を描き分ける01

サンプルプログラムの開発は成功ですね。

実はステンシルバッファを使わなくても見た目は一緒になります。しかし(画像の矢印のように)重複領域の描画が1回で済むので、パフォーマンスが良くなると考えています。

…実際には遅いかも(汗)



◎次回予告

サンプルができたので、次回はメインプログラムに実装します。パフォーマンス大丈夫でしょうか?(^^;

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
部隊ラベル04
開発中のメイン画面
部隊にラベルが付いて、武将名や敵味方が判別可能となった。顔画像の有無で、本体と支隊を判別可能とするようだ。



◎敵味方の区別

旗手を追加したものの、旗だけで敵味方を区別するのは難しそうです。他の方法を検討しましょう。

A案:部隊を色分けする
B案:ラベルで表示する
C案:プレイヤーが選択したユニットのデータを表示する

A案が一番わかりやすくて良い気もしますが、色付けのセンスが悪いと初期のファミコンゲームのようになってしまうかもしれません。C案はプレイヤーが面倒なので却下。とりあえずB案を試して、駄目ならA案を検討しましょう。



◎部隊ラベル表示

城名をラベル表示したことがあるので、そちらのコードを流用します。部隊名は「関羽」か「関羽隊」になりますが、XNAで漢字を表示するのは面倒なんですよね。

テキスト処理用のプロセッサは組み込み済ですが、使い方を思い出して、スプライトフォント定義用とデータ定義用の2種類のテキストファイルを用意して、部隊クラスを修正して……ブツブツ…。

あれ?定義追加したのにエラー?…そうか、テキストはUTF-8形式で保存する必要がありましたね。

部隊ラベル01   部隊ラベル02

左画面は負荷確認のため200部隊出したのでゴチャゴチャしてますが、通常は50部隊ぐらいを想定しているので右画面のようになりそうです。最初の印象としては、まずまずかと^^



◎顔画像の追加

試しに、顔画像も表示してみましょう。

部隊ラベル03

顔画像が小さいので人物の判別は無理ですね。でも顔画像の有無で本隊/支隊の判別はアリかも。



◎調整

ラベルは透明/半透明部分の2画像に分けて表示していたのですが、コードの柔軟性が低く修正しにくかったので、左/中/右の3画像に分けて表示するようにしました。画像数は増えましたが、スプライトバッチなので負荷は殆ど変わりません。

ラベルに縁を付けたり、文字を読みやすくしたりと、地味な調整も加えました。



武将名が表示されて、ようやく三国志のゲームだとわかるようになりましたw



◎次回予告

今回は珍しくハマりませんでした。
いつもこうだと良いのですが(^^;

とりあえず敵味方の区別がつくようになったので、次回は履歴画面イメージの検討です。もしかしたら、ビューポートの分割表示にチャレンジするかもしれません。

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
旗手モデル実装03
開発中のメイン画面
部隊の中央に旗手が追加された。影に関しては問題があるようだ。



◎忘れかけ

メイン画面に旗手を追加します。久々のメインプログラムなのでちょっと忘れかけてましたが、しばらくソースを眺めていたら思い出してきました。

2モーション分の画像を登録し、槍兵モデルクラスを流用して旗手モデルクラスを作成。アニメパラメータを調整してユニットリストにモデルを追加。さらにプログラムを…ブツブツ…こんなもんかな?

メイン画面旗手追加01

あれ?旗だけ表示されましたね?…あ、地面に埋まってました。とりあえず旗手だけ空中に表示してみましょう。

メイン画面旗手追加02

画像が思いっきり欠けてますね。画像解像度に制限あったかなぁ?

…解析中。ビルボードとUVアニメとシェーダーインスタンスの複合体なのでわかりにくいッス。いや、自分で作ったプログラムなんですけどね(^_^;

…わかりました!板ポリモデルのテクスチャマッピングの問題でした!

板ポリモデルを解像度毎に用意すれば回避できますが、プログラムを改修した方が望ましいですね。何でやってなかったんだっけ?

…ああなるほど、シェーダーインスタンスの都合で、左上隅を除く3頂点のテクスチャ座標は指定不可だから諦めたんですね。

しかしそれ以前に、テクスチャのマッピング座標を動的に変更できれば解決するかもしれません。ちょっと調べてみましょう。



◎悩みまくり

で、半日かけて調べたのですが…う~ん。

Texture2DやModelクラスのプロパティには無さそうなので、頂点バッファ内の各頂点データのUV座標を書き換えるしか無いだろうと考えたのですが、最終的にシェーダインスタンスやUVアニメに対応する必要があるので、かなりややこしくなりそうです。

しばらく悩んだのですが、結局今回も諦めることにしました。右下座標を動的に指定したいだけなのに、ハードルが高くてなかなか超えられません><

で、従来の回避策に戻したのですが、現象変わらず。
何でやねん!?(何故か関西弁)

これには複数の要因が混在し、解析と修正に手間取りましたが、とりあえずこの段階になりました。

旗手モデル実装01

まだ幾つか問題がありますが、一番よくわからないのは「旗手モデルだけアニメしない(ビルボードにもならない)」という点です。槍兵のコードを流用したのに…う~ん(ー_ー;

コンテンツファイルがゴチャゴチャしてきたので、調査を中断して先にコンテンツファイルを整理したら、木やユニット等が画面に表示されなくなってしまいました。
うわ~何かヤバイことしたかオレ!
(実はビルボードが機能しなくなって板ポリの裏側が表示されてました)



◎判明

その後もあれこれ悩んだ末に、ようやく以下のことが判明しました。

・インスタンスモデルのプロパティに
 専用シェーダー指定必須
 →指定後ビルボードが機能した

・インスタンスモデルの追加のみ必要
 →通常板ポリの追加は不要

モデルの種類毎に、シェーダーインスタンスモデルと通常モデルがそれぞれ登録されていたので、UVアニメとシェーダーインスタンスの2段階計算に使用していると勘違いしてしまいました。またも一人で混乱状態><



◎調整

今後はなるべく混乱しないようにプログラムやコメントを整理し、大きさやタイミングなどを調整しました。

旗手モデル実装02

各部隊の中央に旗手を配置しました。
予想以上に戦場の雰囲気が出てきましたよ!^^

ビルボードなので、影を追加しても負荷が増えないのがいいですね。槍兵モデルも影付きで連画再取得しましょう。連画の解像度を上げたりアニメのタイミングをずらすなど、さらに細かく調整します。



いかがでしょう?
戦場っぽくなってきた気がしませんか?

槍騎兵はまだACLモデルなので影無し状態です。頑張ればACLでも実装可能と思いますが、いずれSoftimageで作り直す予定なので当面このままです。



◎影の向き

動画を見て気付いた方がおられるかもしれませんが、影の方向がおかしいです。部隊毎に統一されるのでそれほど目立たちませんが、部隊が方向転換したり、他の部隊と見比べるとすぐにわかります。

対処方法で考えられるのは、

A案:板ポリを追加して小さな影を作る
B案:カメラの向きを固定する
C案:影を無くす
D案:このまま

A案は負荷が上がるので避けたいですね。B案はゲーム性に大きく影響するので保留。C案が順当かもしれませんが、D案もアリかな~?などと考えていますw



◎次回予告

苦戦の予感はありましたが、まさかここまでとは…一度忘れるとシンドイですね(汗)


旗だけで敵味方を判別するのは厳しそうなので、次回は部隊の色分けについて検討します。

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
FlagMan01_12_000
旗手モデルの画像
新型モデルに対応できるよう連画ツールを改修し、旗手モデルの画像を取得した。単体で見ると小さくてわかりにくい。



◎連画取得ツール

連画取得ツールとは、通常/ACL/Softimageモデルを単数/複数配置し、周囲を回転しつつスクリーンショットを連続的に取得するツールです。プログラムはシャドウリグ方式の頃のままですので、新方式のモデルを利用できるように改修します。

元のプログラムコードは複数モデル対応などで複雑化しているため、苦戦が予想されます(--



◎実装

ボーン増加、マテリアル一括置換、ステンシルシャドウなどの機能を実装しました。

連画取得ツール改修01

うげっ!何じゃこりゃ~!!

…ああそうだ、ボーン増加改修時はワールド座標の指定方式を改める必要がありました。

連画取得ツール改修02

だいぶマトモになりました。色や腕の形がヘンですが、旧モデルだからかもしれません。新モデルに入れ替えましょう。

FlagMan01_04_016   FlagMan01_00_012

OKですね。影も無事に付きました(右図)。



◎モーションの分割

現在のモーションを滑らかに再現したい場合、20枚(=フレーム数)ぐらいの画像が必要です。これを32方向分取得する場合、20×32=640枚になります。640枚の画像を2048×2048の1枚に集約する場合、1枚あたりの解像度は80×80ぐらいです。

しかし、80×80で取得するとこんな感じになってしまいます。

FlagMan01_25_015

これでは小さすぎてわかりにくいですね。解像度をもっと大きくしたいので、モーションを分割し、フレーム数をなるべく抑えましょう。

…うむむ、後半モーションのアニメ開始時間を指定したのですが、うまく機能しません。上半身は0フレーム目から再生し、下半身は指定フレームで動きが固定されてしまいます。
何だコリャ?

…思い出した!
開始時間はうまく実装できなくて挫折した機能でした(爆)
以前はコンテンツ側で強引に回避したのですが、いろいろと面倒なので、プログラムを作り直しましょう。

…改修してテストすると、一見良さげでした。しかし取得した画像を確認すると、初めの数フレームの下半身だけ開始時間が無視されました。上半身は期待通りなので、プログラムではなくコンテンツの問題でしょうか?

…結局、Softimage:600(ミリ秒?)に対しXNA:1000(ミリ秒)の比率で開始時間や再生時間を指定すると、何故かうまくいきました。

FlagMan01

4フレーム×32方向=128枚取得しました。

解像度は160×160ですが、こうして見ると小さいですね。影を除けばもう少し大きくできますが…ここから先は、メイン画面に実装してから調整しましょう。



◎次回予告

連画取得ツールのプログラム改修が完了したので、次回は画像をメイン画面に実装して調整します。

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
旗手モデル09
旗手モデル
フォースの向きの問題は解決したらしい。
ポイントは、ヘルプの手順に逆らうこと??



◎フォースの向き

現在、重力フォースの向きは、槍の根元方向が下になっています。このため、槍を横に傾けると、旗が下方向ではなく横方向に垂れ下がってしまいます。この現象を正すのが今回のテーマです。

重力の向き

フォースの向きは、エンベロープ設定時のボーンの向きを基準に固定され、ボーンアニメの現在の向きを考慮していないようです。

ボーンの現在の向きを反映させるにはどうすれば良いのでしょうか?とりあえず思い付きで試してみます。

・槍兵モデル全体にフォースを適用する→NG
・クロスメッシュの階層上の位置を変える→NG
・クロス作成元のカーブにエンベロープを設定する→NG
・クロス作成元のカーブを削除する→NG
・フォースにエンベロープを設定する→NG

全てNGでした。
やはり思い付きレベルじゃ解決できないか…。



◎サンプルの動作を確認

スクリプトで作成したクロスを使用していますが、何か設定の問題でしょうか?

…そういえば、クロスサンプルがありましたね。あれで一般的なクロスの設定や動作を確認しましょう。

棒を回転させて倒し、重力フォースの向きを確認しました。

クロスサンプルテスト01   クロスサンプルテスト02

重力を大きくすると、画面下向きに働きました。OKです。

もしかすると、旗手モデルのクロス関連パラメータを全てサンプルに合わせたら重力が下向きになるのでは?
…やってみたけどダメでした。よく考えたら、ボーンアニメの動きで比較しないと条件が合いませんね。

というわけで、クロスサンプルの棒にボーンを入れて旗メッシュにエンベロープを設定し、ボーンアニメで横倒しします。

クロスサンプルテスト03   クロスサンプルテスト04

重力が画面右方向(棒の根元)に向かって働きました。

旗手モデルとサンプルで同じ現象になるということは、スクリプトクロスメッシュの構造や設定の問題では無さそうです。



◎オペレータスタックの順番

ということは、エンベロープの問題?しかしエンベロープを設定しないわけにはいかないし、Envelope Operatorのパラメータはミュートしかないし…ブツブツ…。

そんな感じでEnvelope Operatorを見ていたら、ふと気が付きました。「オペレータスタックの順番の問題じゃないか?」

オペレータスタックの順番の変更01   オペレータスタックの順番の変更02

試しに、オペレータスタックの順番を変えると、重力が画面下向きに働きました。

やった!コレだったのか~!!



◎実装

順番を変えてシミュレーションを再計算しました。



風や重力のフォースの向きが正しく反映されました。



◎アクションの切り替え

1つのモデルデータに2つのアクションを格納済ですが、アクション切替時はクロスの再計算必須となってしまいました。Softimageでアクションを切り替える際にちょっと面倒です。

さらに困ったことに、XNAでアクションを切り替えると、旗メッシュが最初のアクションの動きになってしまいます。これでは、1つのモデルデータに複数アクション格納不可です。

そんなわけで、今回の動画は、2つに分けて録画したものを編集でくっつけました。

かなりイヤな状態ですが、これは改善できるのかしら?
(XNAアドオンを改善してくれないとダメかも??)



◎ヘルプとの相違

後でSoftimageのヘルプを確認したら、『エンベロープやその他のデフォーメーションでのクロスの使用』という頁に、今回のテーマに関する記述がありました。しかし内容をよく読むと、本稿と全く逆の順番で記述されています(Envelope Operator→ClothOp)。

これはどういうことでしょうか?

1.槍ボーンが動く
2.槍ボーンの位置に連動してクロスメッシュが動く
3.クロスメッシュのエンベロープが動き、nullが動く
4.nullの位置に連動して旗メッシュが動く

旗手モデルでは、2→3の順番を実現するためにClothOp→Envelope Operatorの順番とする必要があったのですね。



◎次回予告

今回も毎度の如く苦戦しましたが、結果的には「たかが順番を変えるだけ」の話でした。
もっと早く気付けたらいいのに…。

でも先にヘルプを読んでいたら、ヘルプの順番を盲目的に信じて、解決に至らなかったかもしれません。
そう考えると結果オーライかも?(^^;

旗手モデルが完成したので、次回は連画取得ツールを改修します。

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
天地を喰らう
天地を喰らう
本宮ひろ志原作の漫画は未完のまま終了。演義ベースだが、天界や魔界が登場するなどオリジナル要素が強い。
アーケード/コンシューマ/PC/パチスロなど幅広くゲーム化され、中でもアーケード版の評価が高い。



◎11月の目標達成度

・活動時間月160時間以上

実績:114h(達成率:71%)

 (中間目標:11/15迄に80h以上)

実績:57h(達成率:71%)


・XNAレンダーステート修得(48h)

実績:44hでステンシルシャドウ等修得(達成率:100%)


・旗手モデル作成(24h)

実績:19hで旗手モデル作成中(達成率:80%)


・履歴画面イメージ作成(16h)
・企画見直し(24h)

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


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

実績:49hでブログ更新、HPに「SoftimageのシミュレーションモデルをXNAで動かす」等を追加(達成率:100%)


レンダーステートのスキルが向上したのは良いのですが、月間活動時間少なすぎ!><



◎作業時間分析

作業時間集計2010年11月(PDF形式)

○良かった点
・三か月ぶりにHPを更新した
・終盤にペース回復の兆し

○悪かった点
・月間活動時間が先月よりさらに低下
・一日の時間目標の達成率は僅か30%(6勝14敗)
・ブログの月間更新数が少ない


一日の時間目標の達成率が30%というのは我ながら酷過ぎです(ーー;

まずは勝率の逆転(70%)を目指さないといけませんね…。



◎原因分析

秋は一番好きな季節なんですが、この時期に活動時間が低下した原因は何でしょうか?

典型的なパターンは、

1.原因不明の問題が発生し試行錯誤する

2.なかなか打開策が見出せず、余計なことを考え始める
 例:「テーマと無関係の問題に
    これ以上時間かけて良いのか?」
   「本番使用予定の無かったテクニックを
    今マスターする必要があるのか?」

3.気分転換モードへ突入

これは先月に限らず毎度のパターンですが、先月は2番の機会が普段より多く、また3番の気分転換モードから復帰するまでの時間が長かったのが敗因です。うーん…。

XNAやSoftimageの基礎勉強の重要性は認識していますが、ゲーム制作の進捗が進んでいる実感は無いので、迷いが多くなったりやる気が低下したりするのは、ある程度仕方が無いのかもしれません。

修得シリーズが一段落し、最近は回復傾向にあるので、もうしばらく様子を見ましょう。



◎進捗状況チェック

スケジュールは凍結中です。企画見直しが完了したら、スケジュールの見直しを行います。



◎12月の目標

・活動時間月128時間以上
 (中間目標:12/15迄に80h以上)
 (1日の時間目標達成率70%以上)

・旗手モデル作成(16h)
 →フォースの向き制御方法調査含む

・連画取得ツール改修&連画取得(24h)

・履歴画面イメージ作成(24h)

・企画見直し(24h)

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

年末年始はイベントが多いので、前半に頑張らないといけませんね。



◎次回予告

次回は、フォースの向きを制御してXNAに反映させる方法を調査します。

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

| BLOG TOP |
DATE: CATEGORY:三国志軍記開発
旗手モデル08
作成中の旗手モデル
槍兵モデルの槍にクロスシミュレーションの旗を加えた。
一見まともそうだが、まだ何か問題があるらしい。



◎シーンファイルのマージ

今回は旗手モデルを作成します。というか、槍兵モデルの槍に旗を加えるだけです。

で、実際にシーンファイルをマージしようとすると、

オブジェクトを作成出来ません。クリーンアップを実行します。

とエラーが発生してマージできません。他のシーンファイルも試してみたのですが、やはりエラーになります。

シーンファイルのマージは、これまで一度も成功したことが無いので、これを機にいろいろ試してみましょう。



◎さっぱりさっぱり

まず、カラッポのシーンを2つ用意してマージすると…エラーになりました。カラッポは良くないのかな?

次に、nullを1つだけ取得したシーンを2つ用意してマージすると…エラーになりました。
なんだよ、これじゃ何もマージできないぞ!(怒)

モデル/カメラ/ライト/Nullの名称を重複しないように変えてもダメ。ドラッグ&ドロップでもやっぱりダメ。ヘルプを読んでも不審な点が見当たりません。

…さっぱり糸口が掴めません。諦めて1から作ります。



◎備忘録

槍兵モデルをベースに作業開始。まずはカーブを描いて、スクリプトでメッシュを作成して、フォースを適用して…あれ?ファンを適用しても動きませんね?

何度も同じ経験をした記憶がありますが、コレの対処法は何故か憶えられないんだよなぁ…ブツブツ。

…ああコレだ!ClothOpのフォースタブの外力係数。自動的にポップアップするメニューに出てこないし、ファンのプロパティにも存在しないから気付き難いのですね。

また忘れそうなので、HPにメモっときました。



◎クロスメッシュの移動

ファンがOKになったので、クロスメッシュの位置を移動します。

旗ポリゴンの座標を移動したい

メッシュの位置を移動しただけだと、(Softimage上は問題無いのですが)XNA描画時に形が崩れてしまいます。それを防ぐためにメッシュの座標を(0, 0, 0)とする必要があるのですが…「ニュートラルポーズの設定」「全ての変換をフリーズ」「リファレンスポーズの設定」などは全てNG。

本来はセンターを移動してオペレータスタックをフリーズするのが正しい手順と思いますが、センター移動時にオブジェクトもコンストレイントで連動してしまいNG。仮頂点を追加して「センターを選択した頂点に移動」とすると、オブジェクトとセンターの座標がその位置に移動するだけで効果が無くNG。全頂点をゴッソリ選択して移動もNG(頂点移動不可)。

各頂点がセンター座標と連動するようコンストレイントで設定済のようですが、これを外すとクロスが動きません。
うげー参った(x_x)



◎考え過ぎ?

…いや待てよ?クロスメッシュを直接XNAで表示するわけではないのだから、クロスメッシュは別の場所でも支障無いのでは?とりあえず試してみましょう。

旗手モデル01   旗手モデル02

クロスの旗パタパタアニメを再生しつつ、槍の位置に連動して旗メッシュが移動しました。槍から離れすぎてしまうのが問題ですが、これを修正できれば見た目はOKっぽいです。難しく考え過ぎだったのかな?(^^;

クロスの初期位置を槍の位置にピタリ合わせれば、槍から離れなくなるんじゃないですかね?

旗手モデル03   旗手モデル04

旗メッシュが槍と連動しなくなってしまいました。何故!?


その後もいろいろ試してみたのですが、試せば試すほど不可解なことが増えるばかりでさっぱり理解できません。
ウッキー!!(サル化)



◎冷静に考えよう

不可解な現象が多数発生する場合は、何かが引き金になっている可能性があります。まずは問題点を絞り込みたいので、試しにクロスメッシュを削除してみました。

旗手モデル05

旗メッシュは槍の動きに素直に連動しました。
(クロスを削除したので旗はパタパタしません)

旗メッシュの位置や、デフォーマであるnullの階層上の位置は正しいようです。やはり問題はクロスですね。nullの位置にクロスを合わせると、旗もクロスも位置が固定されちゃうんだよなぁ…。

…待てよ?クロスにエンベロープを設定して、クロスを槍と一緒に動かせば、旗メッシュも連動するのでは?

旗手モデル06

動きました!こんな単純なことだったのか~!

中途半端に動くものを先に見てしまい、一人で混乱してました。自分で自分にメダパニ状態(汗)



◎お次はXNA

ようやくSoftimageで動くようになりましたが、XNAで動かすと画面乱れまくりでした。キャラクターキーセットを再作成しても現象変わらず。う~ん…。

試しにクロスや旗メッシュを削除しても現象変わらず。さらにnullを削除すると、正常動作しました。ということは、nullの問題ってこと?

しかしnullは画面に描画しないのに、nullがあると画面が乱れるというのもヘンな話です。
ハッ!もしやボーン数オーバーでは?
(ボーン数オーバーはXNAでエラーにならなかったっけ?)

試しにnullを2つだけ残すと正常動作しました。
どうやらボーン数オーバーだったようですね(汗)



◎ボーン数の上限

元の槍兵モデルのボーン数をチェックすると、89でした。
…ゲッ!そんなに多かったっけ!?

クロスの動きを再現するには、少なくとも25ぐらいは欲しい所ですが、現在確実に使用できるボーン数上限は108です。ちょっと足りませんね。

108という数は、ひにけにXNAの記事の内容をそのまま差し引きして導き出した「確実に使用可能な数」です。Softimage付属シェーダで使用中のシェーダ定数から差し引きすると116まで使用できそうなんですが、いまいち自信が無いので保留にしてました。良い機会ですので確認しましょう。

クロスメッシュと旗メッシュを4×4マス(25頂点)で再作成し、シェーダ定数の上限を116に拡張してXNAで動かしました。

旗手モデル07

動きました!ボーン数114で正常動作したので、116までOKだと思います。



◎画像ファイルの自動集約機能

旗の裏側の文字が逆になってしまうのでテクスチャを追加しました。

Flag00A   Flag00B

旗メッシュのクラスタを2つに分割し、裏側のテクスチャを選択して貼り付けようとしたら、画像ファイル名の連番で自動的に集約されました。

2つの画像ファイルが集約された

そのまま裏表に貼ってくれたらありがたいのですが、やっぱり駄目でした。時間経過によるUV差し替えアニメを想定した機能らしいので仕方ないか。



◎実装

とりあえずファイル名を適当に付け変えて回避し、UV座標調整後、フリーズしてXNAに反映させました。



攻撃モーションはおまけです(ゲームでは使用しません)。

攻撃モーションを見るとすぐに気付くと思いますが、旗の向きが不自然です。これは、クロスメッシュのデフォーマに槍を設定した都合により、フォースの向きが槍を基準としているからです。(重力フォースを適用すると、槍の根元に向かって垂れ下がってしまう)

槍を回転させればある程度ごまかせますが、モデルやモーションが増えると深刻な問題になりそうです。何とかしないとまずいなぁ…。



◎次回予告

12月になったので、次回は「11月の総括と12月の目標」です。

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

| BLOG TOP |

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