進捗状況(2009/04) - FPSを作ってみる@wiki

(2009/04/21)

トップページが頻繁に更新されてるのを見ればわかるかもしれないが、
特に理由は無いが少々急ぎ気味でグラフィック関連のおさらいをしている。
実装したらその都度目に見える形で結果が出る、ついでにwikiにも乗せられる
のはやる気の持続という点では非常に良いですな。
今は水面処理やってたりする。もうちょっとでそれなりのエフェクトになるかも。

で、こうして色々やってくと自然にグラフィックカードが欲しくなるのはお約束なのだろうか？
買うとしてもどの程度のカードか迷う。迷いまくる。
やっぱGeForceなのか。Radeonも好きなんだが。
GeForce8000番台以降は物理演算補助機能があるっぽいし(統合されたPhysXのこと)
あとGPGPUにも興味あるし。

バリバリにゲームやらなそうなので予算は一万前後かな～
プログラミングの間にちょくちょく調べてあたりをつけておこうか
(補助電源コネクタ付いてるのは遠慮しとく方向で)
GeForce9600GTの省電力版が狙い目かな

(2009/04/18)

STGばっかりだったしFPSっぽい事もしなきゃ。
てなわけで個人的にリアルタイムシャドウの大革命だと思っているVariance Shadow Mapというのを実装してみた。
途中で致命的な単純ミスを2つも犯してしまったのでえらく時間食った。
(何が致命的かというと解決するまでの時間が致命的。勘違いとも言う)

というかこの実装考えた人スゲー
それまでリアルタイムシャドウといえばDOOM3のような超シャープな物(シャドウボリューム)か、輪郭のギザギザが当たり前(シャドウバッファ)だったのが
このシャドウバッファの影判定に細工をする技術によって解決してしまったわけだ。
次は弾痕のパララクスマッピングしようかな。

(2009/04/18)

そういえばFPS動画その2で弾痕をバンプマップの親戚であるパララクスマップで表現したら・・・という
意見が出てたっけ。多分やります。やりますとも。
F.E.A.Rでやってたもんね。

でもマップにもそれを、となるとちょっと難儀するかなあ。
マップポリゴンにバンプマップを掛けるならともかく、パララクスマップを掛けるとなると
パラメタの調整を重ねないとヌメッとした質感になってしまって
なんか、壁や床が物凄い熱で溶けたんじゃないかという印象を受けるからです。
例としてはどっかから拾ってきた画像とか、わかりやすいかも。
いやまあこれは極端な例ですけどね。

それとは別に、弾痕を消すタイミングが難しいな～
全部残しとくわけにもいかんだろうし。かといってすぐ消えてるのも不自然だし。
対戦系のゲームでは通信負荷が問題になるのか、30秒くらいでスーっと消えたりしてるなあ。
通信プレイ中では仕方ない所だろうが、シングルプレイでは・・・・？
処理時間の余裕を見て一つのバッファに纏めるかなあ。

(2009/04/14)

今何やってるかっていうと、シャドウマップ（初期の実装で、ジャギが目立つ）の実装だったりする。
理由は特に無くてなんかそろそろやりたくなったから、やってる。
別に珍しい技術じゃなくて、逆に箱○とかPS3で出る今時のゲームは淵のぼかし処理を含めて
やってないとm9(^Д^)ﾌﾟｷﾞｬｰされてしまうのだろう。
－－－と思ったらSource Engineは対応してなかったっけ。あれは投影シャドウだったかな？
Left4Deadやってたときに銃やフラッシュライトがリアルタイムに影を計算されてない気がした。まあいいか。
なんにしてもオプションで切り替えして負荷を調節出来るのがベストだと思っております。

で、実装自体はそんなに難しくなくってどっかから論文なりwebサイトを探してきてサンプル通りやれば大体出来る。
(と言いつつパラメタ設定ミスって中々上手く動かなかったり)
でも理論を理解しておかないと応用が利かないから自分的に困る。
力仕事ページにサイトのURLを幾つか載せておいたけど
そこの説明がわかりやすくていいですね。っていうか皆さん凄いですね。

一応60fps(2009/04/09)

