DirectX総合スレ (Part5)

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

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

**名前は開発中のものです。** · 2006/09/15(金) 00:59:55

難しいってのはループのことかね
それはまた別の方法を考えるべき屋根

**名前は開発中のものです。** · 2006/09/15(金) 00:59:55

>>117
そうそう。
できるじゃん。
よく考えてよ。
螺旋階段を辿るようにぐるっとつないでいけばいいだけじゃん。

**名前は開発中のものです。** · 2006/09/15(金) 01:05:44

最初スーファミのF-ZEROとメガドラのソニックしか思い浮かばなくて
何の事だかわからなかったのはオジサンだけの秘密だ。

98 · 2006/09/15(金) 01:24:39

>>118
まさか、1[cm]単位みたいな高密度の標高データを
複数レイヤーで持てとか言うんじゃねーだろうなー。
　
格子状に配置された標高データだと表現力に自由度ないから
無理矢理密度を上げて対応してんのか？
　
俺は螺旋階段みたいな変な形状の建造物は衝突判定用モデルを用意してるよ。
この場合なら直立した中空シリンダーの中に階段のOOBBを敷き詰めて終わり。

**名前は開発中のものです。** · 2006/09/15(金) 01:39:26

×1[cm]単位みたいな高密度の標高データを
○1[cm^2]単位みたいな高密度の格子を

**名前は開発中のものです。** · 2006/09/15(金) 02:07:22

>>118
なんでそんな脅してまでハイトフィールドを奨める…何かに取りつかれてるのか

**名前は開発中のものです。** · 2006/09/15(金) 06:09:31

ハイトマップなんてほんとにベタベタな地面にしか使わねーよ普通。
トンネル掘るのもめんどくせぇし、建造物はStaticMeshで当たり前。
UnrealEngineはハイトマップの使い方上手いけどな。

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

>>122
はぁ？なんでそんなことになるの？
マジで頭悪いの？

**名前は開発中のものです。** · 2006/09/15(金) 06:27:31

>>122
螺旋階段を辿るようにつないでいくって言ってるだろ。
脳みそ腐ってんのか？
つか、お前、人の話聞かないし、馬鹿だから余計なことばっかりやることになるんだぞｗ

**名前は開発中のものです。** · 2006/09/15(金) 08:30:34

階段なんて衝突判定もなにもせず計算で動かせばいい
法線方向はリミットつければいい

**名前は開発中のものです。** · 2006/09/15(金) 12:28:13

いちいちうるせぇな。
つべこべ言わずにハイトフィールド使えっつってんだろうが。
俺の言うことが聞けねぇってのか？

**名前は開発中のものです。** · 2006/09/15(金) 14:17:30

こんなことだからmixiに負けるんだお

**名前は開発中のものです。** · 2006/09/15(金) 16:44:30

んじゃぐだぐだになってきたところで地形関連ということでひとつ
ほとんどの3Dのゲームは壁に当たってなお直進すると壁にそって微妙に横にすべるような動きをしますよね
あれって業界内で統一されたデザインとしてわざわざあのような動きをするようにしているんでしょうか
それとも典型的な壁との衝突時の処理の副作用としてあのようになっているんでしょうか
DOOMは壁をこすりながら走って加速できるバグがありました
MMORPGとかでは進めなくなった時点で歩行をやめちゃう駄目仕様なものも結構あります
そこらへんみなさんどうしてますか？

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

壁に接触するたびに足が止まるとストレスになるから
わざわざそういう風に作ってあるんだろう

当たり判定壁ずりで検索すると解説してるサイトもある

**名前は開発中のものです。** · 2006/09/15(金) 17:49:16

漏れの場合球コリジョンで判定してヒットした壁の面法線方向に
めり込んだ分（球の半径-中心から壁平面への距離）戻してるから
勝手に壁ずりする。

**名前は開発中のものです。** · 2006/09/15(金) 20:38:46

>>133
ぐぐってでてくる壁ずり講座のが色々とあまり美しくない工夫をしてるのに対して
それだとすごい自然だなぁ
やっぱり見た目のメッシュとは別に当たり判定用のバウンディングボックスを設定するんですか

