たけなか制作日誌

最近はプログラムを少しずつ改良しておりました。
オブジェクトの開放処理を自動化させたり、マルチビューを搭載したり。

DirectSoundで音を搭載させようと考えているのですが、
色々難しそうだったので。色々調べ物をしてるうちにシステムの
ビープ音が鳴らせるようになりました。

それで、ビープ音で曲が作れないかなと思い、「かっこー」を
ビープ音で再生してみました。以下かっこー再生部分↓

Beep(1220,200); // かっ
Sleep(300);
Beep(980,500); // こー

WAVをビープ再生するソフトを作ってみても面白いかもしれない。
かなり近所迷惑になりそうですが苦笑。

現在サウンドを読み込めるようにプログラムを追加中です。

それで、ふとプログレッシブメッシュってどうやるんだろうと思ったので
調べてみると、どうやらID3DXMESHを使っている場合、
SetNumFaces()とSetNumVertices()で描画する面数と頂点数を
設定できるみたいですね。リダクションについては、元の形に
近くなるようにDirectXAPIで自動的に削除する面・ポイントを
選択してくれるようで。すごくお手軽です。

けど、スキンメッシュは自作クラスで実装したのでID3DXMESHは
使ってないんです。。まあ、動かないオブジェクトを
標準関数で読み込んでLODさせることなら出来そうですが、
標準関数の読み込みは座標が自動補正されるから気が引けます。。

なんとか自前実装できないかなあ。
頂点ごとの近接リストを別に用意して、それを元にLOD処理させたら、
フレーム毎の近接判定は出来ないけど結構高速にできそうな気がします。
というかそれくらいしか高速にLOD処理をさせる方法が思いつかないので、
SetNumFaces()とSetNumVertices()もそのやり方をとっていそう。

少しひさしぶりなC++制作。

とりあえず、行列計算をなるべくヘルパー関数を使用して
計算しないように変更したり、後はせっかくデバイスロストに対応したので
ウィンドウモードとフルスクリーンモードの切り替えに対応するように
してみました。今までウィンドウモードでデバッグしていたのですが、
今回はじめてフルスクリーンモードで試してみると…。なぜか時々
スクリーン上にウィンドウのタイトルバーらしきものがちらついて
表示されている。。デバイスパラメータの設定ミス？

そういえば、以前は30fpsだったのが40fpsまででるようになりました。
５体計算させるだけならCPU計算でもそこそこいけそうですね。

ひさしぶりの更新です。とりあえず生存報告です笑。

更新しないながらも、一応細々と制作を続けていたんですが、
数日前に背景を制作途中でLWが強制終了してしまい。。
ああ、いかんいかんと思って終了メッセージのダイアログが
出た後で保存を実行したところ…データが壊れてしまいました！

普通の人ならオブジェクトごとに別々にファイルを分けていると思いますが
シーン全体の調節のために１ファイルにまとめて作業してたので。
バックアップをとっておいた１０月辺りのデータからやり直しです。とほほ。

けど今日は悪いことだけではなく、いいことが起きました！
ここ数日データが消えて意気消沈気味だったので、プログラムの方を
進めていたんですが、ようやくデバイスロストに対応したんですよ。
それで今までスプライトは復旧できてるのに、何でモデルは
復旧できていないんだろと不思議だったんですが、スプライトは
行列変換させていないことに気が付いて、デバイスロスト処理の後に
射影行列の再設定を行うと無事復旧させることができました。

どうやらデバイスロストした場合、ステート情報も全てリセットしないと
いけないみたいですね。僕の持っている書籍やWEBサイトには
「Reset()を行うだけでいいから簡単だよ～」なんて書いてありましたが…。
もう少しちゃんと書いてくれよと思いました。まあとりあえず、
デバイスロストは上手くいったので、次はモチベーションの方も復旧しませう。

微調節作業は今回も続きます。

今回は、キャラクタのポリゴンを削減したり、テクスチャを修正したり、
ウェイトを1頂点1ウェイトに設定したりしておりました。

キャラクタのポリゴン数は2000ポリゴンから1800ポリゴン以下まで
削減することができました。地球にやさしい１０%カットです！笑
テクスチャも表情を大幅に修正。ちょっとだけ雰囲気が
でたような気がしますが、何だか別人になってしまったというか。
まだ納得いかないですね。

