出し惜しみせずに３Ｄの技術を誰かが答えます

1 · 01/11/15 21:43

３Ｄで解らない事や気になる技術の具体的内容を
誰かが答えます。
じゃんじゃんネタ振ってくれ。

俺も業界で飯食ってるが知ってる事は出し惜しみせずに
答えるよ。みんなでレベルアップしようぜ。

とりあえずＢＢＸとBio120%の過去ログは見とけ。

**名前は開発中のものです。** · 01/11/29 14:32

>>135 Dualほにゃららマッピングでテクスチャを動的生成する場合、
座標変換は具体的にどうやるんですか？

**名無しサソ** · 01/11/29 14:47

>135
　いや、現状でテクスチャ以外で実装している人は居るのかな、と。
・・・・・良く考えればShaderが使えるよの中だから、居そうだね（自滅）
マッハバンドは嫌な欠点だね。使いどころを考えないと。

**名前は開発中のものです。** · 01/11/29 23:04

的確に回答しすぎると正体が・・・

**名前は開発中のものです。** · 01/11/30 01:05

>>136

おれもDual Paraboloidは全然理解してないけど
頂点の座標変換ならココで説明してる気がする。
http://www.opengl.org/developers/code/sig99/advanced99/notes/node185.html

このページの説明を実践すれば欲しいテクスチャが２枚生成されるって
事でよいかな？試した人いる？

**名前は開発中のものです。** · 01/11/30 01:47

139と似たような資料がnvidiaにもあったような気がする。
誰か試した？

**135** · 01/11/30 03:06

>>136
Dual ParaboloidはD3DTSS_TCI_CAMERASPACEREFLECTIONVECTORを使うわけだけど
D3DTSS_TCI_CAMERASPACEREFLECTIONVECTORで自動的に計算されるベクトルと、
環境マップされる物体から環境までのベクトルとの関係を考えれば簡単に分かると
思いますよ。
# ズバり答えを書いてもいいけど、図でも描いて自分で考えてみてください :-)
# これって出し惜しみ？

SphereMapの場合は、ハーフベクトルを求める必要があるんですよね？＞やった人
そのコストを考えると、Dual Paraboloidでも座標変換のコストはほとんど変わら
ないと思います。

**名前は開発中のものです。** · 01/11/30 07:52

質問です。
DirectXでトゥイーニングを使った　人物のアニメーションを自前でつくろうとしているんですが、
メタセコイア　を使って同じ頂点数で　ポーズの違うＸファイルを２つ用意して、時間によって頂点座標を
線形補完させるというやりかたをしようと思ったんですが、
モデリングした２つのＸファイルの頂点情報の並び方が違ってしまいます。
座標を変えても同じ頂点情報の並びになるようなモデリングソフトを誰か知りませんか？

**136** · 01/11/30 12:57

>>141
いや、なんか基本的なことが解かってないんで申し訳ないです・・・
Dual～とかsphere用のテクスチャを作成する際に
テクスチャに対してレンダリングしますよね｡

その時に座標変換用のマトリックスを作成して透視変換をかけると
思うんですが、これって通常のプロジェクションマトリックスの替りに
環境マップ用のものにすれば良いということですか？

なんか、レベル低くて申し訳ないっす・・・鬱氏

**名前は開発中のものです。** · 01/11/30 14:54

>>142　一つのモデルをつくって、ポーズを変えたものを
２パターン作ればすむ話では？

**名前は開発中のものです。** · 01/11/30 21:09

>座標を変えても同じ頂点情報の並びになるようなモデリングソフトを誰か知りませんか？

市販の３Ｄソフトならだいたい出来ると思うけど。
使った事ないけどフリーならMikotoってのもあるが。
http://www2.nbn.ne.jp/~you-ri/cgi-bin/?11271800
http://niigata.cool.ne.jp/cyphers/tuft/miko/

それより頂点列の並びが変わるってのは元データを
少しいじってＸファイルにしても元データと並びが
変わってるの？普通あまりありえんと思うけど。

**名無しサソ** · 01/11/30 21:35

　出し惜しみしないで答えていると、素性が知れてしまう罠（汗）
案外こういう事している人達って多くはないのかな？

>141
　ハーフベクトルという言葉の詳しい定義は知りませんが、
全天球の空間を半球の空間に変換する計算の事でしょうか？
多分それ程負荷は変わらないかと。クリッピングを除けば。
しかし、どうも知っている人のような・・・（笑）

>142
　そう言う物なの？>144の話している通りでは駄目なのかなぁ。
マテリアルとかを変更していると変になりそうだけど。元が同じ
モデルで頂点座標だけ移動させる限りは大丈夫のような。