**名前は開発中のものです。** · 2006/09/15(金) 20:44:11

球コリジョンって書いてあるような

**名前は開発中のものです。** · 2006/09/15(金) 21:46:10

>>134
俺は検索かけたら真っ先に>>133の方法が出てきたが・・・

**名前は開発中のものです。** · 2006/09/15(金) 22:45:06

コリジョンである。
コリジョンっていう言葉のイメージは、
まるまるとしてて、つっかかりが無いが、ゲドゲドしたもの。
という感じである。
これを表している物は、丁度、キウイフルーツである。
あの、丸々としてるくせに、表面がジョリジョリと気持ち悪いそれである。
また、親父のジョリジョリした髭がそれである。
あの、短い髭によって摩擦が減少してるのに、ジョリジョリされると痛いあれである。
つまり、コリジョンとは、ジョリジョリが痛い親父の髭。という意味なのである。

**名前は開発中のものです。** · 2006/09/15(金) 22:50:28

ちがうよ。コリジョンて犬のことだろ。

**名前は開発中のものです。** · 2006/09/15(金) 23:01:55

信号が失われたときに再送するべき範囲のことだっけ

**名前は開発中のものです。** · 2006/09/15(金) 23:05:30

>>133
適度にブレーキがかかって具合がいいんだよな（ ´∀｀）

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

VIPのバカが釣りにはしゃいで喜んでいます

女子大生拉致監禁事件！？12くらい
http://ex16.2ch.net/test/read.cgi/news4vip/1158323954/

「どう見ても釣りだろ」
というと顔を真っ赤にしてレスしてくるので注意！！！

98 · 2006/09/16(土) 00:24:55

>>126-127
なんで火病ってるの？
　
でさ、お前の使ってるのって本当にハイトフィールドなの？
俺、>>117でハイトフィールドの定義を確認したよな？
これに対して君は>>118で「まあ、定義はどうでもいいけど」とか
はぐらかしてたけど、なんでかな？違うなら違うって言えよな。

**名前は開発中のものです。** · 2006/09/16(土) 00:29:49

ハイトフィールド（ハイトマップ）の基本的定義は
「XZ平面の格子点上でY(高さ)データをサンプリングした2D配列」
　
この定義で螺旋階段を表現しようとすると無理があると>>122-123で言っている。
層状の地形であるから多段でハイトマップ用意することになる。
階段は放射状に配置されている格子点サンプリングでは
うまく再現できない。高密度でサンプリングしてガタガタを減らすしかない。
　
例外的に、極座標系でサンプリングするなら高密度でなくて済むが
螺旋階段だけのためにわざわざ特例的な座標変換かますってどうよ。

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

×階段は放射状に配置されている
○階段は放射状に配置されているから

**名前は開発中のものです。** · 2006/09/16(土) 00:33:23

ゼルダトキオカ風のアクションゲーム用のレベルデータなら
洋物FPSのそれと相違点は少ないだろ。この手のレベルエディタなら
エンドユーザでも触れるし、レベルデータも見放題。
螺旋階段は厚みのある板を折り重ねて階段を作ってたりする。

**名前は開発中のものです。** · 2006/09/16(土) 00:40:15

っつーかさ、螺旋階段とか立体交差ができないからって
ハイトフィールド使えねーってのは短絡すぎね？

そういう制限があるけど、実装が簡単だからって薦めて終わりにしねえ？

**名前は開発中のものです。** · 2006/09/16(土) 00:43:32

「ハイトフィールド使えねー」なんて誰も書いてないと思うぞ。

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

まえ、ベクターで灰とフィールドを使った３Ｄゲーダウンした。
なるほど、高低差が表現できてるな。ってのは当たり前なんだし、
バカっぽい印象があったな。灰とフィールド。

**名前は開発中のものです。** · 2006/09/16(土) 00:56:03

>>143
無理じゃないよ。
自分の常識に勝手にとらわれてるだけじゃん。
定義はそれでいいよ。
「XZ平面の格子点上でY(高さ)データをサンプリングした2D配列」

普通に四角形つないでいくだけで螺旋できるだろ
いや、螺旋なんていうからよけいややこしくなるのか？
じゃ、上からみて円状の道が表現できればそれの連続で螺旋は表現できるよな？ＯＫ？

