DirectX総合スレ (Part5)

**名前は開発中のものです。** · 2006/09/08(金) 23:56:42

言語はC++
他の言語使ってる奴はいますぐ消えろ

**名前は開発中のものです。** · 2006/09/30(土) 00:34:44

CreateSakuratan

**名前は開発中のものです。** · 2006/09/30(土) 06:08:14

mikoto2xで吐いたXファイルを、シェーダーを介してボーン変形出来るようになったんすが、
どうもMikotoでの変形結果と同じにならない

調べたらMikotoのボーン変形は、関節部を潰さないようにかなり特殊な計算をしているみたいっすね
これってどうやってるのかな。シェーダーじゃ無理っすかね

**名前は開発中のものです。** · 2006/09/30(土) 08:48:50

D3DXの高レベルAPIを使っているのなら、それをやめれば解決。
クオータニオンの補間がおかしいし、その他問題が沢山あるので使い物にならない。

**510** · 2006/09/30(土) 10:27:47

>>511
レスどうもっす
申し訳ないっすが、姿勢行列の補間は関係なさそうっす。シェーダーなんで頂点補間の部分は当然自前です

スキニングなんて誰がやっても同じ計算（ボーンごとに変形した頂点座標を、ウェイト値に基づいて再調整）に
なるわけっすが、どうやら他の算出方法もあるらしい。それをお尋ねしたい次第っす

それとも、あまり有名じゃないんすかね。検索しても全く出てこないっすし・・・
Mikotoオリジナルっぽい気がしてきましたわ。一体どうやってるんすかね

**名前は開発中のものです。** · 2006/09/30(土) 11:13:00

定番の方法は所詮線形補間だからな。
ちゃんとやるならそれなりに面倒なコトになるだろうけど、
線形補間でもちゃんと見えるようにデータを作るほうがいいと思う。

**名前は開発中のものです。** · 2006/09/30(土) 12:41:48

手作業になるけど関節の間にわざと緩んだ骨を仕込むってのがあったなー。
このへんはCG屋さんに聞いてみるのも良いんじゃない？

**名前は開発中のものです。** · 2006/09/30(土) 12:58:03

>>510
間接部の回転角度の補間はクォータニオンで扱って初めてやれる処理なんで
行列の方（つまりxファイル形式）に落とし込んじゃうともう事実上不可能だと思う
実際にはミクロマンのひざ間接みたいな二つの骨の間を埋める小さい骨を何個かつくってる
…はず

**名前は開発中のものです。** · 2006/09/30(土) 17:01:55

>>512
以前、mikotoの掲示板で「bdefアンカーによる影響ってどういう計算式？」
っていう質問があって、それに対してゆーり氏が
『秘密です。
　っていうのは嘘ですが、
　詳しく説明するのもアレなので、ヒントを。
　２個以上のアンカーに影響される頂点に対して、
　その頂点と互いのアンカーの面との距離で影響力を決定しています。
　アンカーの面は最低でも６つありますが、
　どの面との距離をとればいいかは想像つきますね？』
って答えてた。
結局、正確な計算式は不明。

**名前は開発中のものです。** · 2006/09/30(土) 17:21:25

>>516
すごくいいことを聞いた
横から㌧

**510** · 2006/09/30(土) 18:15:01

>>513-514
線形補間を詰めた方がｲｲって事っすね。ゲームですし、線形補間の方が速そうっすしね
ただあの綺麗な曲げは捨てがたく・・・

>>516
引用感謝っす。補間方法では無さそうっすが、ウェイトを決める方法っすね

>>515
なるほど、検索結果と合わせて何となく分かってきたっす
ボーンの回転中心を、頂点が結果的に円を動くような位置へと補間していけばいいんすね

おかげでなんとか出来そうです。皆さんレスありがとうございました

**名前は開発中のものです。** · 2006/09/30(土) 19:34:59

>518
確かにMatrixの線形補間の方がはやいけど、Quaternionで補間しても
誤差程度しか差は出ないよ。
肘、ひざ、肩とか必要な箇所だけ頂点の補間法変えればよし。

**名前は開発中のものです。** · 2006/09/30(土) 21:05:20

