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

(2012/09/28)

進まないな

またしてもスタック．ライト軌道とアンビエント定数ライトはOK．
残りは透明物のソート・・・で終わりの筈が
マップに配置した透明物が縦に長い円柱形状 ->
中心座標でソートしてたんじゃ角度によっちゃ変になる ->
モデル頂点を内包する境界ボリュームの求め方って？　->
なるほど．主成分解析・・ ->
多項式や行列式や固有値の計算ルーチンを組む ->
連立一次方程式を解くルーチンも要るか・・ ->
解が一意に定まらない時の戻り値？どうするか << イマココ

とりあえず主成分解析の用途じゃ必ず解がα（任意の数）倍になるようだから
それだけカバーする方向で行くが．

主成分の軸からOABBや球や円柱を求める部分は既に書いた．
まぁ，境界ボリューム計算はどの道必要だから良しとしようかねぇ．

Qt関連

ついでにQtフレームワーク上でOpenGL表示などもやっていたり．ゲームのちょっとしたツールを作れたら楽しいかなと．
あとQt5の話は無しになった．暫く4.8.1で行く．というのも
LUbuntu上でQt5をビルドして実際動かしてみたんだけど自分が使ってる範囲じゃ4と変わらないのが1つ．
それとこっちのが理由として大きいのだけど「Qt5にするとQtCreatorのコマンド補完が効かない」って事．
という訳で今すぐQt5に移行する利点が見あたらない．
開発元は4から5の以降はなるべく楽になるようにすると言ってるし．

(2012/09/22)

もう少し

幾つかの「やる事」を済ませたらデモが出せる状態まで来た．
次回の目玉はモーション（軌道）によるカメラ制御と
今までライトが円運動しかしてないのは寂しかったので同じく軌道によるライト移動，
透明物体のソート強化，である．
内部的にはクォータニオンと回転行列の相互変換とか計算間違いしてるのを直したり
モーション再生ルーチンを書き直したりだの色々やっているものの
見た目で分かるのは，上に挙げたものだけ・・・

前回からの進捗

まず前回の軌道や姿勢の問題は殆ど解決した．
具体的にはモーションの補間は何も手を加えてないので上軸がずれる問題は相変わらずだが
フリールックモードへ移った時の上軸補正をちゃんとしてるから演出の一部と捉えれば変でもない（ちょい無理があるか）
対数クォータニオンで補間する案はまた次回という事で．

で，前述した「やる事」というのは

• 定数アンビエントライト

　　　カメラ・ライト軌道の導入にあたりもう少し広いマップが必要で，その時に
　　　暗闇が本当に真っ黒ではちょっと不都合なんで昔ながらの定数ライトを入れる

• ライト軌道

　　　ライトを軌道に沿って動かすだけ・・なのだが．どうせなら軌道の断片を複数用意して
　　　接続点でどのルートに進むかランダムで決められたら面白いよね，と．

• 透明物のソート

　　　まだ未完成

定数アンビエントライトはすぐ終わるとして残りの2つはバグ取り含めるとどの位かかるかな？という感じ

その先の事

現状マップと言いつつモデルファイルを描画してるだけなんで
いい加減PVS含めたマップフォーマットを決めるべきだね．

(2012/09/20)

CPUを微妙にアップグレード

CPU(AthlonX2 5600+)を，PhanomII X4 955へ交換した．
とはいえCPU以外のマザボその他一式そのままという超妥協的アップグレードなので目に見えて
キビキビしてる印象は・・・どうだろう？
普段からデフラグや各種セッティングを気にするタイプなのもあってか少なくともWindowsXP上じゃ体感的な差はほぼない．
強いて言えばタスクマネージャで4コア表示されて優越感に浸れるくらい．
後はたまにするエンコでH264を選びやすくなったとか．

そもそも何で4コアかといえば
配信しながら裏で作業用BGMの動画を流しつつコンパイルすると重い（縮小とエンコで1コア位）というのと
先日触れたcygwinやlinux環境であれやこれやビルドする時の時間短縮，
それと一部のオープンワールド系ゲームが4コアに最適化されてる・・という理由だったんで満足感はぼちぼちである．

デモの予定が物凄い遅れてる件

急ぐつもりだが，1,2箇所詰まっている．
具体的にはカメラを軌道に沿って動かす場合に現在位置から軌道の一番近い所を調べて
そこからモーションを再生しつつ，カメラをその姿勢に近づけるようにクォータニオンの球面線形補間したら
例えば右へ90度回転すれば良い所を何故か逆から270度回転してしまう．
クォータニオンの軸が変になっている？

