前回の惨事を踏まえて。頂点ブレンディング数が4つだったのを
減らしてみるとどうなるかという実験を行ってみたところ、
・ブレンディング数4:19FPS
・ブレンディング数3:23FPS
・ブレンディング数2:28FPS
という結果になりました。よかったー、そこそこ回復して。
けどブレンディング数を1にしてみると1頂点1ウェイトに
なるかなと思ったのですが、基本ポーズになってしまいました。。
自分のプログラムなのに、あまり把握できていないという苦笑。駄目だな。
ちなみにこの計算を踏まえると、モーションの毎フレーム計算を
12FPS程度にすれば、一応今のクオリティのままで10体まで
動かせるということが分かりました。
12FPSとか。。超ギリギリですね。というよりアウト?
そういえば、試しにテクスチャサイズも小さくしたり圧縮テクスチャを
使用したりしてみたのですが。これが全然FPSが変わらないんですよね。
E3Dを使っていたころはテクスチャサイズを変えただけで
ガラッとFPSが変わったりしたのに。。なんでなんだろ?
それと後々になって気がついたんですが。
僕の自作モーション関数はCPUで処理させてるから、それが
一番のネックになってるんじゃないかと思いました。
普通だったら頂点計算はGPUで計算させると思うので。
DirectXでモーションをやる場合、ほぼ9割近くの人は
ID3DXAllocateHierarchyインターフェイスというのを
扱うと思うのですが。ネットで調べてみてもなんだかとっつきにくそうで
今まで避けてたんですよ、こいつ。。けれどこれ以上の
クオリティを求めようと思うと、やっぱり覚えないといけないですね。
まあCPUでモーション計算できたっていうのはそれはそれでよかったかな。
状況によってはCPUよりもGPUの方が負荷が大きくなることもあるので、
状況に応じてモーション計算をCPUとGPUに分散できるように
なれば。。今までやってきたことも無駄ではないはず!
たけなか 2009.11.22-02:07 Edit
ひょっとしてE3Dの頃はGPUを圧迫しすぎてたから
テクスチャサイズを変えただけで処理速度が変わったのかな。
今のC++版だと、モーションさせると逆にCPU稼動率がものすごいんです。
テクスチャをガンガン使っても処理速度が変わらないのは、GPU計算を
テクスチャ処理にフルに割いているからなのかもしれない。