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

1 · 01/11/15 21:43

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

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

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

**名無しさん＠お腹いっぱい。** · 01/11/20 14:31

>>70
わかんねー

71 · 01/11/20 15:38

>>73　無理。チミにまかせた。

**名無しさん＠お腹いっぱい。** · 01/11/20 15:51

じつはｺｿｰﾘ^cさんとかkanoさんとか新坂さんあたり流れて来てそうだが、
2chなのでななしさんですますことにする。
つーか、解からない事ありすぎるから教えろや、ｺﾞﾙｧ!!

**名無しさん＠お腹いっぱい。** · 01/11/20 15:59

>>73
一時期の洋ゲー方式ですね。
OpenGL対応ボードが普及したのもQuakeのおかげみたいなもんだしヽ( ´ー｀)ノ

_ · 01/11/20 16:21

誰か、パーティクルについての知識を、アライザライブチマケテちょ。

**(・∀・)つ∴ﾆｸｺﾌﾟｰﾝｸｴ!!** · 01/11/20 16:54

子供の頃、三菱化学の炭化物パーティクルで喘息を患いました。
この頃は、春になるとスギ花パーティクルによる結膜炎で悩みます。
パーティクル超嫌いです。

悩みをブチマケたらスッキリしました。

５１ · 01/11/20 17:54

すみません…また質問させてください…。
いただいたアドバイスどおりに実装しようとして
マップデータのローダーを観てて気付いたのですが、
「Stripしてる三角形の扱いはどぎゃんすればよかですか！？」と。
独立した三角形としてプログラム内で扱って…というのは
手としてアリなんでしょうか？そのためのプリミティブの保存領域や
コマンドの転送が余計に必要になりますよね？

**名無しさん＠お腹いっぱい。** · 01/11/20 20:20

>>51
表示モデルとあたり判定を取らないほうがいいよ。
もっとローモデルにしたものを独立三角形データで
用意してバウンディングボックスデータを
事前に生成しておく。

５１ · 01/11/20 21:00

>>80
>>マップデータのローダーを観てて気付いたのですが、
↓
「マップデータのローダーを書くために、
モデルデータを観てて気付いたのですが、」

＞８１
狼狽しててわかりにくい日本語で書いたにも関わらず
回答ありがとうございます。
つーことは、描画・表示用のプリミティブデータと
当たり判定用のローモデルデータを別に用意した方が
ベターって理解でいいでしょうか？

んで、バンウンディングボックスなんですが、
その格子の中に頂点を持っている三角形であれば対象にしても
構わないんですよね？

44 · 01/11/20 21:05

>公開されてるよ。場所は探してね。多分分かるから（笑）

コラム一通り見たけどテクスチャ自体の作成は無いと
思うが。
IF氏あたりがコラム書いてくれねーかなぁ。
動的スフィアで屈折＆反射マッピング。

**名無しさん＠お腹いっぱい。** · 01/11/20 21:58

>つーことは、描画・表示用のプリミティブデータと
>当たり判定用のローモデルデータを別に用意した方が
>ベターって理解でいいでしょうか？

そうしないとバウンディングボックス用のデータ作成に
時間がかかるじゃん。

>その格子の中に頂点を持っている三角形であれば対象にしても
>構わないんですよね？

それも当然対象になるけどボックス内に頂点が無くても
三角形がボックスと交差している事はある。
ボックスの１２個の辺が三角形と交差していないか
面と直線の判定で調べる必要がある。

**名無しさん＠お腹いっぱい。** · 01/11/20 21:59

ひぃぃ

**名無しさん＠お腹いっぱい。** · 01/11/20 22:22

ｶﾞﾝﾊﾞﾚ

**名無しさん＠お腹いっぱい。** · 01/11/20 22:35

**名無しサソ** · 01/11/20 23:03

>83
　分かりにくい解説かなぁ・・・。

　要するにスフィアマップを特殊な座標変換で直接作成する
お話なんだけど。

**名無しサソ** · 01/11/20 23:08

>74
>83
　場所を間違っていると行けないので一応。
bioのBBSに話題が出ているから、たどってみよう。

　それでも分からない事があれば質問をどうぞ。

83 · 01/11/21 00:54

>要するにスフィアマップを特殊な座標変換で直接作成する
>お話なんだけど。

