1

主な問題は、Bullet 2 (具体的には 2.82 - おそらく Bullet 3 もまだチェックしていない) がエッジ衝突をお粗末に処理し、歪んだ反応法線を生成することです。

テスト ケース 1: 小さなbtBoxShapeが (0,9,0) に配置され、垂直方向に配置され、別のボックスの (同様に作成されたbtBoxShape) 面に落下し、整列します。法線は適切に計算され、衝突は Y (垂直) 軸でのみ発生します。ボックスは OY 軸上でわずかに跳ね返り、その中心にとどまります。

ケース1

テスト ケース 2: 配置された (0,9,0) 垂直に配置された小さなボックス (同上) が別のボックスの面 (今回btBvhTriangleMeshShapeは 2 つの同一平面上にある三角形から作成されたもの) に落下し、これも同じ位置に配置されました。法線が正しく計算されていません。すべての軸で衝突が発生しています。ボックスが横に跳ね返ることがあり、(特定の衝突座標によっては) 非常に目に見えることがあります。

ケース2

法線をハードコーディングし、それに基づいて衝突ポイントを再計算しても (以下を参照)、役に立ちません。

//newNormal was set to hard-coded value of (0,-1,0) before
cp.m_normalWorldOnB = colObj0Wrap -> getWorldTransform().getBasis() * newNormal;
cp.m_positionWorldOnB = cp.m_positionWorldOnA - cp.m_normalWorldOnB * cp.m_distance1;
cp.m_localPointB = colObj0Wrap -> getWorldTransform().invXform( cp.m_positionWorldOnB

NB を使用しても、tri 情報を適切に設定し、コードがbtAdjustInternalEdgeContacts正常に実行されていることを確認しても、目に見える形では役に立ちません。これは機能し、シミュレーションの信頼性をいくらか向上させますが (CPU コストはかなり高くなります)、それでもこの特定の問題は解決しません。

問題は、ケース 2 の動作をケース 1 の動作に合わせて修正する方法です。この状況を回避する方法 (コードの説明は歓迎)、またはこれが本来の方法で機能しない理由を歓迎します。

さらなる参照:

https://github.com/bulletphysics/bullet3/issues/92

http://www.bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=8113

https://bullet.googlecode.com/files/GDC10_Coumans_Erwin_Contact.pdf

https://code.google.com/p/bullet/issues/detail?id=27

http://www.bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=4603

4

1 に答える 1

1

この問題は、2 つのオブジェクト間で複数の衝突が発生したために発生しました。これは、球 <-> 三角形の衝突でも同様です。衝突検出器はトライサーフェス衝突を検出し、(予想どおり) サーフェス三角形の反復を終了するだけでなく、BVH を横断し続け (予想どおり)、隣接する三角形のエッジとの別の衝突を引き起こします。 . これは、さまざまな方法で再現できます。たとえば、オブジェクトをトリメッシュ エッジの近くに投げたり (ただし、メッシュの内側にあるままです!)、オブジェクトを内部トライ ボーダー (エッジ) の近くに非対称に投げたりします(対称ドロップが発生します)。エッジ力で相殺されます）。その時点で表面が完全に平らであっても、オブジェクトは横に（時には乱暴に）飛んでいきます。

Bullet 2 のコードを完全に書き直す必要のない唯一の多目的な解決策は、たとえば で衝突オブジェクトの多様体をフィルタリングしgContactStartedCallback、すべてのサーフェス衝突を見つけて、そのサーフェスに隣接するすべてのエッジのすべてのエッジ衝突を除去することです。与えられたtrimeshnumContacts >= 2の多様体を監視するのが通常の方法です。これはあまり頻繁に発生するべきではなく、多様体上のいくつかの点をチェックすることはそれほど CPU を集中的に使用しません。

距離に基づいて連絡先を削除することもここでは驚くべきことですが、それは生産コードの IMO で使用するにはあまりにも大まかでコンテキスト固有の修正です。ただし、よりシンプルで効率的なソリューションを探しています。

また、部分的な回避策 (フォーラム ディスカッションの 1 つに記載されているように) は、タイムステップ値を変更することでした。デフォルトのものは、三角形のメッシュに対して適切な速度で移動するオブジェクトに対して失敗します。「通常の速度」の場合、最大 1/300 の固定タイムステップが必要です。「高速」の場合、1/600 またはそれ以下の YMMV が必要です。CPU負荷が大幅に増加し、問題を軽減するだけであり、多くの状況ではまったく解決しないことに注意してください.

関連する問題は、こちらの Bullet の問題トラッカーに投稿されています。

于 2014-11-18T13:49:05.917 に答える