Contents — 6 sections
RicochetTanksのMapは点対称で生成している。
なら安全チェックも、片側だけ計算して鏡写しすれば半分で済む。
そう考えた。
実際に検査すると、壁をかすめる方向で鏡像側と16方向ずれた。
見た目は対称。
配置も対称。
でも離散化した弾道判定は、完全には同じ結果にならなかった。
点対称なら計算結果も対称、とは限らなかった
Map geometryとしては点対称。
ただし実際の判定では、
- 浮動小数点
- 角度の刻み
- 壁との交差
- 境界を「当たった」とみなす閾値
が入る。
特に壁をかすめるような方向では、小さな丸め差が判定をひっくり返す。
片側ではClear。
鏡像側ではHit。
という差が出た。
16方向の差を見て、鏡写しをやめた
記録では、鏡像側との安全判定に16方向のずれが出た。
そこで、
「対称だから片側だけでよい」
という最適化を捨てた。
SPAWN_SAFETYでは、両向きとも実際に弾道を数える方式へ変更した。
計算量は増える。
でも安全判定の意味を優先した。
Geometryの対称性とNumerical Resultは別
ここで学んだのは、
入力が対称でも、数値計算の結果まで完全に対称とは限らない
ということ。
特に、
- 境界判定
- Ray / Segment intersection
- epsilon
- quantized angle
- normalized vector
が絡むと、小さな差がBooleanへ変換される。
Booleanに落ちる瞬間、微差が0/1の大差になる。
「理論上同じ」をTestで置き換える
設計上は同じ。
数式上も対称。
それでも今回のような差が出る。
なら、片側の結果をコピーするより、
本当に両側を計算して一致するか見る
方が確実だった。
MapGenは大量候補を自動で捨てる仕組み。
ここで安全判定を間違えると、良いMapを落とすか、危ないMapを通す。
少しの計算節約より、判定の信頼性を取った。
これはUnity Physicsそのものではない
この検査はMapGen側のモデル。
実VRChatの弾道やUnity Physicsを丸ごと再現した結果ではない。
だから、両向きを計算したことで本番挙動まで完全保証できるわけではない。
あくまで、
自分たちの検査モデル内部で、対称性を仮定しすぎない
ための修正。
いまの結論
点対称Mapなら、片側を計算して鏡写しすれば速い。
理屈は合っていた。
でも境界付近の浮動小数点計算では、実際に16方向の差が出た。
そこで最適化を一つ捨てた。
対称性は性質として使う。でも、判定結果まで無条件にコピーしない。
小さな話だけど、自動生成で大量の候補を判定するほど、こういう差が効いてくる。
Signal / 観測記録
この記録への観測を送る
反証、