結局それが必要なのは解っているんだけど仕組みが
イメージ出来てないおれ。
フレームバッファに背景描いてからテクスチャにコピー
した後に特殊な変換掛けるって感じなの？
でもそれだと前面以外の横や上下分もレンダリング
してやらないとダメなような。
３６０度って事だと結局６方向要るだろうし。
なんか物凄い勘違いしているとは思っているが。

もしかしてモデルの頂点トランスフォームを自前で
全てやって単位化した円のなかに納まるように変換して
トランスフォーム済み頂点で描画して作成するとか。
んな恐ろしい事するわけないか。

**名無しさん＠お腹いっぱい。** · 01/11/21 01:06

レベルage。

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

>90
　その「もしかして」が正解（笑）

　DirectX7からだと、直接テクスチャサーフィスに描画できるから、
フレームバッファに書かなくても大丈夫だよ。で、描画先にSphereMap
用に確保したサーフィスを指定して、自前の変換で円の中にがりがり
書いていく。その座標変換の方法を紹介してあるんだけど。

　ただ、色々欠点があるので、Dual-Paraboroidの方を詳しく勉強
した方がいいかも。

90 · 01/11/21 01:31

>その「もしかして」が正解（笑）

ななななっなにゅ～！！悪夢のようだ。
んじゃ頂点シェーダー使わないと速度的に無理じゃん。
しかも全方位のモデルを描画だからクリッピングも
クソもオクールジョンカリングも無い。
グランツーの様なゲームで動的環境マップしようと
したら背景ポリゴン多すぎて不可能じゃないの？

そのへんはDual-Paraboroidとやらも同じでっか？

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

>93
　映り込むオブジェクトを上手く取捨選択するのなら、そこまで
無理ではないよ。自前変換にかかるコストは比較的高いけど、
死ぬほどではない。問題は破綻をどう防ぐか。通常のクリッピング
とは全然勝手が違うからね。

　具体的な解決策としては、簡略化した背景をいくつかのブロック
に分けて置いて、距離的に離れたオブジェクトは最初から描かない、
とかね。一度に描くのが2000ポリゴン前後位だったら、CPU側の処理
でもまだ現実的だと思う（Pentium!!!クラスのPC、TNT2以上のビデオ
カード前提で）。もちろん出来る限りの高速化の工夫は必要になりそう
だけど、何とか実用にならないかなぁ。

　ちなみに、Dual-Paraboroidもやっていることは基本的に一緒。ただ、
話を聞いた限りでは、180度の映り込みを2枚描いて、それを切り抜いて
かつ歪ませてSphereMapを作るとか。某氏は座標変換をVertexShader、
画像処理をPixelShaderに任せているという話。

**名無しさん＠お腹いっぱい。** · 01/11/21 13:20

>>94
横入りスマソ。おれもちょうどその辺やってるんで｡
円の中に収まるように描いていくってとこだけど、
画角を180度とかに広げて描画したらそれっぽくならないですか？

あと、この話題で出てくるＨＰのアドレス教えてくださいナリ

95 · 01/11/21 13:24

ちなみに、動的スフィアを作る時は環境マップしたい対象のオブジェクトから
カメラ方向に向いた視点をセットして周りの背景とかを描画するんでＯＫ？
複数オブジェクトに環境マップしたいときは・・・コストかかりまくり。鬱

**名無しさん＠お腹いっぱい。** · 01/11/21 15:09

>>95

Dynamic Sphere Mapping
http://www.opengl.org/developers/code/sig99/advanced99/notes/node180.html

Dynamic Dual-Paraboloid Mapping
http://www.opengl.org/developers/code/sig99/advanced99/notes/node187.html
http://cgi3.tky.3web.ne.jp/~tkano/DynamicParaboloid.shtml

advanced99では、いったんキューブマップに通常の線形変換で描画してから
それを歪ませて環境マップを作成している。一方、Kano氏の方法では、
頂点座標を非線形変換させて環境マップに直接描画している。

通常の線形射影変換では、原理的に画角を180度にはできないのでは？

**名無しさん＠お腹いっぱい。** · 01/11/21 21:34

