FPSを作ってみる@wiki
04)
最終更新:
slice
-
view
(2012/04/25)
もう,疲れた・・
(2012/04/22)
振り出しに戻る
実装途中で薄々感じてはいたが・・
遠くがもろにギザギザ.ポッピングと相まって哀愁を誘う.
ま,これは波の向きがポリゴンに対して一番不味いからだろうと思い,変えてみた.
ま,これは波の向きがポリゴンに対して一番不味いからだろうと思い,変えてみた.
今度はまずまず見られる範囲.と思いきや・・・
残念でしたー!テクスチャでごまかせるとか言うレベルじゃない.
何が起きているか?
これは動画じゃないと伝わりにくいかもしれないが,手前のメッシュが細かい部分は左へ
遠くのメッシュが荒い部分は右へ流れている.
扇風機の羽根をビデオカメラで撮影しながら回転数を上げていくとある時点で逆向きに見えたり,
サウンドで言えばデータ化する周波数より高い周波数の音を受けた時に全然違う音に聞こえちゃったりするアレである.
これは動画じゃないと伝わりにくいかもしれないが,手前のメッシュが細かい部分は左へ
遠くのメッシュが荒い部分は右へ流れている.
扇風機の羽根をビデオカメラで撮影しながら回転数を上げていくとある時点で逆向きに見えたり,
サウンドで言えばデータ化する周波数より高い周波数の音を受けた時に全然違う音に聞こえちゃったりするアレである.
そもそも海面は事前に高さデータを入力する類のハイトフィールドじゃない.
実行時に波の周波数や高さから動的に頂点シェーダで高さを決めているのでこのアルゴリズムは全く合わない.
「えー!今更」という声が聞こえそうだが,紛れもない事実である.
それだけなら別に「じゃあ地形に使えばいいか」となってダメージも少なくて済むのだが
これもまた悪い予感がする.
実行時に波の周波数や高さから動的に頂点シェーダで高さを決めているのでこのアルゴリズムは全く合わない.
「えー!今更」という声が聞こえそうだが,紛れもない事実である.
それだけなら別に「じゃあ地形に使えばいいか」となってダメージも少なくて済むのだが
これもまた悪い予感がする.
というのも今回実装したのは地形に合った尺度でポリゴンを構成せずに
単にタイルベースで解像度を切り替えているいわば粗末でシンプルなアルゴリズムなので
なだらかな山の中腹なんかディティールレベルの境界がタイル状に凸凹しそうなのは容易に想像つく.
まぁやってみないと分からんが.
単にタイルベースで解像度を切り替えているいわば粗末でシンプルなアルゴリズムなので
なだらかな山の中腹なんかディティールレベルの境界がタイル状に凸凹しそうなのは容易に想像つく.
まぁやってみないと分からんが.
ちなみに最初のスクリーンショットのように波の頂点がギザギザになる現象は主にメッシュ(タイル)の頂点配置のせいで
少し工夫すれば(格子状じゃなくて網目状とか)改善は出来るだろう.が,その場合タイルの構成方法からやり直さねばならない.
八方塞がり.散々だね,今回は.
少し工夫すれば(格子状じゃなくて網目状とか)改善は出来るだろう.が,その場合タイルの構成方法からやり直さねばならない.
八方塞がり.散々だね,今回は.
話が湿っぽいから最後に上手くいった点を無理矢理挙げてみる.
上下左右6方向分のD3Dバッファに見えているタイルをそれぞれ登録して
視錐台を使ってどれとどれを実際に描画するか判断する部分.
それと十数フレームに渡ってD3Dバッファにジオメトリ情報を書き込む部分.
これらは予定通り動作した.
上下左右6方向分のD3Dバッファに見えているタイルをそれぞれ登録して
視錐台を使ってどれとどれを実際に描画するか判断する部分.
それと十数フレームに渡ってD3Dバッファにジオメトリ情報を書き込む部分.
これらは予定通り動作した.
今後どうするかについては
- 海面
Isometric Gridで構成し視点を中心とした放射状グリッドを使う.
但し前のように円周上に頂点を置くのではなく網目状に散らし
遠くに行くに従って密度を減らしていく.アルゴリズムは何とか考える.
但し前のように円周上に頂点を置くのではなく網目状に散らし
遠くに行くに従って密度を減らしていく.アルゴリズムは何とか考える.
- 地形
No idea.
一応今のアルゴリズムで表示してみてからでないと何とも.
見るに耐えなかったら多分ROAMかその類を使うんだろうな(他人事)
一応今のアルゴリズムで表示してみてからでないと何とも.
見るに耐えなかったら多分ROAMかその類を使うんだろうな(他人事)
(2012/04/19)
なんも成果が出てないけど一応報告だけ.
無限平面,というかハイトフィールドを実装中なのだが前回書いた視錐台でタイルが見える範囲だけ
頂点&インデックスバッファに転送して描画するというのが惨敗に終わったので一から書き直している.
何がどう駄目だったかと言えば
「幾らDrawCallを減らす為とはいえメインメモリからD3Dバッファへの転送を毎フレームやっていたのではCPU側が重い」
という事.勿論数フレームに渡って更新するのも試してみたが今度は違和感がありすぎる.
キャラクターは60fpsなのに背景は10fpsとか.
MDシルフィード10面の背景と言えばわかるだろうか.
見た目はちょっと面白いからそのうち動画上げるか.
無限平面,というかハイトフィールドを実装中なのだが前回書いた視錐台でタイルが見える範囲だけ
頂点&インデックスバッファに転送して描画するというのが惨敗に終わったので一から書き直している.
何がどう駄目だったかと言えば
「幾らDrawCallを減らす為とはいえメインメモリからD3Dバッファへの転送を毎フレームやっていたのではCPU側が重い」
という事.勿論数フレームに渡って更新するのも試してみたが今度は違和感がありすぎる.
キャラクターは60fpsなのに背景は10fpsとか.
MDシルフィード10面の背景と言えばわかるだろうか.
見た目はちょっと面白いからそのうち動画上げるか.
まぁでも
「DrawCallを極力減らした方が,多少無駄なポリゴンが描画されようと軽い」
というのは分かった.
そもそも視点の向きはFPSの場合特に激しく変化する物だから
視線方向に依存した最適化は無理があった訳だね.
「DrawCallを極力減らした方が,多少無駄なポリゴンが描画されようと軽い」
というのは分かった.
そもそも視点の向きはFPSの場合特に激しく変化する物だから
視線方向に依存した最適化は無理があった訳だね.
で,今度は視点から一定距離以内のタイルを全てD3Dバッファへ転送する方針で組んでいる.
D3Dバッファを上下左右(本当は上要らないが)の6面 * LODのレベル分用意し
視点の方向に応じて描画するかしないか判断する.
当然前のアルゴリズムより処理するタイル数が多くなるが
そこは10フレーム程度かけて負荷を分散する.
後はちょっと動かしてみない限り何とも言えない・・
D3Dバッファを上下左右(本当は上要らないが)の6面 * LODのレベル分用意し
視点の方向に応じて描画するかしないか判断する.
当然前のアルゴリズムより処理するタイル数が多くなるが
そこは10フレーム程度かけて負荷を分散する.
後はちょっと動かしてみない限り何とも言えない・・
というか進んでない主な原因はQtフレームワークに手を出してしまったからな気がする.
プログラミングやっててGUIもロクに出せないようでは格好がつかない.
前々からゲームに関連するツールを作ってみたくてC#を触っていた時期もあったけど結局普段使わなくて忘れた.
QtならC++でクロスプラットフォームだし良いかなと.
プログラミングやっててGUIもロクに出せないようでは格好がつかない.
前々からゲームに関連するツールを作ってみたくてC#を触っていた時期もあったけど結局普段使わなくて忘れた.
QtならC++でクロスプラットフォームだし良いかなと.
(2012/04/12)
少し空いてしまった.
現在,無限平面を”ちゃんと”実現する為の作業中.
前までやってたような視点の周りにテキトーに頂点を配置するのではなく
予め格子状に分割したタイルを視錐台を使って見える範囲だけ距離に応じて簡易化したジオメトリを描画する・・・
(無論これは地形にも使う予定)
で,見栄えのしないスクリーンショットを貼ってみる.
現在,無限平面を”ちゃんと”実現する為の作業中.
前までやってたような視点の周りにテキトーに頂点を配置するのではなく
予め格子状に分割したタイルを視錐台を使って見える範囲だけ距離に応じて簡易化したジオメトリを描画する・・・
(無論これは地形にも使う予定)
で,見栄えのしないスクリーンショットを貼ってみる.
分かり易いようにワイヤーフレーム描画,可視距離も近めに設定してみた.
遠くのタイルはモザイク上に欠け(可視距離限界),手前の方はジオメトリが細かくなっているのがわかるかなと.
.....等と言われてもいまいちピンと来ないと思うのでタイルの境界を緑線で示すとこうなる
遠くのタイルはモザイク上に欠け(可視距離限界),手前の方はジオメトリが細かくなっているのがわかるかなと.
.....等と言われてもいまいちピンと来ないと思うのでタイルの境界を緑線で示すとこうなる
分割度が異なるタイル間も巧く繋がっている.
ちなみにこの手法(?)はGame Programming Gems2に載ってるから持ってる人はそっちの方が詳しい.
ちなみにこの手法(?)はGame Programming Gems2に載ってるから持ってる人はそっちの方が詳しい.
さて気になる描画負荷であるが
現在の実装ではタイル一枚毎に本体のDrawCallが1回,
隣接タイルの分割度が異なる場合はリンクの描画で更に1回,
更にこれが4方向全てだと最悪のケースでタイル1枚につき5回となる.
タイルの見かけ上の大きさをどうするかにも依るが1画面で60枚程度だとすると最大300回,少なく見積もっても100回程度になるだろうか.
現在の実装ではタイル一枚毎に本体のDrawCallが1回,
隣接タイルの分割度が異なる場合はリンクの描画で更に1回,
更にこれが4方向全てだと最悪のケースでタイル1枚につき5回となる.
タイルの見かけ上の大きさをどうするかにも依るが1画面で60枚程度だとすると最大300回,少なく見積もっても100回程度になるだろうか.
地形だけで100回・・・DrawCall回数がどの程度パフォーマンスに影響するかは環境によりけりとはいえ
以前海面を描画した時にDrawCall1回の1万ポリゴン超(頂点遷移あり)がデバッグビルドの時点で100fps程度出ていた(Radeon HD4770)のに対し
上に挙げたスクリーンショットのような地形(頂点遷移なし)で30fpsを割ってしまう事から考えると
最大でも20回,理想的には5,6回程度に抑えたい.
(あとこれは自分の想像なのであるがDeferred Renderingを用いた場合はForward Rendering時に比べ
レンダーターゲットを複数出力する関係でDrawCall回数の影響が更に大きいのではないか?)
毎フレームか一定フレーム毎に描画対象の頂点データを連結してバッファに格納,DrawCallで一括描画の方が
コピーの負荷考えても軽そうだ.
以前海面を描画した時にDrawCall1回の1万ポリゴン超(頂点遷移あり)がデバッグビルドの時点で100fps程度出ていた(Radeon HD4770)のに対し
上に挙げたスクリーンショットのような地形(頂点遷移なし)で30fpsを割ってしまう事から考えると
最大でも20回,理想的には5,6回程度に抑えたい.
(あとこれは自分の想像なのであるがDeferred Renderingを用いた場合はForward Rendering時に比べ
レンダーターゲットを複数出力する関係でDrawCall回数の影響が更に大きいのではないか?)
毎フレームか一定フレーム毎に描画対象の頂点データを連結してバッファに格納,DrawCallで一括描画の方が
コピーの負荷考えても軽そうだ.
(2012/04/06)
ううむ
ひとまず反射させてみた・・・のだが.
まあ,ねえ.いいんだけどねぇ.
波が頂点変位のみでしかもおとなし目になってるからかもしれないが
パッと見「これならまだ法線マップだけで行けそうじゃね?」というのは正直思う所である.
遠景だったら以前の奴の方がマシかもとさえ.
まあ,ねえ.いいんだけどねぇ.
波が頂点変位のみでしかもおとなし目になってるからかもしれないが
パッと見「これならまだ法線マップだけで行けそうじゃね?」というのは正直思う所である.
遠景だったら以前の奴の方がマシかもとさえ.
これに法線マップ足したら何とかなるんだろうか?もうどうしたらいいかわからん.
わからんっつって立ち止まってても埒があかないので
海面の高さは0固定でハードコーディングしてしまってるのでそれを直すのと
コレ
海面の高さは0固定でハードコーディングしてしまってるのでそれを直すのと
コレ
の修正でもしながら次の一手を考える.(ハーフライフ2の初期バージョンであった気がする.懐かしい)
あと無限平面化.
あと無限平面化.
#追記
そもそも法線マップのみの場合と違って頂点が上下するから反射マップをレンダリングする時に
海面の基準XZ平面でクリップしちゃ駄目っぽいね.
ステンシルでなんとか出来そうだが,もっと簡単にやるなら平面のマージンを取るのか?
大体からして反射と屈折マップを一枚で済ませてる訳で,多少の不具合は気にしてないし.
海面の基準XZ平面でクリップしちゃ駄目っぽいね.
ステンシルでなんとか出来そうだが,もっと簡単にやるなら平面のマージンを取るのか?
大体からして反射と屈折マップを一枚で済ませてる訳で,多少の不具合は気にしてないし.
(2012/04/05)
まあまあ
一応それっぽくはなったが・・・後は無限平面化と映り込みの再現でどうなるかだな.
数値を変えればもっと波を細かくするのは可能.
数値を変えればもっと波を細かくするのは可能.
市販ゲームの動画見てると波しぶきはデカール的なポリゴン切り抜き & 重ね張りなのかな?そんな気がする.
(2012/04/03)
基本に戻って
海もどきが納得行かな過ぎて耐えられないので今度は文献を読みながらちゃんとやる.GPU Gemsの最初のアーティクル.
VTFなんて要らなかったんや.ピクセルシェーダーのそれよりもコストが高いらしいし.
放射状の頂点配置も特に利点が無い気がする.
VTFなんて要らなかったんや.ピクセルシェーダーのそれよりもコストが高いらしいし.
放射状の頂点配置も特に利点が無い気がする.
(2012/04/02)
海(続き)
力量の限界を感じた.これ以上はHDRでないとどうしようもない.
光源の位置が高い時:昼など
光源の位置が高い時:昼など
光源が低い時:夕方など
空の色がそのまんまなのはツッコミ無しで.
にしても折角VTFを使っているのにでこぼこ感が少ない気がする.
波が複雑なときは高さ遷移を押さえ海面ポリゴンの数を増やさないと破綻するというのもあるが,じゃあ波を穏やかにしてうねらせたらどうなるのっと.
にしても折角VTFを使っているのにでこぼこ感が少ない気がする.
波が複雑なときは高さ遷移を押さえ海面ポリゴンの数を増やさないと破綻するというのもあるが,じゃあ波を穏やかにしてうねらせたらどうなるのっと.
他のハイクオリティな動画を幾つか見て気付いた事を踏まえると
多分HDRをやって,メッシュを思い切り細かくしてハイトマップテクスチャもノイズを適当に加工したのじゃなくてちゃんとしたの用意して,
波が高くなってる所に泡立ってる見た目のテクスチャを適用したら変わるんじゃないかと思うが・・・まぁそこまでは.
海面のメッシュもGems3に載ってた視点から放射状に配置するのではなく普通に格子状でも良さそう.
多分HDRをやって,メッシュを思い切り細かくしてハイトマップテクスチャもノイズを適当に加工したのじゃなくてちゃんとしたの用意して,
波が高くなってる所に泡立ってる見た目のテクスチャを適用したら変わるんじゃないかと思うが・・・まぁそこまでは.
海面のメッシュもGems3に載ってた視点から放射状に配置するのではなく普通に格子状でも良さそう.
しかし,ちょっと納得いかないなぁ
とりあえず動的反射を入れたい.
とりあえず動的反射を入れたい.