aabb capsule intersection bug about mathgeolib HOT 4 CLOSED

from mathgeolib.

Thanks for the test case! Debugged this a bit, and lifted the assertion checks to utilize double precision floating point in the above commit. That causes the assertion failure to not fire - however the collision test still reports wrong result - no collision even though the AABB and Capsule should collide (if I interpreted the numbers correctly?)

The commit above at least avoids the math assume failure. Not sure if there is a bug in the GJK algorithm implementation or if this is a limitation of single precision floating point - the numbers have relatively large range, and some of the intermediate computations exceed the scale 1e6, so the issue may be that single precision floats do not have enough resolution to detect the collision.

from mathgeolib.

{
    gte::Vector<3, float> minPoint({ 438.420929, 805.586670, 493.709167 });
    gte::Vector<3, float>  maxPoint({ 443.420929, 810.586670, 498.709167 });
    gte::AlignedBox3<float>   aabb(minPoint, maxPoint);

    gte::Vector<3, float> a({ 479.665222, -30.0000000, 509.737244 });
    gte::Vector<3, float> b({ 479.665222, 1530.00000, 509.737244 });
    gte::Vector<3, float> dir = a - b;    gte::Normalize(dir);
    float height = gte::Length(a - b);

    gte::Line3<float> axis( a, dir);
    gte::Cylinder3<float> cylinder(axis, 37.6882935f, height);

    gte::TIQuery<float, gte::AlignedBox3<float>, gte::Cylinder3<float> > query;
    gte::TIQuery<float, gte::AlignedBox3<float>, gte::Cylinder3<float> >::Result res = query(aabb, cylinder);
    if (res.intersect)
    {
        std::cout << "gte intersects\n";
    }
    
}

The image above shows that AABB and Capsule should not collide(OSG). I also test this case with GeometricToolsEngine3p25. It reports no collision.

from mathgeolib.

Oh, thanks! Then it looks like MathGeoLib does compute the proper result after the commit above. Updated the test and closed as fixed.

from mathgeolib.