初心者の質問で申し訳ないのですが、
Direct3DでXファイルを読み込んで表示するまではできたんですけど（ライブラリ使いましたが）
モデリングする時と実際に表示される時の大きさが分からないと不便なので
カメラも視点がXY方向の平面に垂直だとして、
3Dでの640が画面の640ピクセルになるようにしたいんですが、
（0,0,0にある640*480の物体が画面いっぱいに表示されるということ）
どのような式を書けばいいんでしょうか。
カメラに映るZの範囲は-100～100にしたいです。
ということはカメラのZは-100ですよね。
XYに垂直なのでX = 0, Y = 0 まではわかるんですが、
視野角度というものを何度にすればいいのか分かりません。
教えてください。

93 · 01/11/21 21:55

>>名無しサソ
確かにＣＰＵで２０００ポリぐらいは行けそう。
それでも背景は２回描くはめになるからやっぱり
コストは高そうだなぁ。
VertexShaderで頂点変換は必須になりそうだ。
写りこみ用モデルはローポリ＆テクスチャで
ごまかしたやつを使うか。

>>97
>一方、Kano氏の方法では、
>頂点座標を非線形変換させて環境マップに直接描画している。

kano氏もいぢわるしないで日本語でバカにも解るように
解説してくんねーかなぁ。

**名無しさん＠お腹いっぱい。** · 01/11/21 22:12

>>98
スレ違いだと、思うぞ。

OpenGLプログラミングガイドにそれなりに載っている。
3D初心者はDirectXよりも、OpenGL+GLUTライブラリの方が良いと思うが。

**名無しさん＠お腹いっぱい。** · 01/11/21 22:30

>>98
トランスフォーム済みの頂点フォーマット
使っちゃダメ？
２Ｄスプライト的に使うならD3DFVF_XYZRHWを
使えば十分。
３ＤでやりたいならＣマガジンの１０月号で
似たような記事があったよ。

>>100
まっageてくれたからいいじゃん。
おれ的には初心者の質問もＯＫだと思うよ。

**名無しさん＠お腹いっぱい。** · 01/11/21 22:57

>>99
>kano氏もいぢわるしないで日本語でバカにも解るように
>解説してくんねーかなぁ。

掲示板やメールで質問してみるとか。
ここも見てるだろうけどリアクションは無いと思うのん。

つうかKanoさんモテモテね。きゃは。

**名無しさん＠お腹いっぱい。** · 01/11/22 00:34

http://www.genki.co.jp/soft/phantomcrash/system/index.html
このエフェクトやってみたいんですが仕組みについて
ヒントだけでも聞かせてもらえないですか？

**名無しさん＠お腹いっぱい。** · 01/11/22 00:54

>>103
上で散々っぱら話されている動的スフィアマップと大体同じ考え
なんじゃないかな。
違うのはテクスチャー行列(というかテクスチャの座標変換)
を反射から屈折にするくらいかな。
っていうか屈折って行列で表現できるのかはわからないけど。

**名無しさん＠お腹いっぱい。** · 01/11/22 01:15

某掲示板ではバックバッファの絵をテクスチャにして、
モデルの頂点を透視変換かけたものをｕｖ座標に
してから適当にずらすとかあったが。（んなアホな）

他の可能性としてはバンプマッピングも
考えられんか？おれには解らんが。

**名無しさん＠お腹いっぱい。** · 01/11/22 01:18

>>103
別に、動的スフィアみたくテクスチャを変形しなくても
背景をテクスチャにレンダリングしてそれをそのまま
環境マップ用のテクスチャとするだけでそれっぽく見えないかな？
変換の式を適当にいじる必要はあるだろうけど｡詳細はわからんっす。

屈折マッピングについては
↓聖地とか
http://developer.nvidia.com/view.asp?IO=Refraction_paper
↓聖書とか
Game Programming Gems
・・・にあります。

**名無しさん＠お腹いっぱい。** · 01/11/22 01:21

>>105　かぶった。しかも（んなアホな）っていわれてるし。（；；）鬱出汁脳

**名無しさん＠お腹いっぱい。** · 01/11/22 01:29

屈折マッピングをちゃんとやろうと思ったら
動的キューブ環境マップか動的スフィアが
必要になってきて速度的にヤバそうだな。

>背景をテクスチャにレンダリングしてそれをそのまま
>環境マップ用のテクスチャとするだけでそれっぽく見えないかな？

この路線がいいとは思うがそのままだとうまく
いかんと思うなぁ。

**名無しさん＠お腹いっぱい。** · 01/11/22 01:38