**名前は開発中のものです。** · 01/11/30 21:45

半球の空間に変換する前に半球の空間に
入らないポリゴンはクリッピングで省くんですか？
でもそれを判定するには座標変換しないとわからない
と思うから結局半球への変換は背景モデルを２回
座標変換するって事？
もしそうだとスフィアの２倍変換が必要になるけど。

**名前は開発中のものです。** · 01/11/30 22:37

>>146
出し惜しみしないで質問しまくると厨房と呼ばれてしまう罠（鬱）
しかも、某ＢＢ※とか野朗BBSでも同じく教えて君な俺…
＃いや、低レベルな質問には答えるようにしてますってば。（←それしか答えられない）

**135** · 01/12/01 01:11

>>145
ハーフベクトルは、ようするに２つのベクトルのニ等分角のベクトルです。
ttp://www.microsoft.com/japan/developer/directx/japan/dx8/SpecularLight.asp
ついでなので、DynamicSphereEnvironmentMappingのページを見てきたけど、座標変換に
三角関数使ってるんですか？ベクトルで計算するともっと簡単だと思いますよ。
長さが同じ２つのベクトルを足すと、それだけでハーフベクトルが求められます。
SphereMapの座標系で計算してるなら、ハーフベクトルを正規化すればそのx,y成分がその
まま求めたい座標になると思います。

DualParaboloidの場合は位置ベクトルに行列１つ掛けてxとyをzで割ってあげればいい
のかな？あまり変わりませんね。

SphereMapもDualParaboloidも実際には試してないので、嘘ついてたらゴメン :-)
DualParaboloidはVertexShaderだけで実現するメドが立ったので、暇ができたら試して
みます。

>案外こういう事している人達って多くはないのかな？

してても表で発言できない人は多いと思います。

>>147
DualParaboloidの１つのテクスチャに必要な視野は180度だから、カメラの前か後ろか
の判定だけでクリッピングできますよ。その判定はカメラの方向ベクトルのz成分と物体
への方向ベクトルで内積を計算するだけです。

ちなみにSphereMapもDualParaboloidも極点が存在するので、クリッピングしないと
カメラの正面や真後ろをまたぐポリゴンが画面を覆ってしまう問題があります。
SphereMapでは極点がテクスチャの必要な領域に存在するので困りますが、DualParaboloid
では極点がテクスチャの外側になるので単純にクリップするだけでほとんど解決でき
るかと。クリップしなくても頂点のα成分にカメラの方向ベクトルのZ成分との内積を
入れれば、αテストで背面のポリゴンは消せそうですね。座標変換のコストは減りませんが。

**名無しサソ** · 01/12/01 12:39

>149
　あ、言葉通りの意味ですか（笑）

　で、実際に言われているとおり足して単位化すれば済む話
でしたね。最初に考えて、確か計算量が多そうだと勝手に
思い込んでいたようで・・・（駄目人間）

で、書き換えたコードはこんな感じです。

D3DVECTOR v,half;

FLOAT cosa = sqrt((1.0f+v.z)*0.5f) * 0.5f;
v.z = 0;
v = Normalize(v);
の部分を

half = v;
half.z -= 1.0f;
half = Normalize(half);

に。平方根が見事に減ってますねぇ（汗）ご指摘どうもです。

**147** · 01/12/01 15:39

>>149

おお、丁寧な説明のおかげでだいぶ頭の中にイメージが
出来てきた。クリッピングのコストが少し心配だけど
スフィアよりちょっと負荷がある程度ですむのかな。
これならVertexShader化まで試してみたくなるなぁ。暇ねーけど。

ちなみに俺は148じゃないよ。某ＢＢＳはロムってる。
先輩方サンキューです。

**名前は開発中のものです。** · 01/12/01 16:54

ポリゴンの乳揺れはどうやっているんですか？
動画じゃなくってすごいヤツ見ました。

**名前は開発中のものです。** · 01/12/02 03:30

簡単なものなら乳の中にボーン通してそのボーンを
バネモデルで揺らせば出来そうだが。
エターナルアルカディアとかは町の人も髪や服が
揺れてるけどボーン方式とクロスの２種類な感じ。
プログラムで一人づつ作っていくなら量的に大変そう。

**名前は開発中のものです。** · 01/12/03 11:53

>>153
やっぱ、髪の毛とか乳みたくプログラムで特別に制御するモデルって
他の部分とは別で持つの？
それともモデル中にフラグ立てて管理してる？

