- 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/
- 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 ]
- きわめて一般的な描画方法だからどこかおかしいんと違う？
- 655 名前：デフォルトの名無しさん mailto:sage [2009/08/02(日) 17:51:26 ]
- >>653
それだけの情報で分かるわけないだろう。
デバッグランタイムも何も文句言わないの？
- 656 名前：デフォルトの名無しさん mailto:sage [2009/08/02(日) 19:32:40 ]
- >>655
デバッグランタイムは動かしたことないな。試してみる。
開発マシンじゃなくてテストマシンだったからDirectX SDKは入れてないので。
vs/ps3.0を指定してたら描画結果が真っ白になってしまったことはあったけど、
今回はそんなわかりやすい現象じゃないからなぁ。
- 657 名前：デフォルトの名無しさん mailto:sage [2009/08/02(日) 23:00:15 ]
- developer.download.nvidia.com/SDK/10.5/direct3d/samples.html
Stencil Routed K-BufferってDirectX9では出来ないんでしょうか？
マルチサンプルへのアクセスが必要でDirectX9では出来ない、というようなことが書いてありますが
マルチサンプル使わずに出来たりはしないんでしょうか。
- 658 名前：デフォルトの名無しさん mailto:sage [2009/08/03(月) 00:21:35 ]
- ここで質問していいのか微妙な内容なのですが
スレ違いでしたらスルーしてください。
DirectXを使用するとどうしても気になってくるんですが
プログラムで使用されているVRAMの消費量を調べる方法はありませんか？
メモリ使用量を調べるような関数があるのかと思ったのですが見つけられず…
よろしくお願いします。
- 659 名前：デフォルトの名無しさん [2009/08/03(月) 02:01:17 ]
- DeviceCaps取得すれば
ＶＲＡＭ容量わかるお
- 660 名前：デフォルトの名無しさん mailto:sage [2009/08/03(月) 13:27:18 ]
- nai
- 661 名前：デフォルトの名無しさん mailto:sage [2009/08/03(月) 13:27:58 ]
- このスレにいる人レベル高いなぁ
多分大学生が多いだろうから、大手狙いなんだろうなぁ……負けないように何か作るか
- 662 名前：デフォルトの名無しさん mailto:sage [2009/08/03(月) 14:04:14 ]
- Zバッファがうまく動かないんですが
環境
WindowsXP VisualStudio2005 MFC Geforce9600GT
初期化
m_d3dPP.EnableAutoDepthStencil = TRUE;
m_d3dPP.AutoDepthStencilFormat = D3DFMT_D16;
LINE_VERTEX line[6] = {
{-1 , 0, 0, 0xFF00FF00},
{1 , 0, 0, 0xFF00FF00},
{0 , 0 , 0 , 0xFFFF0000} ,
{0 , 1 , 0 , 0xFFFF0000},
{0 , 0 , -1 , 0xFF0000FF} ,
{0 , 0 , 1 , 0xFF0000FF}
};
CreateVertexで書き込み
- 663 名前：デフォルトの名無しさん mailto:sage [2009/08/03(月) 14:06:11 ]
- 視点の初期化（マウスで回転した時も）
D3DXMatrixLookAtLH(&d3dm , &D3DXVECTOR3(0, 0, 6) ,
&D3DXVECTOR3(0, 0, 0) , &D3DXVECTOR3(0 , 1 , 0));
m_pDeviceD3D->SetTransform(D3DTS_VIEW , &d3dm);
D3DXMatrixPerspectiveFovLH(&d3dm , D3DXToRadian(45.0) ,
(float)rect.right / (float)rect.bottom , 0 , 1000);
m_pDeviceD3D->SetTransform(D3DTS_PROJECTION , &d3dm);
D3DXMatrixRotationYawPitchRoll(&Rot, D3DXToRadian(m_AngleY), D3DXToRadian(m_AngleX), D3DXToRadian(0.0f));
m_pDeviceD3D->SetTransform(D3DTS_WORLDMATRIX(0) , &Rot);
m_pDeviceD3D->SetRenderState(D3DRS_CULLMODE , D3DCULL_NONE);
m_pDeviceD3D->SetRenderState(D3DRS_LIGHTING , FALSE);
m_pDeviceD3D->SetRenderState(D3DRS_ZENABLE, TRUE);
m_pDeviceD3D->SetRenderState(D3DRS_ZWRITEENABLE, TRUE);
- 664 名前：デフォルトの名無しさん mailto:sage [2009/08/03(月) 14:09:05 ]
- 描画
m_pDeviceD3D->Clear(0, NULL, D3DCLEAR_TARGET|D3DCLEAR_ZBUFFER, D3DCOLOR_XRGB(20,0,50),1.0f, 0);
m_pDeviceD3D->BeginScene();
m_pDeviceD3D->SetStreamSource( 0, g_pVB, 0, sizeof(LINE_VERTEX) );
m_pDeviceD3D->SetFVF( D3DFVF_XYZ|D3DFVF_DIFFUSE );
for(int i=0; i<3; i++)
m_pDeviceD3D->DrawPrimitive( D3DPT_LINELIST, i*2, 1);
XYZの軸を引いてマウスで回転させてるだけなんだけど
角度によって後ろの線が前に出てきたりZバッファが機能してないみたいなんだけど
どこが間違ってるんでしょう？
- 665 名前：デフォルトの名無しさん mailto:sage [2009/08/03(月) 15:40:38 ]
- D3DXMatrixPerspectiveFovLHの第4引数（znear）が0になってますがな
- 666 名前：デフォルトの名無しさん mailto:sage [2009/08/03(月) 19:40:54 ]
- >665
ゼロからじゃだめなんですか？
- 667 名前：デフォルトの名無しさん mailto:sage [2009/08/03(月) 20:22:40 ]
- だめ。
視錐台の前面が面積0になってしまう。
- 668 名前：デフォルトの名無しさん mailto:sage [2009/08/03(月) 20:49:46 ]
- >>665
ありがとう、とりあえずそこを1.0にしてみたら出来たけど
いまいち原理が良くわからないから調べますわ
- 669 名前：デフォルトの名無しさん mailto:sage [2009/08/03(月) 23:17:36 ]
- 質問です。
川瀬式MGFを実装しようと思い、ここを参考にしながら
journal.mycom.co.jp/column/graphics/050/index.html
やってみたのですが、うまくいきません。
低解像度テクスチャに書き出し拡大しても
こんな風に●の中心を中心に、拡大されたようにならないんですが
何かご存知のであればアドバイスをいただきたいです。
- 670 名前：デフォルトの名無しさん mailto:sage [2009/08/03(月) 23:33:29 ]
- きみがやってみて失敗した結果の画像をどこかのアプロダに張れないか
- 671 名前：デフォルトの名無しさん mailto:sage [2009/08/03(月) 23:35:04 ]
- ちょっと待っててください
- 672 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 01:58:54 ]
- そして>670は待ち続けた。
雨が降ろうと、風が吹こうと、雪が積もろうと、>671が帰ってくるのをずっと
待ち続けた。
スレの主人はそんな>670を不憫に思い、毎晩、スレを畳む時間になると、残り
物のレスをそっと脇に置いて帰ったが、翌朝までに手をつけられていたことは、
一度も無かった。>670は、ただひたすら一つのレスを見続けていた。
結局、>671が帰ってくることは、二度と無かったのだ。
なぜなら、>671は
- 673 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 08:48:32 ]
- （続き） なぜなら、>671は>672だったからなのだ。
- 674 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 10:00:36 ]
- UV値を入れずにポリゴンを書くとテクスチャを指定しても表示されないんだけど
大きさを可変にしたいからタイルパターンでテクスチャを貼り付けたい時はどうすればいいの？
- 675 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 10:03:27 ]
- そういうふうにUVを指定しろ
- 676 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 17:30:35 ]
- >674
テクスチャ画像を作る段階でタイルパターンの画像にしておけば良いのでは？
- 677 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 17:36:42 ]
- シェーダー使えば可能だろ
- 678 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 17:51:34 ]
- いろいろあるよ
- 679 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 18:17:51 ]
- ２Ｄを扱う場合、高速で描画できる方法を教えてください。
一応自分なりに調べて、描画をさせてみたのですが
ＤＸライブラリというライブラリを使った場合と比べるとかなり差が出てしまい
原因を探しています。
描画方法は、頂点バッファを使いDrawPrimitiveで画像を１つずつ描写しています。
よろしくお願いします。
- 680 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 18:26:04 ]
- 頂点バッファを使い1回のDrawPrimitiveで全部の画像を描画すると速いと思うよ
必要な絵全部を1枚のテクスチャに詰め込んでおくと良い
- 681 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 18:44:55 ]
- >>頂点バッファを使い1回のDrawPrimitiveで全部の画像を描画すると速いと思うよ
このやりかたが分からず…方法の載っているサイトなどありましたらおねがいします。
DirectXによる２Ｄゲーム制作サイトなど見たのですが、１フレーム分描画するのに何度もDrawPrimitiveしているものばかりでした
- 682 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 19:00:41 ]
- 画像数×6個の頂点が入る大きさの頂点バッファを作って、
全部の頂点を書き込んで、DrawPrimitiveするだけ
- 683 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 19:15:58 ]
- 頂点バッファを一つにまとめて、テクスチャも一つにし
それを一度にDrawPrimitiveすればいいってことですよね…
つまりDrawPrimitiveの呼び出し回数が描画速度に関わってるって
ことですか…
複数のテクスチャを扱っているので、できるだけ呼び出し回数を減らしてみます。
- 684 名前：デフォルトの名無しさん mailto:sage [2009/08/04(火) 19:25:00 ]
- >>683
↓まだ読んでないなら、読んでおくといい
msdn.microsoft.com/ja-jp/library/bb147263(VS.85).aspx
- 685 名前：684 mailto:sage [2009/08/04(火) 19:47:36 ]
- >>684
ありがとうございます。複数のテクスチャを扱うときは
グループ化すれば、描写速度があがるんですね。非常に勉強になりました。
- 686 名前：683 mailto:sage [2009/08/04(火) 19:51:33 ]
- >>685は名前ミスです。
早速、現状と比べてきます。
|
 |