>>108
普通に考えると、
>背景をテクスチャにレンダリングしてそれをそのまま
>環境マップ用のテクスチャとするだけでそれっぽく見えないかな？
このやり方では映り込んでいるように見えると思う。
屈折させたいなら環境マップとテクスチャ座標の計算式は
変えなきゃだめだと思う。

**名無しさん＠お腹いっぱい。** · 01/11/22 01:43

>屈折させたいなら環境マップとテクスチャ座標の計算式は
>変えなきゃだめだと思う。

Gemsにもあるスネルの法則ってやつで
屈折させるんだと思うけど、どこにどーやって
組み込むんだろう。
環境マップも頂点シェーダーで独自で計算とか？

**名無しさん＠お腹いっぱい。** · 01/11/22 01:45

あのエフェクト下から徐々にかかってる。

**名無しさん＠お腹いっぱい。** · 01/11/22 01:45

描画面の法線の角度をN
光の進入角を-Nと考えると、結構簡単に屈折した法線角を
でっちあげることはできそう。

**名無しさん＠お腹いっぱい。** · 01/11/22 01:50

きっとIF氏が今作ってるんだよ！

**名無しさん＠お腹いっぱい。** · 01/11/22 01:55

Gemsは２冊とも持ってるけど、一つ一つの技術はとてもために
なるんだけど、なんか小手先みたいな感じがして積極的に
ゲームに取り入れる気がしないよう。
もっと包括的に、シーングラフレベルでのテクニックみたいなの
はないかなあ。シーングラフで屈折マップも表現できるのなんて
無いか。

**106** · 01/11/22 02:32

背景をまんまテクスチャ化
↓
SetTextureStageState(1, D3DTSS_TEXTURETRANSFORMFLAGS, D3DTTFF_COUNT2)
SetTextureStageState(1, D3DTSS_TEXCOORDINDEX, D3DTSS_TCI_CAMERASPACENORMAL)
・・・とかやってみる。
↓
マトリックスをゴニョゴニョ
↓
屈折まっぷ（ﾟдﾟ）ｳﾏｰ

とか、こんな程度でなんとかならんもんかと妄想してみる俺・・・

**名無しサソ** · 01/11/22 09:32

　いきなりログが進んでるね（笑）屈折マッピングもCubeMapか
SphereMapを使うと良いとは思うけど、光学迷彩はそこまでしなく
ても良いんじゃないかな。透過する背景が遠方にあると仮定して、
屈折した先の光線の角度を視野角内に何とかして収めれば、
フレームバッファをそのままテクスチャに使えると思う。多分（適当）。
厳密にやるならPixelShaderとかの出番だね。真面目にやるか
汎用性・高速性を取るか。PSのMGSでもそれなりに見えるから、
自分は後者で良いかな。

**名無しサソ** · 01/11/22 09:38

　連続ゴメソ。

>95
　SphereMapは球の表面に映り込む風景だから、単純に
視野角を狭めるだけではおかしくなると思う。>96のはその通り。
これはCubeMapも一緒だね。解説は>97にも紹介されている
けど、bio100%の3DFollowsBBSにその話題が出ているから、
リンクを辿ってみて。ちなみに、自分が話しているのは>97の
ようなCubeMapからSphereMapを作るの方法ではなくて、直接
ShereMapを描画する方法。

>99
　当たり前の話だけど、人間の目って動く物体の映り込みの
中身まで、そんなに見ていないよ。と言うわけで、ローポリで
十分だし、実際にもそうされていると思う。GT3でもよく見ると
案外省略されまくってるし。ただ、動的か否かはやっぱり違うね。

**名無しさん＠お腹いっぱい。** · 01/11/22 10:03

X-boxのgothamは動的環境マップしてるがどういう方法？

**名無しさん＠お腹いっぱい。** · 01/11/22 10:08

あのロボットの頭部は球状に近い形なわけだけど
その形をレンズに置き換えて見ると向こう側の絵は
虫眼鏡のように拡大されるはずじゃないですか。

それが環境マップのように縮小されて張られているけど
おかしくない？

**115=106** · 01/11/22 11:58

しまった。
D3DTSS_TCI_CAMERASPACENORMAL
じゃなくて
D3DTSS_TCI_CAMERASPACEREFLECTIONVECTOR
だった。
・・・つってもただの妄想なんでいちいち訂正せんでもいいが。