>>519
シェーダーでやるってことを考えるなら色々と最適化を考えても場所ごとに分岐はやめたほうがいい気がする。
ツール系は全部CPUで計算しちまっても問題ないがリアルタイムなゲームだと色々面倒だぞ。

**名前は開発中のものです。** · 2006/09/30(土) 21:44:59

>やめたほうがいい気がする。
「やってダメだった」じゃなくて「気がする」って事は
試してないって事でOK？

**名前は開発中のものです。** · 2006/10/01(日) 01:15:18

シェーダーの方で球面線形補間を頂点ごとにやってやろうと思ったけど
クォータニオンをマトリクスへ落とすだけでほとんど命令数を使い切っちゃう感じで駄目ですた
なにか最適化する方法があるのかもしれないんだけど頭が悪いのでわかりません

そんなわけなんで骨と骨の間にそれらを半々の割合で球面線形補間した骨をあらかじめ
用意しておいて使うことにしたんだけど、そうすると今度はシェーダーへ渡すマトリクスの
数が2倍近く増えるんでレジスタ数の限界を考えてモデルの方で使えるの骨の数に
かなりきわどい制限がでてきてしまう始末

**名前は開発中のものです。** · 2006/10/01(日) 01:24:03

大抵はシェーダで2パスの処理するわけだし
2度も線形補間のコードをシェーダで通すくらいなら
CPUでやったほうがよくね？

ぶっちゃけ簡単だし

**名前は開発中のものです。** · 2006/10/01(日) 01:49:58

確かに何回もDrawPrimitiveしなきゃならんとなると変形をすましちゃったものを
最初から用意しておいたほうが速くなる場合もあるね
そういうどーしょもない話がDirectX10だと解消されてくるわけだ

**名前は開発中のものです。** · 2006/10/01(日) 01:52:50

え、そーなの？それは知らんかった。
シャドウバッファとかやるときはどうすんだ？

**名前は開発中のものです。** · 2006/10/01(日) 03:27:09

ここはゲーム製作板なのに、レベル高いなぁ。

**名前は開発中のものです。** · 2006/10/01(日) 12:46:08

シャドウバッファとかは素直に書くしかない。
CPUとGPUを比べた場合現状はGPUの特に頂点シェーダーは
よほどのことがない限り遊んでるから頂点シェーダー側で命令が増えるのは
そんなにペナルティにならないことが多い。

一般的にゲームを作っていて処理がきつくなるのはCPU負荷とピクセルシェーダー部分。
とくにDrawPrimitiveはGPUコマンド発行するだけだがこれがべらぼうにCPU負荷食う。
ここはDirectX10で緩和されると言われてるね。

>>522
確かにボーンが増えてそれを全部定数レジスタに入れようとすると結構厳しくなるね。
とくにVS1.1だとボーンなんて10本くらいがいいとこだから現実的じゃないね。

最低でもVS2.0くらいのレジスタ数は欲しいねぇ。

できればVS3.0にしてボーンのマトリックスをfp16/fp32のテクスチャにいれて、
頂点シェーダー内でボーンのマトリックスをテクスチャからサンプリングするという方法もある。
これなら3テクセルに1ボーン入るからかなりの量のボーンが使える、ハズ。

**名前は開発中のものです。** · 2006/10/01(日) 12:54:03

モデリング時に頂点辺りの最大数を設定して最適化するしかない。

**名前は開発中のものです。** · 2006/10/01(日) 12:57:10

すいませんちょっと聞きたいことあります。
すでにDirectXで作ったゲームがあるんですが、
これをネトゲにしようかと思ってます。

そこで気になったことが１つあります。
うっかりウィンドウキーを押してしまうと最小化されてしまい、
その間にやられて死んでしまう可能性です。
人間同士の駆け引きを楽しむネトゲにしたいんで、
こういった部分は全て排除していきたいんです。

一応ウィンドウキーを無視するようにはできたんですが、
これはマナー違反みたいな意見もあるかと思いまして、
ちょっと迷っているところです。

