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

(2012/08/30)

矢継ぎ早に

また前のぐだぐだペースは嫌なので次々と更新をしていく．本当は昨日か一昨日が目標だったけどまぁ，遅れた物は仕方ない．
今回新たに加わったのはトップにも書いた通りノードの視覚化と操作，それとライトのちょっとした効率化．

アニメーションがまだなのでモデルにちゃんと関節入ってるかイマイチ実感できないというのもあり
とりあえずユーザーが関節をクリックで選択し，キー入力でX,Y,Z軸それぞれで回転できるようにしてみた．
ただ，一度に1つの軸でしか回転できないので自分の思い通りの回転は難しい．

ライトの効率化については
まずライトを覆う球を描画し，Zバッファでカリング「されなかった」部分をステンシルバッファに記憶させる．
その後ステンシルバッファをマスクに使っていつも通りピクセルシェーダでライティング．
実はこれ，デバッグビルドで動作させると何かのオーバーヘッドなのか速度が半減したのでヤバイと思ったものの
リリースビルドでは割と順当な速度で動いてくれたので安心した．
現状複雑なライティングをしていないので画面全域とライトを全く映さないの2ケースでしか違いを実感できないが・・

次の目標は

• ライトの更なる効率化

　　　ステンシルに加えスクリーン座標で更新すべき2D領域を限定

• 文字列を途中で色変更

　　　前のソースでは出来ていたのだが何故だか動かん・・

• サンプルのスキンメッシュを用意

　　　現時点で描画出来てたりするがモデルを用意するのがダルかった
割と小粒なタスクだ．目標は明日か明後日．

(2012/08/26)

苦節○年

やっとこれからゲーム作るぞという雰囲気のデモを公開できた．
背景はちゃんとテクスチャとUV座標をセットしようとしたけど，たかがデモなのに面倒すぎて中止．

幾つか既知の問題点があったものの全てを修正していては埒があかないという事もありここで一旦公開とした．
例えば以下のような物である．

• ライトを120個程度出すと落ちる（メモリアロケータの設定が不味い）
• 「モデルを開く」ダイアログのデフォルトパスがマイドキュメントになっている
• 必要もないのにシェーダー3.0でコンパイルしている（実際は2.0で十分）

それと自分以外のPCではロクに動作確認してないので
この環境で動いたor動かなかった，dllが無いと言われたなどあれば
トップぺージに報告してくれれると有り難い．

これから上記の修正とtwitterクライアント公開の準備に入る事にする・・
いや，関節をグリグリ動かす所まではできているしそっちが先かもしれない．

#追記

とりあえず上の3つは修正した．ライトも512個までは確認．それ以上はマシンスペックとメモリの許す限り出せると思う．

(2012/08/22)

リリースビルドが通れば・・

あれから更にエクスポータをいじった。
一つの頂点が複数の法線やUV座標を持っているケースにおいて「その組み合わせの分だけ」別々の頂点として出力、
それに合わせインデックスも改修するように変更。
こうすると例えば一つの頂点が3つの法線と3つのUV値を持っている場合、3*3で9つ生成される事になり
モデルによっては爆発的に頂点数が増える事が予測されるが

• 使われてない組み合わせをチェックする気力が無い
• そもそもモデルの作りが不味いのでは？

とも思ったのでこれで一段落。
3ds maxの謎な法線格納方式のお陰で余計に時間食ってしまったなぁ・・・
ポインタをやりくりして無理にメンバ領域を読んでるから非常にアレだ（でも他に取得方法がわからなかった）

で、現在関節ありのメッシュとスキンメッシュをバンプマップ有りで描画して
スクリプトからノードにアクセスする事で角度を変え、関節を曲げるくらいはできている。あと一応DeferredRendering。
文字列、HUD用矩形の描画クラスは前代エンジンからの移植。

ちなみにモーションはまだできてない。モデルエクスポータをあれだけいじったので前のソースがすんなり動くとは思えない。

モーションはまたひと悶着ありそうだから放っておいて、
ここで一旦デモを出したいのだがリリースビルドが通って動くかどうか。
というかメモリアロケータからしてリリースビルドバージョンが安定しないのでその時点で駄目っぽい。

(2012/08/12)

モデル出力

結局エクスポータを書き直した．結果は以下の通り．