**153** · 01/12/03 21:18

おれが作った時は別モデルにして後からくっ付けたよ。
３Ｄソフトも布とかは跡付けでやってるし。
デザイナがモデリングした服とかの一部を揺らそうと
思うと頂点が等間隔じゃないからやりずらくないか？

**143** · 01/12/04 11:30

すんません、>>143の質問なんですけど・・・
どなたか出し惜しみせずに教えていただけないでしょうか？（；；）

**名前は開発中のものです。** · 01/12/04 13:31

>>143
行列だけでは無理ですね。VertexShader使うか、自分で変換する必要があります。
SphereMapもDualParaboloidも途中で正規化が必要になるので。

>>154
乳はボーンで処理するなら、制御するのはボーンだけでいいから、フラグ立てる
ならボーンの方ですね。

**名無しサソ** · 01/12/04 13:33

>156
　今までのレスを見ていれば分かりそうなんだけど・・・
ただ「分からないから」教えてくれ、と言うだけじゃ進歩が
無いよ。直接のレスでなくてもちゃんと関連する話題も
あったのだし。

　投影行列に何か指定するだけで良いのであれば、
Shaderなんてわざわざ使おうとはしない。視野角を
180度に近くしても、球面上に映り込んだときの歪み
は再現できない。擬似的に出来ると思うのだったら、
自分で試してみるべし。

**名無しサソ** · 01/12/04 13:34

　被ってしまった・・・（苦笑）

**名前は開発中のものです。** · 01/12/04 13:57

>>157-158　ありがとうございました。
やはり、自前変換が必要なんですか・・・
たしかに、頂点座標を変換するだけでは球状のゆがみなんて再現できないですよね。
＃ポリゴンを細かく分割していけば擬似的には再現できるかもしれないですが。
行列だけで何とかお手軽に､と思ってたんですが甘かったですね。
頂点シェーダーについても、もっと勉強してみます。

**名前は開発中のものです。** · 01/12/04 21:32

>>158
おいおい、このスレの性質からして教えて君が聞くのは
当たり前なんだよ。むかついたんなら無視しろよ。
誰かが質問して誰かが答えないとこのスレなりたたないよ。

>>160
http://www.daionet.gr.jp/~masa/column/98-11-07.html
masa氏のコラム参考になるぞ。
やった事は無いが背景ポリゴンの頂点座標からターゲットの
座標を引いて単位化したベクトルをm=2*sqrt(x*x+y*y+(z+1)*(z+1))
から書かれている式に入れればuvが求まると書いてある。
これで変換したポリゴンをTLVERTEXでレンダリングすればよさそう。
まずはＣＰＵで頂点変換して物が完成してからシェーダー化
すればいいんじゃないの。

**名前は開発中のものです。** · 01/12/04 23:17

>>161
masaさんのページ見たけど、
その式はどうやって導出したものか説明がないですね。
教えて欲しい。

**名無しサソ** · 01/12/04 23:39

>160
　いや、別にむかついた訳じゃないんだけど・・・
話題がちゃんとでていたのだから、>156でもうちょっと
分からないことを絞って欲しかっただけだよ。気分を
害したのなら申し訳ない。ﾏﾀｰﾘと行こう。

　と言うわけで折角だからソース公開。汚いけど気合いで
読んでもらえると幸い。

D3DMATRIX vmat,wmat //vmat：ビュー変換行列　wmat：モデル変換行列
D3DVECTOR v,half; //v：単位化した頂点座標　half：ハーフベクトル
WORD a = *pTIndices; //頂点のインデックスを取得

wmat = *pMatrixStack->GetTop();　//モデル変換行列を取得
pd3dDevice->GetTransform( D3DTRANSFORMSTATE_VIEW,&vmat);　//ビュー変換行列を取得
v = *((D3DVECTOR*)&pVertices[a]);　//モデルの座標を取得
D3DMath_VectorMatrixMultiply(v,v,wmat * vmat);　//ビュー座標への座標変換
v = Normalize(v);　//vの単位ベクトル化
half = v;
half.z -= 1.0f;　// vに視点ベクトルを足してハーフベクトルを算出
half = Normalize(half); //ハーフベクトルの単位化
m_pTLVertices[NumVertices].sx = half.x * 0.5f + 0.5f;
m_pTLVertices[NumVertices].sy =-half.y * 0.5f + 0.5f;
m_pTLVertices[NumVertices].sx *= viewport.dwWidth;
m_pTLVertices[NumVertices].sy *= viewport.dwHeight; //テクスチャのUVテクスチャ座標に変換

