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

(2012/11/30)

大体できた

こればっかやって（というかサボってて？）ゲーム制作が全然進んでないのが気になるが
試行錯誤の末に割といい感じに仕上がった。

いやぁ、何度諦めてキューブマップにしかけた事か。
ぶっちゃけこれでも光源が限りなく壁に近づいた時に不具合出ると思うが
それはそれで分割アルゴリズムは他に使いまわせるかも知れないし、モノができて安心した。
ポリゴン数は元が451で分割後は1345と、許容範囲内だ。

ただ・・・相変わらず広い部屋ではポリゴン数が増えまくるので分割する回数を制限したりなんなりが必要だろうか。

ときにCGの分野において
他の物体に影を落とす物体を「キャスタ」、他の物体の影が落ちる物体を「レシーバ」と言うのだが
（現実世界では全ての物体は両方に属する）
シャドウマップの深度を描画する際に対象となるのはキャスタのみなのでキャスタが細かければ非線形写像による
不具合は目立たない。
論文等ではあくまでもサンプルのためかキャスタ（球や円柱など）とレシーバ（立方体の部屋とか）が明確に分かれてる事が多く
このため論文の画像を見ただけだとゲームでそのまま使えると勘違いしやすいと思われる。
一応よく読めばキャスタのポリゴンが荒いと影がうまく出ないケースがあるよと書いてあるのだが。

結局はキューブマップの利便性と品質をとるか、DualParaboloidの速度やメモリ帯域をとるかのトレードオフなのだろう

次の予定

はい、そうですね。さっさと影を完成させますか。

(2012/11/28)

ポリゴン分割

実はデータが間違っているのに気づかず散々時間潰したけど一応ポリゴン分割してみた。
でもまだポリゴンの大きさで一様にやってるだけなんで
凄く広い部屋とか出てきたらすぐに頂点数が6万個以上になって死ぬ。
このサンプルにしても元は450ポリゴンなのに分割後はなんと2万である。最適化してないとはいえ、アホかと。

現状、エッジの長さのみで分割するか判断してるんだけど
これをもうちょっとマシにする手法としては
隣接するポリゴンの法線を比べて平らなら分割しない、谷折りの状態だったら程々に分割する、山折りなら通常通り・・くらいだろうか？
やってみないとわからんが。
しかしいくら平らでも広い床とかは少しは分割したほうが良いよなぁ。
じゃあ面積も考慮に入れて一定以上の広さだったらポリゴンの重心に1つ頂点を追加、
エッジも長すぎるようなら分けないと・・

最終的には多くても3000ポリゴンに収めたい。

(2012/11/24)

シェーダーのリアルタイム書き換え

最近思うんだけど、折角処理速度を犠牲にしてスクリプト言語を導入したのに
確かに再コンパイルの必要は無くなるもののプログラム自体が混み入ってくると
起動して画面が出るまでに15秒以上とかザラな訳で。デバッグビルドだし。
例えばちょっとライトのパラメータを調整したいだけなのにその都度プログラムを再起動しなくちゃならない。
これじゃあ前とあまり変わらないなあと。

UnityとかWebGLの、とある（名前忘れた）プログラム見てるとスクリプトを書き換えて保存したら即座に反映される仕組みになっていて、あれは良いなあと。
というかあそこまでしなくちゃスクリプトの魅力半減だろうと。

前々回の記事で全方位シャドウが頓挫してしまったのでついカッとなって
前々からやりたかったシリーズを発動。今回は「リアルタイムのスクリプト反映」
実はスクリプトは今やってる最中だけどシェーダーはなんとか完了。
ファイルやフォルダの書き換え検知方法からその後のファイルツリー比較までザザっと書いた。
とはいえ主に詰まったのはマルチスレッド関連だったりする。
リソースマネージャを組んだ時点では、たかがデュアルコアしか持ってなかったのもあり
「どうせ並列化してもデュアルだし」とほとんど考慮に入れなかったマルチスレッドを後から入れたのだから想像はつくだろう。
詳しく書いたところで双方退屈だろうからやめておく。

次の作業

無論、スクリプトのリアルタイム更新。
手を伸ばせばテクスチャの更新やモデルの更新～～とキリがないので今回は見送り。
それが終わったらシャドウに戻る。

メモリ管理について