　　□□□
　□　　　　□
□　　　　　　□←Start
□　　　　　　□←End
　□　　　　□
　　□□□

例えば↑こんなんでどうだ？（ずれないかな？ｗ）
ちなみにこの□の１つ１つがハイトフィールド。
（格子の大きさはそれぞれで調節できる。でも、大抵は一定。ＸＺで矩形のヒットを確認した後でＹの計算に移る）
イメージわいた？ｗ
まあ、これは俺の方法だけど。（他の方法もあるかもしれんけど）

**名前は開発中のものです。** · 2006/09/16(土) 01:08:20

>>149
それは螺旋階段じゃなくて、リングみ見えるお

**名前は開発中のものです。** · 2006/09/16(土) 01:11:27

>>150
上からみた図って言ってるだろ。
標高データはあんだからＸＺ上でつながりゃＯＫでしょ。

**名前は開発中のものです。** · 2006/09/16(土) 01:31:05

何でそんなムキになってるんだ

**名前は開発中のものです。** · 2006/09/16(土) 01:37:00

だってすげー馬鹿なんだもん。
俺が専門行ってた頃のまわりもアフォはアフォだったけど、
ここまで頭固いのか馬鹿なのか知らんけど、そういうのいなかったし。
会社入ってからはアフォなのいなかったからね。ストレス溜まるよｗ

**名前は開発中のものです。** · 2006/09/16(土) 01:51:12

>>149
螺旋階段ごときでこんなに細かくハイトフィールドを分割・配置すんのか。
これ、階段の一段につきディスプレースメントマップ一枚の間違いじゃね？ｗ

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

>>154
細かくってそんな情報どこにもないけど？
別に格子の大きさなんて大雑把に配置してもいいんじゃね？

>これ、階段の一段につきディスプレースメントマップ一枚の間違いじゃね？ｗ
何言ってるのかさっぱりわからない。

**名前は開発中のものです。** · 2006/09/16(土) 02:08:54

>>154
いや、細かくってのは「□」の個数。
一回りするのに14個のハイトフィールドが要るんだろ？
各ハイトフィールドの解像度はどれぐらいなんだ？
それで何段ぐらいの階段を表現してる？

**名前は開発中のものです。** · 2006/09/16(土) 02:10:06

>>149
> ちなみにこの□の１つ１つがハイトフィールド。
１つ１つがハイト情報ってことだろ？
それの「１つ１つがハイトフィールド」って言ってるんだから
細かく分割するって解釈されても文句言えねーよな。

っつーか、>>149 の言う螺旋階段って、１周しかできてないだろ？
それなら誰だってできること知ってるよ。
ハイトフィールドでは何周もする螺旋階段ができないって話なんだが。

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

＞１周しかできてないだろ？
いや、それは一週分のハイトフィールドの実体さえ用意すれば
あとは繰り返し実体を参照でしかないわけで。
　
例えば「□」はAABBで、ハイトフィールドへの参照を内包みたいな。

**名前は開発中のものです。** · 2006/09/16(土) 02:15:45

>>147
>>97 >>102 >>107

またスレ違いなので、そろそろ本気で止めとけ。

**名前は開発中のものです。** · 2006/09/16(土) 02:20:36

>>156-157
はぁ？マジでアフォなの？
細かさなんてそんなの作る奴が勝手に決めりゃいいじゃん。
ていうか、作る奴が決めるしかないじゃん。
自分の質問がそういうことをいってることがわからないほど頭悪いの？

>っつーか、>>149 の言う螺旋階段って、１周しかできてないだろ？
お前に関しては、死ね。
応用力なさすぎ。ゲームＰＧなんて辞めちまえよ。

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

まあハイトフィールド厨は実際にゲーム作った事ないんだろ。
地面をハイトマップで作って建造物をメッシュで表現するのが最も一般的。
バカとハサミは使いようというか、適材適所。
スレの流れ通りの実装をするならメッシュより超絶メモリ喰うし、
モデラーにさくっとメッシュ作ってもらった方が断然良い。

応用力とか言いながら無駄な努力。
ゲームに限らずPG向いてないよ。