つまり、
Ａ．ウィンドウキーを無効にしてゲームの快適さを優先
Ｂ．うっかりウィンドウキーを押して死んでしまってもＷＩＮのマナーを優先
どちらにすべきか・・・ということです。
個人的にはＡ．と思うんですが・・・。

よろしくおねがいします。

**名前は開発中のものです。** · 2006/10/01(日) 13:02:43

余計なことはして欲しくない。
世に言うところの、小さな親切大きなお世話。
どうしてもやるんだったら、後から設定するオプション扱い。

**名前は開発中のものです。** · 2006/10/01(日) 13:05:39

>>530
なるほどオプションですか。
これならばウィンドウキーの有効・無効が自由にできますね。
そうするとデフォは普通にウィンドウキーが有効になっていて、
ネトゲに熱中しちゃう人はオプションで無効にできるから、
うっかり押しちゃって死ぬなんてことはない・・・と。

とてもいいアドバイスありがとうございました。

**名前は開発中のものです。** · 2006/10/01(日) 13:09:47

・Windowsキーをブロックするのは確かにルール違反。
　だがやっているゲームも存在する。
　そもそもの問題としてキーフックはWindows2000以降でなければできない。

・ALT+TABをブロックするのはかなり嫌われるコトになるけどそっちをどうするのか？

・ALTキーを押したときに動作が停止しないか？

・タイトルバーをクリックしてウィンドウを移動させるときにゲームが停止しないか？

動作に関して気になるならこの辺も全部確認しとき。
ちなみに個人的にはWindowsキーやALT+TABは自己責任で
デバイスロスト状態からの復帰をきちんとサポートってのが好み。
普通はWindowsキーってそうそう押さないし。

**名前は開発中のものです。** · 2006/10/01(日) 13:15:22

>>527
頑張れば2テクセルでいけるな。
姿勢だけなら自由度6だから、6つのパラメータ有れば十分。
VSからテクスチャ参照するコストと、VS内で行列を生成するコストを
天秤にかけることになるが。

>>529
キーフックとかで無効にしてるのならやめよう。
DISCL_NOWINKEYでググるべし。

**名前は開発中のものです。** · 2006/10/01(日) 13:18:22

>>533
姿勢で持つにしても別途移動と親からのオフセットは必要にならない？

**名前は開発中のものです。** · 2006/10/01(日) 13:19:36

>>532
>・ALT+TABをブロックするのはかなり嫌われるコトになるけどそっちをどうするのか？
これにつきましては何もしないつもりです。
ウィンドウキーは１つ押しただけでスタートメニューが出てしまうので、
こういった操作ミスによるキャラ死亡だけは避けたかったんです。
ALT+TABは2つ押すんで操作ミスはありえないと思ってます。

>・ALTキーを押したときに動作が停止しないか？
>・タイトルバーをクリックしてウィンドウを移動させるときにゲームが停止しないか？
これについては後で考えますが、
現在はフルスクリーンのみで動くようになってます。

>>533
現在はキーフックでやってますが、
これはいいのを教えてもらいました。　→DISCL_NOWINKEY
早速取り込んでみたいと思います。

ありがとうございました。

**名前は開発中のものです。** · 2006/10/01(日) 17:20:55

>>523
DirectX10だと頂点シェーダー通った頂点をまたビデオメモリへ書き戻せるんだってさ
だから結構重たい変形処理を頂点シェーダーにやらせても次のパスではその結果を再利用できる

てか俺vs1.1で動かないといやなのにDirectX10とか何いってるんだろうね

**名前は開発中のものです。** · 2006/10/01(日) 17:26:08

ビデオカード側が対応していないと、全部CPUでやることになるけどね。

**名前は開発中のものです。** · 2006/10/01(日) 17:36:19

>>536
vs1.1を前提にするならそもそもレジスタが全く足りないので
ボーン処理は不可能と考えたほうがいい。

全部CPUでやるか固定機能でやるのが定番だな。

VS1.1ってGeForce3あたりだっけ？GeForce4も含まれるのかな。
どっちにしろそんな今となっては屑みたいなビデオカードをサポートすることで
クオリティを落とすというのはどうかと思うが趣味でやる分には別にいいのか。

