Hello World Introduction to Bullet

[SynVis]

For my first post to the forums I would like to start by thanking everyone that works on this project and the documentation. The demonstration software is quite impressive and I hope to grasp the knowledge that some of the people who post on this forum seem to have attained. That being said I'm a graphics guy that is playing around and this is my first attempt to use a physics library/engine. For a 'hello world' type application I set a goal of making a demo that drops a ping pong ball on a table with realistic bounce mechanics. A quick wikipedia search for table tennis shows that a ping pong ball dropped from a height of 30cm should bounce to a height of 23cm, yielding a coefficient of restitution of 0.88. I started by building a world to match this test scenario and quickly degenerated into the following setup:

Code: Select all

    _btCollisionConfig = new btDefaultCollisionConfiguration();
    _btCollisionDispatch = new btCollisionDispatcher(_btCollisionConfig);
    btVector3 worldAabbMin(-100,
                           -100,
                           -100);
    btVector3 worldAabbMax(100,
                           100,
                           100);
    _broadphase = new btAxisSweep3(worldAabbMin, worldAabbMax);
        
    // Default constraint solver.  
    _btSolver = new btSequentialImpulseConstraintSolver();
    
    // World object.  I believe this is the main object the application will
    // interact with
    _btWorld = new btDiscreteDynamicsWorld(_btCollisionDispatch, 
                                           _broadphase,
                                           _btSolver, 
                                           _btCollisionConfig);
    
    // Sets the gravity for this world: Z is up
    _btWorld->setGravity(btVector3(0, -0, -10));
    
    
    /*********    Create and position the table    ****************************/
    _btTableShape = new btBoxShape(btVector3(btScalar(1.48), 
                                             btScalar(2.75), 
                                             btScalar(0.5)));
    // Position the table in the world
    btTransform tableXForm;
    tableXForm.setIdentity();
    tableXForm.setOrigin(btVector3(0, 10, -0.5));
    
    // Set the mass of the table - zero means it can't move
    btScalar tableMass(0.0);
    btVector3 tableInertia(0, 0, 0);
    
    _btTableState = new btDefaultMotionState(tableXForm);
    btRigidBody::btRigidBodyConstructionInfo tableInfo(tableMass, 
                                                       _btTableState, 
                                                       _btTableShape, 
                                                       tableInertia);
    _btTableBody = new btRigidBody(tableInfo);
    _btWorld->addRigidBody(_btTableBody);                                                       
    
    
    /**************   Create and position the ping pong ball   ****************/
    // 40mm diameter, 2.7 grams
    // Should drop from 30cm and bounce to 23cm, COR 0.88
    _btBallShape = new btSphereShape(btScalar(0.02));
    btScalar ballMass(2.7);
    btVector3 ballInertia(0, 0, 0);
    _btBallShape->calculateLocalInertia(ballMass, ballInertia);

    // Position the ball in the world
    btTransform ballXForm;
    ballXForm.setIdentity();
    ballXForm.setOrigin(btVector3(0, 10, 2.0));
    _btBallState = new btDefaultMotionState(ballXForm);
    btRigidBody::btRigidBodyConstructionInfo ballInfo(ballMass,
                                                      _btBallState,
                                                      _btBallShape,
                                                      ballInertia);
    _btBallBody = new btRigidBody(ballInfo);
    _btWorld->addRigidBody(_btBallBody);

As you can see I gave up on the 30cm drop and went for nice round numbers to help debug the situation. My intent with the code above is to drop the ball from 1m above the table surface. I started with positioning associated graphics using the getOpenGLMatrix() function but after the results I just started looking at the Z values (Z is up in the sim code above, Z values obtained from getOpenGLMatrix()). I'm stepping the associated btDynamicsWorld instance at 60hz using the guide found in the Canonical_Game_Loop Wiki article on this site.

The first odd behavior I'm seeing is that the ball appears to fall below the top of the table (to a height of -0.162844) and then 'bounce' to a height of 0.2. I emphasize bounce because the ball doesn't really bounce because it rises to a height of 0.2 and then settles at that height. It almost looks like it bounces as demonstrated in the demo software but instead of peaking and falling back down it continues to rise to a height of 0.2m. I just feel like I'm missing something here.

The second question I have is with respect to gravity acceleration. The ball definitely accelerates downward in the Z direction but the acceleration seems much slower than expected. I timed dropping a ball from one meter and it was significantly faster than my observed results with Bullet. I suspect that this has to do with how I'm stepping the simulation but my diagnostics indicate a smooth 60hz.

The last question I have is with regards to the coefficient of restitution; none of the demo software seemed to address the 'bounciness' of an object. Any tips on where to start to replicate this behavior?

[chunky]

_btBallShape = new btSphereShape(btScalar(0.02));