**名前は開発中のものです。** · 2006/09/16(土) 02:30:43

＞細かさなんてそんなの作る奴が勝手に決めりゃいいじゃん。
　
あぁ、そうだ。主観の相違だよ。
ハイトフィールドの数だけ空間分割してるわけで、一周に14分割なんて
データ作る奴が可哀想だよ。描画用の螺旋階段の静的メッシュ一個作って
それに対応する衝突判定はハイトフィールドだよ。しかも超分割。
　
「螺旋階段ごとき、階段一段につきボックス積み重ねれば終わりだろがよ。」

**名前は開発中のものです。** · 2006/09/16(土) 02:32:05

>>160
一般的なハイトフィールドで螺旋階段できないって話してる時に
応用とかあり得ねえ。そんなこと言ったらなんでもアリだろｗ

ｵﾒｰは書き込みを止めろ。全然伝えられてないしスレ違い。

**名前は開発中のものです。** · 2006/09/16(土) 02:32:14

作りたいゲームにあったアルゴリズムを使えばいい。
ハイトフィールドで苦手な螺旋階段をどうしても使いたいなら、
素直にハイトフィールド以外で妥当なアルゴリズムを使えばい。
( ﾟДﾟ)ﾏﾝﾄﾞｸｾｰから俺はだいたいオクトツリー＋コリジョン用モデルで済ませちまうけど。

そして>160の必死さに乾杯。

**名前は開発中のものです。** · 2006/09/16(土) 03:28:26

１６０の言うのは、
ソケット７用ママンで、ソケット３７０ＣＰＵを使うという話だ。
その為には、ＰＣＩに拡張ボードのせてできるぞ！って言ってるんだ。
何でもありということなんだ。

**名前は開発中のものです。** · 2006/09/16(土) 04:17:31

3Dって倍率変えればどんなサイズでもいけるんだけど
標準的なキャラクタの大きさ（身長）って
（ゼルダとかのアクションタイプの場合）
どのくらいがいいんでしょうか？

**名前は開発中のものです。** · 2006/09/16(土) 06:33:25

>>166
そんなもんどのくらいのスケールで処理したいのかによって変わるだろ。
座標単位÷仮想距離が小さくなるほど桁落ち誤差が酷くなってく。
座標の精度がfloatでマップの広さが数百メートルくらいなら
1.0=10cmくらいでいんじゃね？
あとはモデリングツールで扱いやすいサイズを考えるとかな。
まあどのみちデータ吐き出す時にスケールかけりゃいいだけの話なんで
作りやすいように作って問題が出たら変えりゃいいとおも。

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

>>161
はぁ？どこまで想像力ないの？
今回のレスにしたってちょっと突けば矛盾がボロボロ出てきそうな
糞レス返しやがってアフォにもほどがある。
だいたい、メッシュなんてどんだけ無駄な手間かけてんだ？ｗアフォｗ
デザイナが作ったメッシュってことは抜けの処理全部手作業で確認すんだぞｗ
しかもメッシュなんて判定が遅い。小粒なオブジェクトを散りばめたら速度的に不安が残る。

レスがみえないけど、あんまり馬鹿過ぎて話しにならないID:ybUsKN1Jはすでに
ＮＧワードなのでレス書いても無駄だからｗ

**名前は開発中のものです。** · 2006/09/16(土) 10:30:40

＞ID:LjBp93/T
もー少し冷静になれないものかなあ。
大人気無さ過ぎるよ。

**名前は開発中のものです。** · 2006/09/16(土) 10:46:53

まぁ、プログラミングのレの文字も知らない単なる馬鹿なんだろ

**名前は開発中のものです。** · 2006/09/16(土) 10:59:39

例えば街中で喧嘩をしてて仲裁されたとき
「俺の方が正しいのに何で止めるんだ！」ってさらにヒートアップしそうなタイプですか？

別にどういう結論を出しても構わないけど、
周囲がドン引きなのでできればこの辺で止めて頂けるとありがたいです

**名前は開発中のものです。** · 2006/09/16(土) 11:39:58

LjBp93/Tの人気に嫉妬

