PC用眼鏡【管理人も使ってますがマジで疲れません】 解約手数料0円【あしたでんき】 Yahoo 楽天 NTT-X Store

無料ホームページ 無料のクレジットカード 海外格安航空券 ふるさと納税 海外旅行保険が無料! 海外ホテル

log

2009.11.21 C++:すごく重いよ、モーションが。

ファイル 211-1.jpg

                  ドドドドドド。

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

・モーション1体:57FPS
・モーション2体:55FPS
・モーション3体:30FPS
・モーション4体:23FPS
・モーション5体:19FPS
という惨々たる結果になってしまいました…。

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

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

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

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

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

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

comment

たけなか 2009.11.21-05:27 Edit

ひょっとしたら自作のモーション関数が重いだけで、
DirectX標準のモーション関数だと結構軽いのかな。

うーん、気になる。

たけなか 2009.11.21-05:57 Edit

息抜きにC#の勉強サイトをちらほら訪問。
WinAPIまわりを記述せずにゲームループだけ書けばいいなんて。

思わず、いんちきだー!って思いました。

何気にライトのメンバにピクセルパーライティングのフラグが
ついてるのがうらやましい…。よし!参考にしよう笑。

たけなか 2009.11.21-07:21 Edit

ライトのメンバのアンビエントとレンダーステートのアンビエントの
違いが今までピンと来なかったけど。色々試してみると、
おそらく以下のような式になってるような気がしてきた。

アンビエント部分の描画色 = 頂点のアンビエント色 *
( ライトのメンバのアンビエント色 + レンダーステートのアンビエント色);

ようするに、レンダーステートのアンビエントは全体の
アンビエントを加算させたいときに使うのかなと思いました。