ポリゴン数を削減したことでプログラムがちょっとくらい早くなったかなと、
さっそく試してみたのですが。。前回28FPSだったのが
30FPSまでしか回復しませんでした。

まあ、全体でたかだか1000ポリ分の頂点計算が減っただけなので
こんなものです。1FPSを笑うものは1FPSに泣く、と。

エコといえば。今の鳩山さんの政権、すごい国債発行することに
なるらしいじゃないですか。あれだけ負債をこれ以上増やさないと
謳っていたのに。。

なんだか世界全体の景気は除々に回復してきてるそうなのに、
日本はまたデフレ経済に逆戻りしてるそうで。。
なんだかなあ。何とかならんもんかね。

前回の惨事を踏まえて。頂点ブレンディング数が４つだったのを
減らしてみるとどうなるかという実験を行ってみたところ、

・ブレンディング数4：19FPS
・ブレンディング数3:23FPS
・ブレンディング数2:28FPS
という結果になりました。よかったー、そこそこ回復して。

けどブレンディング数を１にしてみると1頂点1ウェイトに
なるかなと思ったのですが、基本ポーズになってしまいました。。

自分のプログラムなのに、あまり把握できていないという苦笑。駄目だな。

ちなみにこの計算を踏まえると、モーションの毎フレーム計算を
12FPS程度にすれば、一応今のクオリティのままで１０体まで
動かせるということが分かりました。

12FPSとか。。超ギリギリですね。というよりアウト？

そういえば、試しにテクスチャサイズも小さくしたり圧縮テクスチャを
使用したりしてみたのですが。これが全然FPSが変わらないんですよね。
E3Dを使っていたころはテクスチャサイズを変えただけで
ガラッとFPSが変わったりしたのに。。なんでなんだろ？

それと後々になって気がついたんですが。
僕の自作モーション関数はCPUで処理させてるから、それが
一番のネックになってるんじゃないかと思いました。
普通だったら頂点計算はGPUで計算させると思うので。

DirectXでモーションをやる場合、ほぼ９割近くの人は
ID3DXAllocateHierarchyインターフェイスというのを
扱うと思うのですが。ネットで調べてみてもなんだかとっつきにくそうで
今まで避けてたんですよ、こいつ。。けれどこれ以上の
クオリティを求めようと思うと、やっぱり覚えないといけないですね。

まあCPUでモーション計算できたっていうのはそれはそれでよかったかな。
状況によってはCPUよりもGPUの方が負荷が大きくなることもあるので、
状況に応じてモーション計算をCPUとGPUに分散できるように
なれば。。今までやってきたことも無駄ではないはず！

　　　　　　　　　　　　　　　　　　ドドドドドド。

って感じでキャラを複製させようとしてみたのですが。なんと
３体目にして処理落ちが顕著になってしまったので、５対表示中、
モーションを行うモデル数を変えながらFPSを測定してみたところ、

・モーション１体：57FPS
・モーション２体：55FPS
・モーション３体：30FPS
・モーション４体：23FPS
・モーション5体：19FPS
という惨々たる結果になってしまいました…。

うーん。テクスチャサイズが大きいからというのもあるけど、
やっぱりある程度モーションの頂点バッファをあらかじめ生成しないと
駄目なようです。かといって全てのモーションの頂点バッファを
メモリに格納してしまうと、少なく見積もっても300MB以上はいきそうなので、
アイドリング・走り等の指定した基本動作だけあらかじめ生成した
頂点バッファを利用できるようにしようかな。
まあ、結局は容量を考えるとビデオメモリではなくシステムメモリに
格納することになっちゃう訳で。ビデオメモリに転送する手間を考えると
あまり効果がないような気もしますが。。

それと、メインの1体以外のモーションをOFFにした状態で
色々テストしていて気がついたんですが。どうもZバッファへの書き込み
というのはかなり処理速度が重いということが分かりました。

僕のプログラムではメインキャラを一番先に描画して、その後に
順番にオーバーライドモデルを描画してるのですが、メインキャラが
オーバーライドモデルより手前にいる場合と後ろにいる場合では
それぞれ56FPSと40FPSという差がでてしまいました。

これはおそらくメインキャラが後ろにいる場合、メインキャラをZバッファに
書き込んだ後、オーバーライドモデルを描画する際、同じピクセルに
結局また同じようにZバッファに書き込むことになるので
その分のロスによるものだと思います。