自作のメモリアロケータを、律儀にstd::vector<>とかに渡してると管理が面倒だしそれほど意味もない事に気づいたので
次にエンジンを組みなおす時は素直にグローバルのnew/deleteをオーバーライドする。
ぶっちゃけ論理メモリ空間なPCとかじゃメモリのフラグメント減らしたところで何？って感じだし
標準のnew/deleteで全く問題ない気さえする。
しかしページサイズが2Kbだとすればやっぱり30byteだか100byteだかのメモリ確保はフラグメント減らしたほうが効率良いの？う～む。よくわからん

(2012/11/22)

取り急ぎ

前回は非常に残念だったので気晴らしに別の部分を組んでいる。詳細は次回にでも。

影についてあの後少し考えてみた。
マップをローポリのまま歪みを改善するのは（少なくとも自分の技術、知識では）早々に無理と判断。
じゃあ別の手段を・・と思いついた対処法は「ハイポリで描画」

結局それか！
元も子もない感じだが、多くの論文のサンプル画像に見られるようハイポリなら歪みは抑えられる。
ただしよくよく考えればハイポリ描画は深度の時だけで良いし
光源からの角度によってはハイポリで描画する必要も無い。
モデルを読み込んだ時に内部で適度な大きさで面分割しておいて、要るのは頂点位置だけなのでデータも小さく抑えられそうだ。更に詰めようと思えば16ビット浮動小数点数という手もある。
で、必要に応じてハイポリか元のモデルか決める。

モデル自体は特にDualParaboloid意識せず普通に作るけど読み込んだ時に自動で分割っていうのがポイントか。
後半の高速化の所は面倒だからやらないと思うけど
この方法ならいけるか。
更に言えばキャラクターはマップに比べればメッシュが元々細かい場合が多いからマップだけ一工夫すればいいのかもしれない。

(2012/11/20)

非線形変換は曲者

みんなちょっと静かに聞いてくれ
今日は先生からちょっと残念な話がある

ローポリでDualParaboloidは　キツかった

LightPrePassまでしたのに歪みは直らなかった

先生は計算式を疑うのは情けない
「ポリゴン数を増やせばいい」なんて思いたくもない

しかし　影の形は　歪だった

---

段々と真面目に更新する気が無くなってきた。

ネットのサンプルを見るとピクセル単位でUVを算出してるが、これだと
深度描画の時は頂点単位で変換してるのに参照はピクセル単位となるのでズレが生ずる事は前々からわかっていた。
(背景のポリゴン数を増やせばマシになる。ネットのデモは平面の床に見えてもポリゴン分割されてる事が多い)
じゃあUV算出も頂点単位でやれば～とか思ったのだろうか？過去の自分は。
少し冷静に考えればわかるが勿論そうは問屋が卸さない。だって元々非線形な変換してるから。
壮大な時間の無駄というか、なんというか・・・

ま、もうちょっと悪あがきしてから考える。

(2012/11/19)

自前クライアント

もうすっかり忘れられた頃であろう、自前Twitterクライアント。
現状出来ることといえば投稿とTLの回覧程度なので自分で使ってるだけなのだが。
開発のモチベーションが上がらない主な要因として「linux上でwindowsバイナリをコンパイルする手段がわからない」というのがあった。
もちろんソースだけwindowsに持っていってそこでコンパイルすれば動く訳だが。いくつかそうしたくない理由もあって

• Qtの開発環境を2つ構築するのは面倒くさい
• Win版QtのMingwが4.4と少し古い

ラムダ式や範囲for文に慣れてしまった身としては特に2番目が大きい。
試しにMingwだけ入れ替えたりもしたがダメだった。

Linux上でクロスコンパイラのビルド方法から始まり
QtをLinux上でWin向けにビルドしてみたがよくわからんundefined referenceが頻出し
自力でどうにかしようとソースに編集入れてみたりしたけど技術が足りないせいかこれも断念。
（掲示板を見る限り向こうとしても「WinのQtはWinでビルドしろよ」なスタンス？）
じゃあWinのプリビルドなQtをインストールしたらフォルダごとLinuxに持って行って
あらかじめビルドしておいたmingw32も用いつつqmakespecをwin32-g++にセットし、アプリケーションをビルド・・
っとQtは例外方式がdwarf2でビルドしてあってこっちのmingw32はsjljだ -> gccをdwarf2で作り直し

裏ではもう少し色々手間取ってはいるが大体こんな調子で進め、つい先ほどwindows上での動作に成功した。

といってもテンプレを動かした程度だが。
じゃあ自前Twitterクライアントはどうだ？と

ネットワーク関連で何かがコケている模様。
ただ、この状況はLinux上で動かしてた時にも遭遇した記憶がある。
とにかく以前は動きもしなかったのだから進歩である。

(2012/11/16)

2012へ

