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

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

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

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

7:7】なあUO系のゲームのキャラって・・・・
1 名前：名無しさん＠お腹いっぱい。 01/11/15 21:00 ID:WSJSkszu
作るのにはどのＣＧソフトがいいかな？今度2ch優遇の作ろうと思うんだけど？

189 名前：名無しさん＠お腹いっぱい。 ：01/11/15 21:08 ID:WSJSkszu
UO系のゲームのキャラってどんな３Ｄを作るソフトが必要？

ディアブロは確か3DStudioMaxじゃなかったか？
まっゲーム製作ならLightWaveかSoftImageか
MayaかMaxが業界では多いだろ。

ディアブロのことなんか聞いてません

softimageでつくられた作品リスト
http://www.avid.co.jp/softimage/list/list_games.htm

ところでソフトイマージュって読むやつってどうよ？
本社がどこだか知らねぇがパッケージにもソフトイマージってかいてるのによぉ。

コピーCD買ったくせに何がパッケージだ（藁

>>7
ソフトイマージュはプロテクト掛かってて無理だったよ。
その以前に9x系で動かねえらしいが。

>>7
漏れはシェンムーパッケージ

スフィアマップの環境マップはDirectX8と
DirectX8.1のサンプルで処理が違う。
立方体のＸファイルでもDX8.1は綺麗に張れるが
どんな計算式なんだ？

みんなＦＯＶどれくらいに設定してる？
オレは試行錯誤したあげくに 25 度

>>6
日本人ならソフトイメージと読むぞ。
略してソフイメ。

>10
　法線の計算式が改善されているのでは？

　自分が知っているDirectX7の時点で、法線計算は非常に
適当だったし。三角形分割されている立方体でもうまくいかな
かった筈。もちろん、ちゃんとしたモデラ並に、綺麗に法線が
平均化されていればスフィアマップでも綺麗に周りが映り込む。

動的スフィアマップとやらはどんな感じにやるの？
３６０度写りこんだテクスチャをリアルタイムに
作るやり方が想像つかない。
（リアルタイムじゃなくても解らんけど）
６面分の背景をレンダリングするCubeMapなら
原理は理解できるんだけどなぁ。

>>14
Dual Parabroid Environment Mappingで検索すれ
３６０じゃなくて１８０度のテクスチャ２枚でやる。
ただし、どうやってやるのかは知らんので
kanoさんとこでも逝ってBBSで聞いてみれ

>>12
＞略してソフイメ。
なんだかやらしいよ

俺の周りでは『ソフィ』だけど・・・。

ソフイマに１ッぴょウ

>>1
>とりあえずＢＢＸとBio120%の過去ログは見とけ。
Bio100%は知ってるけど、BBXってどこ？

http://isweb8.infoseek.co.jp/computer/bbx/cgi-bin/bbx.cgi

こっからじゃないと入れないよ＜ＢＢＸ
http://isweb8.infoseek.co.jp/computer/bbx/

BioのＢＢＳは寂れてきてるし、Bio見てる人は大抵BBXも見てるので
マルチポストせずにＢＢＸに書き込みしましょう

最近ＢＢＸ寂しくない？

せっかくこの板ができたんだから他の掲示版は無視してここだけでやろうよ。
掲示板の過去ログなんて膨大で読みきれないよ。
ここで質問すれば誰かが答えてくれるよ。

俺起ちは便利な道具じゃない！

初心者の質問はＮＧですか？？

とりあえず質問してみ。

Ｚソーとっていうのはなんですか？
よく話題に上がっているのですが分かりません。
DirectX初心者です。

プリミティブを、奥から手前に、あるいは手前から奥に、
っていう順番で描くと、場合によって嬉しいことがあるので、
そういうふうにプリミティブの描画順序を並べ替えることです。

絵で説明してあるページがあるよ。
http://pegasus.sfc.keio.ac.jp/~cgsoft/Release/Textbook/zsort01.html

ＺソートはＰＳなどで使われていたが今はＺバッファ方式が
多い。DirectXもＺバッファだよ。
今でも半透明ポリゴンを描画する時にモデル単位で
奥からソートする事があるけどＺソートと呼んだりするね。

Dual-Paraboloid Environment Mappingの説明。

http://www.opengl.org/developers/code/sig99/advanced99/notes/node184.html
二重放物面環境マッピングとも呼ばれている。
http://www.ati.com/jp/pages/technology/hardware/radeon/visual_details.html
テクスチャ生成が難しいんだってさ。

＞28、29
なるほど、ありがとうございます。
もひとついいですかね・・
半透明でＺソーと使うメリットってなんなんですか？

コンシューマーなんかだとオブジェクト単位にしかソートしないの？
入り組んだモデルなんかは破綻しそうだけど

>>31
先に手前の半透明ポリゴンを描いて、
後に奥のポリゴンを描くと、合成の結果が変になるだろ。
２枚以上の半透明ポリゴンで、試してみそ。
加算合成だけなら問題にならない。

＞33
ありがとっす！
やってみます。

ＤＣで使われてるPowerVRなんかは描画順は考えなくても
いいんだけどね。
とりあえずＺバッファだと不透明を全部描いてから
半透明を奥から描くんだけど仮にポリゴン１枚単位で
Ｚソートしてあってもポリゴン同士が交差していると
うまくいかない。
Order-Independent Transparencyという技術で
うまくやる方法も考案されているが実用までは
もう少しかかりそう。

だから
★☆★描画順を極めろｺﾞﾙｧｧｧ!!★☆★
http://game.2ch.net/gamedev/#7
なんてスレが専門で出来たりするんだろう。

半透明以外にも環境マップや水面の屈折とか
やる場合は描画順が気になるんじゃない？

>14
　実はスフィアマップでも出来る。掲示板を巡ってみよう。
やり方は近日中に公開されるはず（謎）

>>12
業界人じゃないだろ？
普通はソフイマだよ。

念のため、業界人じゃなくてもいいのだぞ、この板は。

ソフトイメージって読むやつははじめて見たなぁ

>実はスフィアマップでも出来る。掲示板を巡ってみよう。

ん？スフィアマップでもキューブマップと同等の
事が出来るって記事のことかな？
それよりまず基本的に動的スフィアマップがわかんね〜。
結局キューブマップと同じように背景を６面分
レンダリングしてからどーやるか知らんが
３６０度写りこんだ魚眼レンズ的な変形をかけて
テクスチャ作るんだろうか？
どっか解説してるページ無い？

>>36さんの正体が・・・

PIXELって雑誌があった頃は、ソフトイマージュと呼んでいたよ。

>40
　現時点なら、GLCl○ckを作っている某氏のページに
説明があるよ。ただ、具体的なアルゴリズムは書いてない。
国内では、そこ以外の解説は見たことがないよ。今のところ。

>41
　バレバレかも（苦笑）出来れば秘密のままで。

>現時点なら、GLCl○ckを作っている某氏のページに
>説明があるよ。ただ、具体的なアルゴリズムは書いてない。
>国内では、そこ以外の解説は見たことがないよ。今のところ。

M氏のは見たけどテクスチャ作成について書いてあったっけ？
ＵＶの作成についての説明は参考にさせてもらったが。
国内ページは更新が止まっているところが多くて残念だ。


>バレバレかも（苦笑）出来れば秘密のままで。

誰だっていいよ。ここでは周りにあわせて口調も
荒っぽくしてよ。相手が誰か解ると丁寧にならざるをえん。
そんな気を使わずに会話出来る事を望む。

>>37
業界人じゃないだろ？
普通はイマージュだよ。

>>38
業界人ではない怪物に来て欲しい予感・・・。

隠れ２ちゃんねらーって多いね(藁

DirectXで被写界深度をするにはどうしたらいいですか？
バックバッファをテクスチャ領域にコピーしてから
ドット単位でなんらかの処理をするの？（バウンサーみたいに）
でもＺバッファも読みたいけど確かロック出来ないんだよね。
とりあえずピクセルシェーダーは使わない方法でお願い。

そのテクスチャ一旦縮小して、適当なＺ値で拡大して貼りつけるとか。

単純にドットを拡大するだけじゃダメだと思うが。
焦点からズレている所はにじんだ様に見えるし。

カメラ座標を動かしてマップ中を飛んでいるような
プログラムが作りたいのですけど、衝突判定で質問です。
…ぶっちゃけた話、Zソートかけたときにカメラ座標と
一番近いポリゴンが衝突してるかどうかの判定対象でいいんですよね？
あと、全部のプリミティブを一旦登録してから
描画開始だと、カメラの後ろにある「見えないポリゴン」まで
描画の対象になってしまいませんか？それだと効率が悪いような気がするのですが…
Zソートの段階で、「このプリミティブはスクリーン上から見えるのか？」という
検討はすべきですよね？

SoftImageはカナダの会社で開発されたので
仏語読みで「イマージュ」と発音するのだと聞いたけど

http://ne.nikkeibp.co.jp/NEWS/990302ps1.html
みなさんも当時はこのニュースをみて騙されたりしたんですか？

>>48
MIPMAP生成（縮小BLTでもいいかも）でやれば、それっぽくできるかも。
http://www.gamasutra.com/features/20010209/evans_03.htm
もし見れなかったら、登録無料なんで是非見てみるべし。

>>51
近いものだけが当たるとは限らない気が…、たとえば
複数の面に同時に当たる可能性もあるよね？
（カメラが部屋の隅にぶつかる時とか）
// 「近い」の定義も文面から良く分からなかったけど。

あと、オブジェクトのカリングはZソート、描画プリミティブの登録以前に
視垂台上でカリングしちゃえばいいんではないかな？

>>51
３Ｄ空間を格子状に区切ったバウンディング領域を
作ってから、１つのバウンディングＢＯＸ内に引っかかる
全てのポリゴンインデックスを持たせて
カメラの居るバウンディングＢＯＸ内の全ての
ポリゴンと衝突判定ってのでどう？
複数のバウンディングＢＯＸを突っ切るように
移動した場合はそれら全ても判定する。
チェックしたポリゴンは判定済みフラグを持たせて
重複チェックは避ける。
でもこれってＢＳＰってのを利用するともっといいみたい。

ブレンダーの使い方がさっぱり分かりません。いいＨＰありますか？
xfile読み込もうとしても受け付けないし・・・・
根本的に使い方まちがってるんですかね。アニメをしたいんですが。

ソフトイメージって言ってるヤツ初めて見た（藁

（藁って言ってるヤツ久しぶりに見た（藁

SoftImageも終了したからこれからはXSIだろ。
Mayaのほうがカッコ良いけど。

DirectX8でテクスチャ貼らず、lightを使わないとポリゴンが真っ白
になるのですが色は付けられないのでしょうか？。

>>60
頂点色は？

typedef struct
{
float x, y, z; // 位置座標
float nx, ny, nz; // 法線
DWORD Diffuse; // ディフューズ色
} VERTEX;

(D3DFVF_XYZ | D3DFVF_NORMAL | D3DFVF_DIFFUSE )

この頂点フォーマットを使用すれば付けれるよ。

>>54-55
多謝。頑張って実装してみます。

>61-62 やってみます。感謝。

だれか質問しないと下がりまくるな。

(D3DFVF_XYZ | D3DFVF_NORMAL | D3DFVF_DIFFUSE )

これ書いてるってことはコンスタントシェーダー使ってる？
Vertex&Pixelシェーダー使った方が圧倒的に楽だよ。
アセンブラを敬遠する人もいるかも知れないけど、1度トライしてみて欲しい。
頂点フォーマットを自分で設計できるのは便利だから

一番簡単な実装を書いてみようか

struct BasicPoly
{
float x,y,z;
int color;
};

型定義はこれ

DWORD Vhandle,Phandle;

static const DWORD PolyType[] = {
D3DVSD_STREAM( 0 ),
D3DVSD_REG( 0, D3DVSDT_FLOAT3 ), //x.y.y
D3DVSD_REG( 1, D3DVSDT_D3DCOLOR), //color
D3DVSD_END()
};

このおまじないも書いておく


初期化関数内でCreateVertexBufferで確保した領域に値を入れる

BasicPoly *V;
VBuffer->Lock(...);
for(i = 0;i < POLY_MAX;i++)
{
V[i].x = ...;
V[i].y = ...;
V[i].z = ...;
V[i].color = 0xffffffff;
}
VBuffer->UnLock();

シェーダーのハンドルを取る

Vhandle = CreateVertexShader( dwVertexShader );
Phandle = CreatePixelShader( dwPixelShader );


描画関数内で
SetVertexShader( Vhandle );
SetPixelShader( Phandle );

SetVertexShaderConstant( 20, tmpMatrix._11, 4 );
ここで全てのMatrixをかけたものを渡す。

SetStreamSource(...);
DrawPrimitive(...);

で終了

Vshaderの中身は

vs.1.1

dp4 oPos.x, v0, c20
dp4 oPos.y, v0, c21
dp4 oPos.z, v0, c22
dp4 oPos.w, v0, c23
//x,y,zにSetShaderConstantで渡されたMatrixをかける

mov oD0, v1
//Colorをそのまま転送


Pshaderの中身は

ps.1.0
mov r0,v0
//Vshaderから渡されたColorをそのまま使用

２つのShaderはそれぞれ拡張子をvshとpshにして
xsasm -h *.vsh
xsasm -h *.psh
でヘッダーを作る
それにCreate***Shaderの引数が入ってる


なんか汚い説明だし、これ実行しても頂点カラーを指定した板きれが出るだけ
後はShaderのリファレンスを見ながら改良していけばいいと思う
ShadowVolumeだろうが、Bump環境だろうが、Furだろうが思いのままだ
健闘ヲ祈ル

xsasmはまずいだろ（ｗ

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

Shader使うと環境が限定されるからやだ。
つーか、i810Eとかにも対応なんてしたくねーっちゅうの！！
世の中GeForce2以降とRADEONで統一してくれＹＯ！

>>56
blenderはxfile読み込みのスクリプトがなかったはず。
blenderはやめてtrueSpaceにした方がいいのでは。
もしくは、コンバータでDXFに直して持って来るとか。

アニメーション付けするだけなら、xfile用のモデラ＆アニメーションツールを
freeで公開されている人がいるので探してみては。

>>71
あんたがメチャ面白いゲームをGeForce2とRADEON限定で
作り出せばいいかもよ。

>>70
わかんねー

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

ひぃぃ

ｶﾞﾝﾊﾞﾚ

?

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

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

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

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

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

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

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

レベルage。

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

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

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

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

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

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

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

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

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

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

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

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

>>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度にはできないのでは？

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

　連続ゴメソ。

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

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

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

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

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

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

>>113
IF氏って誰？

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

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

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

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

>>120
>D3DTSS_TCI_CAMERASPACEREFLECTIONVECTOR

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

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

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

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

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

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

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

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

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

あげー

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

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

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

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

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

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

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

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

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

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

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

>>136

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>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成分との内積を
入れれば、αテストで背面のポリゴンは消せそうですね。座標変換のコストは減りませんが。

>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);

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

>>149

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

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

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

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

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

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

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

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

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

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

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

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

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

>>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でレンダリングすればよさそう。
まずはＣＰＵで頂点変換して物が完成してからシェーダー化
すればいいんじゃないの。

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

>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テクスチャ座標に変換

こんな感じ。

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

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

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

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

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

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

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

>>162

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

リンクもやめてくれえ。

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

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

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

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

>>182

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

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

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

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

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

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

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

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

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

>>186

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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?

markがsageてる…

(・∀・)sage kakoii!!

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

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

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

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

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

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

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

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

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

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

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

正解

まーくぱんさーでした。

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

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

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

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

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

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

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

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

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

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

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

>>227
…マジで…。

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

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

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

ｗだから