こんな感じ。

**名無しサソ** · 01/12/04 23:41

　補足：zの値は距離の絶対値で取っているけど、平方根は
重そうなので2乗のままで保持していたり。この辺は適当で良いかも。

　ただ、ライティングはこのままだと不可能。個人的にはやっても意味は
あまり無いと思っているので、していない。

**名前は開発中のものです。** · 01/12/05 00:53

>ただ、ライティングはこのままだと不可能。個人的にはやっても意味は
>あまり無いと思っているので、していない。

あ、やっぱり。シェーダー考えるとライティングどうしようかなぁ
って思ってた。クランプとかいろいろちゃんとやると結構速度低下
するから省くか頂点カラーかどっちかがいいかなと。
でもアンビエントぐらい足してやりたいなぁ。

**名前は開発中のものです。** · 01/12/05 01:06

BRDFってGeForce3だとリアルタイムでいけるのか？
最近よくBRDFって聞くから気になる。
http://tom.g-micro.co.jp/graphic/01q1/010227/geforce3-23.html

＃そういや半球ライティングとかの説明が出てた。
＃ＤＩＹライティングが気になる。
http://www.microsoft.com/japan/developer/directx/welcome/dsmsdn/directx11192001.asp

**160** · 01/12/05 01:30

>>163　うおおお！ソースまで公開してもらって感激っす～。
早速、教えてもらった部分を理解できるよう努力します。
＃見ただけではすぐに理解できない辺りが・・・
俺的に今年度最高の名スレ＆名レス認定。

>>161　教えて君で申し訳ない。
元々数学的素養が欠如してるので最近の３Ｄマンセーな開発事情は
辛いんですよ…いや、飯の種なんで頑張りますけどね。鬱氏。

**名前は開発中のものです。** · 01/12/05 01:35

>>162

ひょっとしてこれって説明じゃ。
http://www.opengl.org/developers/code/sig99/advanced99/notes/node177.html#s.equation

**名前は開発中のものです。** · 01/12/05 02:03

>>164
vの正規化の時点で距離は求まってるから、それを利用するといいかと。

それと、ライティングはオブジェクト空間で計算するといいですよ。
法線を変換するのではなくて、ライトをオブジェクト空間に変換します。
描画前に1回だけライトを変換すればいいので、法線を変換するよりも
計算量が少なくなります。スキニングとかの関係でオブジェクト空間では
処理できない場合もありますけど。
(いま書きかけのシェーダー関係のhtmlに全く同じ事書いてあるから、ます
ます身元がばれてしまうな)

**名無しサソ** · 01/12/05 02:14

>160
　プロの人？となると将来何かいい結果が目に見えて
生まれるのかな？期待してます（笑）

>169
　あ、Z値はどうにかしてますです。上のコードには簡単の
為に書いてないだけで。あと、ライティングは実用では
わざわざする程の効果はあるのかな、と。ちゃんとする
のであれば、オブジェクト座標系が多分効率がいいでしょうね。

**名前は開発中のものです。** · 01/12/05 10:47

>>160
マジでお金貰ってコード書いてる人？
それだけが知りたい。

**160** · 01/12/05 11:37

そうですが、あまりつっこまないで・・・
まぁ、プロにもピンからキリまであるって事っすよ。
低層プログラマの憂鬱・・・鬱出汁脳

**名前は開発中のものです。** · 01/12/05 13:27

http://www.xbox.com/projectgothamracing/default.htm?det=1

動的環境マップをやるならこれくらいやらないと。
ムービーで確認せよ。

**名前は開発中のものです。** · 01/12/05 14:19

>>173　これってXBOXってことはCube環境マップ？
ハードに任せりゃできるってんなら、それでもいいんだけどな

**名前は開発中のものです。** · 01/12/06 22:07

某氏が反応していたのでコピペしとこう。
このスレいい資料になりそうだ。

>>149
双放物面のクリッピングで、環境マップ空間のＺ座標をアルファに入れて
アルファテストで処理するというのは、僕のアプローチにかなり近いです。
ただ、僕のデモでは、ヘリコプターのプロペラの部分に既にアルファを
使っているので、代わりに texkill を利用しています。

注意すべきことは、頂点座標が非線形変換されるため、
線形補間されるＺ座標が必ずしも正しい値にはならないということです。
うまく処理しないと、単位円の内部でクリップされてしまう場合があります。

あと細かいことですが、双放物面マッピングは View-Independent なので、
カメラ空間と環境マップ空間のＺ軸が一致する必要はないですね。通常は、
環境マップ空間とワールド空間の基底を一致させると使いやすいと思います。
キューブマップの場合も、そうすることが多いですよね。

