ver3.0.0.1から当たり判定の方式が変わりました。
結論から言うと、精度が上がりました。
ですが、気をつけないと処理速度が遅くなる場合があります。
以下は詳細です。
旧バージョンでは、パーツごとに、座標軸対して傾いていないボックスを作成し、判定計算をしていましたが、
ver3.0.0.1からは、下図のように、座標軸に対して傾いたボックスを使用します。
旧バージョンは、パーツ１個に対し１個ボックスを作成していましたが、
新しいバージョンでは、パーツとボーンの組に対して１個のボックスを作成します。
座標軸に対して傾いたボックスと書きましたが、ボーンの軸を基準にして傾いたボックスを作成します。
ボーンの無いモデルデータに対しては、座標軸に対して傾いていないボックスが使用されます。
つまり、ボーンを入れていないモデルデータより、ボーンを入れたモデルデータのほうが、
ボックスの数も多くなり、ボーンの傾きを考慮することで、よりフィットした形状を作れるので、
精度が上がることになります。
E3DChkConflictは、従来どおりのモデルデータ全体を囲むようなボックス１つで判定します。
高速ですが、粗い判定となります。
E3DChkConflict2, E3DChkConflict3では、パーツ単位で関数を呼び出しますが、
内部的には、更に細かいボーン単位で判定計算が行われます。
つまり、モデルデータ全体同士の判定をする場合でも、
E3DChkConflict hsid1, hsid2, confflag, inviewflag とするよりも、
E3DChkConflict2 hsid1, -1, hsid2, -1, confflag, inviewflag
としたほうが、計算精度がアップします。
E3DChkConflict2, E3DChkConflict3は、精度が高いですが、気をつけないと処理速度が遅くなる場合があります。
この２つの関数は、モデルデータ同士が、ぎりぎり当たらないくらいの距離にいるときに、一番遅くなります。
遅くなる度合いは、ボーンの数にもよりますが、ボーンの数が１００を超えるモデル同士が、近距離で向かい合った場合は、
FPSに影響するくらい遅くなる場合があります。
そうした現象が見られる場合には、モデルデータがぶつかった場合に、ある程度モデルデータ同士を遠ざけるなどして、
なるべく近距離でじっとしないような工夫をしてください。
精度以外にも大きな変更点があります。
旧バージョンでは、当たり判定に使用するデータは、E3DRenderで計算していましたが、
新しいバージョンでは、E3DChkInViewで計算します。
これにより、当たり判定と描画が１フレームずれてしまうという不具合が解消されました。
ただし、気をつけてもらいたいのは、ビルボードの当たり判定です。
ビルボードには、E3DChkInViewがないため、従来どおり、当たり判定用のデータは、E3DRenderBillboardで計算されます。
ですので、ビルボードの当たり判定は、E3DRenderBillboardより後ろに持ってくるのが好ましいです。
旧バージョンの当たり判定の弱点として、
モデルデータが視野外にあるときには、当たり判定が機能しない、という問題がありましたが、
新しいバージョンでは、モデルデータが視野外にあるときでも、当たり判定は機能します。
Win32版ではE3DChkConflictはE3DChkConflictAABB、
E3DChkConflict2はE3DChkConflictOBBという名前です。
トップページに戻る