GeForce3とかをHALでサポートするっていう前提の場合、
CPUも世代を合わせるとPen3の1000Hzあたりがターゲットってコトだよな。

日本は2D信仰が病的な程あるが、その強い影響で低スペックマシンを
前提として考える傾向が抜けないよなぁ・・・

低スペックマシンはオプションでギリギリ動くんじゃない？程度にしといて、
標準機能をは現行スペックにあわせて作ればいいのに。

**名前は開発中のものです。** · 2006/10/01(日) 17:37:00

1000Hzじゃなくて1000MHzネ・・・

**名前は開発中のものです。** · 2006/10/01(日) 17:41:36

>>538
↓で説教してきてください。

エロゲメーカーはいい加減低スペックPCを切り捨てろ
http://pie.bbspink.com/test/read.cgi/erog/1114845529/

**名前は開発中のものです。** · 2006/10/01(日) 17:54:14

趣味でやる分には切り捨てても良い、の間違いじゃね

>>515
行列に落としても出来るっしょ
逆にXファイルにクォータニオンで持たせることも(標準テンプレ範囲で)可能

**名前は開発中のものです。** · 2006/10/01(日) 18:02:29

いや業務でやる分にはとりあえず現行スペックにあわせて作ったうえで、
最終的には低スペックのマシンでも「表示がされなかったり動かなかったりはしない」
っていうレベルにしとけばいいわけだし。
切り捨てるっていうか基準を上にシフトさせるってコト。

そもそもvs1.1で作ったってGeForce2じゃHardwareTnLで動かんのだし。
MatroxG400じゃvsなくてもHardwareTnLで動かんわけだし、
作るときはこの辺でも全部「表示はされてゲームは動く」レベルには合わせるだろ。

まぁゲームのソースはビデオカードのサポート具合に合わせて
大量に機能毎の分岐やらシェーダー切り替えが出てくるケドナー。

**名前は開発中のものです。** · 2006/10/01(日) 18:03:29

>>538
足りないというのは、一頂点辺りいくつのボーンを前提にして足りないといってるんだ？
固定で出来る数なら1.1で十分に対応できるんだが、いったい何の話をしているんだ？

**名前は開発中のものです。** · 2006/10/01(日) 19:17:28

>>543
それはボーン数というかウェイト数だろう。
1回のDrawPrimitiveに使えるボーンの数が少なすぎるという話。

定数レジスタが96しかないんだからすべてをボーンに使ったって32本しか使えない。
だが実際には透視変換・ライティング・フォグ・テクスチャアニメーションなどの頂点処理で
レジスタを使わないといけないのだから１回のDrawPrimitiveで使えるボーンはせいぜい20本がいいトコだろ。

vsで凝ったことをするほど1回のDrawで使えるボーンの数が減っていくんだよ。
逆に凝ったことをやらないなら固定機能で十分なわけだ。

**名前は開発中のものです。** · 2006/10/01(日) 19:29:57

それはGeforce系でMaxVertexBlendMatrixIndexの数を確認した上での発言か？

**名前は開発中のものです。** · 2006/10/01(日) 19:37:58

Vistaが出るからこれからのメーカ製PCのグラフィック機能も底上げされる

といいな

**名前は開発中のものです。** · 2006/10/01(日) 19:55:43

底上げされても結局OSにパワー食われてしまうのでは？
と不安です。

**名前は開発中のものです。** · 2006/10/01(日) 20:06:55

どうせAeroは切れるし底上げしなきゃ喰われて死ぬしｗ

**名前は開発中のものです。** · 2006/10/01(日) 20:13:34

>>545
とりあえずGeForce6600

固定機能ライト数： 8
ブレンドマトリックス数： 4 ← MaxVertexBlendMatrices
ブレンドマトリックスインデックス数： 0 ← MaxVertexBlendMatrixIndex

頂点シェーダー定数数： 256
頂点シェーダーバージョン： 3.0
ピクセルシェーダーバージョン： 3.0
動的フロー制御命令のネスティング： 24
静的フロー制御命令のネスティング： 4

DirectX9世代のビデオカードでは固定機能はもうサポートされてないね。
メーカーの言うとおり全部シェーダーでやれっていうことなのだろう。
DirectX8世代はサポートしてるらしいけどねぇ。

