Incorrect collision detection? [Solved]

[hiker]

Hi,

I am still working on including bullet in SuperTuxKart (too busy with real life to make much progress, but I am close to officially swapping to bullet ), but I am currently stuck with a problem which appears to be a bug in bullet(?). Bullet reports a collision where actually no collision is happening.

Some details:
in STK I load the 3d track via the plib library, and then convert the graphical tree into the bullet representation. Originally I would create the bodies in the same way the graphical objects are structured.
When I noticed the incorrect collisions, I had a look at some of the objects and detected that some of them are not connected, e.g. one graphical object could contain all triangles for the left side and the right side of the track, so in bullet a single rigid body is created which contains the left side and the right side of the track. Expecting this to be the problem, I first split up the graphical objects into connected sets of triangles, which were then converted into rigid bodies. Same error.

Then I got desperate and converted each and every single triangle of the track into a separate bullet rigid body. I then added code to the debug drawer to draw the triangles for which a collision is reported in red:

hitcorrect.png

The rocket is not too good visible (look at the 'dark spot' at the lower right edge of the triangle in red), but in this case bullet reports the expected collision.

But a bit further on in the track, the following happens:

hitincorrect.png

You can see that a triangle to the left is drawn in red, indicating that this is supposed to be hit, but the rocket (look straight ahead of the kart) is quite obviously not hitting this triangle (the white rectangle is part of the UI, which isn't drawn correctly when using the bullet debug drawer).

At the same time I sometimes see that some triangles (which are the ones that are usually incorrectly hit) are drawn in yellow (instead of green) when the kart is close (but again still not hitting that triangle). Not really sure if this indicates the same issue?

Now, the code is somewhat complex, so I can't really reproduce this problem in one of the demos, and it might be a problem in my code somewhere. A quick outline of the (what I think are) the important bits (using bullet 2.63):

Init:

Code: Select all

    btDefaultCollisionConfiguration* collisionConf
                        = new btDefaultCollisionConfiguration();
    m_dispatcher        = new btCollisionDispatcher(collisionConf);

    btVector3 worldMin(-1000, -1000, -1000);
    btVector3 worldMax( 1000,  1000,  1000);
    btBroadphaseInterface *axis_sweep    = new btAxisSweep3(worldMin, worldMax);

    btConstraintSolver *constraintSolver = new btSequentialImpulseConstraintSolver();
    m_dynamics_world = new btDiscreteDynamicsWorld(m_dispatcher, axis_sweep,
                                                   constraintSolver);
    m_dynamics_world->setGravity(btVector3(0.0f, 0.0f, -gravity));

The actual conversation from graphical tree to bullet objects is:

Code: Select all

        ssgLeaf             *leaf       = (ssgLeaf*)(track);
        for(int i=0; i<leaf->getNumTriangles(); i++)
        {
            short v1,v2,v3;
            sgVec3 vv1, vv2, vv3;

            leaf->getTriangle(i, &v1, &v2, &v3);
            // matrix multiply to get the right transform
            sgXformPnt3 ( vv1, leaf->getVertex(v1), m );
            sgXformPnt3 ( vv2, leaf->getVertex(v2), m );
            sgXformPnt3 ( vv3, leaf->getVertex(v3), m );
            // convert plib vectors into bullet vectors
            btVector3 vb1(vv1[0],vv1[1],vv1[2]);
            btVector3 vb2(vv2[0],vv2[1],vv2[2]);
            btVector3 vb3(vv3[0],vv3[1],vv3[2]);
            btTriangleMesh      *mesh       = new btTriangleMesh();
            mesh->addTriangle(vb1, vb2, vb3);
            btCollisionShape *mesh_shape = new btBvhTriangleMeshShape(mesh, true);
            btTransform startTransform;
            startTransform.setIdentity();
            btDefaultMotionState *myMotionState = new btDefaultMotionState(startTransform);
            btRigidBody *body=new btRigidBody(0.0f, myMotionState, mesh_shape);
            m_dynamics_world->addRigidBody(body);
            body->setUserPointer(0);
        }   // for i

Do you have any suggestions on how to proceed from here? I could tar up my code (it comes with configure scripts and visual studio project file, but it has some dependencies: plib, SDL, OpenAL, alut, libogg, libvorbis - though most of the sound dependencies could be removed), or can you give me any idea on how to help me debugging this problem any further? Any help is highly appreciated!


Thanks a lot!
Joerg

[Erwin Coumans]

Yellow should be fine, it just means close proximity: the triangle didn't get rejected by the bounding volume hierarchy/aabb tree, and is tested further.

You should add all triangles to the same btBvhTriangleMeshShape, but I guess you did before.

- Do you change the world transform of the static mesh after creation? Do you set any scaling for the mesh? Did you override/set the margin on any of the shapes?

- Is is possible to share the mesh data in .obj or other format? The triangle seems to be extremely long/thin, it might cause issues.

- What collision shape and size is the rocket? Have you tried a different shape, and see if that helps?

- Can you render the AABBs of car/rocket/mesh in debug rendering?

Thanks,
Erwin

[hiker]

Yellow should be fine, it just means close proximity: the triangle didn't get rejected by the bounding volume hierarchy/aabb tree, and is tested further.

Ah - wasn't sure about that

You should add all triangles to the same btBvhTriangleMeshShape, but I guess you did before.

Nearly - it a recursive procedure, and I assumed that the 'sub tree' of the graph would already be 'usefully' divided (which they aren't). I was going to change this to convert all triangles into a single object next, but wanted to find the problem first. If you think that this should make a difference, I'll do this first.

- Do you change the world transform of the static mesh after creation? Do you set any scaling for the mesh?

No, no. All triangles are transformed when creating the bullet mesh, no further transforms, scalings, ... are necessary.

- Is is possible to share the mesh data in .obj or other format?

Sure, it's in .ac3d format, which can easily be imported in blender. I'll send it to you.

- What is the collision shape type and size of the rocket?

It's a btCylinderShapeX, which gets rotated by -90 degrees on the Z-axis to have the same alignment as the 3d model (plus some other rotations obviously). Parameters for ctor are:
1.265, 0.2, 0.2

- Can you render the AABBs of car/rocket/mesh in debug rendering?

Yes ... but DBG_DrawAabb isn't really working , it still draws the normal triangles. I'll have a look what's wrong and come back to you.

Cheers,
Joerg

[Erwin Coumans]

It's a btCylinderShapeX, which gets rotated by -90 degrees on the Z-axis to have the same alignment as the 3d model (plus some other rotations obviously). Parameters for ctor are:
1.265, 0.2, 0.2

Just for debugging, could you replace the cylindershape by a boxshape, or capsule shape and see if that fixes the problem?

Thanks for the report,
Erwin

[hiker]

Just for debugging, could you replace the cylindershape by a boxshape, or capsule shape and see if that fixes the problem?

Boxshape has the same problem, my cylinder had the wrong shape (looked like a frisbee, and not like a rocket ), so it was wider, but hit the same triangle.

You asked for the transforms, by now I have the details:
The triangle has the coordinates:
V1: -18.120644 47.574474 3.436482
V2: -10.340431 56.667221 -0.981787
V3: -14.073014 60.399799 -0.981788

The cylinder/rocket has the size: 1.265593 0.200013 0.204460, it is fired at:
xyz: -9.769010 61.356995 -0.157666
hpr: 30.075401 0.135039 -0.078202
(euler in degrees, sorry, that's what plib is using).

After the first timestep for the rocket an explosion is detected at:
origin -10.052976 61.847347 -0.156331
rotation 0.866353 0.001180 0.000680 -0.499430
Now that's the data from bullet's rotation quaternion.

Unless I hear from you otherwise, I'll try to add this data in one of your demos, and see if the problem can be reproduced this way.

Thanks a lot for your quick help!
Joerg

[hiker]

Hi,

Erwin just found my error: if two objects are returned in a btPersistentManifold, this does not necessarily mean that they are colliding. I have to check the number of contact points (persistentManifold->getNumContacs()) to detect 'real' collsion.

Thanks to Erwin for the quick help!
Joerg