Real-Time Physics Simulation Forum

clutching at straws, but have you checked that m_debugDraw is a valid pointer at that point? It's interesting that the code above that line uses getDebugDraw() rather then m_debugDraw directly.

I believe you'll have to specifically set the :

short int m_collisionFilterGroup;
short int m_collisionFilterMask;

values on your callback as by default they're set to :

m_collisionFilterGroup(btBroadphaseProxy::DefaultFilter),
m_collisionFilterMask(btBroadphaseProxy::AllFilter)

I added some further logging to your demo just so I could see what the manifoldpoint data was as your force data was quite variable as you mentioned. I then ran a couple of different scenarios (different timesteps , ccd enabled or disabled) and got the following results which look pretty consistent ...

I know you will have other shapes later , but can you try it with a simple SphereShape first? this would help to isolate where the discrepancies are.

Can't see anything particularly wrong with what you've got. Though as there are external dependenices I can't run your example. You said you're using a sphere to test, have you tried using a sphere shape to simplify things first? replace btBvhTriangleMeshShape* triMeshShape = new btBvhTriangleMeshSh...

Sorry I'm at work so can't actually run this stuff through and see what happens, but do you get consistent results if you use the standard discrete collision detection? Also what size are your objects? could you post your demo code to make it easier to re-create?

Thanks.

What sort of variation are you getting (and what height values are you using) ? if you're dropping from a different height it's possible that it will have higher velocity and may penetrate further before being pushed back out again.

If you look at the use of gDisableDeactivation in DemoApplication.cpp as an example you can see how to override that value, a similar approach can be taken for gDeactivationTime

If you've built the JBullet.jar via ant then that should be in dist/jbullet.jar . If you add this to your project libraries, and then in order & export make sure that jbullet.jar is above the JBullet/src folder then it should correctly pick up the instrumented version.

Not sure it will help, but there are a couple of #defs in btCollisionWorld.cpp

//#define DISABLE_DBVT_COMPOUNDSHAPE_RAYCAST_ACCELERATION
//#define USE_BRUTEFORCE_RAYBROADPHASE 1

that might be worth enabling/disabling and see if you get the same issue?

Out of interest was it the wrapped version of Bullet or the pure c# version (BulletXNA) ? thanks

Sorry, looks like I was getting confused with the XNA functions for that. Looking at Andres' checked in code (Matrix.h) it seems like you need : static Matrix RotationQuaternion( Quaternion rotation ); to generate the rotation matrix from the quaternion. static Matrix Translation( Vector3 amount ); ...

Yup, it is Matrix. For your example :

BulletSharp.Matrix m = BulletSharp.Matrix.CreateFromQuaternion(new New BulletSharp.Quaternion(0,0,0,1));
m.Translation = New BulletSharp.Vector3(0, 50, 0);

or something like that

Yes it does,

Have a look at the MultiThreadedDemo in the Demos directory to see how to setup a parallel constraint solver etc.

The step simulation call takes in a time delta for each call (and an option fixed time step (default 60Hz)) . This is what Bullet will use to progress the simulation, so yes in your example below you're simulating a run time of 100 * (1/60) but are doing it it in .004s. Having it run at a fixed rate...