そういうメーカーやAPI側の問題も踏まえたうえでDirectX8＝vs1.1は使い物にならんと言ってわけだが。
ちょっと言い方に問題あったな。
固定機能は除外してくれ。

VS2.0ベースで作って対応してなきゃD3DCREATE_MIXED_VERTEXPROCESSINGと
SetSoftwareVertexProcessing()で分岐って感じがいいと思うけどが一般的じゃないのかねぇ。

**WindowsVista** · 2006/10/01(日) 20:14:59

Radeon X以下の性能のベデオカード搭載機なんてＰＣである資格はありませんですぅ＞＜

**名前は開発中のものです。** · 2006/10/01(日) 20:41:42

くだらない煽りあいはもういいよ

>>541
＞行列に落としても出来るっしょ
どうやるか教えてください！

**名前は開発中のものです。** · 2006/10/01(日) 21:10:25

モデル読み込めてシェーダーも知識不要でテクスチャ読み込ませるだけで作成できて
プレビューもできるようなソフトない？

**名前は開発中のものです。** · 2006/10/01(日) 21:29:58

>>536
あー、なるほど。そういう仕組みなのか。
最近新しいことについていけねーよ・・・悪い傾向だなぁ

**名前は開発中のものです。** · 2006/10/01(日) 22:32:09

5000円もしないＦＸ5200w＠2z4i4b＠ewXPよりかるいのに
底上げとかないだろ

**名前は開発中のものです。** · 2006/10/01(日) 22:56:16

高いイメージがあるグラボも中古で探せば意外と安かったりする。

後はまぁ、規格が合うか調べる能力とか
コンピュータの蓋を外して中を弄ることについての多少の努力とか

**名前は開発中のものです。** · 2006/10/02(月) 00:53:03

>>552
Unreal Editor
半分マジレス

**名前は開発中のものです。** · 2006/10/02(月) 01:31:38

>>556
今出回ってるUE2はシェーダー関係一切使えない
マトモにUE3使ってエディタ外さないタイトルはUT2k7
すなわち来年

FarCryのエディタで代用できそうだけどメンドイ
誰か作れ

**名前は開発中のものです。** · 2006/10/02(月) 02:38:01

サンプルのShadowMapをいじってまして、これはデフォルトではスポットライトみたいな
効果が出るのですが、無限遠光源の表現に改造しようとしています
とりあえずg_mShadowProj(光源から見た場合の射影行列)を正射影で作るようにしてみた
のですが、細かいシマシマが出るようになってしまいました。
何となくShadowMap.fx内のsourcevalsをいじっているあたりが怪しいと思っているのですが、
よくわかりません。
一応シャドウマップの原理は理解したつもりなんですが、ここは何だか難しい事をやってるようで。。。
どう直したら良いのか教えて下さい。

**名前は開発中のものです。** · 2006/10/02(月) 08:59:30

>>557
をいをい…「シェーダー関係」ってHDRとか法線マップ使えないと
「一切使えない」ってことになるのか？
UEDのマテリアルエディタ触った事ある？
描画パスの勉強するには必要充分なシェーディング機能だぞ。

**名前は開発中のものです。** · 2006/10/02(月) 09:14:15

>>558
簡単にいうと、遠近射影と正射影とでは誤差の乗り方が違うのよ。
とりあえず SHADOW_EPSILON を 100倍にしときなさい。

**名前は開発中のものです。** · 2006/10/02(月) 10:11:45

正射影でシャドウマップを作る場合は、wで割らない方がいいのですか？

**名前は開発中のものです。** · 2006/10/02(月) 10:36:11

>>561
正射影の場合 w は常に1だから、深度値は常に線形になる。
遠近射影の場合は、wで割ると深度値が非線形になる。(一応線形で求めることもできる。)
非線形だと、遠くの方ほど深度の変化が緩やかになるから、
そのサンプルだとたまたま、極少のバイアスでもうまくいってるんだと思う。
一方で線形は、深度値を頂点シェーダの方で求めても正しく補完されるメリットがあるみたい。
とりあえず正射影なら線形一択ね。