追加より消した行が多いという・・でも機能は変わってない．スマートにしようと思うと必然的に行数は少なくなる．
変えた所と言えばバイナリ出力する事も見据えて例えば頂点で
{"position": "0 0 0", "normal": "0 1 0", "uv": "0 0"}
とベクトルをスペース区切りの文字列で表現していた所を
{"position": [0,0,0], "normal": [0,1,0], "uv": [0,0]}
と，配列で出力するようにしたくらい．
他には3ds maxは右手座標系で上がZ軸，奥がY軸になっていたのでD3Dっぽく扱いたいと思い
単純にYとZを交換，それに伴い面を反転．ノードの変換行列も逆行列などかませつじつまを合わせたとか．
材質情報は別途Jsonファイルに定義しファイルパスを指定するっていうのは前回書いた通り．

前は座標変換をよく分かってなくてまずXを反転しその後Y軸やZ軸で回転を加え何とか合わせて誤魔化していた．
この誤魔化しはモデル表示という目的は達成できたものの
あくまでモデルルートのノードに対しての変換で
IKをしようとなるとゲーム中の座標系（左手系）ではそのまま計算出来ず一旦モデル座標系にしてX軸も反転，回転も逆に・・等と非常に面倒だったのである．
ライブラリに頼れば数学なんて大して必要じゃないさーと高をくくってると
ちょっと突っ込んだ事しようとした時にボロが出る典型．

(2012/08/08)

データの受け渡しは基本Jsonで

モデルに付加するゲーム変数をどうやってエンジンに渡そうか考えていた．
当方3ds maxを使っていてモデルはちょっとした自作エクスポータでJson形式としてエンジンへ渡しているのだが
（Jsonはデバッグに便利な為．リリース段階でバイナリ表現にする予定）
一緒に変数を埋め込んでしまうと複数のオブジェクトで同じ設定をしたい時に面倒だ．
なので別途記述したJsonファイルパスをセットする方針とした．
Luaをデータ記述言語として使えば更に柔軟な動作が可能となるがC++から読みたい場合に少々骨だし，それはやりすぎな気がするので却下．

ライブラリ化は早い内に

ついでに今まで座標系の変換を含めテキトーに作っていたモデルエクスポータをちゃんと作ろうという事で
じゃあ出力に使うJsonクラスなんかも新しいバージョンを流用したいよなと思ったまではいいが
新しいバージョンのエンジンは1プロジェクトに全て突っ込んでしまっていてさあ困った．怠慢と言われても仕方ない．

ここで迷うのが静的(lib)にするか動的(dll)にするかであるが
メモリアロケータ等の何百回も呼ばれるルーチンはデバッグビルドだと動作速度が遅すぎてゲーム本体のテストがままならない為
ゲーム本体とアロケータでビルドオプションを分けられるdllにしようかと．
テンプレートクラスのアロケータをいじる度にゲームまでコンパイルし直しも億劫であるし．
（ランタイムライブラリを使わなければ静的でも出来るのかもしれない．しかし少なくとも今の自分には無理）

で，ふと「dllのクラスはバイナリ単位の互換性がない」という，前にどっかのwebページで見た文言が浮かんだ．
いやもう少し正確に言えば異なるコンパイラで同じクラスをコンパイルしたとしても絶対に同じ変数レイアウトになるとは限らない．とかなんとか．
同じコンパイラでコンパイルしないと使えないdllって奴は激しく微妙だし，バグの温床になる．

ここで確かめるのは手間だから遠慮しておくが考えてみればC++の規格でSTLコンテナのデータレイアウトまでは規定してなかったような．
そんなわけで文字列変換とかの単体関数とアロケータはインタフェースを通しdllへ，それ以外のベクトルクラスとかはlibへという
なんだかよく分からない構成になってしまった．

以上が前回からの主な進捗．他は諸処の細かいバグ取り，コメント書きに終始．

戯言

そういやこっちのプログラムがデバッグビルドでもリリースでも使えるライブラリもあるよなぁと
丁度手元にあった3ds max SDKのヘッダを見てたらやはり標準ライブラリは使っていない様子だ．
ところで3ds maxのプラグインを作る際に使う補助ライブラリではクラスをガンガンにエクスポートしている．こりゃ一体？
幾つかファイルを読み進めて察するに

• クラスのサイズを4バイト境界に合わせる
• 仮想継承や多重継承は避け代わりにインタフェースを使う
• テンプレートクラス，というか標準コンテナをメンバに含まない

この辺りを守れば普通にクラスをdllからエクスポート出来そうな予感．
勿論テンプレートクラスは予め実際に使う型で実体化しておく．

と，ここまで書いたら
なんだ結局自分のライブラリは全部dllで行けたんじゃないか？
ライブラリに疎いのがモロバレだな・・