That's really, really, small. This wiki article says that you probably don't want to use stuff smaller than 0.2 units.

Honestly, pretty much all of your issues may well be related to that. I'd suggest trying to just scale stuff up a bit and see what happens.

Regarding the ball not dropping at a speed that "Feels right", that's a common topic of discussion on these forums, and it usually boils down to scale. I'm not very good at holding numbers in my head, but you might want to check that you really are holding the ball a distance from the floor that's 'correct' relative to the width of the ball and the magnitude of gravity in your neck of the woods [which admittedly is hopefully similar to gravity here].

Dropping a ball that's 2cm wide from one meter high is like saying you're dropping a ball fifty times its own width from the ground. Is that what you're doing too, or are you dropping a basketball from waist height?

Gary (-;

[steven.hutheir]

Hi,

I have similar problems with gravity, it was already discussed here and the conclusion looks the same as SynVis guessed: http://www.bulletphysics.com/Bullet/php ... &sk=t&sd=a

Dropping a ball that's 2cm wide from one meter high is like saying you're dropping a ball fifty times its own width from the ground

Could you please explain what does that mean?

Is that what you're doing too, or are you dropping a basketball from waist height?

I think SynVis was pretty clear on what kind of ball and what height, even supplied a listing where we can see exactly what is he trying to do.


SynVis, have you tried changing the size, did it help?

I think it is recommended to have meters as distance unit and than you should have mass in kg not grams, but that shouldn't make any difference with free fall. In any case units do not matter much, it is about proportions and relations, but it might help to have units sorted out especially if you compare results with real life experiments.

In any case you should be able to enlarge your ball to the minimum size of 0.2meters without any impact on physics calculations because air resistance is not directly implemented in Bullet, but also be sure to take that lack of air resistance into account when comparing with real life experiment.


Steven

[chunky]

Dropping a ball that's 2cm wide from one meter high is like saying you're dropping a ball fifty times its own width from the ground

Could you please explain what does that mean?

Well, it's a question of perception. If you look at the big ball on-screen, it drops really fast because
1) It doesn't actually have as far to go; it hits the ground much sooner because it's much wider, in absolute terms
2) It doesn't appear to have as far to go because you're only dropping it three times its own width, while the smaller one has maybe fifty times its own width to fall

Gary (-;

[steven.hutheir]

Do you mean to say - "distance should be measured not from the centre of the ball, but from the lowest point" ?

..big ball on-screen, it drops really fast because

Without air friction acceleration of small objects is the same as big ones.

..it hits the ground much sooner because it's much wider, in absolute terms

It hits the ground sooner only if you measure the "distance" from the centre of the ball. Don't do that, because that is not a real distance you want to measure.

Everything is relative, "only Sith deal in absolutes"
For instance, If you move camera away - the big ball you were talking about ain't so big anymore and it shouldn't fall any "slower" just because we moved camera around.


Steven

[SynVis]

Sorry for going dark for a while. What is left of hurricane ike hit my area yesterday with winds greater than 80mph, which is very unusual for this area of the country outside of a tornado Suffice it to say having access to electricity has become a luxury in the short term.

I found the source of my first problem with respect to gravity and stepping the sim. Based on reading the comments in various demos it looks like the stepSimulation method of btDynamicsWorld wants a time step value in seconds, not milliseconds. I'm hacking this demo up on a new MacBook pro and being new to the MacOSX dev environment I was getting time in seconds when I thought it was in milliseconds, and then I was dividing the time by 1000.0 before calling ::stepSimulation(). Noobie mistake. After removing the divide by 1000.0 gravity seems much more effective

I have tried scaling the world by 10x and by 100x but the results are the same: The ball hits the table and rises to the height of the table plus the radius of the ball. So it is like it penetrates the table (or the radius of the ball depending on how you look at it) before the collision is detected, and then after the collision the sim corrects the error and over two or three steps. Attaching a depiction to the sim shows that the ball doesn't really 'bounce', i.e. collision plus rise in elevation and then another collision etc. It collides and then quickly rises to the height of the table which is the peak of the 'bounce'. This is where it settles and stops moving.

[SynVis]

More time spent with more electricity equals more answers

I started to think that the SDK was assuming a COE of 0.0, which would mean the two objects would effectively stick together which was causing my results. After grep'ing through the source code I found the restitution attribute hanging off btRigidBodyConstructionInfo, and setting this to a reasonable value other than 0.0 seems to have made a world of difference. For my floor static object I set the COE to 1.0; I wasn't sure about this since the limited COE descriptions I've read discuss COE with respect to a single object, but it makes sense that the static surface has this property (like bouncing on carpet VS concrete). After more searching through the code I found where both object's COE is multiplied to produce a combined COE. I set the COE of the ball to the documented value and got results that were actually very closed to the documented test case

Yay! On to the next problem