**名前は開発中のものです。** · 2006/09/16(土) 11:55:43

夏休みってまだ続いてたっけ？

**名前は開発中のものです。** · 2006/09/16(土) 12:02:24

大学はまだ休みかも

**名前は開発中のものです。** · 2006/09/16(土) 12:33:37

いくらなんでも中学生より上ってことはねーだろｗ

**名前は開発中のものです。** · 2006/09/16(土) 13:40:21

口調はさておき、内容はどっちもどっちって気がするが

**名前は開発中のものです。** · 2006/09/16(土) 14:04:54

どっちにしても面使ってるからねｗ
XZ情報からYを取り出すに変わりない

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

>>168
＞ちょっと突けば矛盾がボロボロ出てきそうな
どうぞ突いてみてください。きそうなだけで出てこないでしょ？

＞メッシュなんてどんだけ無駄な手間
の具体例が
＞抜けの処理全部手作業で確認すんだぞ
とありますが、ハイトフィールドを使ってもデータに不備がないかを
確かめる作業は必要ですよね。
ハイトフィールドは自分で作るから絶対間違ってないというスタンスですか？
しかもゲーム中の見た目と実際のデータに視覚的な関連性がないので
ぱっと見て間違いに気づきにくいでしょうね。

＞しかもメッシュなんて判定が遅い
ご自分の技術力がないのを自慢されなくても結構ですよ。

＞小粒なオブジェクトを散りばめたら速度的に不安が残る
ハイトフィールドだって細かく分割して解像度上げていけば
速度的な問題はでてきますよね。メッシュだから起きる問題じゃありません。

ちなみにしつこく食い下がってるのはLjBp93/Tを改心させたいわけじゃなくて
何も知らない初心者がLjBp93/Tみたいなロートルに騙されないように
LjBp93/Tがどれだけ無茶苦茶な事を言ってるか指摘しているだけですので。

**名前は開発中のものです。** · 2006/09/16(土) 15:25:14

>>178
作って無いのバレバレ。
ハイトフィールドは普通にポリで出せるし、
何より格子状だから範囲さえあっていれば完璧に抜けがない。
それに対して、デザイナにメッシュこさえてもらったものは
そもそも抜けを確実に無くすのはほぼ不可能。実際に抜けないことをプログラムを実行させて確かめるしか無い。
範囲がちょっと広くなるだけで抜けを探すだけで膨大な時間が必要となる。
実現できるにしても数をこなすことを考えるとあまり実作業には向いていない。
１ステージチェックするだけでかなりの時間が必要になる。
ま、そうやって作ってるプロジェクトもあったから、駄目というわけではないんだろうけど。俺は奨めない。

>ハイトフィールドだって細かく分割して解像度上げていけば速度的な問題はでてきますよね。
はぁ？
メッシュを散りばめて判定するのと、複数あるハイトフィールドのどれとヒットしてるか探す処理を比較してそんなこと言ってるの？
アフォ過ぎ。比較にならない。

**名前は開発中のものです。** · 2006/09/16(土) 15:46:25

よーく、冷静に考えるんだ。
問題は既にハイトフィールド云々という次元を遥かに凌駕している。

　これはどちらが最後に書き込みをするかっ！！！

という超超高次元な問題に遷移しているのだ。
この場合書き込みの内容は無視して構わない。
あくまでどちらが最後に書き込みをするか。この一点で勝負は決まる！

**名前は開発中のものです。** · 2006/09/16(土) 15:50:38

煽り立てるなっつーの！

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

>>179
まぁなんだ、ツールの段階でポリゴンに隙間がなければ
コリジョンが抜けるなんて事はないんだよ。

抜けるとしたらそれはそれで興味あるアルゴリズムだな・・・

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

隙間があったらシャドーボリュームすら作れなくなるぞ。
いったいどんな馬鹿なモデルデータを使ってるんだ？

**名前は開発中のものです。** · 2006/09/16(土) 16:49:39

