[表示 : 全て 最新50 1-99 101- 201- 301- 401- 501- 601- 2chのread.cgiへ]
Update time : 03/03 11:09 / Filesize : 154 KB / Number-of Response : 657
[このスレッドの書き込みを削除する]
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧] [類似スレッド一覧]


↑キャッシュ検索、類似スレ動作を修正しました、ご迷惑をお掛けしました

3Dグラフィックスプログラミング



1 名前:デフォルトの名無しさん [2006/08/10(木) 04:50:09 ]
DirectXやOpenGL、あるいは言語などにとらわれず、
純粋に3Dグラフィックスのプログラミング技術(アルゴリズムや数学など)
について語るスレです。


357 名前:デフォルトの名無しさん mailto:sage [2007/09/02(日) 15:52:03 ]
分かるかこんなの!

358 名前:デフォルトの名無しさん [2007/09/03(月) 10:38:15 ]
>>352>>356

アドバイスできないなら、ひっこんでろカス
傍で見ていても不快になる

359 名前:デフォルトの名無しさん mailto:sage [2007/09/03(月) 14:08:40 ]
すみませんでした

360 名前:デフォルトの名無しさん [2007/09/10(月) 22:02:51 ]
(´・ω・`) ショボーン

361 名前:デフォルトの名無しさん mailto:sage [2007/09/12(水) 12:19:31 ]
スクリーン座標→ワールド座標の変換をする関数を作りたいのですが(D3DXVec3Unprojectみたいな)、

これどういう風に計算するんですか?教えてください
もしくはどこか参考になるサイトがあれば。逆の場合なら解説しているサイトはたくさん見つかるんですけど…


362 名前:デフォルトの名無しさん [2007/09/12(水) 12:20:28 ]
 

363 名前:デフォルトの名無しさん mailto:sage [2007/09/12(水) 12:32:38 ]
投影行列の逆行列を求めて、座標を表すベクトルを掛ける。

364 名前:デフォルトの名無しさん [2007/09/12(水) 12:45:08 ]
>>363
ありがとうございます


365 名前:デフォルトの名無しさん mailto:sage [2007/09/12(水) 13:40:51 ]
>>358

アドバイスできないなら、ひっこんでろカス
傍で見ていても不快になる殺すぞ!!



366 名前:デフォルトの名無しさん mailto:sage [2007/09/12(水) 18:26:53 ]
   ∧_∧  / ̄ ̄ ̄ ̄
  ( ・∀・) < PRT!!!
⊂/  9)  \____
q(   /
  >  >

367 名前:デフォルトの名無しさん mailto:sage [2007/09/13(木) 23:39:40 ]
3Dアクションの当り判定って一般的にはどうやってとってるの?
進行方向ベクトルのさす1点がポリゴンに交差しているかだけを
見ると、曲がり角に肩をぶつけるような状況の時に抜けちゃうと
思うんだよね。進行方向から扇状に何点か見る感じですか?

368 名前:デフォルトの名無しさん mailto:sage [2007/09/13(木) 23:51:19 ]
モデルを構成する全ポリゴンと交差判定すればいい

369 名前:デフォルトの名無しさん mailto:sage [2007/09/13(木) 23:56:19 ]
それ重杉でしょ…。

370 名前:デフォルトの名無しさん mailto:sage [2007/09/14(金) 00:12:18 ]
当たり判定用のモデルを用意したら良いんじゃないの。単純なフォルムの奴を。

371 名前:デフォルトの名無しさん mailto:sage [2007/09/14(金) 00:45:18 ]
ポリゴン同士の交差判定は出来ればしたくないなぁ。
「辺の数」+「辺の数」x「線分とポリゴンの交差判定」を
「モデル1のポリゴン数」x「モデル2のポリゴン数」
やるわけでしょ?重いなぁ。

372 名前:デフォルトの名無しさん mailto:sage [2007/09/14(金) 00:46:16 ]
こまかいけど、
「辺の数+辺の数」x「線分とポリゴンの交差判定」ね。

373 名前:デフォルトの名無しさん mailto:sage [2007/09/14(金) 07:42:12 ]
単純図形でとる

374 名前:デフォルトの名無しさん mailto:sage [2007/09/14(金) 08:02:19 ]
単純図形で取ってもさ、早く移動する物体だと検出すりぬけちゃうでしょ
みんなどうやってるんだろう

375 名前:デフォルトの名無しさん mailto:sage [2007/09/14(金) 08:50:55 ]
もまいらおはようさん。
この話ってキャラとBGの当りのことだよね?確かに一般的な
方法論があるか気になる。やったこと無いけど、円(球)とモデルの
当り判定は軽く正確に取れないのだろうか。



376 名前:デフォルトの名無しさん mailto:sage [2007/09/14(金) 21:54:36 ]
素人考えの疑問への答えならこの本に大体載ってるだろう
ttp://www.borndigital.co.jp/book/program/4-939007-91-X/4-939007-91-X.html

377 名前:デフォルトの名無しさん mailto:sage [2007/09/14(金) 22:50:28 ]
>>376
ゴメン、どの辺が素人考えなの?その当り、素人で無い人は
どんな感じでやってるの?

378 名前:デフォルトの名無しさん mailto:sage [2007/09/14(金) 23:39:21 ]
素人じゃない人は>>376に載ってるような方法(or さらに発展したもの)をやってると思う。
衝突判定とか詳しく勉強したいなら買っておいて損はない。

おおざっぱに説明すると
1, キャラの境界箱みたいのをあらかじめ作る。
2 空間を分割
3 各分割した空間にどんなキャラがいるか調べる。
4 キャラと衝突するのは同じ空間または隣接する空間にいるキャラだ
5 4で衝突する可能性のあるキャラ同士を集め、1で求めた境界箱の衝突チェック
5 境界箱が衝突したらもうちょい細かいモデルで衝突チェック

詳しく知りたい人は BVH(bounding volume hierarchy),
BSP treeとかググればいいかも

379 名前:デフォルトの名無しさん mailto:sage [2007/09/15(土) 00:13:50 ]
>>378
境界球とかBoxで処理切るのとか、視推台との位置関係で
表示に関係無いモデルの座標変換を省いたりっていうやつは、
今の話題ではないと思うんだよね。>>367は、背景とキャラクタの
厳密で高速なあたりの取り方を聞いてるんじゃないの?

頂点を減らした簡素な背景の当りモデルを一定の区間で分割して、
>>378が言うように自分が存在する周辺27(XZで済む場合は9かな)
区間に対応した当りモデルに対して、キャラが持つ簡素な当り
モデルに対するポリゴン交差判定を実行するってのが結局一番良い
のかね?これならBGを切る区間の幅がキャラのスフィア半径を
超えない限りは大丈夫そうな感じはするけど。
でも、これって理論は簡単だけど、データ管理とか、ソースの
可読性の面で、相当なデメリットを被るから、もっと簡単なやり方を
皆やってるのではないかと思って漏れも聞きたいのだけど。

380 名前:デフォルトの名無しさん mailto:sage [2007/09/15(土) 01:39:55 ]
領域が重複するように区切ると、1区画だけで済むよ。

381 名前:デフォルトの名無しさん mailto:sage [2007/09/15(土) 08:52:30 ]
でかい1区画も小さい27区画もあまり変わらなくない?

382 名前:デフォルトの名無しさん mailto:sage [2007/09/15(土) 10:18:39 ]
全然違うよ。

区画を拡張するサイズは、判定に使うのが球なら半径の分。
(隣接した区画が半径分ずつ広がるから、直径分重複する)

1区画の大きさが100*100*100のサイズだとして、全方向に4だけ拡張すると
1.26倍の体積になる。これで、半径4以下のサイズなら漏れ無く判定できる。
この方法は、特に八分木と相性がいい。

それと、1区画が必要以上に小さくなければ27区画も判定する必要もなく、
一番近い8区画で十分。

383 名前:デフォルトの名無しさん mailto:sage [2007/09/15(土) 10:43:01 ]
>>382
丁寧にありがとう。なるほど、結構効率が違いそうだね。
どうしても、ある区画と、その隣の区画には、同じポリゴンが
存在することになってしまうと思うから、最大の速度効率で
考えると、キャラ半径分で区画を細切れにして、各区画に
割り当てるデータは、中心を含めた周囲27区画(9区画なのかな?)の
広さをカバーしたものにする、っていうのが最も早そうだね。
区画を細かくすればするほど、速度は上がるが、メモリ消費は
大きくなるって感じかね。

ところで、27区画っていうのは中心を含めた3x3x3の区間で、
ルービックキューブのような状態なんだけど、
8区画っていうのは3D?それともXZ平面上での話?

384 名前:デフォルトの名無しさん mailto:sage [2007/09/15(土) 12:15:46 ]
>割り当てるデータは、中心を含めた周囲27区画(9区画なのかな?)の
>広さをカバーしたものにする
正確には中心の区画+半径分の広さをカバーする
ですね。

385 名前:デフォルトの名無しさん mailto:sage [2007/09/15(土) 16:32:27 ]
>>383
8区画ってのは、重複領域がない場合に検査する必要のあるサイズ。
球の直径より小さいと27区画(3*3*3)のチェックが必要だが、直径より
大きければ8区画(2*2*2)でいい。

それと、重複領域がない場合は、通常は地形のポリゴンは隣接する
複数の区画を貫いているから、周囲の区画もチェックするというのは
実際には同じポリゴンに対する判定ばかりで無駄が多い。



386 名前:デフォルトの名無しさん mailto:sage [2007/09/15(土) 16:54:06 ]
なるほど〜。よくわかったです。
けど、高速の時でも抜けないように判定する方法はあるの?
進行方向に対してなるべく沢山レイを飛ばすしかないのかな?

387 名前:デフォルトの名無しさん mailto:sage [2007/09/15(土) 17:11:37 ]
元の質問(>>367,374)は速い移動で抜けてしまうという話だったか。

基本的には、肩がこする程度の抜けは無視するものだと思う。
常識的な速さでfpsが極端に低くなければ、移動先で球なり円柱で判定を
取るだけで、荒が目立つほどでもないかと。
そもそも、判定用の図形は実際のキャラクタと厳密に同じ大きさではないから
それの端が多少めり込んだところで問題ないかと。

ただ、移動前-後の座標で直線を作って、その直線×地形の判定は
入れておいた方がいい。
3D格闘ゲームでは点と点を繋いだ直線ではなく、球と球をつないで
ソーセージ型で判定していたりするが、一般のゲームでそこまでしても
コストに見合うほどの効果はないと思う。

388 名前:デフォルトの名無しさん mailto:sage [2007/09/15(土) 19:21:02 ]
>>387
元の367です。色々なアドバイス有難うございました。
結論としては、キャラの1フレームの移動量を抑えて、
@キャラの簡単なモデルA球や円柱B箱 などで、
移動先の地形と判定を取る。
っていうのが一般のゲームでは基本的な方法という
ことですね。
他にもBGを区分けする方法など、とても参考に
なりました。有難うございました!

389 名前:デフォルトの名無しさん mailto:sage [2007/09/15(土) 21:25:53 ]
ソーセージは初めて聞いた。
カプセルと表現することが多いように思うけどな。

壁に向かって斜めに動く時に、カプセルでやるほうが綺麗に押し戻せるので、コストに見合う効果があると思う。壁でクラッシュするならいいけど。

390 名前:デフォルトの名無しさん mailto:sage [2007/09/15(土) 23:11:17 ]
カプセルで当り取るヒントキボン

391 名前:デフォルトの名無しさん mailto:sage [2007/09/15(土) 23:21:34 ]
球+円柱+球

392 名前:デフォルトの名無しさん mailto:sage [2007/09/15(土) 23:26:15 ]
速度ベクトルと半径(というか形状のベクトル)じゃないの
こっちにその理論がのってるお
ttp://www.gogo3d.com/products/mathema/index.html
そのまま実装すると重いから手抜きしたり工夫したりしないとだめだが

393 名前:デフォルトの名無しさん [2007/11/03(土) 10:49:50 ]
CPUでOpenGLをエミュレートするプログラムを書きたいのですが
何を参考にすればいいですか?
本かソースを紹介してください


394 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 10:50:36 ]
mesaしか知らない。

395 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 11:04:57 ]
何をやりたいかにも依るけど、TinyGL は小さくてお勧め
OpenGL|ES でよければ Vincent



396 名前:デフォルトの名無しさん mailto:sage [2007/11/03(土) 19:06:43 ]
以前なんか実行ファイル形式のTIPS網羅したマガジンうpしてくれてたよね
誰か再うp or 続編があったらうpしてください

397 名前:393 mailto:sage [2007/11/04(日) 13:47:50 ]
>>394-395
ありがとう
Vincentで逝ってみるよ


398 名前:デフォルトの名無しさん mailto:age [2007/11/26(月) 12:31:19 ]
正八面体を描画するプログラミングを教えて!!!

399 名前:デフォルトの名無しさん mailto:sage [2007/11/26(月) 12:55:05 ]
質問です

四次元立方体を描画する猿を探せ


400 名前:デフォルトの名無しさん mailto:sage [2007/11/26(月) 14:21:25 ]
lib3dsを使って3dsファイルを読み込んで描画したいのだけど、具体的にどうすりゃいい?
lib3ds_file_loadでファイル読み込めてると思ってるのだが、正しいのか?

401 名前:デフォルトの名無しさん mailto:sage [2007/11/26(月) 14:26:31 ]
>>400
読めただけでは描画はされません。描画してください。

402 名前:デフォルトの名無しさん mailto:sage [2007/11/26(月) 14:44:26 ]
具体的にはlib3dsのサンプルみりゃいいんじゃなかろうか

403 名前:デフォルトの名無しさん mailto:sage [2007/12/01(土) 16:11:56 ]
>>398
ラミエル萌え

404 名前:デフォルトの名無しさん mailto:sage [2007/12/30(日) 20:02:55 ]
現在特定用途用にレイトレレンダラを組もうと考えているのですが、
1〜20数四角ポリゴンでテクスチャ、透明度を使用し、影や光源を考えない場合、どのような最適化方法
を適用するのがいいでしょうか?目標としては、テクスチャなしの640x480で15fpsくらいを出せるようにはしたいです。
バウンディングボリュームは当たり前として、空間分割もやった方がいいのでしょうか?

405 名前:404 [2007/12/31(月) 00:01:19 ]
ちょっと上げさせてもらいます。



406 名前:デフォルトの名無しさん mailto:sage [2007/12/31(月) 19:49:07 ]
>>404
"光源を考えない"の意味が分からない。
どんなに反射屈折しても光源にたどり着かないなら真っ黒な画像になると思うのだけれども。
多分、ポリゴン色とでもいうべきものを採用という意味なのだろうと思う。
そうだとすると、Z ソートしてポリゴンをラスタライズするのでは何がいけないのかが分からない。

空間分割は、その程度の対象個数だと、実行パスが複雑になることの弊害が多すぎるように思うけど、データにもよるし、結局のところやってみないと分からない。
これもやってみないと分からないのだが、SIMD 演算機があるなら、対象ポリゴンを32個固定にしてアンロールしたヒットチェックを作ったほうが速いかもしれない(その個数ならね)。

ところで今どのくらいの fps がでてるの?

407 名前:デフォルトの名無しさん mailto:sage [2008/01/02(水) 05:19:16 ]
3Dモデルを出力するツールの作成を検討しています。
出力フォーマットは、汎用性を考えてFBX形式で出力を考えているんですが、
目だった問題点とかあるでしょうか?
フォーマット仕様を読む限りではあまり無さそうな印象ですが。

408 名前:404 [2008/01/02(水) 13:36:42 ]
>>406
遅れてしまってすいません。

光源を考えないというのはポリゴン色を使うということであってます。
ただ、ポリゴンに透明度を適用し、ポリゴン同士の前後関係を正しく
表示したいため、OpenGLなどを使うことはできません。
また、オフスクリーンでレンダリングする必要があるので、
ハードウェアの恩恵を受けることができず、ポリゴンを細分化
するとOpenGLではとても重いので・・・

まだ設計の段階で実際に組んだわけではないのでfpsが
どれくらいでるかわかりませんが、とりあえずバウンディングボリューム
のみでやってみます。
ありがとうございました。

409 名前:デフォルトの名無しさん mailto:sage [2008/01/02(水) 21:32:32 ]
OpenGLでもオフスクリーンレンダリングできるし、
ハードウェアの恩恵も得られるでしょ。
半透明ポリゴンの正確な描画も一手間かかるだけで問題ない。

410 名前:404 mailto:sage [2008/01/02(水) 22:39:08 ]
>>409
この前OpenGLでオフスクリーンレンダリングすると
どうやってもソフトウェアレンダリングになってしまって重くて
使い物にならなかったのですが・・・
一応GeForce7600GSを積んでるのでハード的には問題ない
はずですが、なぜでしょう?

411 名前:デフォルトの名無しさん mailto:sage [2008/01/02(水) 23:59:11 ]
具体的ななコードをだせ

412 名前:404 mailto:sage [2008/01/03(木) 01:57:51 ]
>>411
今手元にコードはないのですが、処理の流れは

1.32bitRGBのHBITMAPを作成
2.それを元にデプスバッファ32bitのレンダリングコンテキストを作成
3.テクスチャ、アルファ、デプステストを有効に
4.512x512未満のテクスチャを作成
5.レンダリング

という流れですが、この方法だとハードは使用されないようです。

413 名前:404 [2008/01/03(木) 02:00:12 ]
>>412
この方法というのは、HBITMAPを使用したオフスクリーンレンダリング
のことです。

414 名前:デフォルトの名無しさん mailto:sage [2008/01/03(木) 09:07:05 ]
既存のウィンドウかダミーウィンドウからコンテキスト作ってFBOかpbuffer使え。
拡張を使うのがいやならバックバッファーに書いてフロントバッファーは放っとけ。

415 名前:404 mailto:sage [2008/01/03(木) 11:32:04 ]
>>414
わかりました。ダミーウィンドウ作って試してみます。
ありがとうございました。



416 名前:デフォルトの名無しさん mailto:sage [2008/01/05(土) 22:15:13 ]
>>412
すべて半透明ならデプスバッファは要らないでしょ。
どうせ、すべてのポリゴンを奥から順に描画するのが前提になる話しだし。

ところで、ポリゴン同士は交差するの?
ならば、交差した部分でポリゴンを分割した方がいいのだけど、>408 の細分化ってコレを指してる?

417 名前:デフォルトの名無しさん mailto:sage [2008/01/07(月) 14:17:05 ]
スポットライトのライティング計算式ってどっかにない?
調べても、線光源とか点光源くらいまでしか出てこない。

418 名前:デフォルトの名無しさん mailto:sage [2008/01/07(月) 16:10:08 ]
>>417
Direct3Dのスポットライトモデルでよければ、こんな感じ。
ttp://msdn.microsoft.com/library/ja/DirectX9_c/directx/graphics/programmingguide/fixedfunction/lightsandmaterials/spotlightmodel.asp

419 名前:デフォルトの名無しさん mailto:sage [2008/01/09(水) 01:09:03 ]
>>418
サンクス。無事実装できました。

420 名前:デフォルトの名無しさん mailto:sage [2008/01/20(日) 12:44:49 ]
どうやって高速物体の衝突検出すんだよ

421 名前:デフォルトの名無しさん mailto:sage [2008/01/20(日) 12:49:27 ]
>>420
それはグラフィックスとは関係ないと思うが、
ヒントはスイープ体。

422 名前:デフォルトの名無しさん mailto:sage [2008/01/22(火) 03:19:56 ]
いきなり喧嘩腰だなw

423 名前:デフォルトの名無しさん mailto:sage [2008/01/22(火) 19:07:09 ]
仮想空間って宇宙よりヤバくね?
光速越えも楽勝

424 名前:デフォルトの名無しさん mailto:sage [2008/01/23(水) 12:18:08 ]
>>423
ニュートンの力学法則だけでシミュレーションすればそうなるな。

425 名前:デフォルトの名無しさん mailto:sage [2008/01/23(水) 20:57:27 ]
つまりちゃんと特殊相対論でシミュレートしろとw



426 名前:デフォルトの名無しさん mailto:sage [2008/01/25(金) 02:22:57 ]
特殊相対論の影響が無視できないような物理シミュレーションが必要になるのはどんなときですか?
>>420
物体が変形しないconvexならseparating axisでググ
変形しながら移動する三角形の衝突検出って難しいよ;;

というかこういう話は3Dアルゴリズム全般スレですべき?
それとも物理シミュレーションスレでも立てる?!

427 名前:デフォルトの名無しさん mailto:sage [2008/01/25(金) 08:17:19 ]
そんなスレ立ててもすぐ落ちる。

428 名前:デフォルトの名無しさん mailto:sage [2008/01/25(金) 08:24:13 ]
もうこういうことに興味持ってるの一握りの予感
日曜プログラマはみんな儲かりそうなウェブ方面に行っちゃったし。

429 名前:デフォルトの名無しさん mailto:sage [2008/01/25(金) 12:42:02 ]
>>420
時間の刻みを小さくすれば良いじゃん。


430 名前:デフォルトの名無しさん mailto:sage [2008/01/25(金) 12:44:58 ]
>>426
ローレンツ短縮の短縮率が、必要な精度より大きくなったらで良いんじゃないか


431 名前:デフォルトの名無しさん [2008/01/25(金) 13:02:54 ]
>>420
交差するかしないかだよ。


432 名前:デフォルトの名無しさん mailto:sage [2008/01/25(金) 23:10:14 ]
>>420
ググってひっかかったこれがよい
www.cs.unc.edu/~lin/COMP259-S05/LEC/14.ppt

>>428
ウェブ関係のアルバイトをやったことはあるが,ウェブ系より3D系のほうが100倍楽しいぜ


433 名前:デフォルトの名無しさん mailto:sage [2008/02/04(月) 19:54:53 ]
これからOpenGLかDirectXをはじめようと思うんだけど
どっちが良いとかってある?
ちなみに今まではJavaメインでCGプログラムしてた。
あと少しCができる程度。

434 名前:デフォルトの名無しさん mailto:sage [2008/02/04(月) 20:03:27 ]
なにがやりたいんだ

435 名前:デフォルトの名無しさん mailto:sage [2008/03/16(日) 12:51:18 ]
>>420
つ「ゲームプログラミングのための3Dグラフィックス数学」



436 名前:デフォルトの名無しさん [2008/04/14(月) 18:11:12 ]
3Dはある程度までレベルあがると物理との戦いになるな

437 名前:デフォルトの名無しさん mailto:sage [2008/04/14(月) 18:21:25 ]
>>436
それは別問題。

438 名前:デフォルトの名無しさん mailto:sage [2008/04/14(月) 18:46:35 ]
CPUはある程度までレベルあがると量子論との戦いになるな

439 名前:デフォルトの名無しさん mailto:sage [2008/04/15(火) 16:04:51 ]
ある程度以上の物理って言うとデータ転送速度とオブジェクトサイズに生成速度とHDDアクセス時間とかそういうのかな?


440 名前:デフォルトの名無しさん mailto:sage [2008/04/15(火) 18:59:35 ]
ライト増やすとすぐ重くなるのに何でデモでは幾つもギラギラ光ってんだよ!!

441 名前:デフォルトの名無しさん mailto:sage [2008/04/16(水) 02:39:13 ]
>>440
・ギラギラして見えるのは実はビルボードとかでライティングに影響してない
・ライトから一定距離内にある物しかライティングしてない。
・Deffered shading
など考えられないでしょうか?!

GeforceでPhysXが動くようになったらしいよ
ttp://www.tomshardware.com/2008/04/14/nvidia_gpu_physics_engine_up_and_running_almost_/

442 名前:デフォルトの名無しさん mailto:sage [2008/04/16(水) 18:51:43 ]
3Dマークの光る蝶々と、PS3&pspのメニュー画面の背景のモヤーってなってるのはどうやって描いてるのか教えて!

443 名前:デフォルトの名無しさん mailto:sage [2008/04/17(木) 02:22:57 ]
>>442
どんなんか見てないのでよくわからんが、たぶん
最初に蝶をライティング無で白くレンダリングしてそれをぼかして
その上に蝶をレンダリングしているんでないでしょか。

444 名前:デフォルトの名無しさん mailto:sage [2008/04/17(木) 19:09:44 ]
いや、あの蝶々は光源になってたから、他にも処理があると思う。。

445 名前:デフォルトの名無しさん [2008/04/20(日) 19:20:39 ]
Bounding Volume Hierarchiesって何?



446 名前:デフォルトの名無しさん mailto:sage [2008/04/21(月) 05:32:19 ]
octreeみたいな奴のことか?

447 名前:デフォルトの名無しさん mailto:sage [2008/04/21(月) 22:26:46 ]
そうなのか?
実装しようと思ってHow to pack trees探しているけど
逆から始まっていたり、文字が選択できなかったり、文字の検索が正常に出来なかったりとか変なのしかない。

448 名前:デフォルトの名無しさん mailto:sage [2008/04/21(月) 23:19:10 ]
>>445
簡単に説明すると
・オブジェクトorポリゴンのbounding volumeを作る
・隣接するbounding volumeをさらに大きなbounding volumeで囲む
・これを繰り返してbounding volumeの階層構造を作る。

で、何かと当たり判定するときは
・一番上のbounding volumeと当たり判定する。
・当たったらその下のbounding volumesと当たり判定する。
・当たったらその下のbounding volumesと当たり判定・・・
というのを繰り返して当たったオブジェクトを見つける。

で,Bounding Volume Hierarchiesはレイトレとか
物理シミュするときの衝突検出処理の高速化に使われてるわけだが
>>445はどのような目的で使うつもりなの?

real time collision detectionって本にBVHの説明が載ってるよ

octreeとほぼ同じ目的で使われるけど、違うアルゴリズムだよ。


449 名前:445 mailto:sage [2008/04/21(月) 23:41:33 ]
物理シミュの衝突判定で使うつもり。OBBTree(実装済み)と組み合わせて高速な
衝突判定プログラムを作りたい。
ttp://gamma.cs.unc.edu/COLBVH/
>real time collision detection
価格が高いよ・・

450 名前:デフォルトの名無しさん mailto:sage [2008/04/22(火) 06:14:55 ]
この手の高い本は大学図書館に買わせているけど、たまに研究室にあったりして
購入してくれないことがあって困る。

自分はこれ関係の学部生じゃないんだがね。

451 名前:デフォルトの名無しさん [2008/07/09(水) 12:57:40 ]
Mayaで作った物体形状をファイルに落としたものがあったとして
それの中身(物体形状データ)を調べるにはどうしたらいい?

Autodeskが提供してるライブラリとかある?

何でもいいのでヒントになることあったら教えてください

452 名前:デフォルトの名無しさん mailto:sage [2008/07/09(水) 23:30:34 ]
それはこのスレなのかな…?
FBXについて調べてみ
SDKあるから

453 名前:デフォルトの名無しさん mailto:sage [2008/07/10(木) 22:55:02 ]
人間のモデルを作ったとするじゃん
その人間の髪だけ物理演算でサラサラさせたり、皮膚だけ弾力を計算させたり、どうやるの?
ボーンで髪を動かすくらいしかわからない

454 名前:デフォルトの名無しさん mailto:sage [2008/07/11(金) 01:41:02 ]
>>453
以下はリアルタイムレンダリングの話だけど。

1.オブジェクト単位の物理演算
これはいま大抵のところがやってる。段ボール箱を投げたり、
銃で缶を撃つと転がったりするヤツ。これは簡単。

2.ボンを物理演算する
ラグドールなんかはこの方法。こちらも簡単だし、軽い。
もちろん、ボンの有効角度の設定とか、肉の厚さ、ボンの重さ、間接の摩擦係数とかの
パラメータ自体を増やす必要がある。物理演算するとしたら現状はこっちが無難。

3.メッシュ自体のデータをいじる
メッシュのデータをいじるのでロックする必要がある。ロックすること自体は別段、悪い事じゃないけど、
メッシュの物理演算は非常に重いし、突き抜けとか避けるのは結構面倒。頂点シェーダに
パラメータを与えて、っていう方法も考えられるが、細かいコントロールが当然効かない。
シェーダモデルが3になれば、多少は状況が変わるのかな?

4.パーティクル
これはメッシュとはちょっと違う系の物理演算。これはそんなに重くないので、
意外と実装しやすい。質点の集合で管理する。水とかの流れとかだな。

ディアブロ3は 1.2.4.はやってそう。ブリザードはそんなにCGに凝るメーカーじゃないから、
いまは 1.2.4.ぐらいはやって当たり前なんだろうな。

455 名前:デフォルトの名無しさん mailto:sage [2008/07/11(金) 01:44:13 ]
>>453
なんか上のを書いたけど答えになってないな・・・。

簡単に書くと、
メッシュの物理演算は基本的には頂点と頂点をつなぐ
線分をゴムみたいな弾性体だと仮定して計算する。

メッシュ 物理演算あたりでググってみたら?



456 名前:デフォルトの名無しさん mailto:sage [2008/07/11(金) 09:06:56 ]
>>453
それはグラフィックスの問題だろうか。むしろモデリングやシミュレーションの問題だと思われ。
グラフィックスの問題と言えるのは、>>454の処理がおわって具体的な幾何学オブジェクトを描画する部分。

457 名前:デフォルトの名無しさん mailto:sage [2008/07/11(金) 13:52:42 ]
レンダリングだけがグラフィックスの問題というわけでもなかろうに。硬いこと言うなよ。






[ 続きを読む ] / [ 携帯版 ]

前100 次100 最新50 [ このスレをブックマーク! 携帯に送る ] 2chのread.cgiへ
[+板 最近立ったスレ&熱いスレ一覧 : +板 最近立ったスレ/記者別一覧]( ´∀`)<154KB

read.cgi ver5.27 [feat.BBS2 +1.6] / e.0.2 (02/09/03) / eucaly.net products.
担当:undef