**名前は開発中のものです。** · 2006/10/02(月) 10:55:48

>>562
thx!
だけどホントはｗで割る理屈が勘でしかわかってないから、線形と非線形について調べます。m(_ _)m

**名前は開発中のものです。** · 2006/10/02(月) 11:20:01

>>560
ありがとうございます！
もっと大きな値(0.01とか)で上手く行きました。
このサンプルではライティングをピクセルシェーダーでやってるのですが、これは何か意味があるんでしょうか？
仕組み上こうするしかないんですか？

**名前は開発中のものです。** · 2006/10/02(月) 12:52:14

>>564 スポットライトの内外判定を正確にするためね。

**名前は開発中のものです。** · 2006/10/02(月) 13:07:48

>>565
なるほど。。。
ありがとうございました。すっきりしました。

**名前は開発中のものです。** · 2006/10/02(月) 21:44:16

>>562
遠近射影の場合のｗの導出式はあるのでしょうか？

何となく
ｗ＝ｋＺ　（ｋは定数）

みたいな気がしているのですが、これから

Ｚ＝ｗ/ｋ

になってしまうので、変な気がするのですが…

**名前は開発中のものです。** · 2006/10/02(月) 22:25:57

>>567
詳しくは下を見てね。
http://msdn.microsoft.com/library/ja/default.asp?url=/library/ja/directx9_c/directx/graphics/reference/d3dx/functions/math/d3dxmatrixperspectivefovlh.asp
Zp = (Zv - near) / (far - near) * far, Wp = Zv ね。
Zv = near～far を遠近射影で変換すると
Zp = 0～far, Wp = Zv になって、
depth = Zp / Wp で、(非線形の)0.0～1.0になるわけね。
ちなみに depth = (Zv - near) / (far - near) だと(線形の)0.0～1.0ね。
シャドウマップの深度値を非線形で求めるメリットってあまりないと思うから、
後者の方でいいと思うけどね。
(PSMとかの場合はどうしても非線形になるけど)

**名前は開発中のものです。** · 2006/10/02(月) 22:46:34

>>568
ｻﾝｸｽ！分かるようにがんばってみます。

＞depth = Zp / Wp で、(非線形の)0.0～1.0になるわけね。
の「非線形」というのは、Zp と Wp の２変数の関数になっているから
「非線形」なのですか？

＞ちなみに depth = (Zv - near) / (far - near) だと(線形の)0.0～1.0ね。
こちらは Zv の１変数だけの関数だから「線形」なのですか？

**名前は開発中のものです。** · 2006/10/02(月) 23:38:14

>>569
グラフにしたときに
y=ax みたいに直線になる(均等に変化する)のがそこで言う線形で
y=1/x みたいに曲線になるのがそこで言う非線形ね。
深度値が線形変化だと、頂点間のパラメータ補間も線形補完だからそりがあうのね。
後は自力で頑張ってねｗ

**名前は開発中のものです。** · 2006/10/02(月) 23:42:29

>>570
がんばります

**名前は開発中のものです。** · 2006/10/03(火) 00:59:45

ttp://www.nomuraz.com/denpa/prog006.htm#IDPROG0034
ここを読んでクロスシミュレーションを勉強しています。
基本的な理屈は分かったのですが、これだけだと、例えば棒の上に布を被せた
場合、最終的には布が棒に完全にフィットしてしまう事になります。
もうちょっと末広がりのスカートにクロスシミュを適用させたいと思っている
のですが、広がった状態を保つのに何か良い方法はないでしょうか。

**名前は開発中のものです。** · 2006/10/03(火) 01:18:57

下から風を当て続ける

**名前は開発中のものです。** · 2006/10/03(火) 01:42:04

このやり方だと下から風を当ててもスカートが膨らむ訳ではないんですよ。上下になびくだけで。

**名前は開発中のものです。** · 2006/10/03(火) 01:45:32

あらﾎﾞｹにﾏｼﾞﾚｽが付いてしまった・・(´Д｀lli)ゞ

>>572 の方法を見てないんだが、ベースとなるモデルでスカート広げといて
それである程度制限つけて何とかならないものかなあ？

