- 1 名前：デフォルトの名無しさん mailto:sage [2009/06/22(月) 22:06:29 ]
- ※回答する人も、質問する人も必ず読んでください
これらに当てはまる人のための質問スレです。
１．C/C++は多少理解している。
２．最近DirectXを始めたばかり
３．SDKを見ても、Googleで検索しても、いまいち理解できない人
４．余計な雑談は不要ですよ
【 回答してくださる方 】
・ できるだけ優しく質問に答えてあげてください。
・ 優しく教えるのが嫌でしたら、解決するためのヒントだけでも結構です。
「ググれ」「SDK見れ」以外の回答でおながいします。
・ 神ですら理解不能な質問は無視して下さい。
【 質問する方 】
・ どんな事で躓いているのか明確にしよう。
・ 長くならないなら躓いている部分のコードを晒してみれ。
・ 解決した場合、お礼を言うのは当然だが、何をどうしたら解決したかを明確に書こう。
・ 回答して貰ったら、出来るだけお礼もしよう。
【C++】 DirectX初心者質問ｽﾚ Part23 【C】
pc12.2ch.net/test/read.cgi/tech/1242977486/
- 554 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 01:45:36 ]
- 作ったゲームのテストたのんだ友人の中の一人だけがエラーで止まるので
いったい何が悪いんだと調べてみたらフォント描画が原因だった
\r\nを含んだ文字列描画すると原因不明のエラー警告で落ちる
\r\nを\nにしたらエラーでなくなったが、一体なにが悪いのかよくわかりませんでつた
ＯＳもＤｉｒｅｃｔＸランタイムバージョンも他の正常に動作してるＰＣと同じでつ
- 555 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 03:42:55 ]
- >>554
DirectXとOSのバージョンと描画方法は何ですか？
- 556 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 07:06:17 ]
- プログラム中の文字列の改行コードにCRLFって使った事無いなｗ
テキストに落とす時は別だけど
- 557 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 08:30:56 ]
- >>554
落ちた１台が例外なんじゃなくて、
他のPCではたまたま動いたってだけの話だろうたぶん
- 558 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 13:50:58 ]
- 555は偉いなぁ…真似できん
- 559 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 17:36:51 ]
- 質問です
DIRECTXで作られた質の高いフリーゲームってありますか？
- 560 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 17:47:19 ]
- ここはプログラムを作ることに関しての板ですゲームサロンにでもいってください
- 561 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 17:55:50 ]
- プログラマブルシェーダでのSetTextureについて質問です。
D3DXEffect effects[100];
for(int i = 0; i < 100; ++i)
{
effects[i].SetTexture("DecaleTex", textures[i]);
}
と、それぞれのエフェクトにそれぞれ別のテクスチャーをセットするとします。
これで、すべてのエフェクトが予想通りに動いているのは確認済みです。
このときに疑問が湧いたのですが、d3ddevice->SetTexture相当のことはいつ行われているのでしょうか？
1)effect[0]を使って描画
2)effect[0]を使って描画
3)effect[1]を使って描画
4)effect[1]を使って描画
とやった場合、2→3のところで内部的に行われているのでしょうか？
となると
1)effect[0]を使って描画
2)effect[1]を使って描画
3)effect[0]を使って描画
4)effect[1]を使って描画
とやると、d3ddevice->SetTextureのコストという面では2倍コストがかかってしまっているのでしょうか？
そもそも全てのエフェクトにテクスチャをあらかじめセットしてまわっておく。というのは正しいやり方なのでしょうか？
「d3ddevice->SetTextureはなるべく減らすように」と昔教えられたもので
（実際に、パーティクルなどの表示で切り替えまくると遅かったし）
かなり気になっています。
アドバイスいただければと思います。よろしくお願いします。
- 562 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 21:22:42 ]
- DX9ならBeginPassとCommitChanges
DX10ならApply
それ以外に公開情報あったっけ
- 563 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 21:23:32 ]
- 質問です。
d3d9.hの読み込みより前に
#define D3D_DEBUG_INFO
を設定することで、デバッグウインドウ上で情報が表示されるということで実践してみたのですが、
どう考えてもおかしな数値が入っているように表示されます。
これは皆さんの環境でそうなのでしょうか？
単なるD3Dの初期化＞D3Dデバイスの中身をデバッグウインドウで見る＞数値とかがぐちゃぐちゃ
なのですが…。
環境はVS2008Express
Microsoft DirectX SDK (March 2008)
を使っています。
- 564 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 21:36:20 ]
- 君のプログラムの文字セットの設定は何だろう？
ちなみにIDirect3DTexture9::NameはLPCWSTRだ。
- 565 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 21:40:51 ]
- マウスをクリックしたとき、どのオブジェクトをクリックしたかというのはどういうコードを書けばよいんでしょうか
それとも、マウスをクリックした時にその地点にオブジェクトがあるかないかを総当りで調べるものなのでしょうか?
- 566 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 21:55:37 ]
- スクリーン座標をsx,syとする。
スクリーン座標の手前(sx,sy,0) 奥(sx,sy,1) を3D空間の座標に変換する
（＝3D空間の座標をスクリーン座標にする変換の逆）
2点を結ぶ直線と最初に交差したオブジェクトを選択。
総当りで問題なくOKなら総当り。
総当りでは重いならばケースバイケースで効率的な方法を考える。
- 567 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 21:57:32 ]
- >>566
うおおおおありがとうございます
- 568 名前：デフォルトの名無しさん mailto:sage [2009/07/24(金) 22:12:08 ]
- >>566
直線だけだと漏れが出ないか？
四角錐じゃないと。
- 569 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 00:05:32 ]
- >>563について自己解決です
注
オブジェクトのプロパティ名が表示されますが、この値はデバッグのランタイムが有効な場合のみ正確です。リテール ランタイムに対して実行するときは、値は無効です。
とありました。
DirectX Control PanelからUseDebugVersionOfDirect3D9 を選んだところきちんと値が見られるようになりました
- 570 名前：デフォルトの名無しさん [2009/07/25(土) 13:52:15 ]
- D3DXIntersectを使って当たり判定をしてる人がいましたらご教授願います。
表示した３ｄモデルに対して現在一体にしか当たり判定が有効になっていません。
複数のモデルに対して当たり判定を有効にするには何か特別な仕掛けをしていますか？
- 571 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 18:12:35 ]
- 自分で組め
- 572 名前：デフォルトの名無しさん mailto:sage [2009/07/25(土) 20:11:23 ]
- まともなゲームならほとんどすべて、
詳細な当たり判定より先におおざっぱで高速な判定をして
比較するオブジェクトの数を減らす。
最終的には、D3DXIntersectだろうが自作だろうが
当たり判定の必要な回数だけ繰り返す。
- 573 名前：デフォルトの名無しさん [2009/07/25(土) 21:14:18 ]
- レスありがとうございます！
- 574 名前：デフォルトの名無しさん mailto:sage [2009/07/27(月) 00:22:28 ]
- このスレの70％はゲー専生で構成されているとかいないとか
- 575 名前：デフォルトの名無しさん mailto:sage [2009/07/27(月) 01:14:25 ]
- そんなことはない。
大学にも行かず浪人にもなれず就職もしない人は実社会では多数派でもないし
ゲーム業界内でも少ないだろう。２流３流大卒がほとんど。
- 576 名前：デフォルトの名無しさん mailto:sage [2009/07/27(月) 01:51:48 ]
- 数学とかそこらは、中学レベルだと感じるな。
- 577 名前：デフォルトの名無しさん mailto:sage [2009/07/27(月) 09:42:08 ]
- というかそんな高度な知識がなくても組めるし
まあ効率とかを考えるといろいろむずかしくなるけれども
- 578 名前：デフォルトの名無しさん [2009/07/28(火) 07:57:06 ]
- 今、線分とメッシュとの当たり判定を作っています。
中身は線分と三角形との当たり判定を行っているのですが、
そのために必要な三角ポリゴンデータを、
DirectXのメッシュデータから取得する方法がわかりません。
頂点バッファのロックメソッドから、頂点データへの先頭アドレスを取得し
そのアドレスから12byteずつずらしながら、無理やり三角ポリゴン（と仮定したデータ）を取得し
当たり判定させてみましたが、途中から頂点のデータが「3.587e-043#DEN」などと壊れるようです。
ご存じの方がいらっしゃれば、ご教授よろしくお願いします。
- 579 名前：デフォルトの名無しさん mailto:sage [2009/07/28(火) 08:08:47 ]
- >>578
空間上の特定の点がポリゴンの内包する閉空間状に存在するか(要するに当たり判定）は
計算幾何学の分野で、一応n log nのオーダーで出ることは知られているけど
計算が死ねるのでよしたほうがいい。
大学の研究レベルでやるならともかく、ゲームでやるなら質点同士の運動と考えれば十分なはず。
- 580 名前：デフォルトの名無しさん mailto:sage [2009/07/28(火) 08:22:50 ]
- ttp://sukima.vip2ch.com/up/sukima026731.jpg
江戸時代の人々はこれで抜けるんなら
ある意味聖人だな
- 581 名前：デフォルトの名無しさん [2009/07/28(火) 08:28:13 ]
- >>579
レスありがとうございます。
線分と三角形の当たり判定は、テストデータで計算出来ていることは確認しています。
ですので、知りたいのはポリゴンデータの取得なのです。
わざわざレスくださったのに申し訳ないです。
- 582 名前：デフォルトの名無しさん [2009/07/28(火) 08:31:38 ]
- >>579
すいません、読み違えてました。
Xファイルで入力してるので、問題ないと思っているのですが
無理でしょうか？
- 583 名前：デフォルトの名無しさん mailto:sage [2009/07/28(火) 12:25:04 ]
- >>578
12byteの根拠は？
頂点データにはxyz以外も含まれていると思うので、12byteではないと思うが。
ID3DXBaseMesh::GetFVFでメッシュのFVFを取得してD3DXGetFVFVertexSizeで
頂点データのサイズを取得するか、ID3DXBaseMesh::CloneMeshFVFを使って
都合のいい頂点フォーマットに変換してから扱うのがいいかと。
- 584 名前：デフォルトの名無しさん mailto:sage [2009/07/28(火) 12:59:33 ]
- 最近DirectXを勉強しはじめました。
初心者丸出しですが、質問させてください。
DirectXで2Dを扱う場合、Spriteを使用する方法と
座標変換済み頂点を使用する方法があると知りました。
また、座標変換済み頂点を使う方が処理が早いという書き込みも
チラっとみたのですが詳しく書かれておらず、把握している程度です。
質問は
①Spriteか座標変換済み頂点のどちらを使用すれば処理が早いか。
②Spriteと座標変換済み頂点の両方の利点・欠点。
よろしくお願いします。
- 585 名前：デフォルトの名無しさん mailto:sage [2009/07/28(火) 13:21:14 ]
- スプライトというのは、本来のDirectXの姿を隠して
ユーザが扱いやすいようにラップしているだけで、
最終的に頂点を組み立てて描画するのは同じ
ラップしているオーバーヘッドのぶん、処理が遅いかもね
- 586 名前：デフォルトの名無しさん mailto:sage [2009/07/28(火) 13:22:42 ]
- >>584
D3DXSprite自身が、内部的に座標変換済頂点(rhw)を使ってるんだが、どうよ？
単体の画像を何枚か扱う程度ならこのままでもいいが、小さなチップを大量に描画するようなら
通常の頂点バッファ(Position)を使うことを考えた方がいい。
- 587 名前：デフォルトの名無しさん mailto:sage [2009/07/28(火) 13:22:55 ]
- DirectXにSpriteなど無い
- 588 名前：デフォルトの名無しさん mailto:sage [2009/07/28(火) 13:24:51 ]
- D3DXSPRITEなら定数として存在するが、D3DXSpriteなど無い
- 589 名前：デフォルトの名無しさん [2009/07/28(火) 13:39:16 ]
- >>583
D3DXGetFVFVertexSize( mesh.pmesh->GetFVF() );
として取得したところ、返された数値は12でした。
ですので12byteと判断しているのですが……。
もし不都合があれば教えてください。
よろしくお願いします。
- 590 名前：584 mailto:sage [2009/07/28(火) 13:50:35 ]
- ttp://marupeke296.com/DXG_CreateBorad.html
ttp://marupeke296.com/DXGSmp_No2_2DPoly.html
座標変換済み頂点は、ここの内容を見てます。
>>585
つまり結局は同じ処理をしているという事ですか…
>>586
>通常の頂点バッファ(Position)を使うことを考えた方がいい
通常の…ですか。勉強不足で通常というのがよく分らないのですが
上記のURLにあるコードのような使い方をする場合
「小さなチップを大量に描画」というのは不向きなのでしょうか？
- 591 名前：デフォルトの名無しさん mailto:sage [2009/07/28(火) 14:04:27 ]
- 流体力学研究所とかいうとこを参照してみては？
- 592 名前：デフォルトの名無しさん mailto:sage [2009/07/28(火) 15:10:47 ]
- >>589
途中から？それって頂点データを超えて取得してるんじゃないの？
GetNumFacesとかGetNumVertices使ってる？
- 593 名前：デフォルトの名無しさん mailto:sage [2009/07/28(火) 17:51:19 ]
- |￣￣￣￣￣￣￣￣￣￣|
| |
| |
/ ￣￣￣￣ /＿＿＿__
/ また旅に出ます /ヽ＿＿／/
/ / / /
/ 探さないで下さい / / /
/ ＿＿＿＿ / / /
／ ／ / /
／ 光 圀 ／ / /
￣￣￣￣￣￣￣￣￣￣/ / /
のパターンじゃないんだな
- 594 名前：デフォルトの名無しさん [2009/07/28(火) 21:15:24 ]
- >>592
使用している部分について、ソースをアップしました。
www1.axfc.net/uploader/Sc/so/22044
もしよろしければ、ソースをダウンロードしていただいて
見てもらってよろしいでしょうか？
GetNumFaces、GetNumVerticesは、一応数値は取得していますが
実際のところどのようにしてポリゴンとして頂点が格納されているのかが
まだ分かっていません。
- 595 名前：デフォルトの名無しさん mailto:sage [2009/07/29(水) 02:52:06 ]
- pvertex + fvfsize
らめぇぇぇぇぇ
- 596 名前：デフォルトの名無しさん mailto:sage [2009/07/29(水) 02:55:49 ]
- あれ？そこだめなの？
俺は
v1=*(D3DXVECTOR3*)(pointVert+FVFSIZE*(indexp[0]));
v2=*(D3DXVECTOR3*)(pointVert+FVFSIZE*(indexp[1]));
v3=*(D3DXVECTOR3*)(pointVert+FVFSIZE*(indexp[2]));
ってやってるけど問題ないぞ
- 597 名前：594 [2009/07/29(水) 03:29:12 ]
- >>595
試しに
pvertex[*(pindex+i)];と配列でアクセスしたら幸せになりました。
理由はわかりません。
今回わかったことは、頂点バッファ内に「三角形ポリゴン数×３」個の頂点が格納されているわけではないので
インデックスバッファも使ってアクセスしないときちんと読み取れないということでした。
凸凹の大きいモデルを使った場合、ポリゴンの読み間違いが起こると、Hitが抜けなかったり、
本来あるはずない場所でHitが出たりなどという現象が起こるのは当然でしょう。
しかし、今回の問題は読み込んだ数値自体がおかしくなっていたことでした。
明らかにストライドの量がおかしかったんだと思いますが、何が理由かよくわかりません。
>>596
私の環境でも結果は駄目でした。
突き抜けた穴のあいたポリゴンを使用してテストしていますが、
途中でHitが出てしまいます。
本当に助かりました。
協力してくださった方、ありがとうございました。
- 598 名前：デフォルトの名無しさん mailto:sage [2009/07/29(水) 03:30:46 ]
- (pvertex + 0) の次の頂点は (pvertex + 1)なんだぜ
- 599 名前：デフォルトの名無しさん mailto:sage [2009/07/29(水) 03:38:42 ]
- poly.v[0] = *(Point3D*)((BYTE*)pvertex + fvfsize*(*(pindex+i-2)));
poly.v[1] = *(Point3D*)((BYTE*)pvertex + fvfsize*(*(pindex+i-1)));
poly.v[2] = *(Point3D*)((BYTE*)pvertex + fvfsize*(*(pindex+i-0)));
こうするか、
もしくは最初からpvertexをBYTE*で宣言すればOK
- 600 名前：594 [2009/07/29(水) 03:50:17 ]
- >>599
動作確認出来ました。
pvertexがD3DXVECTOR3*型だったから駄目だったんですね。
ポインタのアドレスって、どんな型であろうと変わらないかと思っていました。
ポインタのアドレスを弄るときはchar*なわけですね。
すごく助かりました。
今度C言語の参考書よみなおします。
- 601 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 02:17:57 ]
- 初心的質問ですみません。
DirectXを使っているプログラム内でwavを再生させるにはどうすればよいのでしょうか？
ほとんどのところでdmusici.hを使えとなっているのですが、ヘッダーをインクルードしても見あたらないというので調べたところ廃止(?)になったとかで書かれていて
いくつか調べたのですが、ほとんどのところがdmusici.hを使ってでのやり方なので、解らずじまいです。
現在の再生方法をおしえていただけないでしょうか？
- 602 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 02:21:17 ]
- おとなしくＤｉｒｅｃｔＳｏｕｎｄを使ったほうがいい
- 603 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 02:57:27 ]
- 普通にXAudio2使えよ
- 604 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 10:26:20 ]
- XBox360の市場が壊滅状態でもXAudio2はヤバくないんですか？
- 605 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 11:15:28 ]
- 実際のところ、X～～ ってどうなんでしょう。
XAudio2って言うほどまともとは思えないんですが。
- 606 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 12:12:44 ]
- 失礼します。
directx_mar2009_redist.exeをCドライブにインスコしようとするのですが、
必ず半分ぐらい進んだところでゲージが巻き戻り、結局右端までたどり着かず
途中で終了してしまうのです。一体どういうことなのでしょうか
- 607 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 13:14:58 ]
- 炎や爆発、煙などのエフェクトをビルボードを大量に出して
描画しようと思っているのですが、どうすれば高速に描画できますか。
- 608 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 15:09:40 ]
- 現状のエフェクトでどんな処理をやっているのかが分からないので、
より高速な方法について答えようにも答えることができません。
- 609 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 15:38:19 ]
- 大量に出すのをやめる
- 610 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 15:43:31 ]
- より高速かどうかは置いといて、
最も早いと思われる描画方法を教えてください。
- 611 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 15:44:56 ]
- マジレスすると
視錐台クリップが最重要だな
次にその中に入ってしまったものをまとめて描画だな
あらかじめDrawPrimitiveにぶち込んでしまうとクリッピングされないから
ある程度の塊でおおざっぱな判定でもするといいよ
なんにせよクリップ方法が最重要
これでしっかり省けば余計な最適化いらない場合のが多いよ
- 612 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 15:46:35 ]
- >>610
それはいつでもどこもでネタでもなんでもなく「描画しない」ってのが最速
- 613 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 16:00:32 ]
- >>611
まとめて描画とは、Zsortをして
板ポリ(2ポリ4頂点)×出す量 を毎フレーム描画
ということですか？
>>612
描画しなかったら私のも速くなります。
しかしビルボードをたくさん描画すると重くなるのです。
- 614 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 16:31:13 ]
- やめろよ
また不毛な議論が始まるぞ
せめてどうやってるのかも書かない奴に
答えてどうする
- 615 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 16:53:11 ]
- >>614
カメラ空間でのZ値でZsortして、板ポリ一個一個毎フレーム
逆行列作る
worldViewProjectionMatrix作る
effect->SetMatrix
でセットし
effect->setTechnique
effect->Begin
effect->BeginPass
effect->setTexture
effect->CommitChanges
ここでdeclarationをセットし
DrawIndexedPrimitive((D3DPT_TRIANGLELIST....);
effect->EndPass
effect->end
と普通にやっています。
- 616 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 16:57:07 ]
- >>613
その前にクリッピングそれができないなら気にしなくていい
- 617 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 17:11:27 ]
- >>616
そうですか、今回作るゲームが引いた視点なので
結構、というかほとんど視錐台に入るんですよね…
- 618 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 17:23:29 ]
- 特殊な条件、爆発の煙や湿原の霧でパーティクルが数百個くらい普通に出てるような状況。
ポリゴンを自前で座標変換後したあとにバッファにためておいて、バケツソートで数個のブロックに分けて描画とか。
- 619 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 17:42:07 ]
- >>618
>ポリゴンを自前で座標変換後したあとにバッファにためておいて、
>バケツソートで数個のブロックに分けて描画とか。
ちょっと良く分からなかったのですが、
座標変換は存在するすべてのビルボードパーティクルに対して行い(頂点座標を書き換えるのでなくてワールド座標)
それらビルボード一枚一枚をzソートするクラスに溜めています。
そしてｚソートし、一気に一枚一枚描画しています。
ブロックごとに分けて描画するとなると
ブロック内のz値の順番はうまくいきますが
ブロックごとのz値の順番がおかしくなりませんか？
- 620 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 18:01:08 ]
- ソートした後で分割
- 621 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 18:29:54 ]
- >>620
分割する意味がわかりません
- 622 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 18:40:22 ]
- もしかしてポリゴン1枚づつDrawPrimitveしてるの
- 623 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 18:51:59 ]
- そうです。
- 624 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 18:58:04 ]
- そりゃないわ。
炎を100個のビルボで表現しているとするなら、その100個は1回のDrawPrimitiveで描画してしまいなさい。
ところで、加算合成なら前後関係をソートする必要がないのは知ってるか？
半透明にしても、ソートがてきとーでも、そうそうばれないからあまり気にするな。
炎単位でソートするくらいで十分。ビルボ1つ単位でソートしてたらすさまじいことになっちまうぜ。
- 625 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 19:17:12 ]
- >>624
>炎を100個のビルボで表現しているとするなら、その100個は1回のDrawPrimitiveで描画してしまいなさい。
いったいどうやるんですか？
頂点バッファに全ビルボードの移動後の頂点を入れておくとかですか？
そうだとすると、フレームによってビルボードの数が変わるので
毎フレーム頂点バッファを作りなおさなくてはいけなくなりませんか？
全加算なら単純に足すだけですから、炎とかならいいと思いますが
ミサイルなどの手前から奥に飛んでいく煙を表現する場合の線形合成は(今回使います)
ソートは必須です。
しかもいくつもミサイルが飛んでいる場合それらの煙単位でソートしては
煙１と煙２が重なった場合板ポリの輪郭が見えてしまいます。
なので煙全部でソートしないとうまくいかないんです。
- 626 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 19:22:06 ]
- ここで以前DrawPrimitiveUPや動的頂点バッファの話をしてたが、
まさに枚フレーム書き換えるような頂点のためだよ
- 627 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 19:25:30 ]
- >>625
>頂点バッファに全ビルボードの移動後の頂点を入れておくとかですか？
それでOK。
頂点バッファを毎フレーム「作り直す」のはつらいので、500ビルボード分作る。
MSのヘルプによると、一回のDrawPrimitiveでは1000ポリくらいが適切だということなので、ビルボは三角形二つだから500ビルボード分ね。
ミサイルの煙を半透明でやるのね。OK。
「気にすんな」でOK
とりあえず試してみ。前後関係が狂っててもまったく気にならないから。
「気にならない」正確さより、「気になる」処理落ちを防ぐのを優先。
>煙１と煙２が重なった場合板ポリの輪郭が見えてしまいます。
半透明の物体を描くときは、Zバッファへの書き込みをOFFにするべき。
そうすればこの現象は起きないよ
- 628 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 19:28:30 ]
- >頂点バッファを毎フレーム「作り直す」のはつらいので、500ビルボード分作る。
500ビルボード分の大きさで作る。のほうがわかりやすかったね。補足。
描画するたびに中身を書き換えて使うべし。
ロックする際D3DLOCK_DISCARDを指定すれば、ロック待ちも発生しないので早いぞ。
- 629 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 19:33:42 ]
- >>626
毎フレーム書き換えるのは頂点バッファをLock,UnLockして書き換えるより
頂点シェーダでやったほうが高速だと思ってたので、すべて頂点シェーダでやっています。
それはスキンメッシュのスキニングをシェーダでやったほうが
何倍も高速だったのでそう思っています。
DrawIndexedPrimitiveを何回も呼ぶより
バッファ作ってLockして書き換えたほうが速いということですか？
上のほうで言ってたことは
結局はDrawIndexedPrimitiveもUPも大して速度は変わらないという結論ですよね。
- 630 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 19:43:28 ]
- >DrawIndexedPrimitiveを何回も呼ぶより
>バッファ作ってLockして書き換えたほうが速いということですか？
書き換えたほうが速い。
というのも、DrawIndexedPrimitiveの呼び出しオーバーヘッドは遅いので。
頂点シェーダでやると高速化するのは確かにそうだが、やるなら281法をやることになる。
確かにID3DXEffect::SetVectorArray()で座標情報を渡すのが大抵のグラボで最速。
ただ、定数レジスタの数の制限を考えるに1回につき250ビルボ程度しか描画できない。
あとは場合によりベターな方法は変わる。
まとめて描画する単位が250ビルボ以下ならこちらでいいと思われ。
- 631 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 19:50:21 ]
- 固定的な頂点バッファとは別に、毎フレーム書き換わるデータ向けの動的頂点バッファがあるの。
その違いを分かってないから、スキンメッシュとの比較検証も、効率悪いやり方でやった場合の結果にすぎない。
- 632 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 19:59:06 ]
- >>630
複数の頂点情報ストリームを登録しておいて、片側を毎回書き換えるという方法が考えられるな。
（で、VertexShaderで合算する）
計算がいくらか楽になるかもしれない。どれくらい速度が変わるかは試してみないと分からないけど。
- 633 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 20:02:57 ]
- とりあえず、281法含めて色々実測した身としては、
UPだろうがUPじゃなかろうが、頂点シェーダを使う方法だろうが
「沢山のビルボードを、まとめて一回のDrawIndexedPrimitive*で描画する」という基本を守っている限り、
速度誤差は0.1%にも満たないということだ。
小難しいことを考えるが面倒なら、DrawIndexedPrimitiveUP使っておくといいよ。
（レガシー関数だから嫌というこだわりがなければ。ね）
本気で速度の差はほっっっっっとんどでないから。
まぁ、流石マイクロソフト。DrawIndexedPrimitiveUPの中身もちゃんと最適化されてるんだなといったところ。
- 634 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 20:11:38 ]
- >>627
>一回のDrawPrimitiveでは1000ポリくらいが適切
それは知りませんでした。
>半透明の物体を描くときは、Zバッファへの書き込みをOFFにするべき。
>そうすればこの現象は起きないよ
そうですよね、なるほど！
>>630
>書き換えたほうが速い。
>というのも、DrawIndexedPrimitiveの呼び出しオーバーヘッドは遅いので。
そうなのですか。
>>631
Lockして書き込む際のD3DLOCKの種類のことですよね？
ここはよくわかっていませんでした。
D3DLOCK_NOSYSLOCKを指定していました。
Lockの際に、D3DLOCK_DISCARDを指定すれば動的頂点バッファになるということですね。
CreateVertexBufferの第二引数はD3DUSAGE_WRITEONLYでOKですか？
いろいろやり方が見えてきたので早速試してみたいと思います。
ありがとうございました。
- 635 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 20:55:13 ]
- WRITEONLYが適切。
だけどこのスレで「間違えて読み込みしてて、性能だだ落ちしてた」ってのが実例としてあったから気をつけるこった。
- 636 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 21:10:38 ]
- 質問です。
2D描画時のテクスチャー矩形転送のお約束として、
転送先座標を-0.5ｆするというのがありますよね。
あれの意義はわかりますし、そうやっているので普段は良いのですが、
拡大転送する際「テクスチャーの参照の際、隣のドットの色が影響してしまう」現象が起きるようです。
これを回避する方法はないでしょうか？
LINEARを使わず、NEARPOINTでやればいいのでしょうが、拡大の粗が見えてしまいますので・・・。
- 637 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 21:19:08 ]
- 一枚のテクスチャの中で別パーツと混ざるのが嫌なケース？
そりゃ周囲には1ピクセルずつ余白を置くとかじゃね。
昔の2Dゲームのような32x32のチップをぎっしり敷き詰められたデータなら、諦めるか、34x34で置き直すとか。
- 638 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 21:36:52 ]
- はい、そのケースです。
やっぱり余白しかないですか･･･。
縮小ならわかるのですが、拡大でも周りを参照しちゃうのがちょっと納得いかないところなんですが・・・
- 639 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 21:39:12 ]
- 状況が許すなら、まず拡大しないブリットでチップを
レンダーターゲットのテクスチャに敷き詰めて
そのテクスチャを拡大するって手はある
- 640 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 21:46:51 ]
- >転送先座標を-0.5ｆするというのがありますよね。
そのやり方は正しいと思えないんだが。
むしろUVを半ピクセルずらすのが正しいやり方だろ？
UVをそのままで表示座標を変えてごまかしたりするから、表示倍率を変えると狂っちゃうわけで。
UVマッピングの詳細はMSDNにちゃんと書いてあるので確認すること。
ちゃんとやったらチップを画面いっぱいに並べようが拡大しようが、ずれたりすることはないよ。
現に手元で動いてる。
- 641 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 22:03:18 ]
- >>640
0.5ずらすのは
「バイリニアフィルタを適用している時に」
「頂点座標をスクリーン座標に直接マッピングすると」
ピクセルがテクセルの中心にマッピングしてしまい、拡大してなくてもぼやけてしまうのを防ぐためでしょ。
だから表示倍率を変えると云々はそもそも文脈としておかしいんだが。
- 642 名前：641 mailto:sage [2009/08/01(土) 22:06:18 ]
- うん、俺の文もおかしい。
x テクセルの中心
o 4テクセルの中心
- 643 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 22:16:46 ]
- >>641-642
オレの言ってることと君の言ってることはほとんど同じような気がするんだが、どうだろうか。
当倍表示の場合は636でも640でもいいが、拡大表示したら636ではおかしくなる。
そういうことだろ？
というか、そんな細かい処理をするときはフィルタはNoneにしたほうがいいと思うんだが。
拡大・縮小はきたなくなるけどな！
- 644 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 22:20:30 ]
- >>640
一応
ttp://msdn.microsoft.com/ja-jp/library/bb219690(VS.85).aspx
これには目を通しています
これでも、ほかのサイトでも、転送先座標を + xy(-0.5f, -0.5f) するように思えます
640さんの方法は、拡大しても隣の色を巻き込んだりしないのでしょうか？
一応「座標はそのままに、UVを半ピクセルプラスする」方法でもやってみましたが、やはり拡大時には隣の色を巻き込んでしまうようです。
- 645 名前：641 mailto:sage [2009/08/01(土) 22:29:42 ]
- >>643
拡大するとおかしくなるんじゃなくて隣の色を拾うんだから
アルゴリズム上は正確な挙動だよ。
てゆーか言ってるのはテクスチャ座標を0.5テクセル分ずらす方法だよね？
言い忘れてたけど、その方法だと拡大はせずに反転した時に
完全なミラーにならずに一ピクセル分表示がずれちゃうよ。
そっち方法で隣の色を巻き込まないってのは、うーん、
手元で試せないので「そんな馬鹿な」としか言いようが・・・
- 646 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 23:11:12 ]
- ＦＦＴ式に回転させるとそんな苦労も水の泡だぜ
- 647 名前：デフォルトの名無しさん mailto:sage [2009/08/01(土) 23:29:58 ]
- 周りからそんなに反論されると、なんか自分も自信がなくなってきた。
まあそれはともかくとして、
表示を10倍くらいに拡大すると、もはや直角二等辺三角形２つを並べたテクスチャの斜めの辺の挙動が無視できなくなるな。
大体10x10にならんでるけどところどころ９になったり１１になったりする。
それに斜めにずれているところがあることに気づく。ちょうどポリゴンを斜めに並べたところだ。
なんだかどうにもならないことのような気がしてくる。
頂点を共有せずに微妙に１ピクセル分ずらしたりの調整が必要になってくるのかも。
- 648 名前：デフォルトの名無しさん mailto:sage [2009/08/02(日) 00:21:13 ]
- とりあえず軽く実験してみたが、
転送先スクリーン座標を-0.5f, -0.5f しただけでは、拡大転送時に周りの1ドットの影響を受けてしまうな
- 649 名前：デフォルトの名無しさん mailto:sage [2009/08/02(日) 00:33:43 ]
- >>648
そうだなぁ。例えば１０倍拡大したときは0.1f、0.1fくらいでちょうどいいようだ。
微妙に9倍や11倍されてるピクセルがあるようだが、
こんなに拡大されたＣＧを凝視するようなことはないだろうから実用上は問題ないだろう。
２Ｄ表示における倍率に指定すべきUVオフセットが影響を受けるのかもしれない。
しかしGPUの機種の差異もありそうだしなぁ。
- 650 名前：デフォルトの名無しさん mailto:sage [2009/08/02(日) 14:36:23 ]
- >>641が言っているように、0.5ずらしは
本現象とは何の関係もない。
D3DTEXF_LINEARが、2x2エリアをサンプルするのが原因。
一応、UV座標を半テクセル分内側にずらすことで回避出来る。
float texture_width = 512;
float texture_height = 512;
float wh = 1.0/(texture_width*2);
float hh = 1.0/(texture_height*2);
float uv_quad = { u0 + wh, v0 + hh, u1 - wh, v1 - hh };
ただし、ずらす分マップするエリアが狭まるので注意。
- 651 名前：デフォルトの名無しさん mailto:sage [2009/08/02(日) 15:24:25 ]
- 状況や描画させ方によるので
唯一これが最速だという答えは出せません。
ゲーム、あるいはエンジンに合わせて最適化がそれぞれ必要です。
- 652 名前：デフォルトの名無しさん mailto:sage [2009/08/02(日) 15:28:10 ]
- それでも、Direct3D9で2D等倍表示をするときだけしか正しくない「頂点座標を0,5ずらす」を
後生大事に信じ込むのは馬鹿だろう
- 653 名前：デフォルトの名無しさん mailto:sage [2009/08/02(日) 15:40:27 ]
- 基本的な質問で申し訳ないんだが、
GPUの機種によって描画できる場合と描画できない場合ができていて困っている。
原因は何が考えられるだろう？
動作条件は
・DirectX 9使用
・Vertex/PixelShader使用
・FVFはPosition|DiffUse|UV
・空間座標変換はCPU側で事前に合成してから単一の4x4行列としてID3DXEffectに入力。
現行のプログラムでRADEON HD4850だと正常にポリゴンが描画できるが、
Intel GMA950では描画されない。Device->Clear()は動いてる。
また、FVFがPositionRhw|DiffUse|UV のときは描画できることも確認している。（座標変換が利かなくなるが）
シェーダー使ってなかったころのプログラムやシェーダーを使ってる
サンプルプログラムでは描画できてるから、ハードウェアのせいではない。
- 654 名前：デフォルトの名無しさん mailto:sage [2009/08/02(日) 15:45:16 ]
- きわめて一般的な描画方法だからどこかおかしいんと違う？
|
 |
