search

code-google-com / bullet

Automatically exported from code.google.com/p/bullet
0 stars 0 forks source link

Box-Capsule Collision Detection #339

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
This is the code implementation of a box-capsule collision detection added to 
the convexconvex algorithm.

The .diff is taken from perforce and manually copy-pasted, so it probably 
won't go through any software-merge. It should be really easy to add it, 
though. It's just one new file and a little bit of additional code in 
btConvexConvexAlgorithm.cpp

/Simon

Original issue reported on code.google.com by mr.lundm...@gmail.com on 26 Jan 2010 at 10:02

Attachments:

GoogleCodeExporter commented 9 years ago 
I'm not sure how I made it into a defect, it shouldn't be. Sorry about that.

Original comment by mr.lundm...@gmail.com on 26 Jan 2010 at 10:03

GoogleCodeExporter commented 9 years ago 

thanks for the contribution, we'll look into it. (and changed it into 
enhancement)

Original comment by erwin.coumans on 26 Jan 2010 at 4:11

GoogleCodeExporter commented 9 years ago 

Hi Simon,

I think the headerfile is missing, can you attach it separately?

Thanks!
Erwin

Original comment by erwin.coumans on 4 Feb 2010 at 3:49

GoogleCodeExporter commented 9 years ago 
Indeed it is, sorry about that. I'll attach it tomorrow as soon as I get to 
work!

Original comment by mr.lundm...@gmail.com on 4 Feb 2010 at 5:03

GoogleCodeExporter commented 9 years ago 
Here's the header-file Erwin!

Original comment by mr.lundm...@gmail.com on 5 Feb 2010 at 8:27

Attachments:

GoogleCodeExporter commented 9 years ago 
I have cleaned up this patch a bit, so that it compiles cleanly with bullet 
2.79. I also fixed an issue with a strict 'vector == vector' comparison, which 
was leading to NaNs through numerical precision issues. I now just compare the 
vectors using an epsilon.

On the platform I'm targetting, it speeds up the average time for collision/box 
intersection from about 0.3ms to 0.09ms, so an approximate 3x speedup.

Original comment by paul.hol...@gmail.com on 29 Feb 2012 at 8:50

Attachments:

GoogleCodeExporter commented 9 years ago 
That's great Paul.

I'm a bit concerned that the epsilon hides most nan-cases from happening, but 
it could still occur in some cases.

Is there a way to reproduce a NaN case and fix it robustly?
Thanks!

Original comment by erwin.coumans on 29 Feb 2012 at 7:52

GoogleCodeExporter commented 9 years ago 
I'll take another look at that, arbitrary epsilons always make me a bit nervous 
:)

We've integrated this change into our engine now, so it will be getting a fair 
bit of testing over the next few weeks. I'll resubmit a patch when we're happy 
that it's behaving as expected.

A colleague also fixed a small inefficiency:

btScalar dist(0.);
{
  dist = btSqrt(distSq) - btSqrt( capsule->getRadius() * capsule->getRadius() );
}

Is redundantly squaring capsule->getRadius(), then taking a square root. I've 
not worked through the maths, but I'm assuming that's a simple mistake rather 
than a more subtle bug. We changed it to:

btScalar dist = btSqrt(distSq) - capsule->getRadius();

Original comment by paul.hol...@gmail.com on 29 Feb 2012 at 8:46

GoogleCodeExporter commented 9 years ago 
Actually, to be clear, the NaNs I was seeing were simply through the 
normalisation of a zero-length vector, which much of the bullet code handles 
using the same epsilon:

btVector3 btConvexShape::localGetSupportVertexNonVirtual (const btVector3& 
localDir) const
{
    btVector3 localDirNorm = localDir;
    if (localDirNorm .length2() < (SIMD_EPSILON*SIMD_EPSILON))
    {
        localDirNorm.setValue(btScalar(-1.),btScalar(-1.),btScalar(-1.));
    }
    localDirNorm.normalize ();

So I'll look at what happens when the else case of that test executes (capsule 
and box are just touching), and ensure that it's stable.

Original comment by paul.hol...@gmail.com on 29 Feb 2012 at 9:11

GoogleCodeExporter commented 9 years ago 
Hi,

Paul and I have given this a pretty thorough testing now and ironed out a few 
bugs.  I've attached the header with some fixes in.

Many Thanks
Matt

Original comment by matt8000...@googlemail.com on 9 Mar 2012 at 5:54

Attachments:

GoogleCodeExporter commented 9 years ago 
thanks for your contribution. I'll review it after the 2.81 release.

Original comment by erwin.coumans on 12 Sep 2012 at 8:45

GoogleCodeExporter commented 9 years ago 
Great!

We've been using this in our codebase since March and it's been performing 
well. I'll check with Matt tomorrow just to make sure that we haven't made any 
other fixes since the last attachment.

Original comment by paul.hol...@gmail.com on 12 Sep 2012 at 9:34

GoogleCodeExporter commented 9 years ago 
See https://github.com/bulletphysics/bullet3/issues/121

Original comment by erwin.coumans on 30 Mar 2014 at 7:28