FPSを作ってみる@wiki
02)
最終更新:
slice
-
view
clipmap
相変わらずこんな感じでポリゴンとにらめっこしてるという。
結局前回触れたような地形描画は使わないことに…って書こうとしたらそんな記事なかった!サボりすぎだ。
レイリー&ミー散乱の後に地形をやるか海にするか迷って、
まあどちらにせよハイトマップをLODも含めて描画する機構は必要だろうという事で
古いGame Programming Gemsに載ってたシェーダーを使わない方法
https://vine.co/v/iMgmP13eQ71
にて実装してみたけど、これは見ての通りCPUでどのタイルをどんな詳細度で描画するかを決め、
描画コールも1タイル毎に行っているし何より一瞬で詳細度が切り替わって見た目が宜しくないし
フィールドに敷き詰める1つのタイルが大きければ瞬時に切り替わる面積が大きく、
タイルを小さくすればCPU&GPU負荷が高くなるというジレンマがあった。
視野カリングにしてもCPUで1マス毎だし、折角GPUがあるのに固定機能しか使ってないというのが勿体ない。
レイリー&ミー散乱の後に地形をやるか海にするか迷って、
まあどちらにせよハイトマップをLODも含めて描画する機構は必要だろうという事で
古いGame Programming Gemsに載ってたシェーダーを使わない方法
https://vine.co/v/iMgmP13eQ71
にて実装してみたけど、これは見ての通りCPUでどのタイルをどんな詳細度で描画するかを決め、
描画コールも1タイル毎に行っているし何より一瞬で詳細度が切り替わって見た目が宜しくないし
フィールドに敷き詰める1つのタイルが大きければ瞬時に切り替わる面積が大きく、
タイルを小さくすればCPU&GPU負荷が高くなるというジレンマがあった。
視野カリングにしてもCPUで1マス毎だし、折角GPUがあるのに固定機能しか使ってないというのが勿体ない。
って訳で第二弾。
https://vine.co/v/iOmFpwvtB6z
こんな感じで係数によって滑らかにポリゴン数と高さの値が変化するようにしておいて
後は頂点シェーダでカメラの距離に応じてそれぞれ変化させれば…と思った。
画像が無くて申し訳ないがこの試みはある程度うまく行き、
見た目ではわからないくらいの変化で徐々に低解像度からポリゴンがせり出してくる様は見ていて面白かった。
が、前述の視点が動く度に1タイルずつCPUで詳細度のチェックを行い〜というのは変わらずなので
「結局タイルを何マス敷き詰めればいいの?」 ->
地平線を埋めるくらいだと最低でも一辺が128位は必要なので描画コール数を考えるだけで死ねる。
最近のGPUは頂点数が多かろうが描画コールさえ減らせば結構フレーム数が出るし、
遠くを濃い目のフォグで誤魔化すならLODなんて面倒な事やらんでいいじゃんとなってボツ。
ここまでが先月。
https://vine.co/v/iOmFpwvtB6z
こんな感じで係数によって滑らかにポリゴン数と高さの値が変化するようにしておいて
後は頂点シェーダでカメラの距離に応じてそれぞれ変化させれば…と思った。
画像が無くて申し訳ないがこの試みはある程度うまく行き、
見た目ではわからないくらいの変化で徐々に低解像度からポリゴンがせり出してくる様は見ていて面白かった。
が、前述の視点が動く度に1タイルずつCPUで詳細度のチェックを行い〜というのは変わらずなので
「結局タイルを何マス敷き詰めればいいの?」 ->
地平線を埋めるくらいだと最低でも一辺が128位は必要なので描画コール数を考えるだけで死ねる。
最近のGPUは頂点数が多かろうが描画コールさえ減らせば結構フレーム数が出るし、
遠くを濃い目のフォグで誤魔化すならLODなんて面倒な事やらんでいいじゃんとなってボツ。
ここまでが先月。
ところで前に海面描画した時は視点から放射線状に頂点を配置し、
テクスチャからその位置に対応した高さを拾って適用していたんだけど今回は最初からその方法は考慮しなかった。
何故かといえば視点とのXZ座標軸において相対的な位置関係を固定した頂点が、その高さ(Y)だけ変化するので
視点が動いた時だけポリゴンが不自然に「うにょうにょ」変形し近くで見ると明らかに違和感を感じるレベルだったから。
常に動いている海面でさえこれなので地形になんかとても使えたものではないかと。
ただ構造がシンプルだしシミュレーションゲームで海面を遠くからしか見ない場合は十分使えるし、
実際そういうゲームもあるみたいなので決して駄目なアルゴリズムではない。
テクスチャからその位置に対応した高さを拾って適用していたんだけど今回は最初からその方法は考慮しなかった。
何故かといえば視点とのXZ座標軸において相対的な位置関係を固定した頂点が、その高さ(Y)だけ変化するので
視点が動いた時だけポリゴンが不自然に「うにょうにょ」変形し近くで見ると明らかに違和感を感じるレベルだったから。
常に動いている海面でさえこれなので地形になんかとても使えたものではないかと。
ただ構造がシンプルだしシミュレーションゲームで海面を遠くからしか見ない場合は十分使えるし、
実際そういうゲームもあるみたいなので決して駄目なアルゴリズムではない。
で、何でわざわざそれに触れたかというとこの「視点との相対位置が常に固定の頂点」というアイデアは結構優れていて
描画カリングは方向についてだけ行えばいいし予めポリゴンを適度に分割しておけるしで効率的、
地平線いっぱいに地形を描画したい時でもカメラのFar距離まで展開しておけばいいので管理も楽なのである。
あとはうにょうにょ動くのだけ何とか出来れば最強なのに…!
と思ったら既にあった。やっと本題。
http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter02.html
GPU Gems2に載ってるClipmapという手法で、そのスクリーンショットがこの記事の一番最初のソレ。
ワイヤーフレームの動画も一応上げてある。
https://vine.co/v/i1BTIvBb3X7
描画カリングは方向についてだけ行えばいいし予めポリゴンを適度に分割しておけるしで効率的、
地平線いっぱいに地形を描画したい時でもカメラのFar距離まで展開しておけばいいので管理も楽なのである。
あとはうにょうにょ動くのだけ何とか出来れば最強なのに…!
と思ったら既にあった。やっと本題。
http://http.developer.nvidia.com/GPUGems2/gpugems2_chapter02.html
GPU Gems2に載ってるClipmapという手法で、そのスクリーンショットがこの記事の一番最初のソレ。
ワイヤーフレームの動画も一応上げてある。
https://vine.co/v/i1BTIvBb3X7
見ての通り、サインカーブを無限平面で描画してみた。
上記の動画ではデバッグの為、ワイヤーフレームだったのでタイルの切り替えがはっきり分かってしまうが
実際にポリゴンフィルすれば分からない。
上記の動画ではデバッグの為、ワイヤーフレームだったのでタイルの切り替えがはっきり分かってしまうが
実際にポリゴンフィルすれば分からない。
視点に沿って移動しカリングが容易、無限平面を表現可能で、しかもウネウネ動かない。と三拍子揃って
ハイトマップ描画に関しては最強だと思う。ただ実装は手軽とは言えない。
(具体的にどんな事をしてるか等は既に記事が長いし解説の気力が持たなかったので次回?)
ハイトマップ描画に関しては最強だと思う。ただ実装は手軽とは言えない。
(具体的にどんな事をしてるか等は既に記事が長いし解説の気力が持たなかったので次回?)
添付ファイル