それと軌道に沿って動いてるカメラを通常のフリールック動作に戻す場合，Upベクトルがずれている
（いわゆるYaw Pitch RollのRollが入ってる）事があって，
補正するルーチンがまだイマイチな出来．
今は角度を考慮しながらRoll入った座標系をZ軸周りに何度回転させるかを求めるアプローチをとっているけど
最初にUpベクトルを(0,1,0)と決めて残りは外積で求める手もあるか．

ただ本末転倒だが「元からそんな変な軌道作らない」選択肢も，あるにはある．

#追記

というか元々Upベクトルが上の軌道を作った筈なのに再生したらUpベクトル傾いてるの何故～？と思っていたら
モーションを3次補間する際に平然とクォータニオンも成分毎補間しちゃってる事に気付いた．
クォータニオンの球面線形補間は有名だけど3次補間するにはどうすれば・・
対数クォータニオンか？（精度はともかく）

(2012/09/14)

モチベーションが危機に瀕していて何も作業する気がしない．
が，本当に何もしないのもアレなので
ライトプリパスレンダリング（Deferred Lightingとも言うらしい）を調べたり
OpenGL(GLSL)やWebGLを勉強していたりした．
DirectXよりOpenGLの方が簡単と言われるけどどっちも同じくらいな気が・・
片方やってるともう片方が楽なのは同意．
あと3つ以上の回転をブレンドするのに便利な対数クォータニオンとか．

更に関係ない所ではCygwin環境を構築して最新バージョンのGCCをビルドしてみようと頑張ってたり
将来的にMicrosoft依存を脱したいのもあってMinGWでwindowsアプリケーションをビルドしてみたり．
別途インストールしてあるLUbuntu12.04環境では難なくGCC4.7.1をビルド出来たのだが
Cygwinだとconfigure通らなかったりmake中になんかエラー出たりで未遂．
一回一回のビルド時間が結構かかるんでこれについては一旦辞めて続きはもうちょっと速いCPUを買った時にするつもり．

ところでモーションを繋げる処理をあれこれ考えていたら既存のソースは殆ど使い回せない事に気付いた．
というか前代のエンジンにモーションを読み込む処理がごっそり抜けてたとか．そういえばそこまで行ってなかった・・！駄目ですな．
（2代前のエンジンには有るという事）

追記

数年前に動画取ったときの実装ではアニメーションのキーフレームを大量に出力し，非常に細かい区間の線形補間としていたが
流石に今世代もそれではファイルの容量とメモリ使用量が大きくなりすぎるし何よりダサいと思った．
（でもLithtechエンジンのAlien vs Predator2はこの方式だったと記憶している．メモリは食うが処理速度は稼げるという事か？）
なのでキーリダクションについても調査中．

(2012/09/10)

v0055を試した人には殆どインパクトが無いが一応デモを更新してみた．
裏側の改良が主なので見た目で分かるのはガラスの歪みサンプリングをいくつか直した部分だけ．

予定

さてさて．次どうしようか？
モーションか，シャドウでもやるか，それとも水面か・・
その前に当たり判定マネージャとかその辺がまだ決まってないから近い内にちゃんと決めないと．

このまま定期的にデモをリリースしているのはもう，それだけで前と明らかに違って良い感じなのだが
もう2,3回デモを出したら次の段階へ進みたいとも思う．
ずっと表示だけやってても面白くないだろうと．こちらとしても，試す側も．
特にFPS的な移動を実装したい．

ま，兎にも角にも目先の事を決めなきゃ進めない訳で・・

• モーション読み込み・再生

　　　これ自体はいいがサンプルが難儀

• ガラスのBSPを改良

　　　実は現在の実装ではガラスを含む平面が交差したときに上手く表示順位を決定できなかったりする
　　　ガラスを中心座標じゃなく凸ポリゴンとして扱うことでこれに対処する

• 座標の3次補間によるカメラ制御

　　　アクションゲームなんかで部屋をぐるっと見回したり演出に使う物といえば分かり易いか
こんな感じで．期限は3日程度を予定しているがどうなる事やら．

余談

光源から更に小さいサブ光源を一定間隔でばらまいてリアルタイムラジオシティもどきをしても面白そうかなと思った．
1つの光源につき平均15個，一度に6～7個視界に入るとすれば総数は100個程度．
メイン光源はシャドウマップあり，サブは無しでやれば負荷的には行けそうだが・・
（サブ光源の光が壁の向こう側に漏れるけど気にしない）

(2012/09/09)

デモについて

本当は2,3日前のリリース予定だったが、やはりというか何と言うか。原因は主にマップだ。
寸法など全く気にせずマップを弄るのはことのほか楽しく、つい時間が過ぎるのを忘れてしまう。
シェーダーパラメータを変化させてその都度結果を見るのも同じ。

