BVHTriangle / Primitive Collision Behaviour

[Major_Error]

Howdy folks,

First off, I'm more-or-less completely new to Bullet, so bear with me if I'm making stupid mistakes

My physics setup is pretty simple; I'm constructing a btBvhTriangleMeshShape from a poly-model for my terrain, and am adding this to the physics world with zero mass, at the origin. I'm the spawning primitive cubes (btBoxShape) a small distance above the terrain, expecting them to fall onto it. I can also fire btSphereShapes at the terrain, from an elevated position. Nothing too complex, the poly counts are ridiculously low at present (well under a dozen for the terrain).

The problem I've got is that in *some* cases, I'm finding that objects pass straight through portions of my terrain. To be clear; all the primitives in the world are smaller than the individual polys of the terrain, yet there are some portions of some polys in the terrain that are consistently failing to collide. So it's not every poly that fails, and it's often only a part of the poly that fails to collide.

I've tried cranking up the simulation resolution, to no avail (well, it improved matters slightly, but not enough!). I'm presently running the sim with:

Code: Select all

    double dt = clock.getTimeMilliseconds();
    clock.reset();
    dynamicsWorld->stepSimulation( dt * 0.001f, 100000000, btScalar(1.)/btScalar(600.) );

Am I being naïve? What foolishly-simple matter am I missing? I don't think it's a function of the velocity of the objects: I've tried placing the cubes precisely on the surface of the terrain, too. This gave me some interesting results - I could, say, place four or five of them on one half of a terrain poly, but then as soon as I placed one on the "bad" half, all cubes resting on that poly would fall through...not sure if that is in any way indicative of the problem I'm suffering!

I've tried enabling CCD for the boxes, too, but that didn't seem to help at all...

Code: Select all

    boxBody->setCcdMotionThreshold( boxSize );
    boxBody->setCcdSweptSphereRadius( 0.2f * boxSize );

Anyway, I'd be hugely grateful if you can point me in the direction of my stupidity I've been bashing my head against this one for long enough!

[Erwin Coumans]

Can you reproduce this in a Bullet demo?

It helps if you use Bullet 2.76 and export it to a .bullet file and attach it (zipped) to this forum,

Thanks,
Erwin

[Major_Error]

Thanks for getting back to me, Erwin.

I'll work on reproducing this in a Bullet demo, if I can, but in the meantime I've tried upgrading my code to use 2.76, and have hit a couple of snags. First off, I'm doing all this on 64-bit Ubuntu, in case platform makes a difference.

It seems that the Makefile generated by cmake (version 2.6-patch 4) has a target for install, but it doesn't actually do anything...I had to copy the libs and headers manually to /usr/local/{lib,include} (making sure to move the 2.75 ones out the way first!). This was based on the tgz distribution of the source, from Google Code. Not a major problem, but might be something others run in to, if it's not just my setup!

Second, once I actually build and run my code, it seems that the constructor for btRigidBody / setupRigidBody have some memory write issues; I've attached the relevant portion of a valgrind trace. This is just after Bullet is initialised, and I create my first rigid bodies (the terrain). Shortly thereafter, glibc SIGABRTs the process due to heap corruption.

Again, in the interest of completeness, the relevant code snippet mentioned in valgrind is:

Code: Select all

    btBvhTriangleMeshShape* terrainShape = new btBvhTriangleMeshShape( terrainMesh, true, aabbMin, aabbMax );
    // Now that we have a shape, construct rigid body dynamics as above
    btDefaultMotionState* terrainMotionState = new btDefaultMotionState( btTransform( btQuaternion( 0, 0, 0, 1 ), btVector3( 0, 0, 0 ) ) );
    btRigidBody::btRigidBodyConstructionInfo terrainRigidBodyCI( 0, terrainMotionState, terrainShape );
    btRigidBody* terrainRigidBody = new btRigidBody( terrainRigidBodyCI );

As I say, I'll get on with seeing if I can reproduce the old behaviour in a Bullet demo environment. The demos themselves all seem to work fine, and don't report errors, so I'm not sure what's causing my heap corruption above...

Sorry for being a pain, and thanks for all your hard work

[Major_Error]

Mea culpa Having hit myself with the "complete minimal example" stick, I've worked out what's going on, and if you tell me it's expected behaviour then fair enough!

Turns out it's an issue of scale; my polys are all fairly small (the co-ordinate system I'm using comes from some separate computer vision code I've written and am integrating Bullet into...) I've attached a zip with a modified version of BasicDemo and a serialised .bullet file of the scene, in case you want to reproduce it. The bricks fall straight through the terrain here, but don't when the polys are bigger.

I'm guessing the best solution to this is just to scale everything (say, by 100x) before I put it into Bullet, and scale back those transforms when I pull them out to render, do you think? Or is there something else I can do that will avoid the extra calculation?

[pico]

Mea culpa Having hit myself with the "complete minimal example" stick, I've worked out what's going on, and if you tell me it's expected behaviour then fair enough!

Turns out it's an issue of scale; my polys are all fairly small (the co-ordinate system I'm using comes from some separate computer vision code I've written and am integrating Bullet into...) I've attached a zip with a modified version of BasicDemo and a serialised .bullet file of the scene, in case you want to reproduce it. The bricks fall straight through the terrain here, but don't when the polys are bigger.

I'm guessing the best solution to this is just to scale everything (say, by 100x) before I put it into Bullet, and scale back those transforms when I pull them out to render, do you think? Or is there something else I can do that will avoid the extra calculation?

Everything smaller then 0.04 will not work. It has todo with the margin value.
Best practive may be to keep your smallest objects at a scale of 1.0.

[Major_Error]

Thanks for the insight, pico. Looks like I'll have to wrap everything in Bullet in a nice big scale factor!

Anyone on the forum have any ideas about the memory corruption I posted earlier today?

[pico]

Thanks for the insight, pico. Looks like I'll have to wrap everything in Bullet in a nice big scale factor!

Anyone on the forum have any ideas about the memory corruption I posted earlier today?

Without seeing the actual code its hard to say something but a possibility is that you allocate memory for one of bullets objects or structs or something and after passing that memory to bullet as a pointer you delete the memory. This would cause such a behaviour.