実験の結果一応60fps達成したところでジオメトリ(ryに関しては終了。
ソフトウェア頂点処理しか出来ない環境なのでハードウェア頂点処理の時の挙動がわからん！
これ以上は何かしらのビデオカード買わないとどうにも。

それはそれとして。次回のソース書き直しで
モーションブラーとかのエフェクト掛ける場合にフレームワークどうしようかね～とか考えてたり。
もちろんピクセル単位ライティングとリアルタイムシャドウ、HDR表現、水面エフェクト等も視野に入れて。あと被写界深度だっけ？そんなのも。
物理演算(剛体シミュ)は放置。まだそのレベルまで行かんと思う。

相変わらず動画作るにはまだ素材が足らないのでチマチマ作成中。

単純ミス(2009/04/08)

あ～やってもうた......
モデルの読み込みの時に複数のメッシュに含まれる頂点を一本の頂点データに変換するルーチンで
頂点インデックスのオフセットかますの忘れて最初のメッシュだけ正常に描画されてあとのはぐちゃぐちゃに。
結果を書けばこれだけなんだけど。一日近く無駄にしたか情けない。
ともあれまだインスタンシングやってないけど、関節に属するモデル数分ではなくモデル1体につき1回描画コールになった。
それにより関節が10個ある物体を10体描画したら30fpsに落ち込んでいた所が54fpsへ改善した。
加えてジオメトリインスタンシング(勝手にGIって略そうとしたらGlobal Illuminationになってしまうな)をする事で
60fpsを保てるようになるか、どうか。

ジオメトリインスタンシング(2009/04/06)

あの後いくつか描画手順を試した結果
結論から言って「何度も描画命令を発行すると遅い」

DirectXの描画命令発行は予想以上に重い。
具体的な数値を用意できればよかったのだが面倒なので例え話で
あるオブジェクトAがあったとして
Aを2個分描画するよりもAの3倍のポリゴン数であるBを1個描画した方が軽い、みたいだ。
ただし自分の環境での実験結果(AMD690Gでソフトウェア処理の頂点シェーダー2.0、ピクセルシェーダーなしの条件)だからねえ。
ビデオカード使用時ではどの程度参考になるかわかったもんじゃあないが。
まぁ、まとめて描画した方がかえって遅い事はないと思う。

従って次にエンジンを作り直す時は纏めて描画することに重点を置いた設計にする方針で。
頂点バッファの切り替え、テクスチャの切り替えなんぞは大して意識しなくて良いのではないかと。

で、どんな感じでまとめて処理するかな～と調べたら
同じ形状のオブジェクトを位置や向きを変えて複数描画する場合にモデル形状は共有させて
姿勢情報だけとっかえひっかえして描画する、ジオメトリインスタンシングがDirectX9.0cから存在するようだ。
初代Far Cryの草木の描画で使用されている割と枯れた手法と言ってしまって良いかも知れない。

ところでMSDNの該当項目では使用するには頂点シェーダー3.0のサポートが必要って書いてあるけど、本当かね？
もし3.0でないと使えないとなれば行列を4個分ずつ設定して4個ずつ描画するとかで代用してみようか。

すまぬ、また来年(2009/04/05)

ああ、もう4月になってしまった。
4月1日に何かネタかませれば面白いなあと思って急いで作業してたけど目に見えて品質が低下していくので
来年って事で一つ。中途半端なのは嫌です。
申し訳ない。

今はアプリケーション終了時にVC++の
ランタイムデバッグルーチンで「メモリが破壊されてるぞｺﾞﾙｧ」というエラーが出るんで調査中。
なんだかバックグラウンドでリソースを読み込む処理を追加してからボチボチ出てる様なので面倒そうだ。

もう一つの問題は敵モデルを12，3体程出すと動作が凄い重い事。
これも色々試して調べてるんだけどイマイチ原因がつかめない。
描画が重いのかと踏んでテクスチャを1x1にしても、
頂点数（ポリゴン数）を削減しても殆ど変化が見られないのだ。
敵の動作処理だけやってモデルを全く描画しないと軽いのだが。

なので前に作った（というかGameProgrammingGems1に載ってるのと大部分同じ）プロファイラを
急遽改良実装して更なる原因究明へ乗り出した。
具体的には描画ポリゴン数、[頂点バッファ、インデックスバッファ、テクスチャ]の切り替え回数、
Vsync待ちにどの程度時間使ったかを表示するように改良した。
これを使ってもう少し詳しく調べられればいいな。