**名無しさん＠お腹いっぱい。** · 01/11/22 13:44

>>113
IF氏って誰？

**名無しさん＠お腹いっぱい。** · 01/11/22 13:57

これだと思われ｡最近注目株（俺的に）
http://www5.tok2.com/home/IF/index.html

**名無しさん＠お腹いっぱい。** · 01/11/22 14:13

>>122
Thanks。解説が詳細でイイ！

**名無しさん＠お腹いっぱい。** · 01/11/22 21:32

>>名無しサソ
>屈折した先の光線の角度を視野角内に何とかして収めれば、
>フレームバッファをそのままテクスチャに使えると思う。多分（適当）。

その計算式が解るなら苦労しないんだけど。
いまいち根拠にとぼしいから試す時間を裂けん。
もしかして成功例とかある？

>>120
>D3DTSS_TCI_CAMERASPACEREFLECTIONVECTOR

試してみたが屈折というより反射に見えるじゃないか。
その妄想完成させてくれよ。

**名無しサソ** · 01/11/22 21:58

>124
　申し訳ない。こちらも時間が割けないのは同じでね（苦笑）

　光学迷彩は上に書いてあるようにBBXの少し前のログに
残ってるよ。11月3日の書き込み。そこから実践している
ページもリンクされているので辿ると良いよ。個人的には、
あんまりここで直接リンクを張りたくないんだけど、良いのかなぁ。
自分はちょっと嫌な物で。

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

ム板にあったリンクのことかな？
それなら、JAVA、3Dあたりの用語でわかる人はわかるかと。

**124** · 01/11/23 01:12

>>名無しサソ
>光学迷彩は上に書いてあるようにBBXの少し前のログに
>残ってるよ。11月3日の書き込み。そこから実践している
>ページもリンクされているので辿ると良いよ。個人的には、

さんきゅ～。確かに実践してるんで参考になるよ。
やっぱ実際に見ると感動があるね～。
あれなら時間裂いて試す価値あり。

ただ120の言ってる環境マップを利用した方法も
可能じゃないのかなぁと期待はしてたりする。
あとバンプ利用するとピクセル単位で屈折を
表現出来そうで面白そうだなぁ。

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

Q座標生成すればそれなりには見えるんじゃない？

**120** · 01/11/24 08:33

>>124　あ、実験どうもです。
そうですか、反射に見えますか・・・なるほろ。今後の参考にします（＾＾
＃って、自分の妄想の実験を人任せにする奴

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

あげー

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

最近一部で話題の動的環境マップとか半球ライティングとかって
実際にゲームで使われてるのかなぁ？
このゲームは凄いよみたいな情報ｷﾎﾞﾝﾇ

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

Dual Paraboloid動的環境マップは
某箱用のゲームで使われていくハズ。

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

Dual Paraboloidとキューブ環境マップは
どっちが高速に処理できるんだろ？
つーか動的環境マップで一番実用的なのはどれ？

**名無しサソ** · 01/11/29 10:40

　半球ライティング、ってテクスチャによるライティング技術・・・だよね？
だとセルシェード系はこれを使っているのでは？他に高速で実現出来る
方法を知らないだけかも知れないけど。

>133
　現状ではCubeMap以外選択肢がないかも。GeForce/Radeonが
それなりに普及していて、でもShaderがそれ程普及していない現在だと。
自分はSphere派だけど、あまり未来はないと感じてるよ（苦笑）

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

ちなみに、静的なDual ParaboloidはShader無くても使えるよ。DX7で十分。
もちろんTnLHALで可能。詳しくはHeidrichのオッサンの論文でも読んで。

動的生成の場合のネックは座標変換とZテストかな。
1枚のテクスチャがカバーする視野が180度なおかげでクリッピングが簡単だから、
描画負荷はSphereとそう変わらないレベルになりそう。テクスチャは2枚だと
RenderTargetの切り換えで遅くなりそうだから、1枚のテクスチャをViewPortで
分けて使うのがいいかと。

>>134
半球ライティングとテクスチャは関係ないよ。
テクスチャを併用するとShaderでは内積を1回計算するだけで済むから、近似
としてテクスチャが使われることはあるけど。ただ、テクスチャを使ったシェー
ディングはテクスチャのサイズをかなり大きくしないとマッハバンドが目立つ
のが欠点。

**名前は開発中のものです。** · 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

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