**名前は開発中のものです。** · 01/12/06 22:16

ノクターンのボリューメトリックソフトシャドウって
どうやってやるんだろうね？

http://www.nocturnegame.com/screensbig/set2-3.html

「各ピクセルについて、各光源からの明るさの寄与を計算して
アルファ部に足していき、最後にピクセルの色にアルファ部を乗算する」
これがNocturneの照明システムの基本だそうで、「光源からの光が他の
ポリゴンに遮蔽されていれば、光源からの明るさの寄与が少なくなるため、
結果的に影になって見える」という理屈です。
＃ＢＢＸの記事より。
＃他に資料ない？

**名前は開発中のものです。** · 01/12/06 22:36

コピペはやめれ。
リンクだけにすれ。

**あっちのROM(ｽﾏ** · 01/12/06 23:00

リンクもやめてくれえ。

**名前は開発中のものです。** · 01/12/07 00:26

コピペは止めるけどリンクはいいっしょ？
だって個人ページの掲示板や日記からもリンクしてるし。

**名前は開発中のものです。** · 01/12/07 00:48

|　　　　＿＿＿＿　　　ジー…
|　　／::::::::　　　　ヽ
|　／::::::::　　　　　　彡彡彡
| /::::::::::　　ヽ　　　　　彡彡彡
|/::::::::　　　　　　　　　　ヽ
|::::::::　　　ノ　　　ヽ　　　|　　　　　　　　∧ 　　　　　　　∧
|::::::::::　　　　　　　　　　|　　　　　　　 /　ヽ　　　　　./ .ヽ
|::::::　ヽ　　　　　　　　／　　　　　　　 /　　｀､　　　　　/ 　ヽ
|:::::::　　　　　　　　／　　　　　　　／　　　　￣￣￣　　　＼
|::::::::::　　　　　　／　　　　　　　　　l:::::::::　　　／　　　　　＼　　 .l
|::::::::　　　　　／　　　　　　　　　　|:::::::::: 　　　　　　　　　　　|
|::::::::　　　　 /　　　　　　　　　　　 |::::::::::::::::: 　＼＿＿_／　　　| 　>>179 変なAA貼られたりすんのが嫌なんじゃない？
|　　　　　　 /　　　　　　　　　　　　ヽ:::::::::::::::::::　　＼／　　　　ノ
|　　　　　　/　　　　　　　　　　　　　　丶::::::::　　　　　　　　　ノ

**名前は開発中のものです。** · 01/12/07 01:34

>>175
その某氏だが、引用元を明かさずコピペしたことにご立腹だ。
とりあえず逝って謝ってこい！
＃ＢＢＳじゃなくてメールでな。下らん謝罪であっちのＢＢＳを汚すなよ

**名前は開発中のものです。** · 01/12/07 01:50

そんなん言ってもここは匿名掲示板だぞ？
引用元を隠した配慮ってやつだったんだけどね。
それじゃココでやったんだしココで謝る。
このスレに反応してくれてたんでせっかくだから
コピペしとこうと安易に考えちゃった、てへ。
今後はしないから許してね～。

**名前は開発中のものです。** · 01/12/07 05:14

>>182

ま、コピペなら引用元を隠す配慮になるってーのも都市伝説だから。
数週間待てば検索エンジンで大抵出てくるんでね。みんなやってる。

**名前は開発中のものです。** · 01/12/07 06:49

引用元と引用部分を明確にしないと著作権法にひかっからないか？
とか言ってみたりして

**名前は開発中のものです。** · 01/12/07 07:31

まあ2ｃｈも無法地帯ではないっつーことで

**名前は開発中のものです。** · 01/12/07 08:03

>>182-183
「引用元を隠す」ことが、誰に対する「配慮」になるのですか？

日本人は、欧米に比べて引用 (quotation) に対する認識が甘いな。

**名前は開発中のものです。** · 01/12/07 08:22

しかし某氏もデュアルほにぁららか言って出し惜しみ
っぽいところがあるのが見てて嫌だな。
もう少し自分のところで日本語でしっかり情報を
まとめてくれればなぁ。

**名前は開発中のものです。** · 01/12/07 11:56

　　　　　　 ∫
　　　∧,,∧ ∬　　　　　／￣￣￣￣￣￣￣￣￣
　　ミ,,ﾟДﾟノ,っ━~　　＜　 >>187 中学生かお前は。
＿と~,,,　　~,,,ﾉ＿.　∀　　＼＿＿＿＿＿＿＿＿＿
　　　 .ﾐ,,,/~),　　.|　┷┳━
￣￣￣ .し'J￣￣|...　┃
￣￣￣￣￣￣￣　 .┻

