stepSim twice per frame, gravity wrong but model size ok

[dev1]

Hi, my question is about the value of the gravity vector and calls to stepSimulation and it doesn't seem to be having the effect I expect.

I'm setting gravity to -9.81, as gravity should be and to just test whether the simulation is running at a realistic speed, dropping a car from 490.5 units up. With 1 unit = 1 meter the car should take bang on 10 seconds to hit the ground.

This isn't happening. Calling stepSimulation only once per frame it takes about 15 seconds for the car to hit the ground. I'm not expecting the time to be exactly bang on as the framerate is slightly lower than 60 fps so there should be a bit of interpolation going on but it is noticably wrong!.

The OgreBullet demos call stepSimulation twice every frame (with same timeSinceLastFrame each call). Why is this? Surely that is twice as much physics processing as required? Of course this gets the time to hit the ground closer to realism but now its more like 8 seconds.

One call to stepSimulation per frame takes btVector3(0,-9.81 * 1.9,0) to drop the car on 10 seconds!

My question is why doesn't the car drop on 10 seconds with only 1 call to stepSimulation per frame, even though gravity is -9.81?



The call is mWorld->stepSimulation(evt.timeSinceLastFrame, 9999, 1./60.);

evt.timeSinceLastFrame is in seconds as required.
Framerate is ok, and so the 9999 max substeps should be keeping the physics simulation realtime.
each call to stepSimulation is through OgreBullet as that is the wrapper I am using, but having looked through the OgreBullet code it simple performs a call with the same parameters through to the bullet stepSimulation method so doesn't seem to be the culprit.

Many thanks.

[mi076]

I'm setting gravity to -9.81, as gravity should be and to just test whether the simulation is running at a realistic speed, dropping a car from 490.5 units up. With 1 unit = 1 meter the car should take bang on 10 seconds to hit the ground.
This isn't happening.

Can not confirm. Droping something from 490.5 m takes 10 s (without air resistance), it works exactly as it should . Checked it with Bullet's demo and in own app. Please use (overwrite) Demos/BasicDemo to reproduce the case.

evt.timeSinceLastFrame is in seconds as required.
Framerate is ok, and so the 9999 max substeps should be keeping the physics simulation realtime.

I'm not expecting the time to be exactly bang on as the framerate is slightly lower than 60 fps so there should be a bit of interpolation going on but it is noticably wrong!

check this:
http://bulletphysics.org/mediawiki-1.5. ... _the_World

The OgreBullet demos call stepSimulation twice every frame (with same timeSinceLastFrame each call). Why is this?

No idea, no BulletOgre experience. Sounds strange.

The call is mWorld->stepSimulation(evt.timeSinceLastFrame, 9999, 1./60.);

most likely the problem is wrong delta time. You need time elapsed since last stepSimulation call.

[dev1]

most likely the problem is wrong delta time. You need time elapsed since last stepSimulation call.

Thanks for checking the drop time in your app. This may be a stupid question but you say "without air resistance" - I'm assuming bullet doesn't model this?! If it actually does how can it be turned off?

I've just checked the delta time by using a completely seperate clock object for the stepsimulation call, and surprisingly got the same result as before - 15.5 seconds for the fall! So I don't think this is causing the problem.

I'll have to look at the bullet demo a bit more to get it compiling without linker errors, but in the meantime has anyone else used Ogrebullet and noticed a similar problem?

Thanks!

[jarno]

Do you have any linear damping on? Linear damping will slow down objects even in freefall.