**名前は開発中のものです。** · 2006/10/03(火) 02:19:05

スカート着せないでスク水着せるってのはどうだろう？

**名前は開発中のものです。** · 2006/10/03(火) 02:23:39

そうなんです、「なるべく元のメッシュの形に戻る」というのをやりたいんです。
上の方法は、隣り合う頂点同士がばねで結合してあって、各頂点が重力や風の影響を
受けて動きつつ、お互いに引っ張り合う　というような簡単な実装なんですが、
これをどう発展させれば良いのか・・・
単純に「各頂点は元居た位置に戻ろうとする」みたいなルールにすると、想像しただけで
変な動きになりそうな・・・。

**名前は開発中のものです。** · 2006/10/03(火) 02:27:28

だよね。
巨乳やめてひんぬーにすれば乳揺れ演算の手間が省けるし萌えもアップする

**名前は開発中のものです。** · 2006/10/03(火) 02:28:45

ちょっと、なるべく前向きに考えていきたいのですが・・・

**名前は開発中のものです。** · 2006/10/03(火) 02:50:14

ID:DSdGAOLrよ。
スカートのシミュレーションはDirectXとは直接の関係はない。
かろうじて３Dというキーワードで関連性があるだけだ。
いい加減ここで論じてもネタになるだけだと気づけ。

真に技術的な話をしたければオマエにピッタリのスレがあるから、
↓↓↓↓↓↓↓↓↓紹介してやる↓↓↓↓↓↓↓↓↓

【おっぱい】エログラミング Ver.0【まん○】
ttp://pc8.2ch.net/test/read.cgi/gamedev/1159714969/

（本当に真面目にやってるから困るｗ

**名前は開発中のものです。** · 2006/10/03(火) 05:15:00

>>577
＞各頂点は元居た位置に戻ろうとする
これでＯＫだよ。ペナルティ法みたく力を加算してやればいい。
けど結局重力との兼ね合いがあるからなかなか思ったようにはいかないんだよね
…と思ったけど戻ろうとする位置を重力の強さから計算して少し上にすると
そういう心配がいらないのか今思いついた

**名前は開発中のものです。** · 2006/10/03(火) 06:57:20

あーうぜぇ。
DirectX9でプログラム組んだら、
実行ファイルといっしょにd3dx9d_27.dllもつけてくばれよ。
どうやってdll取得すりゃいいんだよ。

**名前は開発中のものです。** · 2006/10/03(火) 07:07:35

そこで.NETですよ

**名前は開発中のものです。** · 2006/10/03(火) 07:11:05

てか、普通、dllといっしょに配布するもんなんだろ？

**名前は開発中のものです。** · 2006/10/03(火) 07:22:48

ってか、d3dx9「d」_27.dllってデバッグバージョンかよ。
もう、死ねｗ
デバッグビルドで配るのかよ。
これじゃ、dllどうしようもねぇよ。
ってか、製品かよｗこれｗ
担当者首吊っていいぞｗ

**名前は開発中のものです。** · 2006/10/03(火) 07:27:40

どういう状況かわからないので詳しく

**名前は開発中のものです。** · 2006/10/03(火) 08:35:12

DLL配布がマジでうざいので俺はOctober2004が手放せない。

**名前は開発中のものです。** · 2006/10/03(火) 11:21:37

まさにDLL HELL。MSは新しいD3DX出したらWindows Updateで配るべきだ。

**名前は開発中のものです。** · 2006/10/03(火) 13:14:44

>>60
ドラえもんのセリフだったのか。

**名前は開発中のものです。** · 2006/10/03(火) 23:09:52

>>585
>デバッグビルドで配るのかよ。
これって配布しちゃダメなんじゃないっけ？
(d.dllは配布NGだよな・・・)

**名前は開発中のものです。** · 2006/10/04(水) 03:39:54

っつーか、DLL自体も配布禁止じゃねーの？
ちゃんとランタイム入れさせたら問題ないよ。

**571** · 2006/10/04(水) 03:41:52

>>568
度々すいません。やっと計算が合いました。

Pv = ( Xv , Yv , Zv , 1 ) で、Pp、Pv を列ベクトルとすると