**名前は開発中のものです。** · 01/12/07 11:57

>>187　しかし、どの程度自分の知識を披露するかは
完全にその人にゆだねるしかないからな～。
無知な奴は知識のある人に頭下げてお願いするしかないのが普通だろ？
ましてやアカの他人匿名でがその人を出し惜しみとか言うことじたい、
お前何様よ？って感じなんだが。

日本語にまとめてくれとか言う暇あったら英語勉強して
あっちのサイト漁ればもっと有益な情報はいくらでもあるぞ。
＃そういう俺も英語はさっぱりなんだが・・・。鬱氏。

**名前は開発中のものです。** · 01/12/07 12:03

>>186

はいはい。
煽り合戦でお祭りやりたきゃ他所でな。

**名前は開発中のものです。** · 01/12/07 12:55

Dualほにゃららマッピングの解説ページ発見したぞ。
ＯｐｅｎＧＬだが。Kano氏のやり方とはまた違うアプローチのような・・・
http://www.nada.kth.se/~gustavt/dpm/

**名前は開発中のものです。** · 01/12/07 16:43

>>191
見たきたけど全く同じに見えるが。
DualParaboloidはHeidrichの論文見るのが一番分かりやすいかと。
実装するのは簡単だから、いちいち日本語で説明するほどの内容じゃないよ。

あと、そこのページだと２パスで描画しているけど、マルチテクスチャ使えば
１パスで済むよ。２パス描画になると半透明にしたときに使えないから駄目。

**名前は開発中のものです。** · 01/12/07 18:54

２パスってのは前と後ろのDualParaboloid用の
テクスチャがすでにあった状態で、その２つを
１回の描画でターゲットに貼り付けるって事でよい？

**名前は開発中のものです。** · 01/12/07 19:30

ミスった。２パスじゃなくてマルチテクスチャだと
１回の描画で？と聞きたかった。
そういや前誰かがテクスチャ領域の右と左で
前後のテクスチャ用意して１パスで描画するとか
言ってたような気がしたがそれもありか。

**名前は開発中のものです。** · 01/12/07 19:45

Heidrichも某氏掲示板の人も動くソースを出してない。
>>191は参考になる。

**名前は開発中のものです。** · 01/12/07 20:03

実装は簡単だろうと知らない俺にも参考になる。
>>191はエライよ。

**名前は開発中のものです。** · 01/12/07 21:31

>>191の内容って
これと同じ？
http://www.opengl.org/developers/code/sig99/advanced99/notes/node186.html
>>139の次ぎのページだけど

**名前は開発中のものです。** · 01/12/07 22:20

>>192
よく見ないで書いてるでしょ。
>>191はマルチテクスチャ版もあるよ。

**名前は開発中のものです。** · 01/12/07 22:22

>>197
>>191はそれとHeidrichの論文を参考にしてる。

**192** · 01/12/07 23:45

下の方はマルチテクスチャだったのね。上しか見てなかった。
ところで、あそこの行列はHeidrichのと少し違うけど、テクスチャが上下逆さま
なのはその影響なのかな？

**名前は開発中のものです。** · 01/12/08 01:31

DualほにゃららマップのDirectX版デモ（ソース＆日本語解説付き）があるページきぼん＜消防な俺

**名前は開発中のものです。** · 01/12/08 08:42

>>201
まだない。
このスレ見てる人がすぐに作ってくれると思うけど。

**名前は開発中のものです。** · 01/12/08 15:35

たぶん大多数の人はDirectX使ってると思うから
みんなそっちに変換しながら組んでるでしょ。
すでに実装までいった人も何人か居るみたいだし。

**Mark** · 01/12/10 02:18

Hi Japanese programmer guys!

Gustav Taxen is using a circular texture to mask dual-paraboloid maps.
His approach, however, inevitably leads to a certain artifact.

In a +Z paraboloid map, infinite homogeneous texture coordinates such as
(s, t, q) = (1, 0, 0) or (-2, 1, 0) actually represent the identical -Z direction.
Therefore, given that the three reflection vectors at the vertices of a triangle
are near to (0, 0, -1), each of the corresponding non-homogeneous texture
coordinates gets extremely large. As a result, they can surround the circle of
the mask in some circumstances.