さて、今回の目玉は磨ガラスエフェクトと複数マテリアルなのだが
マテリアルに関してはデモで見た目の変化がさほど出せていないのが残念な所で、
パッと見でわかるのはパイプの光沢とその他のコンクリートな質感くらいか。
一応、壁のコンクリートにはOren-Nayarモデルを、ドアや通路の金属にはCook Torrance、そしてパイプにはPhoneを適用しているが
パラメータの調整がなってないらしく正直言って微妙な出来だ。
いくらスクリプトや外部ファイルに記述してあって再コンパイルが不要とはいえ数値を変える度に起動し直すのは面倒過ぎる。
いずれはリアルタイムで調整する機構が必要だろう。

もう一方の磨ガラスエフェクト（というか歪みガラス）はそこそこ納得な出来栄え。
まぁ欲を言えば深度値を比較して手前にある筈のテクセルが漏れ出さないようにしたいが・・キリがないので。
半透明オブジェクトにつきものの描画ソートは単純に中心座標でやってると面積の広い板と複数の半透明スプライトを混ぜた時に
不具合を起こすので板の平面でBSPツリーもどきを形成し、そこにスプライトを中心座標で振り分ける形をとった。
こうすれば古くは初代Doomのようにピクセル単位の深度比較がなくてもきちんとした順序で視線の奥側から描画できるし
ガラスが重なっていてもOKだ。
ただそこまで馬鹿正直にやる必要があるかと言われると疑問ではある。

そういえばDeferredRenderingにおいて半透明物体へのライティングはどうするのだろうか？
って、DeferredRedneringのフェーズが終わった後の話だし当然ForwardRenderingで何とかするしかないか。
とすると従来通り影響するライトを選別してってなるのか・・ううむ

予定

絶賛モチベーション減退中なので
さしあたっては次の項目

• ビュー座標系でのピクセル座標や光源の位置管理がどこか間違ってる？

　　　現状では視線の向きを変えると光源との位置関係が変わらなくてもハイライトの形がガラッと変わってしまう
　　　ゲーム中では気にならないかもしれないがやはり直したい

• G-Bufferにピクセル位置を格納しない

　　　メモリ削減の為．理論上は深度とView&Projection行列から逆算できるハズ

• Jsonクラスを例外をちゃんと使ってエラー処理する

　　　先日とある機会で例外を勉強した為・・
　　　nullを返すダサい仕様なので直す

• LuaからC++の関数を呼ぶ部分でtry catchして警告やらなんやら出す

　　　これも上と同じ逐一エラー値チェック脱却の一環
これだけやろうと思う．どれも目立たない改良なのでデモは無し．
期限は・・1～2日といった所かねぇ．

余談

複数マテリアルに対応したらPixelShader 2_0では命令スロット数が足りないと言われ
PixelShader 2_aと VertexShader 2_bが必須になってしまった．
これはトップページにも書いた通りRadeonならRadeon X800，Geforceなら6600以上のカードを意味する．
開発当初は「オンボで動くようなゲームを」とやっていたけど既にその意志は無いことをお詫びする．
（もしそれを期待してた人が居ればだが）
折角作るのだからやりたかったエフェクトなどバンバン使いたいのだ．

(2012/09/02)

昨日はアップロードしてそのまま力尽きた。
プログラムの方は順当にバージョンアップを続けている。
このままゲームとして動く状態まで現在のペース（週に1〜2回）を維持するのが当面の目標。

その為にまず予定をここに書いて、それに従って作業を進める方針である。
決められた期間でどの位の作業ならこなせそうか見当をつける力？も鍛えられれば幸いだ。

予定

次の一手はモーションをやろうかそれともマテリアル別の描画をしようか迷った挙句、後者にした。
最終的には両方やるからどっちでもいいと言われればそうなのだが・・

マテリアル別の描画というのは1つのシーンに材質の異なる物体が複数あった場合の対処で
これはゲームを動かす際にほぼ必須と思われる。
具体的には金属のシャープな反射とつや消し加工のプラスチックのような質感、それに加え発光といった所か。
前々から言ってた磨りガラスも入れたい。

そしてこれらを踏まえテスト用マップの拡張。

ちなみに今回の期限は3日程度で、余力があれば陽炎なんかの歪みエフェクトもやりたいが
無理そうならきっぱり諦める <= ここが前と違う点

余談

光源の影はマップの構造や描画カリングに大きく影響してくるので当分後回し。
光源自体は視界に入らないけど影だけは入ってくるケースとか面倒だ。

Qtを使ったTwitterクライアントは

• 普通には使えるが、これといった特徴が無い
• 詳細を忘れたのと色々無駄なコードがある

などの点で公開のモチベーションが湧かず単なるオレオレクライアントと化している。これが現実・・・
どうせまたやるんなら大したコード量でもなしQt5で書き直したい。