なので、一番効率のいい描画順序で行いたい場合は、
前のフレームで描画した際のモデルごとのピクセル数を格納しておいて、
描画する前にそのピクセル数を要素としてモデルの描画順序を
ソートしてあげればいいわけです。

て、まあ理屈は単純なんですが。描画したピクセル数なんて
どうやって取得すればいいのやら、さっぱりです。。
最近になって、少しずつシェーダを勉強し始めてるのですが、
ピクセルシェーダで取得でき…たらいいんですけどね。
まあ、そんなことしなくても単純にカメラ距離でソートする
っていうのもありかもしれない。

モデルをオーバーライド読み込みできるようにしてみました。
よく分からない人のために説明すると、頂点バッファを新しく確保せずに
前に読み込んだモデルのデータを使いまわそうぜ！ってことです。
なのでその分読み込みが早くなります。なんせ、読み込まないので笑。

とりあえずキャラクターを２人表示させてみたのですが、
表示させてみて改めて分かったことがあります。それは、

表情がすごく堅くて怖い…。

こんなゲーム、僕だったらやりたいとは思いません苦笑。
とりあえず、なんとかしませう。

そういえば、UNREALエンジンに続いてCRYエンジンも
アカデミックの場合は無料になったそうです。
まあ、僕は学生ではないのですが。CRYエンジンのサイトを
色々見てみると。やっぱりすごいですね、クオリティが。
色々参考になると同時に、なんだか少し脱帽してしまいました。

今回は色々と微調整作業をしておりました。
キャラクターにスペキュラを設定したり、ライティングを調節したり
フォグを設定してみたりといった感じです。

フォグは色々試してみましたが、どうしても深海の中や暗がりの中に
いるような、おどろおどろしい印象になってしまいます。
ちなみに画像だと、個人的には朝方の静かな時間帯の印象です。

卒制の時は深く考えなくても、フォグの演出がシーンと
合っていたんですが。今回の場合は少し難しいです。
自作でフォグを処理してみるのもいいかもしれないな。

それと前々から気づいてましたが、キャラの足が地面に埋まってます。
そろそろモーションを作ろうか、自分。

色々プログラムをいじってたら、いつの間にかミップマップが出来てました笑。

テクスチャオブジェクトを作成する際、MipFilterの引数を
D3DX_FILTER_NONE以外にすると正しく描画されました。
この引数、今まではレンダーステートのフィルタ指定と
同じものなのかと思ってましたが、どうやら違うようだ。。

DirectXのテクスチャ生成関数にはFilterとMipFilterの
二つの引数が用意されてますが、これらはどうもテクスチャ生成時の
補間を指定している感じです。つまり、Fileterの引数は
読み込むテクスチャが2の累乗サイズでない場合、標準の
テクスチャ生成関数では自動的に2の累乗サイズに拡大して
くれるのですが、その拡大する時のサンプリング処理の指定を
表していて、MipFilter引数も同様にミップマップ生成時の
縮小のサンプリング処理の指定を表しているのかなと思いました。

それとUsage部分にD3DUSAGE_AUTOGENMIPMAPを指定すると
なぜかテクスチャが真っ黒になります。。なのでUsageには0を指定します。
なんだかD3DUSAGE_AUTOGENMIPMAPの必要性が
分からなくなってしまいました笑。

けど、前に色々いじった時も同じような設定を試したような気がするので、
原因は此処だけでは無いかもしれません。
まぁとりあえず出来たので、良しとしよう。

で、とりあえずミップマップができたので、レンダーステートの
ミップマップ補間を色々変更して実験してみました。(画像参照)
D3DX_FILTER_POINTだとミップ境界がはっきり分かる感じでした。
D3DX_FILTER_LINEARの場合、正面方向のポリゴンだと
ほとんど気がつかなくなりますが、視線と垂直なポリゴンだと、
境界はぼやけるものの何だか妙に気になります。(画像の"さ"部分の少し左)

一応D3DTEXF_ANISOTROPICも試してみましたが。
テクスチャが大きすぎたのか、またもやミップマップ使用前と同じように
ちらつきが発生してしまいました。おまけにフィールドを移動していると
定期的にFPSがガクッと下がる問題も発生！
(おそらくミップマップ境界と関係してそうですが)

今のところ、D3DX_FILTER_LINEARが安定かな。