VisualStudio2012では現在XPのバイナリを正式には作れないので
2010で暫く開発を続けるか、それとも思い切って2012にするか・・・
なんて悩んでる内に面倒臭くなったのでえいやっと移行してしまった。
何よりウィンドウを移動する際にゴミが残ったりInteliSenseが固まったりが無いのがうれしい。
(メインで使うwindowsとしてxpより8を起動する事が多くなったのもある)
XP用には例のベータなパッチでビルドした物を自環境のXPにて動作確認する方向で。
このページを見ている人はどのOSを使っているのか分布を知りたい。
ちなみにsteamの統計を見るにXPはwindows全体の15%程度の様だ。
正確には”steamでゲームやるようなゲーマー”の15%だと。多いと見るか少ないと見るかは人によりけりだろうか。

そしてもう一つ悩み事が。
いつまでXP環境をサポートするか、すなわちDirectX11にするかどうか。更にOpenGL4.0とどっちがいいかな等と。
正直DirectX9のAPIも設計に古臭さを感じる部分が多々あるのでどちらかに移行したい気持ちは強い。
パフォーマンス的にもDX9よりDX11の方が良いみたいだし。
ただいずれにせよDX11を勉強してからでないと何とも言えず。

(2012/11/15)

進み具合

またペースが落ちてきた．原因は円錐の2D矩形算出のバグ取り，それと「円柱と線分」「円錐と線分」の交点を
ちゃんと方程式をたてて解く（紙とペンで）という高校でやった時以来な事をしていたので
数学のちょっとした復習とかも含め時間を取られてしまった．
3Dプログラマたるもの，このくらいちょちょいと出来なければ格好悪いと思ったのもあり．
ゲーム自体は前回から大して進んでない．当たり判定関数の整備とかしたくらい．

本当の理由

数学もそうだがもう一つ復習している事があって，それはニューラルネットワークや強化学習といったAIに使われるアルゴリズム．
とりあえずバックプロパゲーションとホップフィールドネットワークのプログラムを組んで動作確認して
今は自己組織化マップ等．あとLVQまでサッと見たら強化学習のQ-Learningとかに行く．
何の為か？言わずもがなですな．

P.S.

VisualStudio2012でも例のパッチあてないとクラスのunionやinitializer_listや可変テンプレートに対応してないようで・・
パッチ当てない状態での移行はInteliSenseしかメリットがなさそう

(2012/11/11)

まずは

スポットライトをやってみた。という割にはガッツリ苦戦している訳だが。
そして汎用性を考慮して作ったはずのエンジン（ソース）ぐっちゃぐちゃ。これはひどい。

ところでライティングの段階において

1．スポットライトで作成する深度マップでは頂点に対して線形な変換をするので
カメラビューからライトビューとプロジェクションな行列を合計2つ用意しライトを覆う2D矩形を描画、
ピクセル毎にライト座標系での位置を求める
2．ライトが当たる可能性のあるモデルを再度ジオメトリ変換し、頂点に「ライト座標系での位置」を格納する。ピクセルシェーダーではそれを使う。

と、2種類アルゴリズムが浮かんだんだが（今回は1の方法）どっちが軽いんだろう？
ライティングでモデル頂点を何回も変換してたらDeferredLightingの意味があまりないような・・
ただZバッファは活用できるが。
ちなみに全方位影をDualParaboloidで実装する際は2の方法しかない。

スポットライトと全方位で描画方式違うって微妙な気もするし、正直どうしていいかわからん。

windows8

windows8はあのタッチパネル用UIを除いてアップグレードの値段も考慮すれば概ね良い感じ。
折角だからvisual studio2012をインストールして少し触ってみていた。
まぁメニューとかは大体2010と同じで、それより自分としてはインテリセンスが軽くなったのがデカい。
特に2010でないとダメな理由もないしさっさと移行してみるか・・？
と思いきや。XP上で動くバイナリが、まだベータ版なパッチをあてないと作れないようだ。
そんなわけで自作エンジンはもう少しvisual studio 2010で開発する。

(2012/11/10)

現状

中々思うように進まないので途中経過など。
DeferredLightingによる描画はすでに完了した。
といっても前とほぼ同じ画像が表示されるだけなのでスクリーンショットは省略。
現在は影の描画に使う深度バッファを作成する所。いや、深度を出力して終わりのハズだったんだが
スポットライト用のステンシルバッファを作ってライティングする際に
「はて？円錐を透視変換した後の2D矩形はどうやって求めるんだっけな」という段階で詰まってしまい
結構な時間を潰した。
ぶっちゃけそんなに厳密にやる必要ないので円錐を内包する四角錐で近似しても一向に構わないわけだが・・（いつもの悪い癖だ）
しかも結局これといったアルゴリズムを思いつかなくて四角錐だし！
まぁそんな感じでチマチマと進めている。
やっぱり基本的な微積分はできないと不味いなあと思った。