>>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は出し惜しみのない貴重な情報だと思うのだが、
議論が続かないのは大変残念なことである。(´･ω･`)ｼｮﾎﾞｰﾝ

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

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

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

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

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

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

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

>グロバールイルミネーションで演算した結果を、
>頂点カラーに焼き付ける。これ最強。

そんな何年も前からあるようなテクの話じゃないだろ。
今は環境マップやバンプを利用すんだよ。

･･･というか応用を勉強してください。
http://www.microsoft.com/japan/developer/directx/welcome/dsmsdn/directx11192001.asp

うーん。オイラグラフィカなんだけど・・。

ってかBRDFラジオシティレンダリングした結果を頂点に焼き付ければいいんだ！
うーんそれ自体わすれてたよ！ありがとう！

でもかなりポリゴン数が

>>236
そうそう！コレ見て質問したんだおれー

LWのBRDFラジオシティって凄く時間かかるけど、
なんでおんなじような結果がリアルタイムでできるのかがわからない。

LWで光線評価の品質下げたらマダラ模様が凄くてつかえなかった

やあ、２ｃｈのプログラマー諸君！

Gustav Taxenたんは２つの半球マップを覆うために
円形のテクスチャを使用しているんだけど
彼の手法は必然的にある結果に行き着くんだＹＯ！それは・・

＋Ｚ（上半分？）の半球マップで、無限大の同次テクスチャ座標は
（例えば(s, t, q)=(1. 0, 0) とか (-2, 1, 0)みたいな）
実は−Ｚ方向（下半分の半球？）に一致してしまうんだＹＯ！
そんなわけだから、三角形の座標の三つの反射ベクトルが
(0, 0, -1)に近づいたとすると、それぞれに対応する
非同次テクスチャ座標は極端に巨大になってしまうのさ！
その結果、それらはいくつかの状況で円形のテクスチャを取り囲むんだ。

今時のＧＰＵたん（；´Д`）はいつでもテクスチャ座標を
線形補完してくれるから、座標間で補完された値は
円内に収められるのＹＯ。
（つまりその−Ｚ方向の半球のマップは小さな”穴”を持ってるわけだ）

このような結果（事実）はＫＡＮＯたんのＯｐｅｎＧＬサンプルで
観察できるＹＯ。
（これは彼がGustavたんと同じ手法を使ってることを証明していると
　漏れは思うわけで。）

ここで注目すべき要点は！
環境マップ座標系の−Ｚ軸のような視点ベクトルを選ぶとこの穴は見えない。
したがって、２つの半球マッピングの視野からの独立性は否定される！！

これってどう思うよ？？

頂点焼付け系
・前計算なので比較的コスト安
・オーサリング後の自由度低し

計算結果をテクスチャに埋め込み系
・光源計算用にテクスチャステージ消費。マルチテクスチャ系サポートしてないハードではイタイ。
・頂点焼付けより自由度が高い照光モデル。リアルタイムに光源が動かせる。

みたいな感じの理解でＯＫかな？

ごめん。適当すぎた。ラスト修正

ここで注目すべき要点は！
環境マップ座標系の−Ｚ軸のような視点ベクトルを選ぶとこの穴は
見えないけど・・・
でも２つの半球マッピングの視野からの独立性は否定されんじゃネーノ？？

これってどう思うよ？？

~C氏がirradiance mappingを実験してたね。
正直スゲーいけてんじゃん！って思ったね。
平行光源だと式が小さくなって光源数も増やせると
いうのがリアルタイムへの可能性を感じる。

元ネタはこのへんか。
http://graphics.stanford.edu/papers/envmap/

>偽まーく
お疲れ様。
ところで"穴"ってどんなの？
極点ってのは理解してたんだけど。
kano氏のサンプルをもっかい見れば確認できるのか？

PS2のICOは焼付け系だよねぇ？

>>236
いっとくけど、頂点カラーの話はネタだよ。(というか基本中の基本）
プログラマブルシェーダーでできることとできないことが
理解できていないようだから、勉強しなおしてと言ったまで。
でもまあグラフィッカーさんならしょうがないか。

で、そのリンク先、
グローバルイルミネーションや、BSSRDFと何か関係あるの？

みんな見てるサイトも興味あるネタも同じだね(藁

>>236
それの半球ライディングさー、
面が受ける光の量とかはまあ適当に分かるんだけど、
フォームファクタの算出（遮蔽データの算出）をどうやってるのか分からないんだよねー。
これだけは先に計算してあるの？
だとしたら幻滅。
リアルタイムだったら驚愕。

誰か分かる？？

遮蔽データの算出はリアルタイムではない。

さんきゅー。
やっぱねぇ…、無理だよねぇ…。

>>243
環境マップ空間の−Ｚ軸の方向に、ちゃんと「穴」が見えるよ。

ＨＡＬＯ影、ＩＣＯ影について教えてください
どっちも見たことありませんが影がすごいらしいので。

同次座標というのは、「ｘ座標ｙ座標の図」みたいな感じで図にできるものなのですか？。

>>252
こことか見れ。
http://www.cc.rim.or.jp/~devilman/3dCoding/3dMatrix.html
＃ｗをウェイトっていうのはここが元ネタか？
＃途中にそういう記述があるけど･･･

>>239 >>241
内容を理解しないで中途半端に翻訳するのはやめれ。

>>253
宇治社中は、ときどき間違いっぽいことが書いてあるので、
常に疑いながら読まないとひどい目に会うよ。
＃初心者がいきなりあれを読むと、かえって誤解を招きかねない。
＃かといって、他に同様の日本語資料がないのも事実だが。

>>248
リアルタイムじゃないのか…。
じゃあオブジェクト動かしたら破綻という意味で、
頂点焼き付け系と同じだな…。
びっくりして損した。

>>255
いや、遮蔽項の持たせ方次第では、動的に半球光源を
動かしたりオブジェクトを回転させたりできるはず。

>>254
なら訳してくれよ。
読んでも違いが分からない段階の人は
文句を聞いてもただよけい不安になるだけだ。
読んで違和感を感じられる段階の人ならすでに解っている。
文句を言うだけなら意味が無い。

>>254
３Ｄ野郎によくいる他人の小ミスを見つけて掲示板でコソコソ皮肉るのが得意な人ですか？

>>257
とりあえず訳してみたぞ。
多少直訳っぽくなってしまったが、解釈自体は間違っていないと思われ。
＃Kano氏の訳語を尊重して、「dual-paraboloid」は「双放物面」とした。

――――――――――――――――――――――――――――――――――――
204 ：Mark ：01/12/10 02:18 ID:???
こんにちは、日本のプログラマの皆さん！

Gustav Taxenは、円形のテクスチャを使って、双放物面マップをマスクしています。
しかし、彼のアプローチでは、必然的にあるアーティファクトが起こってしまいます。

＋Ｚ側の放物面マップにおいて、(s, t, q) = (1, 0, 0) や (-2, 1, 0) のような無限大の
同次テクスチャ座標は、実際には同一の−Ｚ方向（Ｚ軸負の方向）を表します。
したがって、三角形の頂点における３つの反射ベクトルが (0, 0, -1) の近くにある場合、
各々の対応する非同次テクスチャ座標は極めて大きな値になります。その結果、
場合によっては、それら（＝３つのテクスチャ座標）がマスクの円を囲んでしまいます。

今日のGPUのラスタライザはテクスチャ座標を常に線形補間するので、そのような
（＝円を囲むような大きな）座標間で補間された値は、円の内部に陥る可能性があります。
このことは、マスクが−Ｚの方向に小さな「穴」を持っていることを意味します。

このようなアーティファクトは、KanoのOpenGLサンプルで観察することができます。
これは、彼がGustavと同じ方法を使用しているという事実を正当化していると思います。

ここで注意すべきことは、環境マップ空間の−Ｚ軸として視線ベクトルを選択すれば、
穴が見えなくなるということです。しかしながら、この選択は、双放物面マッピングの
視点独立性と矛盾することになるかもしれません。

以上のことについて、皆さんはどう思われますか？
――――――――――――――――――――――――――――――――――――

>>256
>遮蔽項の持たせ方次第では、動的に半球光源を
>動かしたりオブジェクトを回転させたりできるはず。
要するにラジオシティで頂点焼き付けを行ったオブジェクトにライトを照らしました」ということでしょ？
確かに宙に浮いてる単体オブジェクトの回転程度なら出来るけどさ。
そこに床なんて置いたら一発で浮いちゃうから動かせない。
出来れば簡略的でもいいからフォームファクタのリアルタイム算出を実現して欲しい（無理か…）

半球ライディング自体は目新しいけど、
遮蔽項無しの時点の画像がそれほどリアルに見えない以上、
一瞬芸のように見えなくも無い。

話が進みそうで進まないこの微妙な空気・・・

>>253
ありがとうございます。
同次座標という考え方を使えば、平行移動の式を行列であらわせるということが解りました。
だけれども、「同次」っていう名前がついているのはなぜなのでしょうか。
「３次元での座標」と「４次元での座標」があって、この２つに共通して存在する座標のことを「同次」っていうのかなあ？。
次元は違うけど、同じ次元での座標と考えてもいいよっていう感じかなあ。

>>262

どうじ【同次】
多項式や関数の性質の一つ。多項式では、各項の次数が同じであること、
関数f（x，y，…）ではf（tx，ty，…）＝trf（x，y，…）なるrがあることをいう。

Kokugo Dai Jiten Dictionary. Shinsou-ban (Revised edition) ｩ Shogakukan 1988/国語大辞典（新装版）ｩ小学館 1988

親切心から言うがまず日本語を疑ってみよう。
無ければ専門用語。それから専門書を当たる。

いまさらだか偽まーくのようなチャレンジは
エライと思うよ。
間違っててもみんなで訂正していけばいい。
解る人が答えなければあーするしかないし。

>>263
つまり、「多項式の各項の次数が等しいこと」が同次座標の「同次」の意味？。
ｘ座標やｙ座標を表す多項式の各項の次数が等しかったら、同次座標といってもいいの？
ｗが無くても同次座標っていってもいいことになるのかなあ？

>このことは、マスクが−Ｚの方向に小さな「穴」を持っていることを意味します。

これを確認しようとkano氏のを見てみたけどよくわからんかった。
映り込んだ背景の一部に欠損部分があるって事？
ティーポットの側面？それとも上下部分？

>>266
解りにくかったらテクスチャを放射状に色が変わる模様とかに
変えてみるとすぐ解るよ。
起動直後のトーラスのテクスチャ中心部に着目すると
中心部とは違う色の穴が出来ている。

>>265
そりゃただの座標だよ。
３次元の座標で演算を行う場合に付きまとうさまざまな困難（不正確、複雑化等）
を回避するために１次元次元を上げてやったような座標系を
同次座標と言うように理解している。

わざわざ同じにした、という意味をこめて同次とつくのかもしれん。
でも幾何学的な意味はハッキリしてるからあまり字面で悩むことは無いと思うよ。

>>269
具体的には何を「同じにした」の？

>>270
次数または次元。
行列化する前の変数の数見れば３次元で表現できないことが解る。
線形代数を勉強すると（・∀・）ｲｲ!!

DualParaboloidの認識についてちょい質問。

Wolfgang Heidrich氏のは
http://www9.informatik.uni-erlangen.de/eng/research/rendering/envmap/
のページの一番下の２枚のテクスチャを使用するんだよね。
（青丸の内側だけ使用？そうするとAlphaがやっぱり要る？）
で、テクスチャそのものが歪んでいて変換は重そう。

Gustav Taxen氏のは
http://www.nada.kth.se/~gustavt/dpm/
のページの真中にある、Front、Alpha、Backの３枚のテクスチャを使用する。
テクスチャの歪みはないので高速に生成できそう。

この前提であってるよね？

>>267=268
E-mail欄にageって入れるとID:???にしておけるよ。
ここ沈んだら誰かageてね。

>>272
Gustav Taxen氏のテクスチャは、たまたま単純な地面と空になって
いるから歪んでいないように見えるだけで、実際には歪んでいる。

円形に切り取って繋げる処理（マスク）は必ず必要となる。
でも、この処理に円形のアルファテクスチャを使うと、
例の「穴」の問題が発生してしまうというわけ。

僕も、同次座標って意味が良くわかりません。
とりあえず移動が表せるって部分で納得してるんだけど…
聞いた話だと無限座標があらわせるとか。
例えば、(1,1,10)だと、(1/0,1/0,1/0,0/0)→(∞,∞,∞,1)らしいけど、だから何？って感じ。
あと、テクスチャのu,v以外の座標もよくわからんです。

プラネタリウムソフト作るのに使った＞W=0の無限遠点

>>275
それは射影における除算を計算せずに分数の形で取っておくことで
０除算や値の発散等を避ける目的でｗという変数を追加しただけ。
３＋１次元で行列もこれに合わせるので同次。

>>274
解説さんきゅーです。
歪んでないように見えて歪んでたんですね。
Wolfgang Heidrich氏のはアルファテクスチャを
使用しないので穴は無いという事でいいですか？

同次座標って、、
２種類の次元の値を、同じ次元のものとして扱う座標ってことかなあ？。
（４つの変数で表されているものを、３つの変数で表すものにかえたりして）

Wolfgang Heidrich氏の原論文の実装説明でも、テクスチャの
アルファ要素に円形のマスクを埋め込む方法が書かれている。
Gustav Taxenは、ただそれを読んで実装しただけ。

Heidrich氏は穴の問題について一切触れていないが、
巧妙に回避する方法でもあるのだろうか・・・。
論文のスクリーンショットではまったく確認できないが、
単にテセレーションが細かいから見えないだけなのかな？
＃あのトーラスは144x72に分割しているとのこと。
＃どう考えても細かすぎだよな。

kano氏のサンプルで確認しようとしたけど
さっぱり分からなかった。鬱。
ディフューズとＢＡＳＥテクスチャをはずして見たんだけど。

>>281
ガイシュツです。>>266-267

267はトーラスって言ってるけどkano氏のではない？
kano氏のはティーポットだし。

>>283
ＯｐｅｎＧＬのサンプルのほう。訳にもそう書いてある。
ティーポットが初期表示のやつはリアルタイムで計算してるサンプル。

ということは動的なkano氏のやつには穴はあるのかな？

確かに kano 先生のはティーポットだったけど、
トーラスにも効くよ。

あはははは。愚民ぷろぐらまさん。
あなたたちは所詮アマなのよ！

>>287
いちごとねこの人ですかぁ？（ﾜﾗ

　　　　　　　　　　　　 　∧　 　∧
　　　　　　　　　　　　　 /　ヽ　/　ヽ、
　　　　　　　　　　　　　/　　　/　　　ヽ_
　　　　　　　　　　　, '´　　　　　　　:::::::::::ヽ、
　　 　　　　　　　/　　　　　 　　　　 　::::::::::ヽ
　 　　　　　 　　 i　　　　　　　　　　　　　::::::::|
　　　　　　 　 　 |　　　　　　　　　　　　 ::::::::::|
　　　　　　　　　 ヽ 　 ． 　　　．　　　 ヽ:::::::/　　ﾔﾀﾞﾓﾝ...
　　　　　　　　　　 丶　　　　　　　　　:::::::<
　　　　　　　　　　　　|　　　　　　　　　　::::::ヽ、
　　　　　　　　　　　　|　　　　　　　　 　　::r　　）
　　　　　　　　　　　　|　　　　　　　　　　::::| ／
　　　　　　　　　　　　|　　　　　　　　　　::::|=＝==
　　　　　　　　　　　 /　　　 　|　　　　　:::::|
　　　　　　　　　 　 （＿＿＿（＿＿＿＿::|

( ・∀・)っ目　ﾎﾝﾓﾉ ﾅﾗ ﾄﾘｱｴｽﾞ ﾄﾘｯﾌﾟ ﾂｶｯﾄｹ!!

彼のページ見るに本物ではないっぽいが。

>あはははは。愚民ぷろぐらまさん。
>あなたたちは所詮アマなのよ！

まぁ笑うなら笑え。
１年で追いついてやる。

漢字を使ってる時点で明らかな偽者.

>>287
>>289
誰？プロですか？

>>293 ﾜﾗﾀ　たしかにそうだな。

トーラスにも効くよ。

出し惜しみしない会age

>>292
１年もかかるの？半年もありゃ十分。

出し惜しみを加速させる有害スレになりつつあるのでsage

300 age

削除依頼出しておきました。

ルイージマンションの懐中電灯みたいな処理をDirectXでやりたいんですけど、
どうやれば出来るんでしょうか？
できれば、スフィア環境マップの要領でライトの絵をテクスチャステージに割り当て
マトリックスによる変換で実現したいんですが・・・。

現状、ソースのような感じでやってるんですが、なんだかライトの広がりが表現されず、
光がまっすぐ伸びていきます。（夕暮れ時の影のような感じ？解かりにくくてスマンっす）
中心から扇形に広がる光を表現したいんですが、どうやればよいか解かりません｡

どなたかわかる方いらしたら教えてください。ｍ（＿　＿）ｍ

（以下、ソースより抜粋）
dev->SetTextureStageState( 1, D3DTSS_TEXCOORDINDEX, D3DTSS_TCI_CAMERASPACEPOSITION );
dev->SetTextureStageState( 1, D3DTSS_ADDRESSU, D3DTADDRESS_CLAMP );
dev->SetTextureStageState( 1, D3DTSS_ADDRESSV, D3DTADDRESS_CLAMP );
D3DXMATRIX mat;
mat._11 =-0.5f; mat._12 = 0.0f; mat._13 = 0.0f; mat._14 = 0.0f;
mat._21 = 0.0f; mat._22 =-0.5f; mat._23 = 0.0f; mat._24 = 0.0f;
mat._31 = 0.0f; mat._32 = 0.0f; mat._33 = 1.0f; mat._34 = 0.0f;
mat._41 = 0.5f; mat._42 = 0.5f; mat._43 = 1.0f; mat._44 = 1.0f;
dev->SetTransform( D3DTS_TEXTURE1, &mat );

>>302
Projective Textureで検索しる。

DirectXのサンプルだと側面ポリゴンから
シャドウボリューム作ってステンシルで
マスク作って影の板を描画してるよね。
やっぱ速度的にきびしくて採用しないのかな。

2Dのポリゴンなのですが・・。
連続した頂点(xy)データから凹ポリゴンを凸ポリゴンに分割する方法を手ごろに説明してあるページってありませんか？

別スレできいたほうがいいよ。

>>305
http://www.win.ne.jp/~m-nagaya/program/Tessellate/TessellatePoly.html

>>305
凸ポリゴンがすべて三角形でよいのであれば、
GLUのポリゴンテセレーション機能を使うのが最も簡単。
＃OpenGLを使っていなくても単独で使用可能。

来年の３Ｄのハードウェアがどの程度まで
パワーアップするか分かる人います？
まずＡＧＰｘ８は期待できるんだろうか。

>>309　ハード板へＧＯ！ＧＯ！

>>303　ありがとう！おかげで完成したＹＯ！（公開は出来ないけど)
グーグルで調べたら日本語のページがありました。
今まで何を探してたのやら・・・鬱堕志乃鵜｡
ttp://www.geocities.co.jp/SiliconValley-Oakland/1373/ProjTex.htm

まさにOpenGLです。ポリゴンテセレーションの関数は確かにあるんですが、
(Delphiで作ってるのですが)gluのヘッダがコメントアウトされていて使えません。
//外しても上手く動作しない・・。

で、自前で分割する方法がないかなぁ・・と。

SpotlightShadowってやつだね。
http://www.ati.com/na/pages/resource_centre/dev_rel/sdk/RadeonSDK/Html/Samples/Samples.html

>>312
考えてみました。
外から180°未満の角をパキパキ折ってく感じで
良いんじゃないでしょうか。

ちょっと具体的に書くと
(1)どれでも良いから180°未満の角を選ぶ。
(2)その角と両隣の角(点)を結んで出きる三角形を切り取る。
(3)切り取った残りの多角形が三角形になるまで繰り返す。

こんな感じでどうでしょう。

>ハード板へＧＯ！ＧＯ！

ごめん。GeForce3以降のハードの構想
よく知らなかったんでつい。
ハード板は３Ｄ技術とは違う方向に行きそうで怖い。

>>314
いくつか問題があるね。
(1)180度未満といっても点の観点では内角か外角か判断できない。
(2)角の選択によっては形状がおかしくなる。
（例えば２辺で構成される三角形内に別の点が存在する場合。）

前者は内角外角を仮定して、総和をとり内角が外角より大きければ
条件を反転させるという方法で回避できる。
後者は２辺を結ぶ線分と、すべての辺との交差判定を行うことで回避可能。

ちょっと長いです。
すいません。

>> 316
> いくつか問題があるね。
> (1)180度未満といっても点の観点では内角か外角か判断できない。
> (2)角の選択によっては形状がおかしくなる。
> （例えば２辺で構成される三角形内に別の点が存在する場合。）

(1)の方は自己解決してくれたようなのでレスしません。
(2)の方のみ答えます。
与えられた多角形は形が破綻していなければ(*)隣り合う点同士を、
全ての点を双方向リストで結べば1本のリング状につながります。
このリストは、全ての角が180°以下の場合、どちらかに手繰れば
時計回りで、どちらかに手繰れば反時計回りになっています。
後は法線クリップの時の要領で、全ての角を外積してみれば
180°以上か未満か解かります。

リストをどっちに手繰れば時計回りかに関しては、
与えられたデータと比較すれば分かると思います。
これで分からない場合、そのデータでは、
与えられた点(辺)のどちら側が内側かも
分からないということのなで、塗ることもできない、
つまりはそのデータは線の集まりであって、
面のデータになっていない。
ということになるからです。

結構長い文章になってしまいましたが、
前出の｢出っ張った角をパキパキ折ってくアルゴリズム｣では
この「全ての点をつないだ1本のリング状のリスト」を
作ってしまうのが近道でしょうから、
それほど難しいものではないはずです。


(*)ここでいう形状が破綻している多角形とは
　・交差している変が有る
　・穴がある
といった形です。

＞後者は２辺を結ぶ線分と、すべての辺との交差判定を行うことで回避可能。

元々、辺同士が交差していなければ、交差判定をするのは冗長。
単に別の頂点が三角形内にあるか判定するだけで十分。

びみょうなとりっぷだなぁ……。

すずなな？

http://www.bunkasha-games.com/frameset_screenshot.html
http://www.bunkasha-games.com/frameset_movie.html
このグラフィックはどうやってますか？

>>319
ﾜﾗﾀ

>>321
レンズフレアが(・∀・)ｲｲ!!

>329

すずなさんは結構かわいいタイプですよ。

>319でした。すずなファンです。

かわいいものにはとげがあるのだ

>>321
ｽｹﾞｰ

鈴菜たん (;´Д｀)ﾊｧﾊｧ

http://suzuna.jp/

ちなみに >>323 鈴菜たん？

　 ∧∧
　(．．、)　　 　／￣￣￣￣￣￣￣￣￣￣￣
　 |　　|)〜　＜　>>329 ﾁｶﾞｳﾓﾝ...
　 Ｕ Ｕ　　　　＼＿＿＿＿＿＿＿＿＿＿＿

初心者な質問をすいません。
カメラの行列を，注視点中心に回転させたいのですが，
ビューマトリックスを元にした行列演算だけで表現できますか？
よく分からなくて結局視点を回転させてビュー作るようにしてしまいました。

ビュー行列には注視点を表すデータがないので無理かと。
注視点が常にワールド座標の原点になるようなシステムを組めば不可能ではないけど、
カメラを回転させた方が良いと思う。

>>321
レンズフレア綺麗だね
光物のモーション部らーも
輪郭検出みたいな効果が入っているのは何なのでしょうか

車ゲーはあまりしないのでよくわかりませんが
ジャンプしたときにタイヤが円弧を描いてるのに感動
飛び出しと同時にぴたっと止まっているので
車体位置からタイヤ位置計算＞サス反力みたいにやっているのかな

３Ｄゲーム率は年々、実は下がっている

ボッキにも輪郭抽出して！
　　 ＼＿＿＿＿＿＿　＿＿＿＿／
　　　　　　　　　　　　　　　　|/

　　　　　　　　　　　　 ／⌒ヽ⌒ヽ
　 　 　 　　　　　　　　 ....:::..　Ｙ.　 .
　　　　　　　　　　　 .::::::::.（･）（･）::ヽ
　　　　　　　　　　.（ ::::::::;;;／ ○ ヽ;.:;）
　　　　　　　　　　..丶1;.' ≡　|　≡!/
　　　　　　　　　　 ...ζ, 　t-┴‐' .j
　　　　　　　　　　　　i　　 ｀'ー‐'　.j
　　　　 　　　　　　　 .|　 　 　八 　 |
　　 　 　　　　 　　　. {=====(T)===}
　　　　　　　　　　　.. | i し　"　i　 　'|
　　　　　　　　　　　　|ﾉ　(　　　i　 　 i|
　　　　　　　　　　　 (　'~ヽ　　　!　　‖
　 　 　　　　　　　　..│　 　;　　i　 　‖
　　　　　　　　　　　　|.　　　　.　!　 　 ||
　　　　　　　　　　　　|.　　　　. !，　　　|
　　　　　　　../＼＿/＼ 　　.　i.　　　./＼＿/＼
　　　　　　 ／:∵:∴.:∵;::..　　|　　.::∵:∴:∵::...＼
　　　　　／∵:∴:∵:∴:∵:∴.!∵: ..::∴:∵:∴:∵＼
　　　　 /.:∵:∴: ⌒:∴:⌒∵...! .:∵:∴: ⌒:∴:⌒∵|
　　　　｜.:.:∴:∵:(･)(･).:∴:.　.i .:.:∴:∵:(･)(･).:∴:.|
　　　　｜∵:三.:∴.○:∵:　:.三∵:三.:∴.○:∵::.三
　　　　｜:∴:∵ ＿＿＿ ::　..| .:∴　;;:∵＿＿∵:.|
　　　　　＼∵:∴＼＿/:;.　──∵:∴＼＿/:;.／
　 　　　　 　＼＿＿＿／ 　 　　..＼＿＿＿／

できたー！
さんたさんからのくりすますぷれぜんと？

３Ｄ技術だのなんだのに妄想話、膨らませてる連中より
しょーもないアスキーアート作ってる連中の方がよっぽどクリエイティブだよ。
いや、イヤミでもなんでもなく。

>>337
じゃあここくんなよ。ウゼェ。

>>337
このスレで語られていることのどこがどういう風に妄想話なのか、
400字詰め原稿用紙100枚で説明してちょ。
ま、キミが理解できない話題は全部妄想話扱いなんだろうけど。

>>339
>さんたさんからのくりすますぷれぜんと？

この部分じゃない？

せっかくの名スレが冬休み突入たった２日で撃沈か。

冬厨には餌を与えないように。←これも餌か。

というか、なぜこのスレに？
3D技術修得に挫折したとかのトラウマがあるのかな？

おいらは、このスレのＲＯＭだったけど、ちと書かせてもらうわ。

＞3D技術修得に挫折したとかのトラウマがあるのかな？
出たよ。ゲ業界のプログラマーが砦にしている「３Ｄ技術」とやらが。
なにが、「修得」なんだか。そんなに高尚なものかよ？
上手な絵書ける人だけが漫画家かよ？（ﾜﾗ
奇麗でリアルな絵がレンダリングされているゲームを
作れればゲームプログラマと名乗れるのかよ？

>>343
今時、3Dのノウハウもねぇアホはゲーム作る資格ねぇんで死んでくれ。
アフォと仕事すんの疲れたわ。
「高尚」じゃねぇが、Matrix程度のことも理解できない馬鹿はいらない。
むしろ最低限の3Dの知識も無いならゲームプログラマを名乗るな。

>>343
んー、この人何を怒ってるんでしょう？

最近のプログラマの立場は７割がた「技術者」なので
分からない、作れないじゃ困るのねん。
多人数制作なら、プログラマは技術を探求し、
アートはデザイナーに任せるのが適切な役割分担ってもんでしょう。

＃で、ここはその技術についてのスレなんだけどなー。

＞奇麗でリアルな絵がレンダリングされているゲーム

そういうのは、いくら高度な3D技術があっても
プログラマだけでは無理です。

>＞3D技術修得に挫折したとかのトラウマがあるのかな？
>出たよ。ゲ業界のプログラマーが砦にしている「３Ｄ技術」とやらが。

なぜＲＯＭってこのスレ読んでる奴がここまで言うかね。
単に自分が技術に追いつけないひがみとかか？
もしそうならこのスレ見て勉強しろ。

芸術系の大学でOpenGLプログラミング教えられると迷惑なだけなんですけど。
ソフト使えよ！馬鹿クッキー

　　 ○
　　,)　 ＼.　 （
　 (＿＿__.) 　 ）
　（　・∀・）っ目 ﾀﾀﾞｲﾏ!! ﾒﾘｰｸﾘｽﾏｽﾀｶﾗ。ﾁｬｰﾉﾒ!!

>>348
いや、それ結構貴重。
普通、プログラムからやらんだろ？
そんなの自分でやるから学校でやんなってんなら別だけど。

ごめん。釣れちゃったみたいね。

＞出たよ。ゲ業界のプログラマーが砦にしている「３Ｄ技術」とやらが。
3D技術がなぜ出てきたかはスレのタイトルをみれば分かると思います。
あなたは、「3D技術があるくらいでゲームプログラマーと名乗れると思うな！」と言われたトラウマを持っているんですか？

れおは、3D技術なんてぐらい当たり前だろうと言えるようになるために勉強してます。

>>351
煽るなYO!

もういいから、３Ｄの技術の話に戻してくれYO！（×д×）

あ〜ぁ〜〜〜〜〜。
勉強になってたのにぃ…

>>314,316-318

貴重な意見ありがとうございます。参考にして試してみました。
鋭角な角を基準に前後のポイントを取り、三角形に分解し続けたのですが、
その間に他の点があるとうまくいきませんでした。
他の点を検出しようと思ったのですが、判定方法がよくわからなかったので、
別の方法を試してみました。

方法は、まず図形内の鈍角の点を探し、またそこから適当に鋭角の点を探し、
その2点間に点又は線がなければ2点間で図形を分割するというものです。
そのまま鈍角の部分が無くなるまで分割しつづければいいかなーと。
やってみたら図形の外側で分割されることもあったので、2点の中心が図形内か
確認するようにしたらまあまあ期待通りの動きをしました。

プログラムが妙に煩雑になりましたけど・・まあ当面はこれでなんとか行けそうです。
助かりました。

3Dテクニック駆使しまくりの独り善がりなゲームより昔のファミコンのゲームの方が遥かに楽しい。
絵がきれいだったり派手なのはゲーム性と全然関係ない。

ってのをわかってないで手持ちの3D関連のスキルを自慢しまくる奴はもう見飽きました。

>>357
3Dに付いて行けなくてコンプレックスを抱く古いプログラマさんですか？

FFXの技術が凄いと語っていると、
シナリオが糞とか言ってくる厨房ぐらい的外れ。
プログラム＝ゲームデザインの時代はとうに終わっています。

>>356
>他の点を検出しようと思ったのですが、判定方法がよくわからなかったので、

３角形を構成する各辺と、３角形の法線ベクトルと外積をとって、
各辺の法線ベクトルを求め、
その辺法線ベクトルと判定する点へのベクトルの内積を取った結果が
すべて正なら点は３角形内に存在するといえるはず。

>>312
ところで、何をしようとしているのでしょうか？
あまり用途の思い当たらないもので。
自力描画ルーチンならありえなくはない
とも思うのですが・・・。

俺は１５年ぐらい昔に２Ｄでシナリオも絵も
プログラムも音も全部一人でやった独り善がりな
プログラマーだったが今は分担の時代だと思うぞ。
ゲームがクソになるのはプログラマではなく
企画者に原因があるだろうし、さらに言うと３Ｄやってる
ＣＧプログラマじゃなくてゲームプログラマに
問題があるだろう。

>>357
そういう話はゲーム性に関するスレでやってくれ。
ここはアンタの愚痴聞くスレじゃねぇんで。

／￣￣ ●￣●､
|Y　Y 　 　 　 ▼ ､
||　　 |__＿＿_人___|
|　 　 ||||||||||||||||||||
|　 　 ||||　　|　 | |　　 ／￣￣￣￣￣￣￣￣￣￣￣
| 　　 ||||　"　.　ノ　＜　Don't waste time on guffs!!
| 　　 ||||◇◇◇|>　　＼＿＿＿＿＿＿＿＿＿＿＿
＼__ノ||||￣￣￣＼

「３Ｄ野郎」とか名乗っておられた、若き情熱に溢れていた方々は今、いずこ？

じゃんじゃんネタ振ってくれ。
業界で飯食ってる1が出し惜しみせずに答える予定だから。

おそろしく厨房質問じゃないかとｶﾞｸｶﾞｸﾌﾞﾙﾌﾞﾙ(((（ ;ﾟДﾟ)))なんですが
いろんな幾何学ライブラリ見たとこ
点とベクトルと分けてないのが多いのはどうして？

点−点＝ベクトル
点＋ベクトル＝点
ベクトル＋ベクトル＝ベクトル
点＋点→不可

とか安全で美しいと（俺的には）思うんだけどもー。
Java3Dのvecmathくらいしか見たことない。

私としては点というより位置ベクトルと考えるので
あまり美しく思いませんが・・・
おっしゃりたいことは解りますが
具体的な利点とかあります？

点を「原点からの位置ベクトル」で表現すると、この世には
原点以外には意味のある点は存在しない！と断言した数学者もいる。

３次元頂点座標変換も、「点を移動させる」のではなく、
「原点とその点を結ぶベクトルを移動させる」という解釈。

いや、好みの問題だと思う。どっちもいっしょ。

ユークリッド

　　　　　　　　　人人人人人人人人
　　　　　　　　＜　　∧＿∧　　　　 ＞　 ／￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　＜　（　 ´∀｀）　　 　＞　＜>>363 まさか、あなたはッ……！？
　　　　　　　　＜　と　　　　つ　　　＞　　＼＿＿＿＿＿＿＿＿＿＿＿＿
　　　　　　　　＜　（￣￣￣￣）　　 ＞
　　　　　　　　＜　（￣￣￣￣）　　 ＞
　　　　　　　　＜　（￣￣￣￣）　　 ＞
　　　　　　　　＜　　￣￣￣￣　　 ＞
　　　　　　　　　∨∨∨∨∨∨∨∨

質問は具体的なものに限る。

ＡＡコピペ野郎うぜぇ。

　　　　　　　＿__　　　　　　　　　　　　　　　　　　　　　　　｜　　＼ ＼
　　　　/　　　　/ ））））　　　　　　　　　　　　　　　　　　　　|
　　　/　　　　／＿ ⊂ﾉ　　　　　　　　　　　　　　　|　ヽヽ　|＼
　　/　　　／ ／　　　　　 　　　　　　i 、、　| ヽヽ　|＼　 　|　　＼
　/　／　＼　＼　　∧＿∧ 　　 　 　ﾄﾞ ド　|ヽ　 　|＼　　|　　　　|
/ ／　　　　＼　＼（　´Д｀） 　　　 ／￣￣￣￣￣￣￣￣￣
／ ／　　　　　ヽ　　　　　 ⌒＼ ＜　>>372さーん!!!
／　　　　　　　ﾉ　　　 　　／>　>　＼＿＿＿＿＿＿＿＿＿
　　　　 　　　/　　　 　／　三ﾉ　　　　　　　　　　　　　　　　　　　　　
　　　　　 　/　　/ ＼　＼ `￣　　　　　　　　　　　　　　　　　　　
―　　　　/　　ん、　 ＼　＼　　　　　　　　　　　　　　　　　　　　
――　　（＿＿　（　　　>　 ）　　　　　　　　　　　　　　　　　　　　
⌒ヽ　　　’　・`し'　／　／　　　　　　　　　　　　　　　　　　　　　
　　人,　’　’,　(￣　／　　　　　　　　　　　　　　　　　　　　　
Y⌒ヽ）⌒ヽ､　）　　|
　　　　　　　　　＼＿つ

ﾏﾀｰﾘﾏﾀｰﾘ

>>373
師走だなぁ

>>360

ドローソフトで作成した2DポリゴンをOpenGLで立体化したいだけです。
ゲームではありませんよ。

本田ゆうなﾀﾝ、ﾊｧﾊｧ…
http://www.iyokan.co.jp/avdxx/jacket_img/jacket_jpg/981634.jpg

irradiance mappingってのはテクスチャじゃないの？
もしかして頂点カラーに焼き付けるの？

>>378
焼き付けるっつーか 頂点シェーダ

>>379
どうも。頂点シェーダーなのはいいけど結局
頂点カラーって事なんですね。
てっきり環境マップ系のテクスチャによる擬似
ライティングかと思ってしまって。
irradiance mappingって光源増やしても
負荷は極端に増えない点光源って感じですか？
平行光源って感じでもあるけどまだ理解不足で。

diffuse の環境光は "ぼやける" から
テクスチャを使わずにいくつかの変数で近似できるという考えね。
オフラインで環境マップ(画像)から変数を算出する。
その変数の数はとりあえず一定だから光源数と負荷は関係ない。

ブラックボックスとして使える話なので、
実際に標準的な光源モデルを使うのと負荷を比べて良さそうなら使えば？

>>381
オフラインで処理するなら、
ラジオシティで頂点カラーを計算した方が遥かに良い気がするのですが。
irradiance mappingを使用するメリットって何ですか？

ラジオシティは静的なオブジェクトにしか使えん。
そもそも使い道が違うものを比べて遥かに良いとか言うのは問題あるかと。

>>363
オフラインで処理するのは変数の算出までで、
頂点カラーの計算は動的ってことですか。
勘違いしてました。

げいむきゅうぶはたのしいな

>385

suzunaたん？

　　 ∩＿∩　　／￣￣￣￣￣￣￣￣￣
　　（ ´（・）｀）＜　まじめなはなししてんのにわりこんだりなんてしないよ・
　　（　　　　） 　＼＿＿＿＿＿＿＿＿＿
　　｜ ｜　|
　　（_＿）＿）

daichi.honda@hitmaker

　　　.　　　　　　　　　　　　∧ ∧
　　　　　　　　　　　　　.　　( ´ー｀)＜シラネーヨ
　　　　　　　　　　.　　　　　 ＼　<
　　　　　　　　　　　　　　　　　 ＼.＼
　　　　　　　　　　　　 　　　　 /￣　/⌒ヽ
　　　　　　　　　　　　 　　　 /⌒/⌒/　/　|
.　ＴＴＴＴＴ　　　　　　　 　 （つ/＿/　/＼　|
　（ *｀ー´）　　　　 　　 　 （＿＿＿_/　　ヽ
　 /　　　　つ 　　　　　 ___/　/　/　＼　 丿
　（人＿つ_つ 　　　　 ( _＿(_＿_ ）￣￣￣
くだらねぇ粘着に引っ付かれちゃったけどどうよ？

388 は放置して続けましょう。いい話をとめずに。

話がとまったのでこのスレ終了。

すいません　このスレの存在を知らずに糞スレ建ててしまいました
だれかおしえてくらはい
http://game.2ch.net/test/read.cgi/gamedev/1009895922/l50

http://game.2ch.net/test/read.cgi/gamedev/1009895922/3

こんにちは、１の父です。
このたびは息子がとんだご迷惑をおかけしてしまい大変恐縮です。
つまらないスレを立てる暇があったら、
ムスコを立てて軸回転の勉強でもしなさいと
幼少の頃より３Ｄ英才教育を施していたつもりではあったのですが、
我が輩の目の届かぬところで、とんだ粗相を呈してしまい、この場を借りてお詫び申し上げる次第であります。

ageとかないと！

某ＨＰで今どきの常識テクが書いてあって、激しく鬱なんだが・・・
これ全部常識か？みんな本当にこれ全部実装できるのか？と小一時間問い詰めたい

常識TOP10
１.路面スペキュラ （GT3）
２.逆光エフェクト（ICO）
３.空気系歪み。陽炎、被写界深度（ボクと魔王以降、GT3、FF10、他多数）
４.陽光表現（ICO）
５.背景動画。ビデオテクスチャ（鬼武者）
６.草シェーダー（DOA3）
７.セルフシャドウ（AC4、ルイマン、SW他）
８.操作可能＆キャラ差替え可能なデモ（MGS2）
９.地形フルMIPMAP（SW）
１０.キャラがいっぱいはやっぱり面白い（真・三國無双2、あとピポザル2000も）

>>396
１、不明
２、視線ベクトルと光線ベクトルの内積が一定以上ならホワイトアウト？
頂点スペキュラ値が一定値以上ならその位置にキラキラテクスチャ？
３、動的ミップマップ生成＋頂点ずらし＋Ｚ参照ブレンド
４、Ｚ参照orαマスクでレンズフレアを調整
５、動画をテクスチャにするだけ
６、アルファチャンネルテクスチャ＋ずらし＋多重レンダリング
７、ステンシル＋シャドウボリューム
８、ようはリアルタイムＤＥＭＯ
９、ようはテクスチャ管理
１０、ようは高速化

理論的にはたいしたことはない気が・・・。

折れ的今年のトレンド
１、逆光、水滴、部分ブラー等のカメラ系エフェクト(MGS2,GP2)
２、屈折（光学迷彩とか）
３、半球ライティング、質感表現

>396
DAKINI氏が書いたやつね。
まあどれもそれなりにヒットしたゲームに実装されてたから、
これからやってもﾌｰﾝで終わりそう。
だから常識と言っていいかも。
1シーンでこれ全部実装したらそれはすごいが。

>>397
屈折は比較的簡単だから俺なら３。
やっぱり新しい光源処理系がいろいろ出てきたから
それを１番にしたいな。
逆光や部分ブラーは一年以上前のトレンドかな。

>>399
１の本質はカメラ特性系のエフェクトってことね。
逆光、部分ブラーはその表現方法の一つに過ぎない。

MOTOGP2とかで感心したのは、カメラに付いた水滴が
フォーカスによって変化するところ。
MGS2は水中から出るとカメラが曇って徐々に戻ったり、水滴が垂れたりと
凝りまくりで感心した。

重要なのは、どのイフェクトも
「なくてもゲーム本体は成立してた」
って点か。「あるにこしたことない」ものであっても
確実にプログラマーの時間と労力を消費するんで、製作側視点では
「そんなことしている暇あったら、バランス調整して欲しい」
って場面が多々ある。あとは、プログラマーの現実逃避ってとこか。

#ゲームにはもっともっと大切なところがいっぱい

まてまて。プログラマーってのはゲーム部分と
ＣＧ部分で担当が別れているだろ。
ゲームバランス部分を作ってるのはゲームプログラマ。
それにゲームバランスは企画の仕事じゃないか。
まぁ401の言う事はほぼ企画作った奴に対する
文句だと思うから別のスレでやれ。

1は>>396のTOP10を全部説明しろ。

401は２Ｄでゲーム作る事をお勧めする。

カメラのエフェクトよりカメラの挙動が気になる。
ライブ中継のような画面を出すには本物ののカメラ
と同様なズームや人間が撮影する時のブレとかが
必要だね。最近のゲームはだいぶ近づいて来た感じ。

>>401
重要なのは、どのイフェクトも
「完成度の高いゲームに実装されていた」
って点か。
結局、お前は技術から逃げているだけなんちゃうかと小一時間問い詰めたい。
なんだかんだ言って完成度高いゲームは新しい技術や表現への挑戦が随所に見られる。
プログラマの現実逃避ではなく、プログラマに向上心があるんだろうね。

まあ、それ以前にプログラマがバランス調整しているようなファミコン時代の制作体制に問題ありだが。

http://www.tirol-choco.com/
チロルチョコはｳﾏｰ。
漏れはチロルチョコとうまい棒食いながら
ゼビウスやドルアーガ遊んでた。

>>407
誤爆ｽﾏｿ

このスレに２Ｄオヤジが出てくると３Ｄ厨は必死に叩くな。

なんか3D技術にコンプレックスを持ってる奴が多いみたいだね。
高度な話題になると荒れてくる…。

>>409
今は2Dでも技術は進んでるぞ。
ここの2Dオヤジはファミコン時代から進歩していないと見える。

っていうかDAKINIページに挙がっていたベスト１０って、
むしろ純粋な３Ｄ技術ってわけでもないよね？
陽光表現だとか、逆行イフェクトとか、背景動画とか。

＞まあ、それ以前にプログラマがバランス調整し
＞ているようなファミコン時代の制作体制に問題ありだが。
悪かったな、俺もファミコン時代からのオヤジだ。
だがな、ＲＰＧなど、制作課程がある程度確立されているジャンルでも
ないかぎり、完全な分業制がかえって摩擦として働くことがあるんだよ。
っていうかオマエ、ひょっとして敵キャラのMaxHPだとかの調整を
プログラマーのバランス調整だとか感違えしてないか？学生？

>>412
パラメータ程度しか調整できないって何時の時代よ。
動き、思考とかゲーム内容に依存する部分は
ツールとかスクリプト作って
プランナーやグラフィッカーに投げるのが普通だろうが。

いい加減ファミコン時代の遅れた制作体制は見なおした方が良いよ。

(・∀・)っ∴ ｶｻｰﾘ ｼﾁｬｰﾀ ﾄｷﾊ ﾆｸｺﾌﾟｰﾝ

>>412
少なくとも完成度の高いゲームは分業は出来てると
思うぞ。うちでは昔からの２Ｄプログラマーが
ゲームメインを担当して新しく入ってくる数学とか
得意な奴が３Ｄの最新技術の導入を研究する感じ。

でも、昔のプログラマーは古いゲーム作りしか出来なくて
ＯＯＰとか３Ｄ技術が本当にダメな事が多い。
で、部下の方がプログラマーの能力が高くなってしまう
わけだが、その時は人をまとめる能力だとかゲームバランス
だとかに長けてると言い張るんだな。
そんでもって出来る奴らは転職を考えると。

>>409
>このスレに２Ｄオヤジが出てくると３Ｄ厨は必死に叩くな。
いや２Ｄオヤジがこのスレ叩いてるんじゃないの？
年寄りが若いのいじめるもんじゃないよ。

　　　　　　　　　　　　　　　　　|　ゴリュア！
　　　　　　　　　　　　　　　　　|　　　ゴリュア！／￣￣￣￣￣￣
　　　　　　　　　　　　　　　　　 ＼＿　 ＿＿＿|　　ダマレコゾウ！
　　　　　　　　　　　　　　　　　　　　 ∨　　　　 ＼＿ 　 ＿＿＿＿
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　 ∨
　　　　・・・・。 　　　　　　　　　　　　∧ ∧　　　　∧η∧
　　　　　　　　　　　　　　　　　　　　(,,・Д・)　　　(・Д・,,)
( ・∀・)　∴　　　　　　　　　　　　〜（＿_ﾉ　　　　　 ヽ＿__ミ

最近だと２５歳でも３Ｄ凄い出来る奴がいる。
うちでは２８歳ぐらいが主力になってる。
３０超えると２Ｄ亡者が多い。

激論！２Ｄオヤジ ＶＳ ３Ｄ厨房

こんなスレでも立ててやれ。

>>419
頼むからゲーハーかサロンに逝ってやってくれ。
ここは3D「技術」について語る場なんだぞ？

とか言いつつ俺も3D技術話できないのでsage

＞パラメータ程度しか調整できないって何時の時代よ。
＞動き、思考とかゲーム内容に依存する部分は
＞ツールとかスクリプト作って
＞プランナーやグラフィッカーに投げるのが普通だろうが。
やぱーり、それはＲＰＧだとかお決まりアクションゲーだとか
比較的工業製品部類に属するものにしか当てはまらんよ。
あと、思考部分をスクリプトに飛ばして、プランナーがその上で
作り込めるくらいの能力があるんだったら、そいつがＣ言語でも
いいから覚えてプログラマーなった方が、効率的だって。

ＤＡＫＩＮＩ記事が思わぬ波紋を起こしてるな（ﾜﾗ

>>419
作ったよ、隔離スレ。３Ｄ叩きはこちらでどーぞ。
http://game.2ch.net/test/read.cgi/gamedev/1010173039/l50

>423
分かってねーな。
「３Ｄ叩き」っていうよりかは
「３Ｄ出来たくれーで、線を引いてしまうバカ叩き」が
正確なところだろ？

それを隔離スレで話せばよかろう。

＞正確なところだろ？

同意を求められてもなぁ・・・・。
必死になって何かと戦ってるのでしょうか？

ＤＡＫＩＮＩってなによ？

424さんよ。誰を説得してるのかね。
震える手でキーボードを叩くのはその辺にしようや。

>427
セールス記録ばかりを気にする業界病患者。（末期症状）
その他、小手先技術全般などの観察ヲタなどの一面も持つ。

でも、最新情報を勝手に適当に集めてくれるので、利用価値は大。

＞４２８
ゴミ野郎にエサ与えてんじゃねーよ、厨房。

ここは
「出し惜しみせずに３Ｄの技術を誰かが答えます」
というスレです。

Bio_100%あたりのＢＢＳで「新◎」あたりに
「良く調べなさい」「過去スレを見なさい」などと
あしらわれた連中が2chに来るとか。

当然、カスっぱが集まるわな。

>>430

てへ。

「○坂」は確かに初心者に厳しすぎ。
ＤｉｒｅｃｔＸの使い方なんて通過点に過ぎないわけで
目的持ってる人にしてみれば、人聞きで済ませたい場合が
あるんだよね。たとえ過去ログにある可能性があっても。

ってこんなとこでコぼしててもしょーもないが

>433
早速、カス、発見

あ、えと、私はＭなので氏の突っ込みは快感です。

っていうかBio100のとこってなんで
教師ヅラする人が必ずいるんだろ？

影で因縁つけるのはよそうや。な。

眠い季節が再び来たようだ。

みんな、地球のあるべき姿を思い出そうよ！

>>436
別に、どこにでもいる。そんなのは。

>>436
無償で教師やってくれんだから感謝すれ。
懇切丁寧を求めるなら金払え。
bioBBSは情報交換の場であって、教えて君の場ではないぞ。

>>433=>>436

＞無償で教師やってくれんだから感謝すれ。
＞懇切丁寧を求めるなら金払え。
するかよ、ばーか。
教師ズラ説教するくらないなら、シカトしてくれよ。
それが、情報交換の場ってもんだろうよ。
親切気取りは手前だけだっつーの。

あなたは右手に自由を掴んだら、左手には何を掴みますか？

ここは
「出し惜しみせずに３Ｄの技術を誰かが答えます」
というスレです。

地球制服計画の一環として地球でもレンダリングしてみましょう。

でも、地球には毛が生えてません。

>>443
まともな情報交換の場にしようとすれば、馬鹿には厳くする必要がある。
質を維持するのは大変だね。

>教師ズラ説教するくらないなら、シカトしてくれよ。
シカトして欲しいなら二度と書きこむなよ、厨房。
お前みたいなのはゲー専にでもいっとれ。

age

くだらねぇ話をしてるなぁ


　

厳しくするより、盛り上がりそうな質問したほうがいいよ。
例えば………たとえば？

同次座標って誰が考えついたものなのですか？

今朝、夢で、看護婦姿した椎名林檎がボクに注射をしました。
深層心理を哲学的にこの夢を分析すると、ボクの欲求はどのように
解釈されるのでしょうか？
ちなみに注射針だけがテカテカ環境マッピングされてました。
フレーム数までは覚えてません。おそらく24bitカラーだったと思います。
解像度も覚えてません。

>>453
ゲハ板に帰れ
http://game.2ch.net/test/read.cgi/ghard/1008821688/-100

>453
俺はどちらかというと、注射されるより、したい方だな。
おっと、環境マップ属性は外してくれよな。
俺の注射はテカテカしてないんでね。むしろバンプで表現すると質感アップだ。
あと、妊娠中の椎名林檎より、矢井田の方が俺の好みだな。

>>452
19世紀の数学者

矢井田って妙にオバサン臭くねぇー？
肌のスペキュラー係数もイマイチだし。
おいら的に勃たないねぇー。

だったら、林檎のテクスチャを修正して、あのホクロを取って欲しいな。
したら、おいら好み。でも看護婦姿してても、股、蹴られそうだな。

スペキュラーを言い出したら、モー娘。系に逝くしかないだろ？
若さにはかなわねーよ。

そうじゃなくて、胸の揺れ具合はどうよ？
パイレーツが「目ぇー見て話せよ」とか言いながら
ＤＯＡの宣伝してからはや４年。

でもＤＯＡの胸揺れって、ありえねー揺れ。

今、ＤＯＡの宣伝すんだったら、叶姉妹ってとこか？

ところでパイレーツって今、生きてる？
合方の一人だけ、ダイエットに夢中に成り、そして成功したんだけど
オパーイまでダイエットに成功してしまって、パイレーツを
名乗れなくなったとまでは嫁さんから聞いたことあるけど。

でも、最近、◇で大量解雇された優秀なＣＧスタッフをもってすれば
ＣＧ修正なんて余裕だろ？おパーいのスケーリングなんて。

巨乳系というよりは美乳系が好みです。
なんでカクゲーに出てくるギャルキャラって、どれもこれも下品な
巨乳なんでしょ？

ＰＳ２で曲線フォーマットモデルを実現したメーカってある？
どこまで接近してもオパーイのポリが全く気にならない
レンダリングエンジン。

ところで
巨乳係数とロリ係数って一般に反比例な法則があるじゃん。
そのギャップを埋めるべくしてアイコラがあるわけで。
そんなアイコラ職人をも不要にした酒井若菜は最高かと。

＃接近しなくても十分に細かい気もするが・・・最近のかくげー。

＞そうじゃなくて、胸の揺れ具合はどうよ？
ただのバネじゃねぇ。
でも実物も基本はバネの筈なんだけどね。

＞パイレーツが「目ぇー見て話せよ」とか言いながら
＞ＤＯＡの宣伝してからはや４年。
そんなに立つっけ？あれってＳＣＥの広報が考えたＣＭなんだよね。
テクモから打ったＣＭは、ゲーム画面だけを見せるありがちなＣＭで
印象にないよ。

....胸揺らせば鉄拳にも勝てる

＞今、ＤＯＡの宣伝すんだったら、叶姉妹ってとこか？
Ｘ箱あたりだと、シミまで表現可能だな。それもバンプで。
熟年好み？

ちなみに「目ぇー見てるっちゅーねん！」って言ってたオヤジ、
都内の松屋で子連れで食いに来てたのを目撃したことあるよ。

オパーイは３Ｄ野郎の永遠のテーマ。

水野美紀ももうオバンだな。
「ちゅーして！」を流行らせたまでは良かったけど、俺には恩恵がなかった。
で、Ｃ社内部でも春麗（だっけ？）をエンディングで洒落で
ちゅーして！と言わせる話もあったらしいけど、ＮＧになったとか。

ってことで、女はやっぱ太股だろ？
あ、やっぱり曲線。
つーかさぁ、曲線モデル実装したメーカってあるの？

まだエロ系の3D技術はたいしたことないからねぇ。

＞ってことで、女はやっぱ太股だろ？
と同意を求められてもなぁ。
オパーイなら、俺は乳輪にこだわるな。
アイドル系が脱ぐ時、真っ先に確認するのが、乳輪。
大きさだとか、形なんて水着見れば予測つくしな。

菅野美穂が脱いだ時、がっかりしたよ、あの乳輪には。
結局、一回もヌかずに古本屋へ。

>>462
> でも実物も基本はバネの筈なんだけどね。

実物は猛烈に細かく見ないとばねで近似できないよ。
「粘性の高い液体が入ったゴム風船」
という表現の方が近いと思う。
ゴムって言ってもほとんど伸びないけど。
骨格と皮膚をちゃんと考えて
シミュレートすれば話題になるかもね。
(いやな話題)

＞まだエロ系の3D技術はたいしたことないからねぇ
ＤＯＡだとかイー線、逝ってると思うがね。
股で顔絞める技があったり、青少年の壷をうまく押さえてるよ。
ソニーも良く、許可したよね。

でも顔がロリなんだよなぁ。

いや、エロは接写も重要だからなぁ。

＞実物は猛烈に細かく見ないとばねで近似できないよ。
＞「粘性の高い液体が入ったゴム風船」
要は脂肪なんだよねぇ？
猛烈に細かくって、バネ何本くらい必要なん？
１００や２００でいーなら、今の「てくのろじー」で可能だね。

でも胸の揺れより、乳首の形状を見て俺はいつも勃ってる気が。ぴゅ

ちなみに、星野ひかる世代なオヤジだす、俺。

釈由美子と東幹久がベッドで絡むシーンがあったんだけど、
そん時、釈の乳首がポロっと出てた。星野ひかる系だった。

4/1のエイプリルフール企画なんで作り物だったわけだけど
番組じゃ「盗撮」という設定だったんで、８ミリビデオカメラの
映像をそのまんま放映。修正くらいしろよ！

なんでもサンタフェは１００万冊売れたらしい。
流石にインフレで、大量に使用済みなサンタフェが
中古本市場に流れたらしけど、当時、上司に、
リエなんかに負けるな！と発破をかけられたものだよ。

まー、実際、比較的簡単に勝てた古き良き時代だったんだけど。

>473
青少年の大量な蛋白質が消費されたわけですな。
流石、消費大国ニッポン。
アメリカじゃ、精子バンク会社があるので、そこに売りつけると
いくばくか金になるよ。っていうか、それでホームレスから
離陸したツワモノもいるくらいだ。（ジャップせーしが売れるか
どうかは知らんが）

当時、スーファミでＲＰＧ作っててね。
部署がかりで徹夜して半年かけて制作しても、ハタチいかない小娘が
ちょろっと脱いだ売り上げに適わないのにはショックだった。

「おまえらも脱いで稼げ」というつまらん冗談を女性社員にも投げたさ。
セクハラなんてコトバもない時代。

＞いや、エロは接写も重要だからなぁ。
となると、PS2は不利と・・・。
別に同時に何体も表示するもんじゃないからな。
こういう時、PS2は可哀相だな。

↑をーをー。ＤＯＡも酷だよな。同時発売タイトルからして
何をレンダリングさせるんだ！とＧＳも嘆いているYO

＞釈由美子と東幹久がベッドで絡むシーンがあったんだけど、
＞そん時、釈の乳首がポロっと出てた。星野ひかる系だった。
ちょっとまてーー！そんな映像があったんか！ﾊｧﾊｧ。
つーかなんで東幹久？？
ワンダフル繋がり？

＞実物は猛烈に細かく見ないとばねで近似できないよ。
＞「粘性の高い液体が入ったゴム風船」
＞という表現の方が近いと思う。
＞ゴムって言ってもほとんど伸びないけど。
＞骨格と皮膚をちゃんと考えて
＞シミュレートすれば話題になるかもね。
＞(いやな話題)
楽しそうに、いやな話題を展開してるな（ﾜﾗ
ここは一つ、kanOクンにシミュレートして貰いますかね？

>>477
有名すぎる映像だ。WinMXで簡単に入手可能。
釈由美子と言わず、ワンギャルのものでいいならば、
編集前映像が結構、流れてる。
全然カンケーないが、東フェチな友人（女性）が、昨年の
１０月に放映された「ヌード爆弾」の撮影時に使われた未修正映像も
ゲットしてた。スティックまる出し映像。
己との比較用にどうぞ。（漏れは負けた）

＞↑をーをー。ＤＯＡも酷だよな。同時発売タイトルからして
＞何をレンダリングさせるんだ！とＧＳも嘆いているYO
何をいまさら。
PS2が売れた最大の理由は、中高生でもエロＤＶＤを見れた点だ。
レンタルすると、エロっぽさがなくなる上、場所もとらない。
購入しても、ＣＤスタンプで偽装可能。
親世代はただのＣＤと誤認。

曲線補完でオパーイはレンダリング可能か？

＞アメリカじゃ、精子バンク会社があるので、そこに売りつけると
＞いくばくか金になるよ。っていうか、それでホームレスから
＞離陸したツワモノもいるくらいだ。
T10000を渡された時、初めて表示させたのが「せーし」だったよ、おれ。
その後、何匹表示できるかで、ちょっとしたベンチマークがわりに。
もちろん繊毛もエロく、動くぞ。

しかし、精子が換金できるのは初耳だ。
脱ホームレス可能なくらいの稼ぎがあるなら、普通の社会人でも
小遣い稼ぎにはなるのか。

ｺﾞﾙｧ　MXで落としたけどｵﾊﾟｰｲ出てねぇぞ
つか、胸ポロするようなふくじゃねぇだろ　ｺﾞﾙｧ

↑そんな錬金術があったのか。ｼｺｼｺｼｺ。
いいねぇ、シコってるだけでメシ食えたら。
レンダのチューニングなんかしてる場合じゃないよ、まったく

※ちなみに星野ひかるなら、池袋で目撃したことある。
フライデーにタイ焼き屋でバイトしてるとこキャッチされて以来、
消息不明だっただけにラッキー♪

>481
君のベンチマークに出てくるセーシ君たちの色も
金色に輝かせなさい。

＞ｺﾞﾙｧ　MXで落としたけどｵﾊﾟｰｲ出てねぇぞ
＞つか、胸ポロするようなふくじゃねぇだろ　ｺﾞﾙｧ
ここは・・・

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

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

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

＞T10000を渡された時、初めて表示させたのが「せーし」だったよ、おれ。
＞その後、何匹表示できるかで、ちょっとしたベンチマークがわりに。
＞もちろん繊毛もエロく、動くぞ。
おい、おめーが誰だか分かったよ。スペグラマーが！
つーか２ｃｈで書いていいのか？誰が見てるか知らんぞ。Ｏ埼！

２Ｄオヤジが荒らしまくってるな。
２Ｄの時代は終わったんだよ？
そんなに３Ｄの時代が嫌なら首吊って氏ねば？

星野ひかるを語れるのはオヤジの証拠。

しかし、こんなにもスレてしまった２Ｄオヤジと
仕事なんかしたくないな。
がんばることを止めたマターリオヤジどもは早く
辞めてってくれないかな。
見てて情けない＆みっともないよ。

経営サイドの人間がこのような事態に目を向けて
２Ｄオヤジをリストラしてくれる事を望む。
若手のモチベーションも上がる事だろう。

＞T10000を渡された時、初めて表示させたのが「せーし」だったよ、おれ。
＞その後、何匹表示できるかで、ちょっとしたベンチマークがわりに。
＞もちろん繊毛もエロく、動くぞ。
ひょっとして、seisi.elfの作者さん？

やぱーり、ＰＳ２は厨房のエロ再生機だったのかぁーはぅ。
いや、薄々、予想はしてたんだけどねぇー。
ハード売れてるわりには、ソフトうれてねーなぁーって。

とかいって、俺もＰＳ２使って妻に隠れて、
優香のＰＶで一度だけヌいたけどさぁー。ドキュソ！

テクスチャをレンダリングしている時間よりも、
吉田潤や加藤鷹を描画している時間の方が
圧倒的に長いＧＳって全国中にあると思うぜ。

かわいそうに・・・。

>>493
悲しくなるからよせよ！

>>493
ﾜﾗﾀ。だがおそらく事実だろうな。

吉田潤は引退してるＹＯ！
sage

>>497
え？あのオヤジ、遂に引退したの？
斎藤竜だとかは、まだ現役なの？
まぁ、そのへんのミーハーＡＶ男優は折れ的にお呼びじゃないけどね。
特に加藤鷹なんか、ヘドが出る。同じ秋田出身だが。

お薦めはヘンリー・塚本監督作品。

サゲ。

バカがまだやってるよ。

>>498
お前、ヘンリー塚本って言いたいだけちゃうんかと。
AV通の俺から言わせてもらえば今、AV通の間での最新流行はやっぱり、
クリスタル映像時代の村西とおる、これだね。

>>483
今すぐＡＶ板の星野ひかるスレに来て星野ひかる目撃情報を詳しく報告して！
http://www2.bbspink.com/test/read.cgi/avideo/1006657499/l50

塚本晋也監督かと思ったよ

■■■■■■■■■■■■ 終了 ■■■■■■■■■■■■

>>クリスタル映像時代の村西とおる、これだね。
んー。そうかなー。
ただ単に下品なだけだと思われ。
それにしても、ps2のAVマシン率ってどれくらいなものなんだろう？
DAKINI先生に分析してもらうしか。。。

すいません、ここまでの話題でどこらへんが３Ｄ技術の質問？？

お前ら雑談スレに逝け、と。
http://game.2ch.net/test/read.cgi/gamedev/1005039431/

あわれ２Ｄオヤジども。
時代について行けないうえに他業界にも行けない。
リストラは氏を意味するね〜。

粘着さんよ、これ見てﾏﾀｰﾘしとけや。
http://www2.odn.ne.jp/~aaq77600/unix.swf

■■■■■■■■■■■■ 終了 ■■■■■■■■■■■■

次のスレ名どうする？
立てるのは粘着が去ってからだけど。

ずいぶんと先の話だな

>すいません、ここまでの話題でどこらへんが３Ｄ技術の質問？？
美しい女体は常に熱血３Ｄ野郎のテーマさ。
とりあえず、ＤＯＡの乳揺れの解析でも続けろや。
っていうか、いるんだろ？ここにも。テクモのプログラマーさんよぉ。

PS2のおかげでエロDVD市場が爆発的に広がったのは事実。

どーでもいいけど、一人、「２Ｄオヤジ」というキーワードを
無理に流行らせたがっている人が一名。
もし君のまわりが２Ｄオヤジだらけなんだとしたら、君の今のその位置も
問題あるよ。たとえ君ができるとしてもね。まわりの２Ｄオヤジをどうにか
してどかしたいエネルギーがあるんだったら、君一人だけの居場所を変えた方が消エネだよ、きっと。

明日から３Ｄ以外にPerlも勉強します。

>明日から３Ｄ以外にPerlも勉強します。
じゃ、おれはRubyでも勉強します。
パールといい、ルビーといい、女への貢ぎ物を連想させるよ、全く。
いや、貢ぐ・・じゃない、投資はいいんだ。問題は、その投資物をそのまま他の男へ持っていかれるところが欝。
え？いいから妄想なら雑談でしろってか？こりゃ失礼。

>PS2のおかげでエロDVD市場が爆発的に広がったのは事実。
永久保存版星野ひかる全集ＤＶＤが30万本だってさ。
ほとんどのPS2ソフトが負けるよ。とほほ。って、漏れも買っとるやんけー！

下ネタオヤジにRubyがわかるわけ無いだろ。
頭悪すぎて荒らす事しか出来んくせに。
荒らしの文章から３Ｄできねー奴って事がよくわかる。

>PS2のおかげでエロDVD市場が爆発的に広がったのは事実。
おっと、ＤＡＫＩＮＩさんのお出まし？
皮肉ではないですが、
逆に「エロＤＶＤのおかげでPS2普及を爆発的に広がせたのは事実」かと。
厨房にはナイスな偽装マシンなわけですよ。
試しに「ps2 エロＤＶＤ」でgoogleで検索してみてください。
実にいろいろなナマの使用例を伺えます。
ある意味、「えもーしょん・えんじん」の名前に恥じない名器じゃない、名機と
して歴史に名前を残す、いや残したと言えるでしょう->ps2

バカがageてID出してるよ。

＞下ネタオヤジにRubyがわかるわけ無いだろ。
＞頭悪すぎて荒らす事しか出来んくせに。
まぁ、ﾏﾀｰﾘとな、ﾏﾀｰﾘと。

粘着さんよ、これ見てﾏﾀｰﾘしとけや。
http://www2.odn.ne.jp/~aaq77600/unix.swf

粘着さんには、こんなのもお薦めだよ！
http://www.mars.dti.ne.jp/~misapapa/1rep/bule.jpg

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

ほりーゆーじ？

では、2Dオヤジから2D問題

与えられた2次元3頂点 (x0,y0) (x1,y1) (x2,y2) が
時計周りであるか否か？の最短調査関数を作りなさい。

int chk(int x0,int y0,int x1,int y1,int x2,int y2){
}

で、もし時計まわりなら、1を返却してください。
なお、３頂点セットの構造体を定義し、その構造体のポインタ一つを
引数にすりゃいーじゃん！というツッコミは認めません。

3D青年なら2D問題は楽勝ですよね？

あ、しまった。
与えられた３頂点が直線上に並んでいる時は-1を返却してください。

外積とか使うと、遅すぎるっていわれちゃうのかな？

続いて、ニセ３Ｄオヤジからニセ３Ｄ問題。

ゲームプログラミングにおいて、
逆行列ではなく、転値行列で事が済むような場面を一例としてあげなさい。

※抽象的な問題でスマソ（いや、他の人はどんな場面があるかなぁ？と参考にしたかったもので）

転置行列では？

題意が良く分からんけど、基本的に行列が正則なとき？

別スレ立てて仕切り直した方がいいのでは？

気にするほどのものでもない。

あ、このスレのままで構わないという意味ね。

２Ｄオヤジ連呼クン、ひょっとしてバックれた？（笑）

>>529
逆行列 ＝ 転置行列 ⇔ 行列式 ＝ ±1 ⇔ 正規直交行列

>>529
つーか、転置行列の方がよく使うような気も・・・

確かに転置行列のほうが良く使うよな。
シェーダーとかでも使うし。

>>535
2chで（笑）を使うのは２Ｄオヤジ世代だな。

正規直交行列だと分かりきっている時は転置で済ませる。

>>2chで（笑）を使うのは２Ｄオヤジ世代だな。
禿同。時計周りか否かのリトマス紙を２Ｄオヤジに見せたれや。

隠れ２Ｄオヤジと自称２Ｄオヤジが入り混じって
いるような気がするよ。
よくわからんがもう少し難しい問題だせよ。

で、時計回りの判定の答え教えて

>543
外積で一発だろ。
首吊って氏ね。屍ね。刺ね。

ばーか　外積なんか使うわけねぇだろ
もっと早い方法があるんだよ
これだから、似非３ｄ野郎はしょうがねぇな

>ばーか　外積なんか使うわけねぇだろ
>もっと早い方法があるんだよ
>これだから、似非３ｄ野郎はしょうがねぇな
ないです。今時のハードなら外積の符号判定が一番速いです。

>545
ひょっとして１０年前からタイムスリップしてきたん？
２Ｄオヤジが若造りしても、すぐにメッキが剥がれるな（藁
いいから引退しろよ、オヤジさん

↑2Dオヤジに餌を与えないように!!

そろそろ時計回り判定のソースＵＰきぼんぬ

>>545
そ　の　方　法　を　だ　せ
説　得　力　が　ま　る　で　な　い

>>545
積算２回、減算５回 以下の計算量でマジで出来んの？
それともやっぱネタ？

　いつからここは「出し惜しみして自分が知っていることを
自慢するスレ」になったの？上じゃ2Dや3Dの問題とか
出されてるし。

{
　if( ( x1 - x0 ) * ( y2 - y1 ) - ( y1 - y0 ) * ( x2 - x1 ) < 0 )
　　return 1;
　return 0;
}

http://www.cc.rim.or.jp/~devilman/3dCoding/3dPlane.html
http://www.cc.rim.or.jp/~devilman/3dCoding/3dPers.html
これを参考に疑似無限平面をつくってみたんですがうまくできません。
教えてくれる人いますか？
いたらアプレットとソースをうｐしますので。

旗のはためきやパンチラに必要な　”風”　のモデル化　ってどうすればいいのかなぁ〜
おしえ下さい。いや教えやがれ　おながいします

数フレームおきにランダムで風に力を与えてやって
その風は常に力が減少するようにしとけばどう？
それとももっと物理シミュレーションっぽいもの？

>>554
どうダメか書いたら？

http://www.geocities.co.jp/Playtown-Queen/8761/
左のほうが歪みます

>>550
１０年前のパソコンは16ビットだ
面積なんぞintで計算したらオーバーフローしてしまうだろ
longやfloatで掛け算など論外

>>559
そんな特定の場面でしか有効でない物に何の意味があるんだよ！
って展開になりそうな予感。

>>559
２０年前は８ビットだぞ！どうしてくれるんだ！

>555
　厳密に流体を計算するのは無茶だから、
質点に力が作用するようにすればどうかなぁ。
というかそれはありがちだよね？

　布の平面の法線と風向きで内積を取った
絶対値を力にかけてやれば、何となく布の
角度も考慮される、見たいな。

>>561
ワイヤーフレームでガマンする

>>558
ソース出せば誰か見てくれると思うよ。

そうだよな。見ただけじゃわからん。
ポリゴンがおかしいのかテクスチャがおかしいのか
判断できんし。

>>558
左側だけでなく全体が歪んでいるように見える。
これはこれで面白い非線形変換だな（藁

大体、２Ｄ平面での３頂点が時計周りか否か？なんて、何の用途に使うよ？
流石、２Ｄオヤジらしい問題だな。

>>567
１０年前の３Ｄポリゴンでは必須だぞ
頂点や面毎に法線データ付けるなんて贅沢なことはできなかったんだ

３Ｄだと当たり判定でポリゴンの正面からか裏からか
判定する時に外積とか内積でやるね。
内積とかはシェーダーだと１クロックだから最短
とかって難しいね。

>568
逝ってる意味が良く分からないのですが？
何の用途に使うか知らないですけど、
欲しいのは３Ｄ法線ベクトルじゃないですか？

>>568
今の３Ｄ厨房はＰＳやDirectX以降の若手だと思われ。

＞今の３Ｄ厨房はＰＳやDirectX以降の若手だと思われ。
そりゃ、おめーだろ？
10年前の計算亮ならば、法線データは是非とも付けておくべきだ。

>>大体、２Ｄ平面での３頂点が時計周りか否か？なんて、何の用途に使うよ？
>>流石、２Ｄオヤジらしい問題だな。
激同。

亮

>>568
メモリが恐ろしく貴重だったのはもっと前の時代だが、、、
言ってることは和歌瑠。

572のように若い奴に言うのも無駄だし意味無い話だが。

572は２Ｄオヤジの臭いがする

あのさー、例えばさー、ライトマップなんかを生成するとしてさ、
ＵＶの自動割り当てとかってどういう感じでやります？
１ポリゴンごとにテクスチャ１枚で解像度固定、
とかアホな方法でやったら、案の定ダメダメだった。

＞１ポリゴンごとにテクスチャ１枚で解像度固定、
＞とかアホな方法でやったら、案の定ダメダメだった。
ｎポリゴンをテクスチャ１枚ではなく？
何がダメだったの？

あのさー
加藤鷹の潮吹き環境マップ・パーティクルをやろう
としたんだけど、案の定、ダメダメだった。

>579
そりゃダメだろ、どう考えたって。
AV女優系だと上手くいくよ。

で>545の方法が気になるんだけど・・・

安住穴「続いては好評ピーコさんのコードチェックです。今日はゲ製作板にお邪魔しました。」
オヤジ「ピーコさん何時も見てま〜す。今日は私の大好きな16bitコードでまとめてみました〜。甘口でおねがいしま〜す。」
ピーコ「もうっどうしたら今時こんなコードがかけるのかしら。ワタシこういう人には3Dについて語って欲しくないのよっ。」三雲「あらでも小数なんて全部固定小数点処理ですよ。凝ってるわね〜。」
ピーコ「float演算使わなければステキなコードとは限らないのよっ。社内で浮きまくりじゃないのよっ。こういう人にはGBAがよく似合います（藁」
安住穴「ご協力頂いた皆さんどうも大変失礼しました。続いては糞コード改造計画です。」

>>582　ﾜﾗﾀ　面白い

またまた、おすぎです。
最近ちらほらと「面白い」と書き込んでくれる男の子がいて、モニターの前で嬉涙が一杯になりました。
煽られ叩かれても、しつこくｼﾞｻｸｼﾞｴﾝ、絶対お勧めです

>>579
パーティクルに環境マップするの？なんで？
水しぶきだから屈折マップとかするってこと？

ＩＭＥの手入れくらい、きちんとしておけ >>ミズ

>>558のソースあげました。
http://www.geocities.co.jp/Playtown-Queen/8761/source.txt

間違えました。こちらです。
http://members7.tsukaeru.net/calpara/chinko.html

>587
73行の、
＞float iDeltaV = itopDeltaV; float diDeltaV = (iendDeltaV - itopDeltaU) * iydiff;
この部分の「itopDeltaU」は「itopDeltaV」な気がする。
ソースは全然読んでないから分からないけど。

>588
一瞬信じちまった・・・鬱

>>589
そんなミスをしていたとは。全然きづきませんでした。
なおしたらうまく行きました。本当にありがとうございます。

>>589
気がするってだけで直してしまうとは。
おれ解析する暇もなかったよ。

>>585
パーティクルに環境マップは変だろ。
パーティクルってスプライト使用するだろうし。
でももしやるなら半球状のポリゴンが必要か。
環境マップよりバックバッファいじった方が速そうだが。

同次座標が便利な場面って？

今頃になって気が付いたんだが、俺、ネタにマジレスしてた？（；；）

>今頃になって気が付いたんだが、俺、ネタにマジレスしてた？（；；）
加藤鷹が出た時点でネタじゃなかったら、一体、なによ？って感じだよん。
でも、水滴が吹き出すシーンってあながちゲームでも使用される可能性あるね。

ちっ、ネタにマジレスしてネタ枯渇解消狙ったのに。
でもさネタがレベル低すぎて話が発展しねーよ。

ネタにレスする方の事も考えてネタ振って欲しいYO。

じゃ、アレジの奥さんが聞いている、便利な場面とやらを教えてやれや。
いいネタだと思うぞ。

で、外戚を使わない右回り判定の答えはまだか？

外積ね

水滴と言えばＭＯＴＯＧＰ２のカメラにつく水滴がいい感じだよなぁ
デモを見たときはビビッた。しばらく見とれてたよ

http://gamespot.com/gamespot/stories/screens/0,10865,2833942-10,00.html

>>599
どうでもいいよ、くだらねえ。

>>599
アレはネタだから…

時計まわり？は、いいよ、そんなもん。
３Ｄ厨房って基礎力ないことが分かったし。
と、同時に、横文字並べて識者ズラしている人たちモナー。

atan2(y1-y0,x1-x0) - atan2(y2-y1,x2-x1)

>605
ネタでもツマラン。

>>605
昔ミサイルが追っかけてくる2Dゲームでそれ使ってたな…
しかもBASIC.... 高校時代の恥である。。。

>>だから答えかけって。おながいしますよ

＞608
実は単に外積のＺ項デシター。俺様２次元しか考えられませんの
でー、っていう結論だったりしてｗ

片方を９０度回転させて内積の符号で判定する、式は同じ

>610
ハ？１０年前のマシンでcos使うの？
外積のほうが速いに決まってんじゃん、そんなの。

>>611
アホ？　XとYの入れ替えだ

>610
>609の言う通りになったな（藁
　　ﾊﾊﾊ
　 ∧＿∧　　／￣￣￣￣￣￣￣￣￣
　（　＾∀＾）＜　　ｱﾎか、首吊って氏ねよ（ﾜﾗ
　（ つ ⊂ ）　＼＿＿＿＿＿＿＿＿＿
　 .）　 ）　）
　（_＿）＿）　　　　　（＾∀＾）ｹﾞﾗｹﾞﾗ

がっかり。密かに期待してたのに。

まぁ、でもいろんな視点でも物を見ることは重要だよね。
少し感謝。実はおもろいこと思いついた。

ｓｈａｄｅユ−ザーは、業界では、相手にされないのってほんと？？

開発では使わないけど新卒の人なら大目に見るよ。
MacのMayaで無料版が出たようだからそっちやれ。

そんな特定のソフトの使い方を知っているかどうかなんて重要なの？

http://www.aliaswavefront.com/en/Community/Special/ple_announce/index.html
これだよね。$5+送料。2月から。

>>618
使い捨て要員には…ｗ

ゴミ箱の中からでも宝物を見つけられる奴こそ、伸びる人材なんだ
ろうな。と、ここ見て素直に思った。

>>617
Win版もでるみたいよ。

おお、そうすっとこれからはMayaの時代か？
プログラマーとしてもSoftImageが終了したら
どのツールに付くかで自分の将来に少し影響するから
気になるよ。

もうプラグ印とLScript含めて慣れすぎちゃったので LightWave
から離れにくいよー。

業界でLightWaveってまだ使ってるとこあるのかな。

>>624
3DSMAXとMAYAはプラグ印書き易いよ〜。
スクリプトもどっちも充実してるし。
Lightwaveはモデリングデータとその他のデータ（プログラムも）
が分断されすぎていて、個人的には今となっては使いにくい。
ウチのまわりでは、一部の人のモデリング専用ソフトになっちゃってます。

今XSI使ってるプログラマの感想キボンヌ。

うーむ。甘えちゃっていいでしょうか？
MAXとMAYAのSDKってWeb上にありますか？
今のうちに高速リーディングしておこうかと。

>>627
WinMXで探せばあるだろうが、ソフトで飯食ってるんならやめた方がいい。
素直に代理店通して評価版を借りるなりすれば？

了解。
俺も割れは大嫌いです。
どうもありがとう。

WinMXでも割れは見つかるのか。
おれは海外サイトで見つけたけどね。3.0を。
周りのデザイナに使わしてみたらみんな本物を
買っちゃったよ。

あ、MaxもMayaも両方とも3.0見つけたし
Mayaも何人も買ってるって事ね。

著作物で飯食ってるくせに割れ使う奴は給料払われなくても文句言うなよ

CGイタ逝け

割れ厨UZeeeeeeeeeeeeeeeee!!!!!!!!!!!!!!

４Ｄ青年の皆様。同次座標で便利な場面を教えてください。

今日、埼京線に乗っていたら、手のひらに
「パンティ３０秒タッチフリー￥３０００」とマジックで
まんが字で書いてた女子高生が誘惑してきた。
世の中なんでも金で買えるもんだと改めて痛感。

>>635
昨日はありがとさん。って違う人かな？

>>635
全部積で済むってだけじゃ不満なのか?

>全部積で済むってだけじゃ不満なのか?
↑3Dｵﾔｼﾞ、ﾊｹｰﾝ

>>>635
>昨日はありがとさん。って違う人かな？
えっと、どなたでしょうか？
ちなみに私は「２Ｄオヤジ」というハンドルの
人とは別人です。

きるがーどせんせいにきいてみよう

クモの足みたいな３間接のＩＫってどうやるの？

３回イテレーションするのでは問題があるの？

VectorとPoint（点or位置ベクトル）クラス分けするかい？って話、
flipCodeでやってる模様。
http://www.flipcode.com/cgi-bin/msg.cgi?showThread=00001903&forum=general&id=-1

#define Vector Point //これでいいじゃん

>>645
インテリセンス効かなくていやん。
class Vector : public Point{};
きぼん。

＞(1)Vector3D, Line3D, Plane3D, ...
＞(2)Point3D, Line3D, Plane3D, ...
＞(3)Vector3D, Point3D, Line3D, Plane3D, ...

(1)

登録無料
http://sawayaka.mariansela.com
http://sawayaka.mariansela.com
http://sawayaka.mariansela.com

>>645,646
継承の向きとして、
class Point: public Vector{};
の方がいいんじゃないか。
気分によっては、Vector→Normal もやるかも。
Vector→UVってのもやることあるけど、これは要素が一つ余るのがちょっと気持ち悪い…。

というかPointだのVectorを継承うんぬんは頭が弱すぎだと思う。
単純に４つの変数をパックした構造体を用意すればよいのでは？

>>649
C++での話だけど。
独自のoperator関数を大量に書く事になるクラスに
なんかいやーんな事にはならないか？

以前それでpointもvectorも独立したクラスに直したよ。

>以前それでpointもvectorも独立したクラスに直したよ
もろもろの演算時に、キャストだとか面倒になることありません？

やはり、分けるのが馬鹿では？

>>653
せっかくだからもっと詳しく。400字詰め原稿用紙２枚ほどで。

なぜvectorとpointに分けたくなるのか400字詰め原稿用紙２枚ほどで説明して欲しい。

typedef Vector Pointじゃダメなの?
継承するのは概念としておかしいような気がする。

Vector に４＊４行列をかけるときは、４行目の成分を無視して
計算できるから、最適化がかけ易い。
とくに、Vector と正規直交行列（座標系）の逆行列を掛けるときと、
Point と座標系を掛けるときとでは、計算量がぜんぜん違うから、
それらを違う関数で定義したいわけなんじゃないかな。

>>657
？？　厨房な俺には理解できんが、概念上違っても実用上
同じものじゃないの？

座表系間でvectorとpointを変換をする場合、
期待される答えが違うでしょ。

>>656,>>658

がいねん【概念】
http://dictionary.goo.ne.jp/cgi-bin/dict_search.cgi?MT=%B3%B5%C7%B0&sw=2

たとえば、ローカル上のある点Pをワールドにするときは、
ローカル座標系がワールドのどの位置にいるかの情報が必要。
だけど、ローカル上のあるベクトル（方向のみ、速度とか）をワールドにするときは
ベクトルに位置情報はないから、ローカル座標系の位置情報は無視できる。

って、言葉でいっても分かりづらいな…
ちなみに、あるローカル座標系を表す４*４行列Aがあったとして、
Vector * (Aの逆行列)と、Point * (Aの逆行列)では、計算量はPointの方が
行列演算１回分多いから実用上ちがうぞ。

なるほど、コンパイラに自動でやらせようってことね。
どーも旧石器時代の俺は明示的に指定しないと落ち着かないので
結果として実用上同じなのです。欝。

>なるほど、コンパイラに自動でやらせようってことね。
なんだよ、そこが問題だったのか。ちょい鬱

やりたいことは分かったけど、継承するのはやっぱ違う気がする。

class Point{
　Vector pos;
　// いろんな演算
　operator Vector() { return pos; }
};

ではダメ? いちいち演算子を書き直すのがうざいとか?

テクスチャ付き三角形ポリゴンのクリップについて、
解説してあるサイトがあれば教えてください。

あぁ俺もポリゴンクリップ＆分割ってよくわかんないんだよなぁ
DXでは(自前演算でもなきゃ）必要ない話でしょ

>>664
違う気がしても便利なんだから継承でいいと思うけど。この辺は。

>>666
使っているAPIがGlideなもので(藁

５面でクリップすると最大＋５頂点増えるわけだよね
DXの場合どうバッファを持つのか悩んだりした(最悪数倍にポリゴン数が膨らむわけで）
STRIPとか組んであるとどうなるんだ？

後、実験した事ないんだけど、クリップ時のUVってパース考慮されてんの？
スクリーン平面に変換後クリップだとZ情報なくなってるからダメだよね？

俺はvectorとpointというよりも、ベクトルと同次ベクトルで分けたいな。

分けるならvecmathみたいに、何の意味も持たないただのスカラーの集まりの
基底クラスから派生させるのがいいんじゃない？

このスレの名前良いね。
大した技術もないのに出し惜しみする奴多いよなぁ。
特に梅汚とかあの周辺の奴ら。

イヤミはタップリ書くくせに、答え書かない奴とかな

同じ手間なら答えの方かけよ

答え書けるわけないじゃん。
分からないんだから（プ

ﾏｧﾏｧ

ﾊｧﾊｧ

>>671
むしろたいした技術がないから出し惜しみすると思われ。
私見だが、真面目に技術の研鑚に勉めてる連中ってのは、
オープンにした過去の技術を下の連中がありがたくいただいている間に
さらに上に登ってくような印象がある。
ある意味エサっていうか囮っていうか。
しもべが多ければ多いほど自分は上位を維持できる構図。

とか余計なことを考えてる俺はたぶん最初から終わってるわけだが。

polygonのclipは大した技術じゃないんだから(?)、教えてほしいデス。

>677
たいした技術じゃないけど、面倒な技術。
場合わけでもすれ。

海外の凄い人達にくらべると日本人はみみちぃ。
自慢ばかりで参考になるページも少ない。
そろそろ潰したら？ってとこも多い。

　自慢は多いね。それはそれでいいんだけど、もっと
人を感動させるぐらいのことを自慢してくれ。

>>679
文句ばっかいってないで自分が提供すれ。

＞海外の凄い人達にくらべると日本人はみみちぃ。
＞自慢ばかりで参考になるページも少ない。
そう？まぁ、俺は自慢欲満たす割合が少なからずあってＨＰ開いてるけど
やっぱ、せっかく作ったものは不特定多数の人に見てもらいたいという
人情は誰にでもあるとお盲が。

>>679
そもそもホームページ自体自己満足みたいなもんだろ。
俺の場合は就職活動用に、ご丁寧に情報を載せてるけど、
就職したら、潰すか、自己満足ページに切り替えるよ。

自慢と批判が多いね、2chと変わらん。
ま、人間の本質ってことだ。

傲慢と嫉妬

>>682
不特定多数に見てもらいたい気持ちも分かるが
ソースも出さずにEXEだけ出してる単なる
自慢ページは見る方としてはむかつくだけ。

>>686
それは単なる妬みでは？
そのＥＸＥをネタにＢＢＳにでも書き込んむか、メールで問い合わせてみれば？
まあ、まともに議論できるだけの知識があればの話だけどネ。

どうせコピペしかできんのでしょうが。

スレの流れがまずい方向逝ってるんで修正。
クリッピングは？出し惜しみせずに答えて下さい。

>>688
Dycoon氏のページにニアクリップの記事があったはず。
俺はそれを参考に作った。
ローカル->ビュー行列にクリップ行列かますと、
視錐体内のオブジェクトはX-1〜+1,Y-1〜+1,Z0〜1の範囲になるので、
範囲外の頂点をクリップすればよし。

>５面でクリップすると最大＋５頂点増えるわけだよね
>DXの場合どうバッファを持つのか悩んだりした(最悪数倍にポリゴン数が膨らむわけで）
クリップ平面をまたぐポリゴンは、別エリアに分割ストアして後でまとめて描画
そのまえにバウンディングスフィアで大まかに判定して、
1.完全に視錐体外、2.視錐体境界をまたぐ、3.完全に視錐体内の３つに分類。
1は除外、2はクリップルーチンを通す、3はそのまま描画すればなおよし。

>STRIPとか組んであるとどうなるんだ？
クリップ対象の面だけSTRIPからLISTに変換して別エリアに分割ストア

>後、実験した事ないんだけど、クリップ時のUVってパース考慮されてんの？
>スクリーン平面に変換後クリップだとZ情報なくなってるからダメだよね？
パースペクティブコレクトテクスチャマッピングの場合、
変換してもrhwが残ってるから問題なし。

俺って親切？

(・∀・)ｶｺｲｲ

Dycoon氏はかなり昔から、ニアクリップの必要性に注目していた
数少ない人。というか、テカテカ映り込ませるより、こっちの方が
重要だったり。ゲーム制作現場では。

ＰＳの時にクリップ関連の公式（？）資料は山ほどあったけど，
全部前の会社に置いてきちゃったよ。
セミナーの本だと思うが，黄色い奴とか・・・
当時は「３Ｄ？ハァ？」だったから見てなかった。
今見れば有効活用できそうなのに。鬱出汁脳

平行投影でやっているのですが、視点をグルグルーっと回るように回転させたいのです。
視点が右手座標で（０，250，０）にあった場合、
ぐるぐるーっとｘ−ｚ的に回転させるには、視点の座標をどういうふうに計算すればよいですか？つまりタクティクスオウガのようにです。

PS1の頃、ｓｏｎｙは発展途上２Ｄ会社に対して暖かかったよねぇ。
それが今じゃ・・・

>692
おまえが知らないだけでニアクリップなんか大昔からソースあるよ。
Dycoonのページ見たけど参考文献見ながら出来の悪い再生産って感じした。
ただのコピペ野郎だな、残念ながら。

映りこみとかユーザーにとってはどうでもいいことを技術者って追求するよね。

>>696

一行目は事実ですな。
残りは、一言多いjan

＞映りこみとかユーザーにとってはどうでもいいことを
＞技術者って追求するよね。
リアルなティーポットをレンダリングするのに人生を捧げている
のは、ある意味、純粋な競技と化していて、それはそれでおもしろい。
傍観者としてならば

＞ただのコピペ野郎だな、残念ながら。
いやいや、それをコピペしようとした注目点が評価されるのでは？
それいったら、マスコミや新聞屋なんてみんなコピペ野郎。

実際、クリップ関連に注目している人は少ないと思うぞ。必須テクの割りには。
環境マップよりもスキルを要求されるのに、見た目は地味だからという
理由であまり話題にならない重要な分野だ。>>クリップ、シザリング

>696
二行目も事実ですな。
元ネタらしき本持ってるよ。

>699
時計に人生捧げてる奴とか？
でも彼はたかが時計で何であんなに偉そうなんだろう・・・。

知るか

　

好きです、プログラマー。

　　∧ ∧　 　 　┌──────
　　( ´ー｀)　　 ＜ 出番ネーヨ
　 　＼　< 　　　 └───/|──
　　　　＼.＼＿＿＿＿__／/
　　　　　 ＼　　　　　　　／
　　　　　　　∪∪￣∪∪

もしかして、タクティクスって、物体を回転させてませんか？
カメラを回したら、どうも変でした。

>705
行列演算を勉強して出直してこい。
話はそれからだ。

行列えんざんならわかりますよ。回転行列とかありますよね。かっこにさいんコサインはいってるやつ。

http://nis-lab.is.s.u-tokyo.ac.jp/~nis/CG/cgtxt/index2.htm

視点の回転を覚える前に、質問の仕方を勉強する必要がありそうだな。
タクティクスオウガを知らないので何をしたいのかサッパリ分からない。
注視点を中心に回転したいってことかなー。ちと違うか？

>708
ありがとうございます。とてもわかりやすくて、さすが東大ですね。

>>701
ﾏﾀｰﾘしよ。

2chでこの程度なら十分ﾏﾀｰﾘだろう・・・

このスレの弊害は大きくなってるよ。
中途半端に情報出してここで出し惜しみって言われるなら
全く情報出さない方がマシだ。

>>713
実はおれもそう思ってしまった。
技術ドキュメント出しにくいなあ・・・。

なんつーか表面だけ見て文句いわれるんなら、
全く出さない方がいい(技術持ってることすらにおわさない)のではと。

これはオープンにいこうという最近の方向から行くといやなんだが。

少し間違っただけで人生まで否定されるからな。
３Ｄ系のＨＰ作ろうかと思ってたが怖いのでやめた。

掲示板にコテハンで書き込んでるだけで
粘着３Ｄサイトウォッチャー君にいつか2chでバッシングされる可能性がある。
バッシングを避けるならどこの掲示板でも名無しで書き込むのがいい。

ここで出し惜しみって言われてるのは、出し惜しみじゃなくて本人が説明を
理解できなかっただけのが多いと思う。
積分の説明するのに四則演算から説明する人はいないのに、四則演算も知ら
ずに積分の質問して文句言ってる感じ。

なんかまともに書きこんだ俺がばかみてーじゃねーか。

>おまえが知らないだけでニアクリップなんか大昔からソースあるよ。
それがどーした。
大昔からニアクリップについて書いた日本語ページはDyncoon氏のところぐらいだ。
出来が悪いと思うなら、お前自身がより詳細な情報を提供しろ。

>>718
出し惜しみとか言ってる奴は
自分が話しについていけないことへの妬みだろ。
奴らにとってはコピペできるソースがなければ、出し惜しみなんだよ。

ということで、クダラナイ奴の煽りなど気にせず、
2ch以外で情報交換しましょう。

>>719
クリップの何が知りたくて怒ってるのかしらないけど、
クリッピングのことだったら"Computer Graphics : PRINCIPLES AND PRACTICE"
( ISBN 0-201-84840-6 )とかに載ってるよ。
（その本は最近では日本語版も売ってるらしい。そっちは読んでないけど。）
教えろ教えろいうのはいいけど、ちょっとは自分で調べる努力もしようぜ。

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

出し惜しみも何も、far,near,上下左右のクリッピングなら相似で片付く算数問題だろ
画面角とポリゴンの交点は内積使うけど
まず紙と鉛筆用意して手と頭を使え。参考資料なんて漁る方が恥ずかしいぞ

>>720
俺が知りたいわけじゃない。>>689を見ろ。
俺が名前だしたことが叩きの原因になったんでむかついているだけ。

>>720　サンキュー
日本語版はこれだね
http://www.amazon.co.jp/exec/obidos/ASIN/4274064050/qid=1011063089/sr=1-1/ref=sr_1_0_1/249-3485832-7856307

このスレの皆さんはずいぶんとエラそうですなぁ〜
やっぱ人気あるから調子にのってるんでしょうか？
マジレスきぼんっな

つーか、GEMSといい、この本といいなんでこんなに高いんだ？
どっち12000円だし、談合か？（ぉ
英語のできない開発者いじめですか？（泣）

>>725　ゲーム業界のプログラマはだいたいこんな感じです。
正確破綻者多いし。（特にWeb弁慶は多いな）

XBOXのダブルスティールが物理計算やってそうな感じ？
あぁもうついていけない。あれ開発してるの誰だ〜
（結構有名なんでしょ〜あそこまで出来るなら）

OpenGLなMasaさんもゲーム作ってるみたいだけど、これ？

>>726
需要が少ないから。

>>726
でも最近円安のせいで原著も翻訳も値段がさほど変わらなくなってきたよね。

>>729
凄腕がみんなWebに露出してるわけじゃない
>>730
問題は日本語訳が無い場合だな

凄腕もWebはマメに見てる罠(藁

しばらく見に来ないうちに、スレが伸びてる。

スクリーンに投影した状態でclipするのではなく、
視錐台の各面に対してclipを行えば良いということですか？

俺ははっきりいって何でも知ってる。わからなかったら俺に聞け。

>>734
水滴の屈折計算の公式を教えてください。

調べればわかる。

スネルの法則

>>736
自分が知りたいのは、スネルの法則をどのように
テクスチャのUV座標として適応するのかです。
レンダリングしたシーンをテクスチャに使うとして、
屈折後の視線ベクトルがスクリーン範囲外になったときのUVの扱いとか。

GEMSに載ってなかったっけ？
またはコレとか。
http://www.microsoft.com/japan/developer/directx/japan/dx8/refract.asp

>>739
水槽の屈折しかGEMSには載ってません。
また、そのサンプルもキューブ環境マップを使用したものですし。

自分が知りたいのは、PS2のタイトルがやっているような、
それまでにレンダリングしたバックバッファをテクスチャに使って
水滴を描画する手法なんです。

>>740
バックバッファをテクスチャに使って、ふつ〜にスフィア環境マップしてみ。
後は、適当に調整だな。
すぺきゅら入れないと水滴じゃなくてガラスみたいになるかな。

>それまでにレンダリングしたバックバッファをテクスチャに使って
>水滴を描画する手法なんです。
そこまで知ってるんだったら、あとは試行錯誤の連続なんじゃないかなぁ。

＞時計に人生捧げてる奴とか？
＞でも彼はたかが時計で何であんなに偉そうなんだろう・・・。
偉そう？俺にはそうは見えないですな。
Ｗバッファに関するとんだ勘違い説明を後から気が付いても、
敢えて消さずに残すところだとか、勇気あるし、謙虚な人だと思うぞ。

>>742
試行錯誤はしているのですが、どうもMGS2のように綺麗にでないもので。
視点とカメラとの距離による移りこみの変化とか
ちゃんとしたモデル理論に基づいて作ればなんとかなるのかと思ったのです。
いまのところ、視線ベクトルを水滴の法線ベクトルで反射させたベクトルに、
係数を適当にかけてやっています。

もともとレンダリング済みのバッファをテクスチャに使うこと自体
フェイクっぽいので（無限遠に投影された背景と考えればいいのかな）微妙です。

MGS2って、倒立虚像を表示してるんでない？
その辺はやってみたんですか？
物理屋的に言えば、水の光速が空気中より遅いので、光を波と考えた場合の波面が屈折します。作図してみてください。
焦点距離が水滴を通して見たときと、まっすぐ背景を見たときで違うので、完全なシミュレーションは困難と思いますが。（被写界深度）

>>745
倒立虚像というのは、上下左右反転した写像のことですか。
それはやっています。
ただ水滴の位置によって微妙に映り込みが変わるんですが（MGS2)
あれがなかなか難しいんですよ。
少しでも係数をミスると、テクスチャ範囲外をUVが示して、
写像の一部がクランプしてしまうのです。

近景が大きく写るような場合は745のいうように屈折マップ用に反転したモデルを
描画した方がいい気がする。（水溜りをまたいでキャラが進むような場合）

あとは法線が動的に動いてるものなら、軽い反射（適当な環境マップ）も入れて
みると、きれいになる気がする。（多分やってると思うけど）
流行の？フレネル項に関しては好みがあるのでご自由に（テクスチャや反射の
度合いによってはギラギラ全反射のほうが好みという人もいました）

>>747
水溜りなどの一般的な屈折ではなく、
カメラのレンズについた水滴の表現なんです。

水面ネタに便乗して，話はそれますが
波動方程式の吸収境界条件のいい方法キボンヌ

>>749
Gems1の近似モデルの奴じゃだめなの。

>>748
それならレンダリングよりむしろアニメーションの方を考えた方がいいような。
http://www.dtek.chalmers.se/~d1hej/smoke/smoke.zip
みたいなFFTソルバのアプローチはいかが？（水滴を飛ばしてたらすような
力を加える）とか…。
# 試さずにいってます。ゴメンネ。

ワンスキンモデルなどの処理で必須となる、法線ベクトルの正規化。
皆さん、これ、どうやって最適化してます？

>>748
それってあらかじめテーブル作っておけばいいんじゃないの？
リアルタイムに計算する必要はないから、複雑でも正確なモデルで
時間かけて計算しておけばいいのでは？

>>746
水滴の位置によって、微妙に移りこみが変わるのは、st値にスクリーン
座標をちょっと反映させているだけかもよ。

>>752
そもそも法線の内挿って、どれくらいまじめにやります？

時計しかwebにないからってそれに人生欠けてると思ってもらっては困ります・・・

お、本人降臨♪
まぁ>>701は自分の部屋とWebでしか世界を認識できない
哀れなヒキコモリ厨房と思われ｡（藁

いきなり企業秘密を聞いてくるとは思わなくてさすがの俺様もたじたじだ。
やばいからもう来ない。

Direct３Dで４点で四角形を構成しているD3DVERTEX(pV)をその場でローカル座標でY軸回転したいのですが

for(int i=0;i<4;i++){
float x=pV[i].x ,y=pV[i].y ,z=pV[i].z;
pV[i].x = x*cos(1.0f)+z*sin(1.0f);
pV[i].z = x*(-sin(1.0f))+z*(cos(1.0f))
}
とやっても、オブジェクトの中心以外のどこかを軸にY軸回転してしまいます。
どうすればよいのでしょうか。

>756
煽りに反応すんなよ、うざい。

>759
pV[i].z = (ｆｌｏａｔ)( z * cos(1.0) + x * sin(1.0) );
pV[i].x = (ｆｌｏａｔ)( x * cos(1.0) - z * sin(1.0) );
だと思われ。

レスありがとうございます。
試してみましたがオブジェクトの中心を軸にしてY軸で回転させたいのですが、回ってしまいます。
下のコードのとおりです。ちなみに(966,0,966)が視点で、平行投影しています。

pFloorVB->Lock(0,0,(BYTE**)&pV,0);
for(int i=0;i<4;i++){
float x=pV[i].x ,y=pV[i].y ,z=pV[i].z;
pV[i].z = (float)( z * cos(0.1+k) + x * sin(0.1+k) );
pV[i].x = (float)( x * cos(0.1+k) - z * sin(0.1+k) );
}
pFloorVB->Unlock();
}
D3DXMatrixLookAtRH(&viewMat,(D3DXVECTOR3*)&viewFrom,&D3DXVECTOR3(966,0,966),&D3DXVECTOR3(0,1,0));
pD3DDevice->SetTransform(D3DTS_VIEW,&viewMat);
pD3DDevice->SetTransform(D3DTS_PROJECTION,&persMat);

pFloarVBの中身

pV[0].x = 500; pV[0].y = 0; pV[0].z = 500;
pV[0].nx = 0; pV[0].ny = 1; pV[0].nz = 0;
pV[0].tu0 = 0; pV[0].tv0 = 0;

pV[1].x = 500; pV[1].y = 0; pV[1].z = 932+500;
pV[1].nx = 0; pV[1].ny = 1; pV[1].nz = 0;
pV[1].tu0 = 0; pV[1].tv0 = 3;

pV[2].x = 932+500; pV[2].y = 0; pV[2].z = 932+500;
pV[2].nx = 0; pV[2].ny = 1; pV[2].nz = 0;
pV[2].tu0 = 3; pV[2].tv0 = 3;

pV[3].x = 500+932; pV[3].y = 0; pV[3].z = 500;
pV[3].nx = 0; pV[3].ny = 1; pV[3].nz = 0;
pV[3].tu0 = 3; pV[3].tv0 = 0;

あ、すみません。kは0なので気にしないでください。

また間違いました。
視点が(50.0f,400.0f,50.0f)で、
注視点が(966,0,966)です。

1ヶ月で1通のメールが届きます（登録メールアドレスに）
このメールを確認するだけで1250円を差し上げます。
通帳の口座番号は要らない。（家に直接配達してくれる。）

わが国のサイトでもメール1通を確認すれば１〜５（円）
を貰いますが、Net先進国アメリカでは10ドルを貰います。
（広告業界はここまできている証拠です。）

このサイトはアメリカUSAのサイトで、
2002年現在日本ではほとんど加入者がいない状態です。
もう世界的に（アメリカ、韓国等で200万人以上の会員が
加入済みで実績有り）

http://www.MintMail.com/?m=1941971
このURLをクリックして入力すれば登録完了です。

pV[i].z = (float)( sqrtf((float)((z * z)+(x * x))) * sinf(0.1+k) );
pV[i].x = (float)( sqrtf((float)((z * z)+(x * x))) * cosf(0.1+k) );


これどうでしょか。こんな式を昔書いたようなうろ覚えです。違ったらスマソ。

スマソ。上から３行目です。

pV[i].z = (float)( sqrtf((float)((z * z)+(x * x))) * sinf(0.1+k+atan2(z,x)) );
pV[i].x = (float)( sqrtf((float)((z * z)+(x * x))) * cosf(0.1+k+atan2(z,x)) );

あ、もしかしてこれかな・・・
pV[i].x = (x*cos(1.0f))+z*sin(1.0f);
pV[i].z = (x*-sin(k))+z*(cos(k)) ;
kが変化するならこうかなぁ・・・？

げ、1.0ｆをどうにかしてｋに変えて下さい・・・

絶対座標系の原点に移動させて回転させて戻したらだめなの？

＞そもそも法線の内挿って、どれくらいまじめにやります？
線形内挿以上の実装をしたことがない厨房です。曲がり過ぎるとバレバレ以前に
不自然なんだけど、まー仕方ない。
でも意外と、クソマジメに正規化しても気持ち良く逝けます。
逆ルートテーブル作れる隙間さえあればねぇ

>Ｗバッファに関するとんだ勘違い説明を後から気が付いても、
別にあれは、masa氏の勘違いではなく、shi3ｚ氏のいー加減な返答が引き起こしただけなのです。

>とりあえずＢＢＸとBio120%の過去ログは見とけ。
alty、今元気かなぁ。やー、ところでなんで、120%なの？

吾輩の推理によれば、あすか120％と混同したと見たぞ。

>>772
痛い奴らの名前出すなよ、荒れるだろ

masa先生は別に痛くないYO.

ところで
>線形内挿以上の実装をしたことがない厨房です。曲がり過ぎるとバレバレ以前に
>不自然なんだけど、まー仕方ない。
全部が全部、不自然に見えるわけではないので、ウチのところでは
「正規化フラグ」というアトリビュートを一つ増やして、
実際に表示させて本当に困る場合に、そのフラグを立てて貰ってます。
たくさん出てくるキャラは、手前にいる時だけ、まじめに計算させて
います。（まぁ、その手前か否かの境界線でズギャと、明るさが変わ
ってしまいますが）

とにかく実際のゲーム中でどれくらいの重要度を占めるのかをテスト
してみるまで、これといった結論は出ないと思います。

ＶＦ４の地面が雪なステージって、どうやるの？
キャラが通った後、ちゃんと凹んでる。

頂点へこますだけだろ

俺もMasa先生嫌いだ。理系にありがちな陰険な香がするよ
気に入らないなら、文句いわないで黙ってればいいのに
厨房のガイシュツ質問を排除して場を良くしようと思ってるんだろうけど、逆効果だよ

>>777
足跡の座標を記録しておいて、
毎フレーム、ステンシルに足跡を書き込んでCSGとか。
ごめん適当。

>>777
あらかじめ雪を格子状のメッシュとして確保しておいて、
足が着地したときの位置が格子の何処に位置するかを計算して、
相当する部分の頂点のＹ座標を（なだらかに凹むように距離に反比例
して下がる量はすくなくなるように？）下に移動させる。
頂点の位置から法線の座標を再計算。

くらいしかしてないように（素人目には）みえる。

おれも３Ｄ野郎の初心者に対しての対応は嫌いだが
密かにこのスレを支えてくれたのも事実。
個人叩きはその辺にしてスレを再生しる。

>>781
３Ｄ野郎以外、まともなことは誰も書き込んでない気が。
初心者は享受するだけなんだから、いてもいなくても同じ。
結局このスレが駄目になったのも、
逆恨みしたアホな初心者とか、時代遅れの業界人のせいじゃないの。

>>780
恐るべきはあのメッシュ量を保つ為に必要になる頂点数だな。
マシンパワーごり押しだとは思うがそれなりに高度な最適化
の賜物だと思われる。

キャラの当たり判定ってやっぱ球なのかな？

>恐るべきはあのメッシュ量を保つ為に必要になる頂点数だな。
でも、これといった最適化なんてしてないんじゃないかなぁ。
NAOMI基盤は知らないけど、ps2になってあのあたり、どのように
移植されるのか激しく興味がある。
ところで、あの雪のメッシュの量って、どれくらいなのかなー？

眼で確認できるくらいの細かさだからたいした量ではないんじゃない？＞雪
転んだり、踏んづけたりして変化したところだけ手をいれればいいだけ
ならそれぞれのキャッシュメモリに収まる位の量に分割できるだろうし…。
法線の再計算も外積なんてSIMD使えば出来るだろうし…。

NAOMI基盤ことならSEGA社員にきいてみよう〜。
確かいたよね？

>眼で確認できるくらいの細かさだからたいした量ではないんじゃない？
確かに目で桝目の最小単位は確認できたけど、それにしてもなかなか凄い
数だったよ。雪だけで数万のオーダーは軽く逝ってるのはほぼ確実。
人体モデルと背景表示をした後の余力で出来るオマケ処理にしては、
処理量、多くない？

数万！？いくらなんでも嘘だろ…
と思ったけど、100×100で１万か。
でもまあ、リアルタイムで加工する必要があるのは踏んづけ部分のメッシュだけなので、
別段水面の処理とかと同じ程度の負担だと思われ。

>>787
氏ね。

格闘ゲームのＰＧから見た技術の順位は
ＤＯＡ３＞ＶＦ４＞鉄拳４
でいいか？

ＤＯＡ３=ＶＦ４=鉄拳４>>>>>>>>>>>...>>>>>>>>>>>791=ゲーハー厨房

DirectGraphicsで。６４ｘ６４ｘ６４の立方体メッシュを4000個作ってそれぞれ描画すると、4000個の作成に時間がかかり、描画も遅くてたまりません。何かｳﾏｲ方法ないでしょうか。

for(int x=0;x<20;x++){
for(int y=0;y<20;y++){
for(int z=0;z<10;z++){
D3DXCreateBox(pD3DDevice,64.0f,64.0f,64.0f,&tmd[x][y][z].pMesh,NULL)
}
}
}

for(int x=0;x<20;x++){
for(int y=0;y<20;y++){
for(int z=0;z<10;z++){
tmd[x][y][z].pMesh->DrawSubset(0);
}
}
}

>>793
1GBメモリのビデオカード買えや。

4000個は今のスペックでも駄目ですか？

表示のたびに作り直してるのか？

>>795
ネタ？それとも真性馬鹿？
64*64*64*4000*4byte計算できんの？

＞795
初期化のときに一回だけつくります。

＞64*64*64*4000*4byte
4000*（メッシュのバイト数）ではないのですか？

リアル厨房なんだけど、３Dプログラミングに必要な数学って
どんなもんなの？高校生レベルないと無理？
いままでの授業でとても３Dに関係することなんもやってないんだけど・・・。

ベクトルから長さと面積と体積が計算できて、
ピタゴラスの定理を知っていれば充分です

３Ｄプログラミングの本を買って見れ。
行列や物理演算もやっとけ。

>>たけし
なぜ20*20*10個のＢＯＸが必要なんだ？
それだけを１つのMeshとして作ってやれないか？

物理は F=M・a と微分積分だけやっとけ

　4000個のメッシュということは、それ全てに一つ一つ
個別の座標変換行列が与えられて・・・という感じかな？
となると、外部・内部にかかわらずDrawPrimitiveの
呼び出しがあまりに多すぎてスピードが全然でないはず。

　という訳で>802推奨。

>>799
まずは2Dで一次変換行列に慣れ親しめ。
とりあえず、大学生の知り合いでも連れてきて質問攻めだな。

さらにはトライアングルストリップを作って
それぞれを縮退三角形で結ぶ。
って、やった事ないけど。

＞＞８０１
物理演算って力学とかいうやつですか？
放物線運動とかですか？

力学でしょ。
キャラが飛んだり跳ねたりするのにも使うし
キャラのコスチューム（布とか）動かすのにも
必要になる。

あっ、あまりageすぎないでね。あまりね。
sage進行でﾏﾀｰﾘ行きましょう。
下がりすぎたらたまにage。
そうしないと荒らされるから。

当方、行列変換知らないけど、
てきとーに動くコード拾ってきて、組んでます・・・。

RMなら割とそれっぽいのが・・・
座標変換は全部Frame任せです。
コリジョンには四苦八苦だけど。

>数万！？いくらなんでも嘘だろ…
>と思ったけど、100×100で１万か。
仮に１辺が100だったとしても 100*100*2 で２万です。
あと、ティーポット類の実験とは違って、クリッピングやシザリングも必要。
地面スレスレのカメラとか平気でありますし。

＞802
＞804
立方体ひとつひとつにパラメータを持たせたかったのですが、何かいい方法ありますか？

>>812
全く同じ形状のメッシュを4000個作るのが無駄なんだよ。
形が同じなら１つのメッシュを4000回使い回す。
どうせ頂点座標いじったりしないんでしょ？

|￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣|
|　　世の中に棲む逝きとし逝けるもの 　　　 |
|　　すべてが自由に平和に平等に美しく　　 |
|　　明るく楽しく暮らせる幸福と善意と　　　 |
|　　優しさと愛とマターリに満ちた世界を　　｜
|　　要求する。　　　　　　　　　　　　　　　　　｜
|＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿|
　　　　　　　　 ∧∧ ||
.　　　　　　　　( ﾟдﾟ)||
　　　　　　　　 /　づΦ

＞813
なるほど。ポリゴンとは別にプロパティの配列を作ればよかったのですね。
頂点は、ワールド座標の原点を中心に２０ｘ２０ｘ１０の立方体（マップデータなので、ところどころ空きはありますが）をY軸で回転させる予定なのですが、大丈夫でしょうか。

２０ｘ２０ｘ１０は、６４ｘ６４ｘ６４の立方体が１０〜20個づつ並んでいるということです。

>>811
仮に2万だとしてもステートの変更とかがなければそんなにたいした負荷になるとは思えない
けどなぁ？結構な大きさのばねメッシュの水面を実装したことがあるけど、表示用と計算用に
ダブルバッファでデータ持てば毎フレーム全頂点書き換えてもたいした負荷にならない気が
する。（大体雪なら全部のメッシュを毎フレーム書き換える必要なさそうだし）

ハードウェアTnLならシザーの心配なんてさほどいらないだろうけど（一部クソハード除く）
これも雪面を全部一個で考えずに、部分ごとに分ければ負荷は減らせるでしょ。
近くてクリップが必要なときは見えなくなる部分をボリュームかリングする事で負荷を減らす
事ができるだろうし、遠くはなれた部分はシザーする必要ないでしょ。（ガードバンドの中に
収まるのでリジェクトでＯＫ）

６４ｘ６４ｘ６４ってボリュームテクスチャじゃなかったのか。
ややこしい書き方するなや、3Dでサイズは無意味。

サイズは無意味なのですか。勉強になりました。

>>819
無意味というかカメラ位置や変換マトリクスによっていくらでも大きさが変わるだろ。
単に「立方体」で十分だよ。

＞820
なるほど。
ところで、メッシュを作ったのはいいのですが、そのメッシュを２０ｘ２０ｘ１０並べる方法がわかりません。
GetVertexBufferを使って頂点バッファを取得し、
DIRECT3DVERTEXBUFFER8のLockで頂点データを取得してそれを操作するのでしょうか。
３次元配列の地形情報等のデータなどが入ったものをどう適用すればいいのかわかりません。

どうでもいいけど初心者スレ行ったら？(´д｀ )

そんなこと言わないでどうかお願いします。

DrawSubsetを20*20*10回すりゃいいじゃん。

>>822
答えてやらないと「出し惜しみするなゴルァ」とか言われるよ

3Dの技術じゃなくてDirectX話みたいだから出し惜しみします（ぉぃ

それはそうと、よく考えたらこの板
「初心者はここで聞け！DirectX相談室」スレないのな。

＞824
メッシュを一回描画するたびに頂点を動かしてまた描画という処理をしないと２０ｘ２０ｘ１０は描けないと思うのですが。
その、頂点の動かし方がわかりません。メッシュを作成したときのデフォルト座標は０，０，０だと思うのですが、そこからどう動かせばよいのか。

↓を実践してきたら教えてやるよ。

1.　コンビニにいく。
2.　普通に買い物をする
3.　なにくわぬ顔で店を出る
4.　数分後、息を切らしてコンビニのレジにかけよる
5.　「お、おい！さっきこんな顔をした奴がこなかったか！」と叫ぶ
6.　「あなたがさっき買い物していったんですよ？」と店員に言われる
7.　「ば、ばかもぉ〜ん！それがルパンだ！追えぇ〜！」と、叫びながら店を出る

ワールドマトリクスって知ってるよね？

すみません。北海道の田舎なのでコンビニがありません。どうぞよろしく。

調べると
モデル座標系からワールド座標系に変換するためのマトリクス。
モデルの移動・回転・拡大などを指定する。
とありました。ということは、モデル→ワールド座標変換のときにこのマトリクスを指定してやればいいということですか？
このマトリクスは
D3DXMatrixLookAtRH(&viewMat,(D3DXVECTOR3*)&viewFrom,&D3DXVECTOR3(0,0,0),&D3DXVECTOR3(0,1,0));
のviewMatのことですか？どのメソッドで使われているのか教えてください。お願いします。

http://gazoo.direct.ne.jp/upboard/fun/img20020112040019.jpg

D3DXMATRIX matWorld;
D3DXMatrixIdentity( &matWorld );
m_pd3dDevice->SetTransform( D3DTS_WORLD, &matWorld );
この後にDrawする。

移動させるならD3DXMatrixTranslationでマトリクスに
場所をセット。

＞833
できました。本当にどうもありがとうございました。またよろしくお願いします。

>ハードウェアTnLならシザーの心配なんてさほどいらないだろうけど（一部クソハード除く）
いや、もっともなんだけど、ほら、その一部のクソハードが市場を
占領しつつあるじゃないですか〜。まぁ、本当に微少なポリゴンに限って
シザしなくても、あんまり困らないけど〜。

鉄拳４のガス煙ってどうやってるの？
意外とただの半透明ビルボード？とてもそうには見えなかったのだが。

ふー、やっとＤＶＤ焼きおわったよ。マスター暢るかな。

＞まぁ、本当に微少なポリゴンに限って
＞シザしなくても、あんまり困らないけど〜。
ps1の頃なんか、手前のポリゴンはリアルタイムに微少にして
までしてシザを避けてたくらいだったしな（藁

>ハードウェアTnLならシザーの心配なんてさほどいらないだろうけど
え？嘘、TnLだと安売りバーゲンなの？
いーなぁＸ箱。

>意外とただの半透明ビルボード？
たぶん正解。

絵描きのセンスの問題じゃよ。

シザー　って何？

俺のこと？
￣￣￣￣￣∨￣￣￣　　　　　　　(´´
　　　　 ∧∧　　　）　　　　　　(´⌒(´
　　⊂（ﾟДﾟ⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
　　　　　　 ￣￣　 (´⌒(´⌒;;
　　　　　　ｽﾞｻﾞｰｰｰｰｰｯ

　　　　　　　　　　 　,一-、
　　　　　　　　　　 /￣　l |　　 ／￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　　　　　　　　　　■■-っ　＜　ハイハイ、いったんＣＭ逝きまーす
　　　　　＼　　　 ´∀｀/ 　　　＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿
　　ﾊﾆｬｰﾝ　　 ∧ ∧　　＼
　　　　＿　　　.(ﾟДﾟ ,)　　　|
　　　　　　　　 ∪Ё|＿_ノ　|
　　　　　　　　　 |　　|
　　　　　　　　　 |　　|〜
　　　　　　　　　 ∪∪

すみません。２０ｘ２０ｘ５個のメッシュを描画してそれの中心を軸にして回転させると、180度ほど回ったところでいきなり表示が変になります。ポリゴンの天井が抜けたような感じです。なぜこうなるのでしょう。

>>839

───────────────────────────−──────―
────────‐───────────−────────────―─‐
─‐────────────‐────────‐∧＿∧ ───‐──―──‐
─────‐∧ ∧,〜　────────────‐（； ´Д｀） ────―─‐──‐
──−──‐( （⌒￣ `ヽ───＿ ───────‐ / 　　 /─―/ヽ────―─‐
──―───‐＼　 ＼　`ー'"´, -'⌒ヽ──────‐| | 1 ‐─‐/ | | ─────―
―‐――──‐ /∠＿,ノ　　　 _/_───‐―──―─‐| |　 /─―/　| |―────―‐
─────‐ /（　ノ　ヽ､＿/´ 　＼―────‐──‐∪ ./──,ｲ　∪ ────―─
────‐ ､（ 'ﾉ（　　　　　く　　　　 `ヽ､ ―────―‐| /−─/||　| ──−───―
───‐‐／`　―＼＿＿＿_>＼＿＿_ノ ──────‐|/──/ ||　| ────‐─―‐
───／───―‐/＿_〉.───`､＿_>.―‐―───‐─―‐|　||　| ─────―─
──／──‐──────────────―−───‐（＿)＿)─────―─
─／────────−────────────‐──────────―‐
───────────────────‐─────────―─────‐

いやマジで教えて
￣￣￣￣￣∨￣￣￣　　　　　　　(´´
　　　　 ∧∧　　　）　　　　　　(´⌒(´
　　⊂（ﾟДﾟ⊂⌒｀つ≡≡≡(´⌒;;;≡≡≡
　　　　　　 ￣￣　 (´⌒(´⌒;;
　　　　　　ｽﾞｻﾞｰｰｰｰｰｯ

・クリッピング
―――――――――――――‐┬┘
　　　　　　　　　　　 　 　 　 　 　 　 |　　　視点外のポリゴン
　　 　 　 ＿＿＿＿.＿＿＿＿ 　　 |　　　を
　　　　　|　 　 　 　 | 　 　 　 　|　　 |　　　窓から
　　　　　|　 　 　 　 | ∧＿∧　|　　 |　　　投げ捨てろ
　　　　　|　 　 　 　 |（　´∀｀）つ ミ | 　
　　　　　|　 　 　 　 |/ ⊃　 ﾉ　|　　 |　 [￣]
　 　 　 　￣￣￣￣'￣￣￣￣　 　 | 　 ￣

・シザリング
視点にかかるポリゴンを・・・斬る！！
─‐────────────‐────────‐∧＿∧ ───‐──―──‐
─────‐∧ ∧,〜　────────────‐（； ´Д｀） ────―─‐──‐
──−──‐( （⌒￣ `ヽ───＿ ───────‐ / 　　 /─―/ヽ────―─‐
──―───‐＼　 ＼　`ー'"´, -'⌒ヽ──────‐| | 1 /‐─‐/ | | ─────―
―‐――──‐ /∠＿,ノ　　　 _/_───‐―──―─‐| |　 /─―/　| |―────―‐
─────‐ /（　ノ　ヽ､＿/´ 　＼―────‐──‐∪ ./──,ｲ　∪ ────―─
────‐ ､（ 'ﾉ（　　　　　く　　　　 `ヽ､ ―────―‐| /−─/||　| ──−───―
───‐‐／`　―＼＿＿＿_>＼＿＿_ノ ──────‐|/──/ ||　| ────‐─―‐
───／───―‐/＿_〉.───`､＿_>.―‐―───‐─―‐|　||　| ─────―─
──／──‐──────────────―−───‐（＿)＿)─────―─
─／────────−────────────‐──────────―‐

>>844
労力は認めるがちがうぞ

教えてクン一人であっさりスレ壊滅かよ。もろいな。

とりあえず、たけし君よ、質問するならこっちのスレにしろ。
http://pc.2ch.net/test/read.cgi/tech/991795568/
あっちならテトリス足トリス教えてやるから。

＞846
早速のレスをよろしくお願いします。

>>845
違うなら説明せんかい糞ヴォケィが。この板から消えろ！

ライブラリが無ければ何もできない３D厨には関係ない話。忘れろ

>>849
じゃあフルアセンブリしかないけど（それ以外は全てライブラリと同様）、
アセンブラが出来るヤツはエライんダッ！！
と本気で信じてるｳﾞｧｶなチミに100パジェス。
インライン汗使ったソフトを公開したら「フリーズしました」
という苦情が殺到したチミには4000プゥオレキト。

>>850
アセンブラごときにコンプレックス抱いているチミに10000bit
拡張命令のサポートを調べることすら知らないチミに40000byte

シザリングってポリゴンの細分割の事かと思ってたけど違うの？

違う

>>852
合ってるよ。再分割ね。

>854
つまりLOD？

にも使われてるよね。
カリングでもシザリングだよね。
ちょきちょきするならシザリング。

>>852 >>854 それはクリッピング。
シザリングはスキャン変換後のピクセル単位での処理。
「コンピュータグラフィックス 理論と実践」くらいは読んでおけ。

ごめん、間違えた。すまんこ。

>>857
> >>852 >>854 それはクリッピング。
> シザリングはスキャン変換後のピクセル単位での処理。
> 「コンピュータグラフィックス 理論と実践」くらいは読んでおけ。

一番上の行とか前回に嘘だと思うんだけど…。
ポリゴンのシザリングって言ったら
ポリゴンを切断すること全般でしょ。
そこから先は方言や、前後の会話のニュアンスで
推し量るしかない。
だから
>>852 細分割
は間違いではないと思うよ(普通こうは書かないけど)。
>>854 再分割
は、パースコレクトの無い描画エンジンを持っていたハードが
幅を利かせていたせいで違うものを連想してしまうと思う。

どちらもクリッピングと直接対応する言葉ではない。

>>857
は、そう言う風にも使われているという例に過ぎない。
scissor で辞書とか引けば、
こんなに狭い考えにはならないと思うんだけど…。

結構、専門用語って、結構方言とかきついから
お互いにおおらかに、補いながら行きましょうよ。

細分割＝サブディビジョンサーフェス
みたいな感じで使ってたんだが。
まぁ、細分割っていうと曲面の分割を想像しちゃうし、
シザリングの説明には不適切だったか。

動いたり傾いたりする３Ｄ床の上にプレイヤーを完全に
同期させる術を教えてください。

>861
キャラの立っている床の行列を、キャラに掛ける。

近い将来、ピクセルシェーダがゲーム制作に与える端的なメリットって
例えばどんなものが考えられますか？

>キャラの立っている床の行列を、キャラに掛ける。
それじゃ、キャラはその上に沿って歩けないよ〜

えと、クォータニオン絡みで虚数質問なんですが〜。

i^2 = -1 となるような数を 虚数 i と定義されているわけですが、
なぜ i+i = 2i になるのか分かりません。

実数だったら当り前な式ですが、虚数は実在しない故、
例えば 2i + 3i = 5i となるのが直感的に理解できません。

過去、数学板で質問してもシカトされたのでー

>>863
ユーザーの動作環境の引き上げ

i+i = 2i
これって虚数の加算の定義では？
1 + 1 = 2と同じでは？

>>864

できるよ。

>>864

[人の行列] 　 　 　 ＝[1フレーム分の移動行列]×[1フレーム分の回転行列]×[前フレームの人　　の行列]
[動く床の行列]　　 ＝[1フレーム分の移動行列]×[1フレーム分の回転行列]×[前フレームの動く床の行列]
[ワールド行列]　　 ＝[動く床の行列]×[人の行列]

左手系ね。

ごめん。間違えた。

[人の行列] 　 　 　 ＝[1フレーム分の回転行列]×[1フレーム分の移動行列]×[前フレームの人　　の行列]
[動く床の行列]　　 ＝[1フレーム分の回転行列]×[1フレーム分の移動行列]×[前フレームの動く床の行列]
[ワールド行列]　　 ＝[人の行列]×[動く床の行列]

[人の　　(座標系を表す)行列] は 「動く床」　　　　を基準にした行列ね。
[動く床の(座標系を表す)行列] は 「ワールド座標系」を基準にした行列ね。

>>859
確かに >>857 の１行目の発言は不適切だった。スマソ。

日常の英単語としては clip も scissor もほとんど同等で、
ともに「切る」くらいの意味しか持っていないことは理解している。
しかし、実際にグラフィックス関係の英語の文献を読んでいれば、
scissor が clip とは明確に区別されていることに気づくはず。

clip はかなり広範囲の意味を含むことがあるが、scissor に関しては
「スキャン変換後に領域（通常は長方形）内のピクセルのみを描画する」
こと以外の意味で使われることは極めてまれ（というか見たことがない）。

よって、日本語でも、「ジオメトリレベルでの解析的なポリゴン切断処理」
の意味で「シザリング」という用語を使うのは不適切だと思うのだが。
（ジオメトリ的な切断の意味では「クリッピング」と言うべき。）

基本的には、シザリング ≒ glScissor ということで。

>>865
(i+i)^2=-4だろ

>これって虚数の加算の定義では？
>>1 + 1 = 2と同じでは？
虚数の定義は i^2=-1 というだけ。1+1=2になるから虚数の係数に線形性が
生まれるのではなく、874のように諸々の式で、そのような性質が観測できる
からだよ。

>[人の行列] 　 　 　 ＝[1フレーム分の移動行列]×[1フレーム分の回転行列]×[前フレームの人　　の行列]
>[動く床の行列]　　 ＝[1フレーム分の移動行列]×[1フレーム分の回転行列]×[前フレームの動く床の行列]
>[ワールド行列]　　 ＝[動く床の行列]×[人の行列]

それはつまり、なんらかのカウンターで一意に決まる姿勢行列でキャラクターを
動かすのは駄目ということなのかなー？回転でもなんでも１フレームずつ回転？

>>876

＞それはつまり、なんらかのカウンターで一意に決まる姿勢行列でキャラクターを
＞動かすのは駄目ということなのかなー？

いや。全然そんなことはないと思うよ。
そのカウンターというのはつまり、アニメーションデータとかの形で与えられる
制御点情報の間を補間するときの、例えばスプライン関数のパラメータの話だよね。

＞回転でもなんでも１フレームずつ回転？

ここはよく分からなかった。ごめん。パス。

＞＞[人の行列] 　 　 　 ＝[1フレーム分の回転行列]×[1フレーム分の移動行列]×[前フレームの人　　の行列]
＞＞[動く床の行列]　　 ＝[1フレーム分の回転行列]×[1フレーム分の移動行列]×[前フレームの動く床の行列]

の部分は例として出したつｍりだった。でも誤解を招いたかもね。ごめんね。

>>876

名前を書き忘れた。877=868ね。

もしかして、「動く床」が予め定められたコースを動くものだとすれば
＞＞[動く床の行列]　　 ＝[1フレーム分の回転行列]×[1フレーム分の移動行列]×[前フレームの動く床の行列]
は不適当だ。ということかな。

うん、その通りだと思う。

>もしかして、「動く床」が予め定められたコースを動くものだとすれば
ブランコみたいに片方に乗ると、乗った位置に応じて傾くという動的な床は
どうなるんでしょ？プレイヤーが床の姿勢を決めて、でも床の姿勢が決まらなければ
プレイヤーの姿勢も決まらないデッドロック問題。

ブランコの片方に乗る？いまいちイメージがつかめぬ。
シーソーというなら分かるが。

真面目にやるなら、力学の話になるよ。

>879
１．全物体の移動ベクトルに重力加速度を加算
２．物体（プレイヤー、敵等）が、傾く床にめり込んだ量と（支点からの）位置で適当に床を傾かせる。
　　同時に、めり込んだ物体を床の上に戻す。
３．再度傾きの行列を物体にフィードバック

こんな感じで、２パスにすればよい。
（２）の計算は物理計算を厳密に行っても良いし、適当にそれっぽい値で処理してもいい。

>[人の　　(座標系を表す)行列] は 「動く床」　　　　を基準にした行列ね。
>[動く床の(座標系を表す)行列] は 「ワールド座標系」を基準にした行列ね。

ということは、動く床の上にいるキャラって、
その床のローカル座標系での姿勢を保持しているものなのかな？
だとしたら、仮にそのキャラの構造体があった時、ワールド座標での
姿勢Matrixのメンバ保持は、それほど重要性がないということ？

>882
そのゲーム次第だし、その物体次第。
プレイヤーが人なら、落ちないように姿勢を垂直に保とうとするだろうし、
車とかの場合なら当然床のMatrixに左右される。

グルグル回る丸太のような床って、どのような座標系で表現するの？
平面床なら分かるんだけど

>>884
(1)
まず、丸太に着地した瞬間、そのプレイヤーのワールド座標系から、
丸太の中心点を原点とするローカル座標系での座標、姿勢を求める。

(2)
以後、球面にいることを意識せず、平面上で普通に１フレームだけ移動させる。
この時、プレイヤーの座標などには一切いじらず、前のフレームとの
姿勢・位置差分マトリックスのみを作成する。

(3)
次に回転している丸太の１フレーム分の姿勢差分マトリックスを求める。

(4)
(2)と(3)で求めた二つの差分マトリックスを合成し、それをプレイヤーの
前のフレームの姿勢マトリックスに合成して、次のフレームの姿勢マトリックスとする。

これで、プレイヤーは動かない場合は、足を丸太の上に張り付いたまま丸太に
依存して移動します。逆さになってもコウモリみたいに張り付いたままなんで、
実際には、毎フレーム、姿勢をワールド座標に変換し、体の軸の向きが丸太の
上に乗っているかどうかのチェックが必要。

Direct3D での W-Buffer と Z-Buffer の決定的な違いって逆数以外に
何があるんですか？

Wバッファって聞かなくなったけど、どうなっちゃったんだろう
ハードでの対応は進んだんだろうか？
逆数演算がネックで放置？普及しないので　互換性を考えると使えない機能とか？

Ｗゴッホになったと聞きました。

逆数というか、Perspectiveな歪みがある空間でZ密度がnearもfarも均等である
事が主たる目的だと思うんだけど…。（だからOrthographicなビューでは意味無し）

RasterCapsのD3DPRASTERCAPS_WBUFFERが立ってれば、使えますぜ。＞W-Buffer
結構最近のカードはサポートしてると思うけど。

あと、このスレのどうでもいい質問は
Real-Time Rendering(ISBN 1-56881-101-2)
を読めばだいたい解決する。一通り目を通しておくことをお勧めする。

WバッファがZバッファより優れてるなら、もっと入門書で取り上げてていいと思うんだけど
イマイチ日陰の存在なのはなんでだ〜？

RADEON8500は標準では使えなかったような＞Wバッファ
Meltdownでも、重要性が下がった機能として挙げられていたしね。

>>891
まぁ、Zに16bit位の精度しか与えられなかった時代の技術ですからな。

PS2 のメタルギアソリッドで使われてるバンプマッピングは
どのように実現されてるんだろ。Ｘ箱ならともかく、ps2で・・・

＞結構最近のカードはサポートしてると思うけど。
「結構」程度じゃ困るから、やっぱ使えないや。

＞Real-Time Rendering(ISBN 1-56881-101-2)
これって英語ですか？
英語読めないし、勉強する時間あったら仕事しなきゃいけないし。
もっと学校で勉強しとけば良かった。数学では困らないけど、エイゴがー！

それにしてもアクションゲーの座標変更処理が、
一般の書籍に書かれているような、座標メンバへの演算操作で
ないことを知って、ちょっとビクーリ。

>>895
？？？どういうこと？？？

>>893

http://www.microsoft.com/japan/developer/directx/welcome/dsmsdn/directx11192001.asp

>>893
対光源の移動をよく確認してないから何ともいえないけど、（少し浮き出てる血管とかの
部分だよね？）あれはエンボスじゃないのかな？頂点のローカルな座標系
（ds, dt, dsとdtの外積）に光線ベクトルを投影してエンボスをその分動かして凹凸を描いて
やればいいんでない？
# まぁDOT3もできないことはないけど、ハードウェア依存な狭い世界の話になるので。

>>895
>一般の書籍に書かれているような、座標メンバへの演算操作

？

Real-Time Rendering マンセー sage

>>893
CG-WORLD Vol41によると。
マルチパスのαチャンネル合成らしいが…。

＞マルチパスのαチャンネル合成らしいが…。
んー、それだけじゃ分からない・・・。
何枚か重ねて実現していることまでは分かるんだけど、
どのように重ねてるかが疑問点。

＞頂点のローカルな座標系
＞（ds, dt, dsとdtの外積）に
ここでいう、ds,dtとはなんでしょう？

>902
影情報をαで表してるなら、面の法線と光源の角度から、ずらす量が求まる気が。

>>903
エンボス用テクスチャ自体の座標系、つまりエンボステクスチャがその頂点中で
どういうテクスチャ方向を向いているかという事。

平面で考えてみると判りやすい。平面でエンボスを作りたいとき、右下に少しずらした
テクスチャで加算、左上に少しずらしたテクスチャで減算すると右下から照らされた
凸凹があるようにみえるでしょ？その時にずらす量は光源の向きによって変わるん
だけど、この平面の時は絶対的な座標系がその平面だから単純に解決できる。
だけど、３Ｄのサーフェースに貼られた場合、３Ｄ的に世界に対してどういう方向で
貼られているかを理解する必要がある。それを表すための座標系と考えれば
だいたいいいと思う。

もっと詳しい（正確な）解説はこちらに。
http://developer.nvidia.com/view.asp?IO=jp_presentations
http://www.acm.org/tog/resources/RTR/bump_map.pdf