テレワークならECナビ Yahoo 楽天 LINEがデータ消費ゼロで月額500円〜!
無料ホームページ 無料のクレジットカード 海外格安航空券 海外旅行保険が無料! 海外ホテル


log

2009.11.22 C++:一番のボトルネックはモーションのCPU計算でした

前回の惨事を踏まえて。頂点ブレンディング数が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に分散できるように
なれば。。今までやってきたことも無駄ではないはず!

comment

たけなか 2009.11.22-02:07 Edit

ひょっとしてE3Dの頃はGPUを圧迫しすぎてたから
テクスチャサイズを変えただけで処理速度が変わったのかな。

今のC++版だと、モーションさせると逆にCPU稼動率がものすごいんです。
テクスチャをガンガン使っても処理速度が変わらないのは、GPU計算を
テクスチャ処理にフルに割いているからなのかもしれない。

post your comment

投稿フォーム
name
mail
url
comment
icon
アイコン一覧
del key