もしかして
>>213,216 =
>>197 なんだろうか。
>>200 で正攻法を教えたら教えたで悪態をつき、
別の人(
>>220 )が「(ごまかしの手段だけど)こういうのがあるよ」と教えたら教えたで
それだと「○○が表現できない」と不満を言ってるとしたら、もうどうしようもない。
実際のゲームが中身がそうなっている。
見えるポリゴンが複雑に作ってあるが、
当たり判定用のポリゴンが単純で明快に階層化されている。
それが単純で、平面の部屋に分かれており
、ドアで繋がれていて階層化される。
"Quake BSP map" で検索すれば解説がある。
高校数学でベクトルをきちっと学んでいた人はこういう場面でもあまり躓かず、
「ベクトル?そんなの何の役に立つんだよwww」と言ってた人は右往左往するわけだな
俺は昔からプログラムを趣味でやってたから「何の役に立つんだよ」なんては思わなかったが
普通に数学で躓いていた。
別にゲーム作るだけが人生じゃなし、「面倒だから諦めた」
「やってみたが出来なかった」で構わない。それも経験だと思う。
むしろ「それなりの努力が必要」という事実から目を逸らして
いつまでも他人を巻き込む方が問題だし、何の為にもならない。
>>222 ちゃんと話の流れを読めば、「何を勉強すればいいかだけ教えれば
あとは自主的に勉強する」かどうか、すぐに分かるでしょ。
226 :
名前は開発中のものです。:2014/12/28(日) 08:16:59.20 ID:atH7vbr7
>>222 bspが空間の再帰分割アルゴリズムなのはわかったけど、それをどう使ってるのかよくわかりません。
FPSのような室内専用?
当たり判定モデルが別途あるのは知ってるけど。
227 :
名前は開発中のものです。:2014/12/28(日) 10:18:16.66 ID:31x1GkHd
まぁね、答えがひとつでなくて、色々な方法がある。
初心者ならば、単純な方法で行えばよい。
Xファイルか高さマップになるだろう、
そして、DXライブラリを使えば良い。
初心者 : C言語、DXライブラリ、Xファイル。 書籍も出てるし
>>227 結局、こうやってツリーにしておけば、キャラの位置のポリゴンが早く探せるってこと?
BSPが、見えるものと、当たり判定の両方を省略して少なくする。
数百の多くの部屋があり、ドアで繋いでいて、
当たり判定は、自分のいる部屋だけを処理すればよい。
見えるものは、自分の部屋からドアを通して見える部屋だけを描画すればよい。
全部の部屋を処理しなくて良いから、処理量が格段に少ない。
BSPが複雑ではあるが、効率よく働く。
現代のCPUやメモリがあれば、BSPを使わなくても実現可能です、昔よりもPCの性能が向上したから。
>>230 見えるものってのがよくわからないけど、
見える見えないはカメラからのベクトルで決めるのでは?
あなたが部屋にいて、ドアがある。
ドアの向こう側の隣の部屋は見える。
部屋に壁がある、壁の向こう側の部屋は見えない。
この情報は、事前に知ることが出来る、
今あなたがいる部屋から見える部屋は決まっている。
だから、あなたの部屋に見える部屋番号のリストを記録しておく。
それで、PCが描画するのは、
あなたの部屋とドアで隣接する見える部屋番号リストの部屋だけを描画する。
-
別のカメラ最適化の方法として、
カメラ視野角の外側は、見えないから描画しない。
見える物体の裏側は、陰になり見えないから描画しない。
-
全部を描画するのでは無く、最適化された必要最低限の描画を行う。
>>232 ああ、部屋情報は別途ファイル参照ですか。
BSPツリーで、ドアから見える向こうの部分もわかっちゃうのかと勘違いしまして。
まあでも、結局BSPで空間を分割していくアルゴリズムがなんともまだよくわかりませんがw
こんないかにもややこしいことも理解できないとダメなんですね・・・。
部屋の形状が単純な立方体ならば、その場で計算も出来る。
部屋番号をツリー状に組織することで、検索などのデータ処理を速く行える。
これが、巨大な大きいマップになれば有効なだけで、
小さくひとつの部屋だけなら有用性が少ない。
235 :
名前は開発中のものです。:2014/12/29(月) 08:35:16.60 ID:h4rdpxTJ
ああ、部屋がたくさんあるマップの表示部屋の管理をBSPツリーでやってるってことですか。納得しました!
君は、2分木を知ってる?
千個のデータ中から、あるデータを探すのに、
線形探索なら最悪千回かかる
2分木なら、2^10=1,024 だから、10回で探せる
なぜなら1回の探索で、半分のデータを切れるから
今、1〜1,000中から、300を探したい場合、
最初に500と比べて、300は500未満だから、
500以上を一気に切れる
次は、250と比べて、300は250以上だから、
250未満を一気に切れる
237 :
名前は開発中のものです。:2014/12/31(水) 15:36:06.93 ID:0ZF0cVIR
BSP木は均等な2分木じゃない
そもそも3Dでのヒットの取り方が分からない相手に
応用技術を解説しても仕方ないんじゃないのかな。
BSPって、空間を再帰的に分割したデータを用意して、
ゲーム上でも自分がどの空間にいるか再帰的に検索するってことでしょ。
つまるところは「ある平面のどちら側にいるかをどうやって判定するの?」って質問に
なってしまうわな。やっぱりベクトル代数分かってないと先に進まないんだけど。
240 :
名前は開発中のものです。:2015/01/07(水) 21:54:57.87 ID:lEBpx2ib
BPS
衝突判定自体はわかってる
問題は、地面の多数のポリゴンからどうやって足元周辺ポリゴンを割り出すのか
総当たりは遅くなる
通常は、総当りで出来る。
当たり判定に使う、必要最低限のポリゴンなら少ない。
処理が重いのならば、それはポリゴンが多すぎる。
シームレスの巨大マップにしたければ、
部屋に分けてポリゴンをグループ分けする。
自分の所属する部屋の中だけのポリゴングループに対して処理する。
色々な最適化がある、方法はマップの条件によって異なる。
データ構造が判らないとなんとも言えない
むしろ判定に都合の良いデータ構造にする。
MAPを格子状に区切ってその格子の順番にポリゴンを格納する。
@ポリゴンの範囲はは格子よりも小さくしておく(最大のポリゴンを元に格子のサイズを決め手も良い)
Aポリゴン座標の最小値で格納する格子を決定する。例えば(Ax,Ay)、(Bx,By)、(Cx,Cy)なら(Ax,Cy)になりうる。
B格子ごとに連続してポリゴンを格納してき、インデックスを保存しておく
これで判定対象のいる格子と、-x側の格子、-y側の格子、-x-y側の格子の4つを範囲にあるポリゴンを
インデックスを元に参照する。検証は任せたw
自分が実際にやったのは基本1km単位で
各頂点のxy値は1kmの範囲内でランダムになっているメッシュ上の地形データで、
隣接する格子を含めた9つの格子の計18ポリゴンでチェック。
そしてHITした頻度の高いポリゴンから判定するようにインデックスを入れ替える。
建物は各所にグリッド状に配置するので、その全体を判定してHITすれば判定すべき建物と判定。
って感じだったかな。うろ覚えだけどw
>>244 ポリゴンを格子で区切るということは、格子と格子の接合面にあたるポリゴンは
格子の枠に沿った形状でつなげてあるということ?
でかい3Dマップも、格子状に分割できるようにポリゴンをつないでいるということ?
格子をまたぐポリゴンはないということ?
「ポリゴンを格子で区切る」なんて書いたっけ?
> 格子と格子の接合面にあたるポリゴンは
> 格子の枠に沿った形状でつなげてあるということ?
格子の頂点とポリゴンの頂点が一致するデータ構造でいいなら、そうするのが良いと思う。
> でかい3Dマップも、格子状に分割できるようにポリゴンをつないでいるということ?
いくつもの格子を跨ぐポリゴンがあると、
ある格子に掛かるポリゴンがどれだけあるか判定が大変になる。
> 格子をまたぐポリゴンはないということ?
跨ぐ前提で話をしている。
ポリゴンは最大で格子と同じサイズまでにすれば
1つのポリゴンは1つの格子と隣接するプラス側の格子に掛かる可能性がある。
これを逆に考えると
1つの格子にはその格子と隣接するマイナス側の格子に登録されたポリゴンが掛かる可能性がある。
247 :
名前は開発中のものです。:2015/01/12(月) 01:18:11.06 ID:HlhvcqEy
>>244 インデックスを格納した格子の構造体がたくさん?
その地形をロードするたびインデックスの並べかえはリセット?
>>242 >衝突判定自体はわかってる
一応聞くけど、兄さん
>>197 や
>>202 と同一人物じゃないのかね。
親切に回答している方も、そろそろ「?」ばっかり連発してる質問者が
あなたに“全部答えさせようとしている”と気が付いた方がいいんじゃないかな。
それどころかどうせ3Dゲームが完成しない事も想定済み。
ピンポイントで質問が浮かぶような人→たいてい自分で解決出来る。
初心者→何から手を付けていいか分からないから漠然とした質問しか出来ない。
答える方も基礎を学べとしか言いようがない。
気位だけ高い→基礎を学べと言われて逆切れする。
サイコパス→全部答えさせようとする。
…うまく噛み合わないね。
251 :
名前は開発中のものです。:2015/01/16(金) 14:55:25.37 ID:1Snv1/Ug
簡単な3Dのゲームを作るなら、DarkBasicが良いと思う。
3Dライブラリを使って、簡単に3Dを扱えるようになっている。
初心者向けで、入門として良い。
サンプルコード( .dbaがソースコードになる。テキストファイル。)
http://www1.axfc.net/uploader/so/3393214 ある程度の雰囲気や概要がわかってきたなら、
高度な3D数学や物理を学ぶのが良い。
いきなり、難しい事から始めると、確実に挫折する。
そして、オリジナル3Dライブラリ自作している自分に気がつく。
モデラーとかアニメーションも
いきなり難しいことから始めたら挫折するというけど、
難しいことを後回しにしたら挫折も後回しになるだけ。
例えば、小学校1年生から6年生へいきなり飛び越えても無理、
算数のたし算を知らなくて掛け算や連立方程式を計算できるわけが無い。
3Dの場合は かなりね、専門用語の壁が厚いのです。
行列やらベクトルの演算やら数学嫌いには拷問だよな
代数幾何の教科書読み直して理解できるくらいじゃないなら、
3D処理は出来合いのものを使ったほうが良い。つか必ず使わなきゃダメ。
教科書はよく選んだ方がいいよね。プログラミングのための線形代数、お勧め。
巻頭のグラフ見るだけでも大分イイ!
昔のアニメ専門学校の広告でよくあったなあ。
「一から教えるからあなたにも大丈夫!」みたいなノリ。
高い入学費払って半分は中途退学。たまに成功する人もいるんだけど、
じつはそういうのは最初から才能を持ってる。
小1から中3まで算数や数学を順を追ってきちんと学んでも、高校数学で行き詰る人間が約半分。
順を追って学べば全て分かるなら、全ての人間がフェルマーの大定理が解けなきゃおかしい。
本当に勉強したければ、自分が行き詰ったところ、もしくは学ぶ機会のなかったところからやればいい。
それこそ小1の足し算からやって「俺にもできるかも!?」なんて気分だけ味わうのは時間と金のムダ。
よく「足し算だけ、掛け算だけを解かせるとちゃんとできるのに、
足し算の応用問題を掛け算して解こうとする子供がいる」って話を聞くだろ。
人に勉強を教えると分かるけど、行列やベクトルの演算が分からない人、
まして数学が拷問に思えたり、教科書読んで分からなかったりする人は、
「計算が出来ない」んじゃなくて、「数式の意味や使い方が分からない」んだ。
意味や使い方そのものが分からないのに、ライブラリで何をどうごまかせるんだ。
3Dモデルを回転させるのに、回転行列を使う。
それを、ライブラリならば、「回転しなさい」というコマンドを使う。
これだけのこと。 四則演算で出来る。 あまり難しく考えてはいけない。
数学が判っていれば、本来なら行列を使うところを
一部の計算だけで同じ結果になるケースを見極めて
計算コストを省けるんだけどな。
でもそんな工夫している間にCPUが早くなっているw
>これだけのこと。 四則演算で出来る。 あまり難しく考えてはいけない。
株に手を出せない人に投資信託を勧めるのと同じ。
本当は複雑で難しいことを、素人でも分かる程度に簡略化して、分かった気にさせる。
「分かった気にさせて、手を出させる」のが狙い。
もう一度言うけど、3Dプログラミングは高卒かそれ以上の線形代数そのもの。
もちろん、昔それに挫折した人や機会がなかった人でも、やる気さえあれば腰を据えてやればいい。
それでできなくても得るものはあるだろう。
でもそこで腰が引けて迂回しようとしても他に道はない。他に道がありますよと言うのは甘言。
同じところをぐるぐる回らされていたと思い知らされるだけ。
GPUって3Dに特化しすぎじゃね?
vector3 とか matrix4 とか何で決め打ちなん!
もっと任意長のベクトルを流し込んで並列処理するような
汎用性のある枠組みにしたほうが分かりやすいのに。
それで3D特化はシェーダプログラムのほうでやればいい。
そうすればこまごました仕様が一掃されてシェーダが書きやすくなるのに。
シェーダでいろいろなアルゴリズムを試そうと思ったけど
ハードウェアの区別と制限がごちゃごちゃに思えて手を出せぬ
DirectX11 にコンピュートシェーダーというのがあるのか!
これで汎用アルゴリズムが直に書けるのかな?!
テンション上がるわー
Unity3D でも使えるんね
でも DirectCompute はまだシェーダ言語の一部という感じだが
C++ AMP というのを使うと C 言語っぽく汎用的に組めるのかな?
Unity3D でも使えるんね
↑
何なんだよ、その不自然な改行。
おまえらステマ業者って根本的に相手をバカにしてるだろ?
270 :
267:
ごめん。普段から言動が不自然と言われるけど
うにちのステマ業者じゃないよ
ちなみに C++ AMP は unity じゃ使えないのでは?
C++ だし。