プロフィール

Na-7

Author:Na-7
SE(システムエンジニア)として約15年間システム系ソフト会社を勤めあげ、2008年3月退社。現在、ゲーム制作会社設立を目指して活動中。


アクセスカウンター


最新記事


最新コメント


最新トラックバック


月別アーカイブ


カテゴリ


DATE: CATEGORY:スポンサー広告
上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
DATE: CATEGORY:三国志軍記開発
インデックス廃止01
デバッグ中の自作地形
インデックスを廃止し、頂点データのみでテクスチャアトラスを試みた画面。飛行テストで謎の浮遊大陸が現われた??


◎不均一なシェーダー入力

HLSL内で頂点描画順序をカウントしたいのですが、グローバル変数は均一データと見なされるため、カウンターに使えないことがわかりました。では、不均一なデータはどのように扱えば良いのでしょうか?

HLSLマニュアルの「不均一なシェーダー入力とセマンティック」では、「不均一データ=頂点データ」と見なしているらしく、セマンティックを利用したシェーダー入出力の事しか書かれていません。

セマンティックは後続のグラフィック パイプライン ステージにデータを引き継ぐためのものであって、次の頂点にデータを引き継ぐものではありません。つまりダメってことです。



◎反復レジスタ

描画時にプリミティブ数を渡しているんだから、GPU側で描画頂点数をカウントしているはず!

…と思ってHLSL組み込み関数を調べてみましたが、現在の頂点描画数を取得する関数は無さそうです。

こちらの記事の図に「反復レジスタ」というものが描かれています。読み取り専用レジスタですが、GPUは多分これを使って描画頂点数をカウントしてると思うので、この値を取得できれば何とかなりそうな気がしますが…変数宣言時にiレジスタを指定するとエラーになります。

HLSLで反復レジスタを参照する方法を探しても見当たらないので、アセンブリ言語とかでないとアクセスできないのかもしれません。


ここまで調べた結論としては「HLSLで頂点描画順序をカウントする方法は無い」ようです。
何でその程度のことが出来ないかなぁ(--;



◎メモリ6倍?

HLSL側で解決できないなら、HLSL側で処理できるように頂点フォーマットを改造するしかありません。しかしそれには大きな問題があります。

・1つの頂点に複数のテクスチャ座標を与えても、
 HLSL側で使い分けが判別できない
  ↓
・頂点データとテクスチャ座標データを1対1で割り当てて、
 HLSL側の使い分けを不要とする
 (頂点データ共有方式をやめる必要がある)
  ↓
・頂点数が6倍に増えてしまう
 (1つの頂点データを6つのポリゴンが共有しているため)

描画頂点数は変わらないので、描画速度は落ちませんが、メモリは圧迫します。カウントできないために頂点バッファを6倍消費するハメに…うわ~嫌すぎ!!

待てよ…6頂点のうち2つは共通だから、インデックス方式なら4倍に抑えられますね?それでも4倍消費しますけど。

…そこまでして、やる意味あるのかなぁ?



◎あまり早くない?

描画速度を上げるために取り組んでいるテクスチャアトラスですが、実現したらどれほど早くなるのでしょうか?

よく考えたら、描画プログラムは既に出来あがっている状態なので、速度効果は今すぐ確認できるはずです。

…確認したら、8~9fpsでした。G案の時点で5~6fpsだったので、1.6倍です。あれ?期待してたほど早くないですね?


このままだと、テクスチャアトラスを実現したとしてもデメリットが強すぎる(やる意味ない?)ので、速度がいまいちな理由を探ります。



◎速度比較テスト

いろいろ試したら、テクスチャ設定変更後のeffect切り替えに時間がかかることが判ってきました。(テクスチャ設定行をコメントアウトするだけで、20fpsを超えました)

でも、テクスチャ切り替え回数は、75回→5回と大幅に減らしています。テクスチャ切り替えに時間がかかるなら、以前より格段に早くなって然るべきでしょう。

…もしかして、テクスチャのデータ量が多いと、切り替えに時間がかかるのでしょうか?
試しに、地形モデル1~4のテクスチャを、データ量が少ない1色テクスチャに差し替えてみました。

テクスチャ切り替え速度検証02

うわ~20fps超えてる…テクスチャのデータ量が多いと、サンプラの準備に時間がかかる、ということかもしれません。

…えっ?切り替えじゃなくて、複雑な模様を描画するのに時間がかかるんじゃないかって?
では、改めて1モデルで試してみましょう。

テクスチャ切り替え速度検証03   テクスチャ切り替え速度検証04
複雑テクスチャ(左図)と一色テクスチャ(右図)

複雑テクスチャが35fps、一色テクスチャが36fpsでした。
テクスチャの複雑さは描画速度に殆ど影響しないが、エフェクト切り替えに時間がかかる、ということですね。マテリアルバッチが有効と言われる理由も納得できます。


ついでに、テクスチャの解像度やファイルサイズも変更して試したところ、どちらも描画速度に影響しない、という結果になりました。



◎B案とマテリアルバッチの併用

テクスチャの切り替えに時間がかかるなら、B案の技術とマテリアルバッチを併用して、テクスチャの切り替え無しで一気に表示すると早くなるでしょうか?でも、最初に全テクスチャを準備するから、サンプラが扱う総データ量は変わらないんですけどね。


…で、強引に試したところ、16fpsでした。(8~9fpsの2倍)
ただし、頂点データやプログラムは中途半端な状態なので、最後まで実装したら、もう少し遅くなると思います。

目標の20fpsに届かないのは微妙ですが、ここまで来たら、やるだけやってみますかね。



◎頂点数の壁

…というわけで、実際にコーディングしたら、画面表示が乱れまくりました。頂点数が16ビット(65536)を超えたために、インデックスデータがおかしくなったようです。

そこで、IndexElementSizeの指定を16ビットから32ビットに変更したら、エラーで落ちました。エラーログを確認したら「This device does not support 32-bit indices.(このPCは32ビットインデックスをサポートしていません)」とのこと。

ぐはっ!ハードっすか!(><)



◎インデックスの廃止

ハードの制約を回避するには、インデックスを廃止するしかありません。当然データ量は6倍になります。「そこまでする価値あるのか?」と嘆きつつ、気力を振り絞ってコーディングしました。

インデックス廃止02   インデックス廃止03

とりあえずポリゴンやテクスチャは形になったようですが、飛行テストでカメラを特定の領域に移動すると、手前や奥の地形が急に消失したりします。なにコレ?

こういう現象って、厄介なんだよね~(ブツブツ)



◎次回予告

そろそろ限界を感じつつ、次回につづきます。

スポンサーサイト

テーマ : ゲーム製作 関連 - ジャンル : ゲーム

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック


この記事にトラックバックする(FC2ブログユーザー)



copyright © ゲーム制作の舞台裏 all rights reserved.Powered by FC2ブログ
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。