>>182-183
データの問題もあるけどチェックの仕方にもよると思うね。
隣接する多角形をちゃんとくっついてるものと保障する構造を作るのが面倒だと思うけどな。
例えば、三角形Ａとそのとなりに三角形Ｂがあるんだけど、
判定してみたら誤差の問題かアルゴリズムに抜けがあるかでその両方の三角形に偶然ヒットしなかったと。
でも、モデル的にはその２つはくっついてて、境界でも必ずそのどちらかにヒットするはずなんだけど
どっかで抜けが発生してしまう。と。
俺がデザイナの作ったメッシュデータで判定をしてたときに面倒だと思ったのはこんなところだね。
しょうがないから隣接情報を三角形ごとにもたせたけど、手間だし、無駄だと思うな。

それに対してハイトフィールドは別に隣接情報を持たなくていいから楽だし、
なによりＸＺから確実にＹが決定できる安心感がいいね。

**名前は開発中のものです。** · 2006/09/16(土) 17:04:12

アルゴリズムに抜けがあるのはPGの技量不足じゃ…

**名前は開発中のものです。** · 2006/09/16(土) 17:12:38

普通にH-θ比例計算でいいだろうに

**名前は開発中のものです。** · 2006/09/16(土) 17:33:58

3Dオブジェクトを利用して当たり判定を行うか、
旧来の擬似3Dマップで使われるような判定を別に行うか、
大きくはこの2通りがある。

旧来の擬似3Dマップ方式でも、3D空間を格子状に分解して個々の
立方体領域全てについて地形が存在するか否かをもつ方式もあれば、
2D平面を格子状に分解して、ここの正方形領域に高さ情報を持たせたものを
複数層重ねることによって地形の当たり判定を管理する方式もある。

蒸し返されてる螺旋階段の例において、螺旋階段状でジャンプしたときに
上の階段とぶつかることについて考える。
3Dオブジェクトを利用した判定や3D空間を格子状に分解する方式では、
下の段に接地することと上の段に頭をぶつけることは、まあだいたい等価
に考えられる。特に特別扱いしなくてもいい。
高さ情報をもつ2D格子を複数層重ねる方式では、その層を場所ごと(螺旋階段
一周の端とか)で切り替えるようにしていると、上の階段に接触しない可能性が
出てくる。高さ依存で層を切り替えるとか、そういう配慮が必要だ。

何の方式にしろ、理屈の上ではたいていのことが工夫すれば(あるいはしなくても)可能だ。
ただ、世界の単純化の度合いが進めば進むほど、複雑なことをするためには世界のモデルを
拡張する必要がでてくる。
あとでシステムが拡張に次ぐ拡張に見舞われるようなことにならないためには、自分の作る
ゲームでやることに対して、どの程度の世界(今回の例では地形)の単純さが適切か考えることが
大切だな。

今回の言い合いでは、たぶんお互いが頭に思い描いているゲームの複雑さの基準がかなり異なっている。
それが単なる一時の思い違いによるものならいいんだが、この様子では、どちらの側も、話の中である程度
具体的に想定できるゲームのバリエーションが貧困なんだと思う。もっといろんなゲームをプレイするといいよ。

**名前は開発中のものです。** · 2006/09/16(土) 17:38:28

>>184
この書き込みを見てやっとLjBp93/Tが思っていたよりはマトモなんだと分かったｗ
だからこそ、普通の（←これ重要）ハイトフィールドで螺旋階段とかが
そのまま（←これが重要）判定できないっていうのに異論を唱えるのが不思議。

>>187
> 今回の言い合いでは、たぶんお互いが頭に思い描いているゲームの複雑さの基準がかなり異なっている。
みんな「時オカ」を例にして話を進めてますよ。
あれくらいの規模（ポリゴンの単純さ）からすると、ハイトフィールドよりも
メッシュ判定の方が断然楽。確かに確認作業は大変なものになるけど、
それこそ「工夫」すれば楽にできるよ、な。

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

>>188
ゼルダなんてＳＦＣの頃やったきりだしｗ

**名前は開発中のものです。** · 2006/09/16(土) 18:19:37

二つの三角形が上手く判定できないくて「面倒」ときたか……。
数値計算もロクに知らないのが露呈しただけじゃん。

**名前は開発中のものです。** · 2006/09/16(土) 18:29:38

>>190
はぁ？

**名前は開発中のものです。** · 2006/09/16(土) 18:38:20