Since the rasterizer of today's GPUs always interpolates texture coordinates
linearly, values interpolated between such coordinates can fall into the circle,
which means that the mask has a small "hole" in the -Z direction.

Such an artifact can be observed in Kano's OpenGL sample, which I guess
justifies the fact that he is using the same method as that of Gustav.

What is important to note here is that, should you choose the view vector
as the -Z axis of the environment map space, the hole would be invisible.
However, it might contradict view-independency of dual-paraboloid mapping.

What do you think of that?

**名前は開発中のものです。** · 01/12/10 04:19

markがsageてる…

**名前は開発中のものです。** · 01/12/10 04:23

(・∀・)sage kakoii!!

**名前は開発中のものです。** · 01/12/10 06:46

この間ロボット系研究室で見た全方位センサに用いられてるカメラ
ttp://www.vstone.co.jp
の画像処理の逆変換みたいな話題でしょうか。英語は何とか読める
けんど、ﾔﾊﾟｰﾘ不勉強ゆえ話についていけんですばい。くやちい。

**名前は開発中のものです。** · 01/12/10 10:22

>>204　Mark Kligard先生の降臨ですか？（ﾜﾗ
あの人って日本語読めるのかな？ましてや２ｃｈ・・・
mark : "鬱"and"逝ってよし"are What meaning?.

**名前は開発中のものです。** · 01/12/10 11:44

「today's GPUs」ってあたりが妙に本物っぽいな（藁

**名前は開発中のものです。** · 01/12/10 19:27

つうか>>204って日本語解説くれだのソースくれだの言ってる阿呆に対するイヤミじゃないの？
本物だったら藁うな

**名前は開発中のものです。** · 01/12/10 19:35

204がしびれを切らせて出てきたよ

**名前は開発中のものです。** · 01/12/10 20:34

>Kano's OpenGL sample
ここ見てる某氏も無反応だから偽者か。
メアド書かずにsageてるのも気になるし。

**名前は開発中のものです。** · 01/12/10 20:38

もし本物なら某氏がリンク張ったのが原因かもね。

**名前は開発中のものです。** · 01/12/10 21:47

http://www.excite.co.jp/world/text/

外国の人もエキサイトのWeb翻訳で日本語のページ翻訳すれば読めるよ。

**名前は開発中のものです。** · 01/12/10 23:59

