PIX for WindowsDirectX SDK付属のデバッグツール。リソース状況の確認やシェーダーのデバッグが可能。
◎アンケート回答が増えてました。ありがとうございます!
「内容薄くてもいいからこまめに更新」が多いのかな?
毎日は無理ですが、なるべく日を空けないよう頑張ります。
回答状況は今後も時々チェックするようにしますので、よろしくお願いします。
では、前回記事の続きです。
◎特定座標の色の取得当たり判定方式がダメっぽいので、次に考えたのは、特定座標の色を取得して、その色で高さを特定する方法。当たり判定方式よりもシンプルで負荷が低そうです。
現在のマップは高さに応じて色分けされていますし、別途グレースケールを用意することもできます。
ちなみに、グレースケールとはこんな感じの白黒画像です。色が白いほど高い場所です。

興味本位もあって、まず3D空間内の特定座標(ポリゴン頂点とは無関係の座標)、またはそれを表示した画面の特定座標の色を取得できるか調べてみましたが、これに関する情報は殆ど見つかりませんでした。
唯一見つけたのはPIXというデバッグツール(冒頭参照)で、選択したピクセルがどのようにレンダリングされているか確認できます。(紹介記事は
こちら)
デバッグツールとしてはかなり使えそうですが、プログラムから直接呼び出して利用することはできなさそうです。
次に2Dテクスチャの特定座標の色を取得する方法を調べてみましたが、こちらも案外情報が少なく、未だ不明です。とりあえずGetPixcelメソッドを見つけたものの、XNA上での使い方がよくわかりません。(C#上とは違う?)
色の取得程度のことが簡単に出来ないってのは、我ながら情けないです。昔はVRAM直接アクセスで単純だったんですが…。
◎一般的な方法は?だんだん煮詰まってきたので「そもそも一般的にはどうやってるのか?」から調べ直したら、MSDNフォーラムで「
Meshからの座標取得について」というQ&Aを見つけました。
この質問は私がやりたいことと一致しているのですが、質問者と回答者のレベルが高すぎて、私にはかなり難解な内容です。これを見る限り、XNAにMesh.Intersectが無いから苦労しなければならないようですが…愚痴を言っても始まらないので、対処法を1つ1つ解読しましょう。
◎対処法の解読まず対処法のひとつめは、「ランタイム時に〜」とあるので、メッシュからリアルタイムに情報を取得して当たり判定に利用する方式と推測しました。
IndexBufferやVertexBufferについては未調査ですが、1つ気になるのは、XNAの公式サンプルや質問者がわざわざ手間がかかるふたつめの方式を採用した点です。よく理解しないままこちらの方式を採用するには不安がありますね。
対処法のふたつめは、コンテントパイプラインでXファイルを読み込む時に、頂点データを全て取得出来るので、
A:頂点データをメモリに退避して当たり判定に利用する
B:頂点データを活用して当たり判定用メッシュを作成する
上記ABを可能とする方式と推測しました。
推測が正しいか否かはさておき、ふたつめの方式の場合、コンテントパイプライン内でのプログラミング必須です。これは私にとって結構高い壁と言えます。
◎サンプルプログラムQ&Aだけではどうプログラムすべきか見当も付かないので、とりあえずXNA Creators Clubのサンプルを入手して動かそうとしたのですが、
う、動かない…
似たようなサンプル「BillboardSample」「HeightmapCollision」でそれぞれ試した所、3Dモデル読み込み時に「This device does not support 32-bit indices.…」とエラーになります。環境上の問題っぽいですが、シェーダバージョンは1.1だからクリアしてるはずだし…う〜む。
◎今後どうする?というわけで、どうも一筋縄ではいかない雰囲気です。
現時点での選択肢を列挙します。
A案:(不正確と承知の上で)元の標高データを解析する
B案:XNA上での色情報取得方法をさらに追及する
C案:Q&Aのひとつめの方式を追及する
D案:Q&Aのふたつめの方式を追及する
E案:XNA以外で色情報をテキスト化してXNAに渡す
実はE案なら簡単にできそうなんですけど…「それでいいのかオイ?」って突っ込みたくなりません?(^^;
初めからそれをしなかったのは、XNAでやることによってXNAの技術力を上げたかったからです。でもこの様子だと相当時間かかりそうだし、プログラム自体は全然進んでないので、そろそろ挫けちゃいそうです。
◎次回予告もうしばらくB〜D案を追求するつもりですが…あまり進展が無かったら、E案にしてしまうかもしれません。
テーマ : ゲーム製作 関連 - ジャンル : ゲーム
最近寒くなってきたので風邪には気をつけたいところです。もう引いちゃいましたけど(笑
高さ取得って結構めんどうくさいですよね。
自分はHeightmapCollisionのコードの判定部分をまるっと使わせていただきました。
HeightmapCollisionって確か戦車を動かすやつですよね。あれは白黒のハイトマップを起動時にモデルにしてどうのこうの・・・って感じで、まねしようと思ったのですが、理解できるエリアを超えていたのでそこは完全に自分流(といってもかなりレベル低いですが)にしました。
本当に雑なものなので偉そうにはいえないのですが、自分のやり方では判定が必要になる"レース状態"に入るときにコースのXファイルの頂点をバーっと2次元配列に格納しています。あとはHeightmapCollisionの判定を取っているコードを丸々コピーでいけます。
これでコンテントパイプラインのゴタゴタからは脱出できます(笑
もっといい方法があるはず(間違いなくある)なので、この方法は記憶の片隅にでも置いておく程度にしてください(笑 あとこの方法はマップ作りにも制限が掛かりますしね。
風邪を引かないように、無理をせずがんばってください!
今年もよろしくお願いします。
風邪をひかれたようですが、もう治ったのでしょうか?ぶり返さないようお気を付けください。
高さ取得に関する情報ありがとうございます。大変参考になります。
>HeightmapCollisionって確か戦車を動かすやつですよね。
えーと、私が見たのは確かボールだったような…あ、他にも戦車を動かすサンプルがありますね!試してみましょう!
…同じエラーで動きませんでした(;_;)
>自分のやり方では判定が必要になる"レース状態"に入るときにコースのXファイルの頂点をバーっと2次元配列に格納しています。
これはmesh内のIndexBufferやVertexBufferから頂点情報を取得する、ということでしょうか?
>これでコンテントパイプラインのゴタゴタからは脱出できます(笑
おお〜それは素晴らしい!(笑)
「こうやったらできました」という情報はとても心強いですね。私もサンプルから攻めることにします。どうもありがとうございました!
私も背景のヒットはメッシュロード時に頂点情報をVector2配列にドカっと入れてます。うちは背景のヒットに使うメッシュがかなりシンプル(100頂点前後)なので、それによる読み込みの遅延などは大した負荷にはならないですが、背景が大きく細かいようでしたら負荷を計測してみると良いかと思います。それによってはパイプラインでやるべきなのか、もっと前段階でやるべきなのかが明確になるかと。
ちなみにC#での画像解析だと『こるなご』さんのコチラのエントリーが参考になります。
http://thorshammer.blog95.fc2.com/blog-entry-254.html
具体的なコードも紹介されていて大変勉強になります。
そのとおりです!どかっといれて使いますよー
今年もよろしくお願いします。
(サイトいつも見てますよ〜また書き込みますね!)
>うちは背景のヒットに使うメッシュがかなりシンプル(100頂点前後)なので、
え?そんなに少ないのですか!?
こちらは今4000頂点ぐらいです。これでも減らしたつもりだったのですが…
今後速度が気になりだしたら、さらに減らすことも検討します。
>ちなみにC#での画像解析だと『こるなご』さんのコチラのエントリーが参考になります。
4つの方式を計測比較した上に、コードも紹介されているのが良いですね。ありがとうございます。
それにしても…「C#のGetPixelは遅い」という書き込みはちらほら見かけましたが、数値で見るとビックリしますね。XNAのGetPixelも似たようなものである可能性が高いので、心しておきます(^^;
>そのとおりです!どかっといれて使いますよー
やはりそうですか…私も頂点情報を配列に格納して使うようにします。ありがとうございました!
ウチの場合移動可能範囲を取得したいだけなので、高さ情報は不要なんです。輪郭だけなら少なく済みますから。
コメントの投稿