みなさん御唱和ください。

「楽だし、安心感がいいから、ハイトフィールド最高！！」

さぁみなさんご一緒に！！

**名前は開発中のものです。** · 2006/09/16(土) 18:41:42

>>192
無駄に苦労して抜けに苦しむ意味がわからない。
隣接情報は作るのも大変だが、それ以上に確認が大変だぞ。

**名前は開発中のものです。** · 2006/09/16(土) 18:41:45

一見して分からないところでメッシュに隙間があって高さが判別できなくなったらそれまで正常に取れてた高さをそのまま使えばいいんでない？

**名前は開発中のものです。** · 2006/09/16(土) 18:56:20

> ID:LjBp93/T
お前の糞スタッフが糞地形データをよこすのはわかったが、
糞スタッフまみれなのはお前だけらしいから、
全世界のPGが「ハイトフィールド最高」と唱えるまで粘着するなと言ってるわけだが…

**名前は開発中のものです。** · 2006/09/16(土) 19:04:21

>>194
隙間にオブジェクトがつっこんだ事それ自体とか、そのときに取得する
「それまで正常に取れてた高さ」とかが正確ならいいんだが、単に行き当たり
ばったりな対策なら余計ひどいことになるから思いとどまったほうがいいと思う。

商用ゲームのリリースとかの社会的な影響が大きいものでもない限り、
共同制作なら締め切りの延期を頼むなりして、まじめに原因と正確な
解決法の模索をしたほうがいいと思う。

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

ハイトフィールドってバンプマップみたいなもん？

**名前は開発中のものです。** · 2006/09/16(土) 19:10:41

>>195
＞粘着するなと言ってるわけだが
せっかくもりあげてくれてるのに…なんでそういうこというかな
彼にはDirectΧMVPをあげていい

**名前は開発中のものです。** · 2006/09/16(土) 19:14:39

>>194
そもそもどうやって正常か異常か判断するのかと問いたいｗ

俺のそのときやった解決策は隣接情報を持つことだな。
これ以外の解決策があるかもわからんが・・・。

**名前は開発中のものです。** · 2006/09/16(土) 19:15:01

技術的な話が一切無いレスが、一番見苦しい

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

自分が次のフレームで進みたいとこに鉛直にレイをとばして何らかのポリゴンと交差したら正常
メッシュの隙間をちょうど通ってなにもヒットしなかったら異常
>>194はメッシュを事前にチェックする手法じゃなくて実際にゲーム内で歩行するときにやる
次のフレームでキャラを描くY座標を求める漸次処理での話だよ

**名前は開発中のものです。** · 2006/09/16(土) 19:47:35

>>201
>メッシュの隙間をちょうど通ってなにもヒットしなかったら
だから、隣接情報がいるだろ？ｗ

**名前は開発中のものです。** · 2006/09/16(土) 20:25:41

点や線ではなく、面でガードすれば多い日も安心。

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

なんかだんだん見えて来たが、ハイト厨とそれをベースに議論してる奴らって
隙間を抜けるとか隣接情報がどうのこうのとか言ってるってことは
キャラの接地判定を点座標かそこからの垂線かなんかで処理してるんだな？
それなら議論が噛み合わないのもわかる。漏れはマップとの当たり判定も
球コリジョンでやってるからな。その方が壁とか天井とか他キャラとの押し合い
とかも全部同じコリジョンで判定できるんで楽なんだよ。

三次元の世界で未だにマップチップ敷き詰めた二次元マップと変わらない
実装してる時点で、ロートルという指摘は間違っていなかったようだ。

**名前は開発中のものです。** · 2006/09/16(土) 20:37:34

>>204
球判定は解決になってねぇ気がする。
俺もヒットの範囲をでかくもつってのは対策としてやったことがあるけど
結局、ヒット後の戻す位置が不安定になるからキャラがガクガクする箇所がでたからその方法はボツった。

**名前は開発中のものです。** · 2006/09/16(土) 20:44:04

ハイトマップの代替にするならバウンディングボックスだと思う。

**名前は開発中のものです。** · 2006/09/16(土) 20:51:36