気になる事

いくつかネットに散らばってるパワポなどを見ていると
DeferredLightingは最初のパスで法線と深度、それとスペキュラ強度を出力するのが一般的なようだが
自分はついShadingの時の癖でマテリアル番号まで出力して、それをライティングで分岐してしまっている。
これじゃあまり意味がないので直さないとイカンな。

(2012/11/03)

バグ修正

先日のメモリリーク云々は生ポインタの管理ミスによる典型的なタイプだった．
FlyWeight関連だったのでとりあえずshared_ptrとweak_ptrに置き換えた．
ここらで古いコードを置き換えてRAIIの徹底，生ポインタの全廃（アロケータ以外），例外機構のフル活用と行きたい所だがグッとこらえて・・
前バージョンのエンジンと違ってそこそこ「動く」ことだし．

Windows8でDLLが無いと言われる件に関して

DirectX9のSDKを別途ダウンロードしてインストールしたら動いた．
windows8(もしかしてvistaや7も？)の人はSDKまでいかなくてもランタイムを自分でインストールして貰う必要がありそう．
http://www.microsoft.com/ja-jp/download/details.aspx?id=35

次の一手

現在DeferredLightingで描画する為の仕様決めを進めている．
レンダーターゲットのフォーマットとシェーダーを差し替えれば行けそうな感じだけど，どうなる事やら．
もし上手く行って1ボタンでDeferredShadingとDeferredLightingを切り替えられたら楽しいし
何より自分のテンションが上がる．
それと，今の実装では半透明物体のライティングがされていない．
この点についてもDeferredLightingで対応出来そうなきがするが，なんにせよ重そうだ．
元々の理由はOmniDirectionalな影付きライトがDualParaboloidで実装できる(描画が2回で済む)だけど．

(2012/11/02)

デモ公開

またしてもマイナーチェンジで、HDRの追加。
内部的にはRTフォーマット定義の拡張、管理の効率化などやっているが見えるのはそれだけ。
トーンマッピングやブルームエフェクトも前にやったので特に説明する事はないかな・・
デモの公開ペースとしてはまずまずか。

予定

自分用マイルストーンメモでは

<demo_v0057>
・DeferredShadingからDeferredLighting(Light Pre-Pass)へレンダリング方式を変更して
DualParaboloidによる影付き全方位光源を実装
・（余裕があればスポットライトを実装）
・マップを、影の効果がわかりやすいような形状へ一新

<demo_v0058>
・モーション補間の動作確認とサンプル作成

<demo_v0100>
・FPS風に歩く & 床や壁とのごくごく基本的な当たり判定。ジャンプなどは無し

<demo_v0101>
・銃を描画し、撃つ処理（線分の当たり判定やフラッシュエフェクト）

<demo_v0102>
・射撃場風マップと的を追加し、得点など出すミニゲーム（？）

<demo_v0103>
・細い足場を歩くとか、登れない坂は滑り落ちるとかのdemo_v0100より踏み込んだ当たり判定。ジャンプや覗き込みなど

ざっとこんなもんである。
もう少し書きたい事はあれど、とりあえず先日書いた「ライト出す度にメモリリークしてる」不具合を直すのが先か。

(2012/11/01)

HDRの出来損ない

調整が足りなくて単に白飛びしてるようにも見える．まぁそれでも現時点で「っぽく」はなっているか．
トーンマッピングした後に輝度が一定以上のピクセルにブルームかけるという，昔ながらの手法だ．

あと気になる箇所

• レンダーターゲットの定義方法について増改築を繰り返し過ぎて軽くカオス
• シェーダーの変数定義も上と同じで無駄がありすぎる

思った事

• 結局シェーダー関係は動的リンクを使用しない限り汚くなるのがわかりきっているので下手にスマートに書こうとせず素直にベタ書きしていった方が早いのでは？
• 前回レンダーターゲットのサイズについてちょっと触れたがやはり面倒だから2の累乗にしなくていいや
• MRTにおける各サーフェスのサイズはキッチリ同じにしないといけないらしい（ビューポート指定で小さい領域を指定してもデバッグランタイムでエラーを食らう）

その後・・

左が暗いところから移動した直後，右が少し時間経った後

ブルームの具合はこんな感じ