いやね、ご飯を食べるときも、シャワーを浴びてるときも、ベッドに横たわったときも、必ず一回は思い出すほど気になってたんです。

前回少しだけ高速化したにはしたんだけど、どう考えても実用レベルじゃないのよね。
それに、衝突判定って3Dの肝じゃない。そんな根幹部分がヘタレじゃその上にもたいしたもの載せられないしね。
ってなわけで、今回はワリとがんばりました。

まず最初に用意したのは↓

画像がばっちいですけど、白線が地形の3角ポリゴンで、赤線が弾丸の1フレームあたりの移動です。
ちなみに、地形のポリゴン数は2万△ポリゴンっすな。

さてさて、とりあえずこの条件で総当り判定を行ってみたところ、やはりさんさんたる結果に･･･
1フレームあたり50回の衝突計算で1FPSとかそんなです。
試しに100回とかやらせてみたら案の定ピクリとも動きませんｗｗｗ

うーむ、今回の敵は強い。
心して応ぜねば。

煙草と珈琲を大量に消費しつつ、やっとこ1案。
地形を4分割してみることにしました。
地形のモデルをぴったり包める大きさの立方体を作り、地形の中心から4分割してポリゴンを割り当てれば、なんと！衝突計算回数は1/4に！
なるわけ無いよね。空前絶後のぬか喜びです、ハイ。
それら分割された空間の境界を1つ超えたら2/4=1/2だよね。
弾丸が直線的に飛ぶとして、飛翔距離が長かった場合や、中心に近い場所から発射されれば3つの空間の境界をまたぐこともあるんだから、これは根本的に1/4しか高速化されてないのよな。
うーむ、しかし、しかしだ、考え方はコレでOKな気はする。
近いポリゴン同士を立方体に内包し、最初に立方体と弾丸で衝突判定すれば余計なとこは計算から省けるやね。

じゃ、とりあえずまとめてみっかぁ。てなわけで今度は空間を10x10x10のグリッドで分割。
おぉ！いいじゃない！グンと速くなった！
つか、律儀に立方体一個一個調べなくても、もっとまとめて計算すりゃいいじゃんね。
立方体を中心から分割し、それを再帰的に3回くらい細分化。
で、その末端の一番小さな立方体に接触するポリゴンを格納。
ついでに、ポリゴンが内包されない立方体はリストから削除。

データ構造は↓のような感じ

全体┬左前上の空間┬左前上の空間┬左前上の空間のポリゴンリスト
　　　　　　　　　　　　　　　　　　　　　　　　├左前下の空間のポリゴンリスト
　　　　　　　　　　　　　　　　　　　　　　　　├右前上の空間のポリゴンリスト
　　　　　　　　　　　　　　　　　　　　　　　　├右前下の空間のポリゴンリスト
　　　　　　　　　　　　　　　　　　　　　　　　├左奥上の空間のポリゴンリスト
　　　　　　　　　　　　　　　　　　　　　　　　├左奥下の空間のポリゴンリスト
　　　　　　　　　　　　　　　　　　　　　　　　├右奥上の空間のポリゴンリスト
　　　　　　　　　　　　　　　　　　　　　　　　└右奥下の空間のポリゴンリスト

1立方体を中心から分割すると8個の立方体が出来るのだから、
8x8x8･･･
ってな感じのツリー構造になるのよな。
んで、弾丸の線を全体に近い立方体から衝突判定していけば良いわけだ。
で、末端の立方体まで判定してみて尚接触しているようならポリゴンとの精密な判定を行うと。
珍しく冴えてますよコレｗｗｗ

そして本日の成果物↓

青線＝末端の立方体
灰線＝立方体が内包しているポリゴン
橙線＝赤線と交差したポリゴン

結果から見れば本日は大成功だの。
改修前は50回で1FPSをきってたのが、改修後は200回ほど計算させても15FPSくらい出てくれます。
1フレームで地形の端から端までぶっ飛ぶようなものが一度に沢山発射されるときついですが、会社のオンボロPCでこれなら十分実用レベルになったのではないでしょうか。
さぁさぁ、今日は帰って祝杯でもあげよう。

それぞれの機能をフローティングウィンドウを使ってOSっぽく動作させつつ、それぞれのウィンドウが非同期通信でリアルタイムに情報を更新しながらDBにデータも溜めていくような管理画面のデモ作ってました。うむ、わかり辛いねｗ

実際Ajaxを取り入れて開発をしてみたところ、非同期通信とフローティングウィンドウの組み合わせは全体の見通しが良くなるし、紙芝居的な管理画面よりはよほど使い勝手が良いと思いましたとさ。あとは開発効率やMVCとかがしっかりすれば実用できそうだなぁ。

もうね、いままで「センスがねぇｗｗｗ」とか軽口を叩いてきた数々のゲームの開発に携わったモデラーの皆様に深くお詫びいたします。