アルゴリズムに拘ったものに限って退屈でツマラナい糞ゲームだらけだからな。
処理負荷が高いだけで何の利点もない。やるだけ無駄。

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

球コリジョンの人は床とか壁にも球コリジョンを敷き詰めるってこと？
ほんといろんなやり方があるもんだね

**名前は開発中のものです。** · 2006/09/16(土) 21:07:57

>>208
おまえはハイト厨の仲間かｗ
>>205も＞ヒット後の戻す位置が不安定になるからキャラがガクガクする
とか言ってるけど、球と平面の交差判定と最近接点の求め方も知らないのか？
ttp://www.amazon.co.jp/exec/obidos/ASIN/493900791X
これでも読んどけハゲども。

>>206
まさかバカ正直に表示用モデルのメッシュのポリゴン１つ１つと判定するとでも？
たしかにモデラーにメッシュ作ってもらえとは言ったが、そのぐらい想像しる。

**名前は開発中のものです。** · 2006/09/16(土) 21:12:18

>>209
いや、普通に↓の状態のどっちの平面を優先するか？って方法が難しいだろ・・・

　　　　　　　＼○／

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

>>209
> 平面
平面？

> 表示用モデルの
バウンディングボックスとか球コリジョンとか言ってるのに
どこから表示用モデルの話が？

**名前は開発中のものです。** · 2006/09/16(土) 21:46:28

>>209
全部本に書いてあるだけの知識なんだったらなんでそんなに人を見下した態度になれるのか
よくわからｎ

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

１から１０まで全部実装方法説明しないと理解してくれないのか…

>>210
あれか、ヒット検出するたびにオブジェクトの位置更新する方法なのか。
漏れはヒット検出だけ先にがーっとやって良い位置を見つけてから動かしてる。
まさか更に後ろから追突されてる場合どうすんだ？とか聞くんじゃないだろうな？

これはもう>>187の言うとおり、想定してる実装が大幅に違うので
これ以上議論する必要はないな。ずっと平行線だろう。

>>212
説明すんのめんどくせーから良書と言われてる本提示しただけだよｗ

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

>>209
今はｵﾏｴの方が痛いやつだな・・
処理が重くて実装が面倒（初心者向けじゃない）な方法を出してきて
優越感に浸ってるんだからな・・・
初心者へのアドバイスとしてはハイトフィールドは正解だよ。

LjBp93/T が言ってる抜けとかガクガクのことは、心配しない方がおかしい。
どんな優れた判定でも厳密な実装をしたとしても、抜けの心配ってのは尽きない。
それを「球コリジョンの判定だから大丈夫」ってのはＰＧとして問題ありだぞ。

**名前は開発中のものです。** · 2006/09/16(土) 22:43:30

お前らそろそろ↓こっちに移動しろよ･･･
【Collision Detection】
ttp://pc8.2ch.net/test/read.cgi/gamedev/1015484028/

**名前は開発中のものです。** · 2006/09/16(土) 23:32:15

ハイトフィールドに関してはデータ量に比べて、
地形が無表情になると感じたので、眼中になかった。

メッシュに関しては隙間があるなんて論外だ。
そもそもそんなメッシュは生成しないか、
どうしても生成する可能性があるなら、
事前にチェックする処理を実装すべきじゃないだろうか。

メッシュの範囲内で抜ける可能性があるのは、
三角形の辺や頂点付近で、計算誤差の関係で、
どの三角形の範囲内とも判定されない場合だろう。

現状、俺の場合は地面にめり込むと即破壊なんで、
（流れに沿えなくて申し訳無いが）無視しても問題なさげだが、
いずれ地面を這いずる処理もする予定なんで、
判定のときに決定されるパラメータを基準に、
高度を決めるに相応しい三角形を決定するかな。。。

正直、１９時くらいから友人に拉致られていた。
亀レスでも一向に反省しない。

**名前は開発中のものです。** · 2006/09/16(土) 23:49:35

＞説明すんのめんどくせーから良書と言われてる本提示しただけだよｗ
面倒くさいくらいで自暴自棄なってたらこの先生きのこれない

98 · 2006/09/17(日) 00:56:16

なんだよ、もう。
土曜日がお休みの奴らだけで話を進めてさ！