Pp = ( DirectXのパースペクティブ射影行列 ) * Pv

と計算をしていたから、計算が合いませんでした。。

DirectXの行列の場合は、Pp、Pv を行ベクトルとし、Pp = ( Xp , Yp , Zp , Wp ) とすると

Pp = Pv * ( DirectXのパースペクティブ射影行列 )

が正しいですよね。

普通の数学の行列とDirectXの行列の掛ける順番が、逆だった事を忘れてました。。

＞ちなみに depth = (Zv - near) / (far - near) だと(線形の)0.0～1.0ね
これは「 depth = Zp / Wp 」の式で
Wp = far　（ Wp は far で常に一定）
とした時の結果だと思うのですが、どういうときに Wp = far で
「 Wp = 一定」となるのですか？

度々ですが、よろしくお願いいたします。

**571** · 2006/10/04(水) 03:59:49

何となく
( DirectXのパースペクティブ射影行列 )
を
( DirectXの左手座標系正射影行列 )
にすれば、上の疑問が解決しそうな気がしてきました。。

**571** · 2006/10/04(水) 04:05:47

おさわがせしました.。。>>593で解決しました。。m(_ _)m

**名前は開発中のものです。** · 2006/10/04(水) 06:15:19

>>591
リリースならいーんじゃなかったっけ？

**名前は開発中のものです。** · 2006/10/04(水) 08:51:54

リリースのDLLは開発者が配布するんじゃなかったっけ？

**名前は開発中のものです。** · 2006/10/04(水) 11:20:48

Redistに入ってるインストーラという形なら再配布おｋ。
DLLをアプリに付けるのはアウト。

しかし、DirectX 9.0c End-User Runtimes (February 2006)とかわかりにくすぎるよな。
DirectX 9.1とか9.2にしないのはなんでなんだ？

**名前は開発中のものです。** · 2006/10/04(水) 12:14:36

開発者が自由に決めていいんじゃなかったっけ？

**名前は開発中のものです。** · 2006/10/04(水) 14:54:41

みんな再配布に関する知識が適当だな・・・(;´д`)
>>597 でFAです。

バージョンは 9.0「c」の時点で怪しいよね。
内部処理の変更だけっていうなら納得もでくるけど、そうでもないし・・

**名前は開発中のものです。** · 2006/10/04(水) 15:44:34

>>597
DX9は場繋ぎだからな
DX8のあと手をかけたのはDX10のほうで
DX9はこの間を埋めるために作られただけ
だからDLLとか変な形で配布するようになってる
9.1とか9.2とか気軽にバージョン刻んじゃうと
Vistaが遅れたらエライ目にあってしまう

**名前は開発中のものです。** · 2006/10/04(水) 20:36:35

んで実際VIstAが遅れているため変なバージョンが乱発されたと

**名前は開発中のものです。** · 2006/10/04(水) 21:21:29

なるほど。しかも、DirectX10はVistaオンリーだからな・・・繋ぎのDirectX9が当分主流になる悪寒。

**名前は開発中のものです。** · 2006/10/05(木) 21:30:05

>>602
>繋ぎのDirectX9が当分主流になる悪寒。

内心そうであって欲しいと思ってる俺は悪い子です。

**名前は開発中のものです。** · 2006/10/05(木) 21:50:19

DirectX9主流に意義はないが、
マイナーチェンジのたびに配布DLL増やすのは辞めろといいたい。

**名前は開発中のものです。** · 2006/10/05(木) 21:52:16

つまりソースで配布してユーザーがコンパイルする時代がDirectXにも来るということか

**名前は開発中のものです。** · 2006/10/05(木) 22:20:45

配布ってなんだよw
MS Update通せって書いとくだけだろ

**名前は開発中のものです。** · 2006/10/05(木) 22:22:09

D3DXに関してはアップデートでは入らない。

**名前は開発中のものです。** · 2006/10/05(木) 22:28:34

ネットにつなげない状況にある子もなんとか救ってやりたい次第。

**名前は開発中のものです。** · 2006/10/05(木) 22:51:12

October2004あたりでビルドしておけば無問題?