モデリングとかテクスチャ描きとか、正直なところこれほどまでに忍耐力を必要とするものだとは思いませんでした。不動の構えを見せる頂点。暗殺者の如く身を潜める重なり面。一振りすればたちまち回りを巻き込んで崩壊の序曲を奏でる究極のナイフ。極座標の彼方で悲鳴を上げるテクスチャＵＶ。ぬぅぅぅぅぅぅぅぅぅぅｌだぅありゃぁあぁぁぁぁっぁぁぁあぁあっぁぁ！！！！！！！本当に気が狂うかと思いました。

まぁ、そんなこんなでも何とか形にしたのですが・・・・

なんつーか。自分で言うのもなんだけど。センス無いねｗｗｗ

それなりにゲームやってきたはずだし、色々なものを見てきたはず。

まったく何の糧にもなっておりません。ただ時間を浪費して安易な評論で小さな小さな水溜りの優越に浸っていただけですな。もうね、死んでしまえばいいや。モデラーって人はすげーって思ったよ。心底。

使用ツール：メタセコイア(本来モデリングする人ではないので、シェア版を機能制限付きの未課金状態で使用)

ポリゴン数：△2266

結果は上々で、10分程度で実装出来る簡単なプログラムでしたが、かなり計算を省略することが出来たようです。以下実装内容。

■弾丸の発生周りの改修

１．弾丸の発生座標から弾丸が減衰を始める(または消失する)座標までの線分を求める。

２．１で得た線分を使って衝突判定を行う。

３．衝突があった場合、１フレームあたりの弾丸の移動ベクトルをもとに、衝突する座標までのフレーム数を求める。また、フレーム数を１だけ減算し、それを衝突カウントとする。(衝突が無い場合は弾丸の終点など使う)

４．３で得た衝突カウントを弾丸クラスのメンバで保持できるようにする。

■弾丸の移動周り

５．衝突カウントを０になるまで毎フレームデクリメントする。

６．今まで衝突判定を行っていた部分に「衝突カウントが０である場合」のみ衝突判定を行うように変更する。

念のため簡単に説明しておきますと、この方法は「発生した時点で消滅が予測できるものは、その消滅の直前まで衝突判定を行わない。」という感じのものです。

従来の方法だと、発生から消滅までを常に監視し続けるため、１０フレームで消滅する弾丸は１０回の衝突判定を必要としました。ですが、今回実装した方法であれば、最初と最後の２回の衝突判定ですみます。また、この方法は移動フレームが１０フレームであろうが１００フレームであろうがその衝突判定の回数は変わりません。もし、重力などによる減衰が無い弾丸であれば、数字をしっかり検証してみたら最後の衝突判定を省いて１回ですむかもしれません。

さてさて、えらそうに講釈たれてみましたが、もしかしたら「そんなん当たり前のことじゃんｗｗｗｗｗ誰でもやってることだしｗｗｗｗｗ」ってなことかもしれません。自分は今朝の通勤電車内でこれを閃き、思わず「おぉっ？！」っとヘンな声だしてすがすがしいほど冷たい視線を集めてみました。

とりあえず開発環境が無いとどうにもならんので、いわれるがままにVC#やらXNAやらをインスコ。

開発環境が無料でそろうってのは凄いことだね。

さてさて、環境も整ったので、いざプログラミング。

で、その成果物↓

いやー、ものすごく省略した感は否めないのですが、実のところ、あまりXNAらしいことしてないので書くこともサッパリ無いのですよ。XNAらしいことって何？って聞かれても困ってしまいますがｗ

とにかく、いじってればそのうち何か見えるものもあるだろうと思ったので、このままネットワークゲームに発展させてみようと思います。

当面の課題は、XNAやC#そのものより、弾丸やキャラクターの移動で使う衝突判定をもう少し高速化かなぁ。今は「壁専用」「地面専用」「弾丸とカメラ専用」という3つのXファイルから判定をそれぞれでとって計算回数を減らしてみてるんだけど、いかんせん実用に耐えると思えない・・・。単純にPCのスペックが低いってのもあんのだけんどもねｗまぁ、プログラムなんてかじった程度にしかやったことないし、そのうち何か閃くくともあるでしょう。多分。

ちなみに、当たり判定に使っているのは↓みたいな感じのXファイル。

みんなどうやってのか気になるなぁ。

■レンダリング用のＸファイル（1716△ポリゴン）

■地面用のＸファイル(104△ポリゴン)

■壁用のＸファイル(638△ポリゴン)

■弾丸とカメラ用Ｘファイル(1716△ポリゴン)

めんどかったので描画用のやつそのまま使ってたりする。

だもんで、弾丸を20発程度とばすとかっくんかっくんですますハイｗ

いいかげんちゃんと作っておこう。