　　　　　　　　　　 ∧＿∧　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　　　（　´Д｀）　＜　 >>204って、本物のキルガード先生なのかなぁ
　　　　　　　　　／　　　＼　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　＿　　 |｜ ∬　｜|
　　　　　 |＼￣￣￣旦￣￣￣ ∬
───／＼＼　　　　 ○ ○　旦＼──､ ∧＿∧　　　／￣￣￣￣￣￣
　　／　　　＼|￣￣￣￣￣￣￣￣￣|.　　（　´Д｀）　＜　ﾝﾅﾜｹﾈｰﾀﾞﾛ
　　 (　　　　　　ﾉ￣￣￣￣￣￣￣￣￣＼～⌒ヽ　/つ　　＼＿＿＿＿＿＿
　　＼　　　　　　　　　　　　　　　　　　　＼＼＼/
　　　＼　　　　　　　　　　　　　　　　　　　　）- ＼.二二つ ''.○,,
　　　　　￣￣￣￣￣￣￣￣￣￣￣￣￣￣　　　　　　＼
＼　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　＼
　￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

**名前は開発中のものです。** · 01/12/11 06:48

きるがーどせんせい登場記念カキコ!

**名前は開発中のものです。** · 01/12/11 10:01

正解

まーくぱんさーでした。

**名前は開発中のものです。** · 01/12/11 12:17

　　　　　　　　　　 ∧＿∧　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　　　（　´Д｀）　＜　 >>215　クリガードって読むんじゃないのかなぁ
　　　　　　　　　／　　　＼　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　＿　　 |｜ ∬　｜|
　　　　　 |＼￣￣￣旦￣￣￣ ∬
───／＼＼　　　　 ○ ○　旦＼──､ ∧＿∧　　　／￣￣￣￣￣￣
　　／　　　＼|￣￣￣￣￣￣￣￣￣|.　　（　´Д｀）　＜　ｿｯﾄｼﾄｲﾃﾔﾚﾖ
　　 (　　　　　　ﾉ￣￣￣￣￣￣￣￣￣＼～⌒ヽ　/つ　　＼＿＿＿＿＿＿
　　＼　　　　　　　　　　　　　　　　　　　＼＼＼/
　　　＼　　　　　　　　　　　　　　　　　　　　）- ＼.二二つ ''.○,,
　　　　　￣￣￣￣￣￣￣￣￣￣￣￣￣￣　　　　　　＼
＼　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　＼
　￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

**名前は開発中のものです。** · 01/12/11 12:39

○ http://www.google.com/search?q=Mark+Kilgard
× http://www.google.com/search?q=Mark+Kligard

**218** · 01/12/11 15:51

>>219
Mark.J.Kligardってのがいるが、そいつと勘違いしてたＹＯ。鬱

**名前は開発中のものです。** · 01/12/11 16:49

つうか結局誰も答えられず、か
まぁそんなもんか
オレモナー

**名前は開発中のものです。** · 01/12/11 19:27

アフィン変換とかっていうのにでてくる「ウェイト」ってなんの為にあるのですか。

**名前は開発中のものです。** · 01/12/11 20:22

かんきょうまっぴんぐのおはなしはおしまい。
これからはうぇいと。

**名前は開発中のものです。** · 01/12/11 20:52

英語なんてドキュメントが理解出来れば十分だよ、
ってのに納得してた自分に鬱。
そういや任天堂は英語がいるんだったよな。

**名前は開発中のものです。** · 01/12/12 09:23

＞任天堂は英語がいるんだったよな

２ちゃんの中の常識は実情と（以下略）

**名前は開発中のものです。** · 01/12/12 11:37

アフィン変換でウェイトなんて出てきたっけ？

**名前は開発中のものです。** · 01/12/12 13:38

同次座標のwの事を言いたいんだろうか？
どこかでウェイトって呼んでる人を見かけたことある。

**名前は開発中のものです。** · 01/12/12 17:32

>>227
…マジで…。

俺はてっきりジオメトリのブレンディングウェイトのことかと思った。

**名前は開発中のものです。** · 01/12/12 17:33

>>227
はい。そのｗの事です。

**名前は開発中のものです。** · 01/12/12 19:51

なぜウェイトと呼ぶ人がいるのか小一時間考えてみた結論はこうだ

ｗだから

**名前は開発中のものです。** · 01/12/12 20:18

>>230
同次座標 (x, y, z, w) の w 座標そのものを重み (weight) と呼ぶのは適切ではないが、
(x, y, z, 1) と (xw, yw, zw, w) を比較したときの w を重みと呼ぶのはある意味で正しいと思う。
同次座標の (x, y, z, 1) と (xw, yw, zw, w) は単一の点としては等しい位置を表すが、
各種の補間（線形、多項式など）を適用する際には w が重みのような役割を果たす。
すなわち、w が大きい点（制御点）に引き込まれる傾向が見られるのである。

有理ベジエやNURBS（非一様有理Bスプライン）などの有理曲線（曲面）は
この同次座標の w による「重み」を巧みに利用した応用例であるとも考えられ、
非有理（＝非同次）の多項式曲線（曲面）に比べて自由度の高い表現を可能としている。
また、テクスチャ座標の線形補間におけるパースペクティブ補正に関しても、
「重み」という視点から見直してみると、直感的な理解が深まるかもしれない。

ところで、個人的に、>>204は出し惜しみのない貴重な情報だと思うのだが、
議論が続かないのは大変残念なことである。(´･ω･`)ｼｮﾎﾞｰﾝ

**名前は開発中のものです。** · 01/12/12 22:49

>>231
>ところで、個人的に、>>204は出し惜しみのない貴重な情報だと思うのだが、
>議論が続かないのは大変残念なことである。(´･ω･`)ｼｮﾎﾞｰﾝ
お願い、翻訳して…。(´･ω･`)ｼｮﾎﾞｰﾝ

**名前は開発中のものです。** · 01/12/12 22:52

リアルタイムのゲームで使用出来るぐらい速度が
出るグローバルイルミネーションって何かありますか？
フォトンマップ、BRDF、Radiance、Irradianceとか
単語を目にする事はあるけど良くわからない。
せっかくプログラマブルシェーダーがあるんだし
使えそうなのを１個作ってみたいな。

**名前は開発中のものです。** · 01/12/12 22:59

半球光源（簡易ラジオシティ？）っていうのが非常に魅力的なんですが、
これってやぱ相当重くなります？

**名前は開発中のものです。** · 01/12/13 00:24

>>233
グロバールイルミネーションで演算した結果を、
頂点カラーに焼き付ける。これ最強。
プログラマブルシェーダーも大活躍！！

…というか基本から勉強しなおしてください。

>>234
半球光源の公式みればどれぐらいのコストがかかるか
わかると思うのですが…

…というか基本から勉強しなおしてください。