開発中のメイン画面城の傾きや方向画像のカクカクを改善したが、スクロールするとまだ微妙な違和感があるようだ。
◎城の傾きカメラを前後や高低に移動すると、城が逆に傾いてしまいます。
カメラを手前(左図)から奥に移動した(右図)カメラを前方(奥)に移動したら、城の手前が浮き上がってしまいました。ビルボードで板ポリゴンを表示するとこうなるわけですが、映像的には、城の手前が沈んで城の上面が多く見えるようになるべきです。
傾きが逆であれば、ビルボードの回転軸の指定を変えれば上手くいくかも?
試しに Vector3(0, 0, -1) と指定すると、カメラのZ軸方向の移動に対してはいい感じで傾くようになりました。しかしカメラをX軸方向に移動すると、あらぬ方向に傾いてしまいます。

そこで今度は Vector3(0, 1, -1) と指定すると、カメラZ軸移動に対して傾きが固定され、X軸移動に対して傾きが自然になりました。しかし注視点を変更すると、あらぬ方向に傾くケースがあります。
出来そうで出来ないのは、もどかしいですね(−_−;
◎城画像の再取得それにしても、同じビルボードのプログラムなのに、兵士は自然に見えて城が自然に見えないのは何故でしょうか?
私が気になるのは下記の2点です。
・兵士の画像は前面8割、上面2割なのに対し、城の画像は前面と上面の比率が逆転している
・兵士は前面、城は上面に注視している
試しに城画像を前面8割、上面2割で再取得しました。

一人称視点はマシになったようですが、上空視点は相変わらずですね。うむむ…。
◎カクカクの原因判明試行錯誤を繰り返す過程で、別件の「カメラを移動して画面をスクロールさせるとカクカクする」原因が判明しました。
それは「(方向転換に伴う画像の)変化量が大きくて目立つから」でした。
…同じことを以前書いた気がします(爆)
すぐに気付けなかったのは、兵士をズームアップして画面に大きく表示された状態でスクロールしても、カクカクした印象を受けないからです。しかし、兵士のスケールを拡大するとカクカクします。
見た目の大きさは同じでも、画像が粗いと気付きにくいのかもしれません。
◎カクカクの解消方向転換に伴う画像の変化量が大きくて目立つなら、方向画像数を増やしましょう。
まずは32枚から64枚に増やしてみましたが、まだカクカクします。そこで128枚に増やしたら、かなりスムーズになりました。
しかしこのまま単純に増やすと128×5=640枚になってしまいます。城門の数と向きはゲームに影響するのですが、映像的に表現するのは諦めた方が良さそうですね。
というわけで、映像的には4方向の城門で統一することとし、90度分の32枚だけ残して使い回すことにしました。
◎対策方針の検討カクカクが解消されて大分マシになったものの、傾きの問題は未解決のままです。どうしたものやら…。
A案:この状態のまましばらく様子見
B案:ビルボードの角度改善を目指す
C案:上面中心の画像に変更する
D案:板ポリゴンを増やす
E案:簡易3Dモデルを作成して置き換える
F案:元の3Dモデルに置き換える
A案にしようかと思ったのですが、柵や森を追加する際に同じ問題で詰まってしまいそうです。簡単にできる案だけでも試してみましょう。
◎パフォーマンス確認まずはF案。多分ダメだと思いますが、3Dモデルとビルボードのパフォーマンス比較ってことで。

・ビルボード方式
兵士無し:58〜60fps
兵士あり:28〜30fps
・元の3Dモデルに置き換え
兵士無し:10〜12fps
兵士あり:8〜10fps
兵士ありでもさほど低下しないのは意外でしたが、城だけでこれほど遅くてはこの先ゲームになりません。映像的にはバッチリなんですけどね〜…って当たり前か(爆)
モデルインスタンシングなどのテクニックで改善は可能ですが、それをやるなら先にモデルを簡略化すべきでしょうから、今回はやりません。
◎画像の変更お次はC案。上面中心の画像に変更しました。

上空視点は改善されたようですが、一人称視点だと城の後部が浮き上がってしまいます。円柱型ビルボードでは、上面と前面の両方を同時にサポートするのは難しいようです。
ゲーム難易度‘強’の場合、一人称視点固定にしようと考えていたので、逆に難易度‘中’‘弱’の場合、上空視点固定として、画像を使い分けるという方法はアリかも。若しくは、ボタンやキーを押すと視点が切り替わるとか?
画像枚数は増えますが、難易度で制限する場合は読み込み数を抑えられますね。アイデアとしては悪くないかも。
◎回転軸の修正画像を使い分けると改善はされますが、傾きが逆であるという現象は変わりません。というわけで、B案にチャレンジ。
やはりビルボードの回転軸が気になるので、こんな感じで指定してみました。
Vector3.Normalize(new Vector3(0, 1, -1))すると、カメラのZ軸方向の移動に対しては良くなりました。しかし、カメラを左右に回り込ませて注視点を変えると、あらぬ方向に傾いてしまいました。これはつまり、オブジェクトとカメラを結ぶ線に直角な上方向を指定しろってことですね?
Vector3 rotateAxis = Vector3.Normalize(billPos - mainMap.MapViewPos);
rotateAxis.Y = 1.0f - rotateAxis.Y;
rotateAxis = Vector3.Normalize(rotateAxis);※Matrix.CreateConstrainedBillboard()の引数に上記rotateAxisをセットする
◎調整城の内側の地面が透けていると城が浮いて見えるので、城モデルを修正して地面を追加しました。城やマップのスケールを考慮して、ユニットのスケールを小さくしました。仕上げに、ネームプレートの位置を修正しました。
う〜ん…ビミョ〜だなぁ(汗)
これでも大分マシになったんですけどね。
城が画面の右下や左下に位置すると、円盤が回転したような傾きになります。ビルボードや板ポリゴンを使用してる以上、これは仕方がないようです。ビルボードは大きなモデルに向かないそうですが、この城も大きくて向かない部類に入るのでしょうか?
◎次回予告別の方式を模索するか、保留して次のテーマに移るか悩みましたが、城だけの問題であれば簡易モデルを作成した方が良さそうですし、静止モデル全般の問題であれば別の方式を模索すべきでしょう。
というわけで、次回は他の静止モデルを作成して、同じ現象になるか確認することにします。
テーマ : ゲーム製作 関連 - ジャンル : ゲーム
ははあ…。
試しに手のひらを垂直に立てたまま、目の真正面よりやや下に構えてみてください。で、その後、つつーと手のひらを水平に手前に引きます。手のひらの縦方向の幅は、離れている時より手前の方が縮んで見えるのではないかと。Matrix.CreateConstrainedBillboard()メソッドはもともとそういう動作をするのが正しいはずです。
ではなぜ、ブログ主さんの城テクスチャの場合、それが不自然に見えるのかというと。そのテクスチャ、「もともと真正面からではなく、やや斜め上から城を見下ろした“絵”」なわけです。なので、それが縦方向に潰れてしまうことで、あたかも手前が浮き上がっているように見えているのではないでしょうか(というか板ポリなんだから、手前だけ浮き上がるなんてあり得ない)。
ビルボード手法は本来、真正面から見たテクスチャを用いることが前提なのです。もちろんここで「城を真正面から描いちゃうと、奥行きのない板ポリであることが丸分かりだよ〜」となりますが、それはこの手法自体がもともと奥行き感の重要な物体を表現するには向いていないということです。
自分なら解決策として
1・ローポリでもいいからちゃんとした立体にする。
2・今のテクスチャのままで、Matrix.CreateConstrainedBillboard()でなく、縦方向に潰れないMatrix.CreateBillboard()を用いる(カメラが上下すると厳しいかも)。
3・ビルボードでない1枚板ポリゴンのモデルを作って、今のテクスチャを貼る。この板ポリを、「元になった3D城モデルの手前下辺と奥の上辺」に挟まれた四角形とするのがミソ。
辺りですね。
1つ試してみました
解説とアドバイスどうもありがとうございます。
>それはこの手法自体がもともと奥行き感の重要な物体を表現するには向いていないということです。
やはりそうなんですか。その可能性には気付きつつも、プログラムや画像が悪い可能性も拭えず試行錯誤してたのですが、解説して頂いたお陰で迷いが吹っ切れました。
とりあえず2番のMatrix.CreateBillboard()が簡単なので試してみると、縦方向に潰れないので以前よりも少し良くなりました。城は円柱型なのに、円柱型ビルボードより球型ビルボードの方が向いてるのは意外ですね。
しかし画面の右下や左下に位置すると、円盤が回転したような傾きになる問題は解消できませんでした。
3番についてお聞きしたいのですが、この方法だとカメラが左右や反対側に廻り込んだ場合、見えなくなりませんか?もしそうである場合、板ポリゴンを4方向分に増やすと対応できる可能性はありますか?
補足
円柱“形”というより、円柱“のように回転する”ビルボード、と考えた方がいいですね。
>カメラが左右や反対側に廻り込んだ場合、見えなくなりませんか?
はい、そうです。この案がうまくいくのはカメラの向きは固定のまま平行移動する場合だけです。そちらのゲームの設計に合わせて選択してください。もちろん、これも32パターンくらい用意する手もありますな。
ただ、(ちょっと事情があってまだプレミアムメンバーシップに登録できていないのですが)360ならその城モデルくらいのポリゴン&ピクセルレートは出せそうな気もするんですよ…。
簡易モデルにします
なるほど、その通りですね。
>カメラが左右や反対側に廻り込んだ場合
やはりそうですか。いろいろ検討した結果、簡易モデルがベストとの結論に達しました。どうもありがとうございました!
>360なら
そうですね。私はPCの最低クラスのグラボでも動かしたくて悩んでますが、360なら一定のパフォーマンスが保障されるので、モデルをそのまま使えるかもしれませんね。
後日360に移行したら、その辺の感触を教えてください(^^
補足2
一応、2番目の方法を補足しますが、たぶんMatrix.CreateBillboard()の行列でなく以前引用されていたhttp://www.platz.or.jp/~moal/billboard.htmlに書かれた手法の行列なら傾かないと思います(あるいはポイントスプライトやスプライトバッチでもよいかも)。ただ、これらだと、今度はビルボードと地面との接地感がなくなるはずでして…。結局、簡易モデルが無難ですね。
パフォーマンスの問題
>地面との接地感がなくなるはず
そうなんですか?悩みどころですね…。
柵の簡易モデルを作成したら、傾きの問題は解決したのですが、パフォーマンスが予想以上に低下しました。(次回参照)
しばらく簡易モデルで進めようと思いますが、パフォーマンスが改善しない時は、そちらの方法を試すかもしれません。
コメントの投稿