Wrong fall height calculation

[Ehsanizadi]

Hi,

I just started working with bullet. (Actually, I had a relatively hard time understanding stepSimulation function and its related arguments.)
I began with "helloWorld" tutorial, however, I have found a small issue with calculation of the falling height.
I have 2 questions:

1) With the default parameters of the helloworld script (fall height =50m and g= -10), first I tried with:

Code: Select all

dynamicsWorld->stepSimulation(1,0);

which means in every step the physics should forward at 1 second (correct me if I am wrong)

I get this results for the first lines:

Code: Select all

sphere height: 40
sphere height: 20
sphere height: -10
sphere height: -1.2
.
.
.

But according to the kinemtic equation of "z=(1/2)g t^2" the results should like:
sphere height: 45
sphere height: 30
sphere height: 5
...

Why there is such difference?

2) if I run the following command:

Code: Select all

dynamicsWorld->stepSimulation(2,0);

(I know it is not reasonable, its just for curiosity)

the results look like:

Code: Select all

sphere height: 10
sphere height: -70
sphere height: -13.2
sphere height: -1.84
sphere height: -1.84
.
.
.
sphere height: -1.84

So, this means that due to specified large time step (2 seconds) the sphere passes through the static plane. Ok, its quite reasonable. But why its height BACK near to the plane?
and Why it does not continue to fall and continuously decrease its height, i.e. to go deeper!

Regards,
Ehsan

[Basroil]

Why there is such difference?

Ever thought that perhaps the starting step is different? If you assume that the starting point is actually between 0.4 and 0.5 (first step at 1.4~1.5, second at 2.4~2.5, etc) , you get the results that bullet is giving. Double check your value for time, it might offset.

So, this means that due to specified large time step (2 seconds) the sphere passes through the static plane. Ok, its quite reasonable. But why its height BACK near to the plane?
and Why it does not continue to fall and continuously decrease its height, i.e. to go deeper!

Bullet is trying to correct for penetration error, so after an initial penetration the height should level out higher. Some shapes react differently than others when it comes to penetrations though, and not all will have the same error correction style.

[Ehsanizadi]

Thanks Basroil!

About question 1:
I've just started Bullet, and I just saw the time tuning can be done in stepSimulation() function.
So if I use "stepSimulation(1,0)", it means that at every step, simulation will go 1 second forward and without any internal stepping (since the second parameter is set to zero).

Actually, I did not get your point by "offset" of time and the way it should be determined within Bullet.
For more clarity I append my code below:

Code: Select all

#include <iostream>
using namespace std;
#include <btBulletDynamicsCommon.h> 

int main() {
	btBroadphaseInterface* broadphase=new btDbvtBroadphase(); 	
	btDefaultCollisionConfiguration* collisionConfiguration = new btDefaultCollisionConfiguration();
	btCollisionDispatcher* dispatcher = new btCollisionDispatcher(collisionConfiguration);
	btSequentialImpulseConstraintSolver* solver = new btSequentialImpulseConstraintSolver;
	btDiscreteDynamicsWorld* dynamicsWorld = new btDiscreteDynamicsWorld(dispatcher,broadphase,solver,collisionConfiguration);
	dynamicsWorld -> setGravity(btVector3(0,0,-10.0f));
	btCollisionShape* groundShape = new btStaticPlaneShape(btVector3(0,0,1),1);
	btCollisionShape* sphereShape = new btSphereShape(1);
	btDefaultMotionState* groundMotionState = new btDefaultMotionState(btTransform(btQuaternion(0,0,0,1),btVector3(0,0,-1)));
	btRigidBody::btRigidBodyConstructionInfo groundRigidBodyCI(0,groundMotionState,groundShape,btVector3(0,0,0));
	btRigidBody* groundRigidBody = new btRigidBody(groundRigidBodyCI);
	dynamicsWorld->addRigidBody(groundRigidBody);
	btDefaultMotionState* fallMotionState = new btDefaultMotionState(btTransform(btQuaternion(0,0,0,1),btVector3(0,0,50.f)));
	btScalar mass=1;
	btVector3 fallInertia(0,0,0);
	sphereShape->calculateLocalInertia(mass,fallInertia);
	btRigidBody::btRigidBodyConstructionInfo fallRigidBodyCI(mass, fallMotionState, sphereShape,fallInertia);
	btRigidBody* fallRigidBody = new btRigidBody (fallRigidBodyCI);
	dynamicsWorld-> addRigidBody(fallRigidBody);

	for (int i=0; i<300 ; i++){
		dynamicsWorld->stepSimulation(1,0);
		
		btTransform trans; 
		fallRigidBody->getMotionState()->getWorldTransform (trans);
		cout<<"sphere height: "<< trans.getOrigin().getZ()<<endl;
	}

	delete dynamicsWorld;
	delete solver;
	delete dispatcher;
	delete collisionConfiguration;
	delete broadphase;
	delete groundShape;
	delete sphereShape;

	return 0;
}

[zbuffer]

Why do you use that strange call to stepSimulation with a 0 for maxSubSteps?
Doing it means you don't allow substeps so why are you surprised that the simulation is not accurate?
It is not possible to get a precise result when you integrate something once a second.

When you are using a large timeStep then you have to pass appropriate maximum number of substeps.
Appropriate means at least timeStep * 60, with the default fixedStepSize of 1/60 s.

[Basroil]

Why do you use that strange call to stepSimulation with a 0 for maxSubSteps?

It's a perfectly valid call, but yes, calling it once a second is a stupid idea unless you want to make the correction to internal timestep or add more substeps (in this case 60). The original question wouldn't be changed though, since even with proper calls the ball is expected to climb back up rather than continue to fall (i'll just do it far more accurately with less penetration)