Experiments in framerate independence

Post Reply
chunky
Posts: 145
Joined: Tue Oct 30, 2007 9:23 pm

Experiments in framerate independence

Post by chunky »

I have no idea if this will be of interest to anyone, but I've been experimenting a little with framerate independence in bullet, mostly as a followup to this thread.

Basically, it's all here: Bullet Framerate Independence Stuff.

Sourcecode, graphs, and a vague conclusion, mostly supporting comment from Erwin, here:
You can decrease the inner timestep to improve accuracy in
collision handling. If you pass the real timestep, then make sure
maxNumSubSteps is large enough so that stepTime < maxNumSubSteps *
internalTimeStep. Otherwise the simulation will drop frames. So you can
increase maxNumSubSteps to a very large value. Alternatively just pass
'0' to maxNumSubSteps and pass a very small stepTime.
Anyways. Just thought it might be of interest, plus I was hoping to ask a question or two...

Why does maxNumSubSteps=0 appear to almost always works perfectly... except when internalTimeStep<stepTime?
Why do all the graphs suddenly appear to break just under 1/200 internalTimeStep? I suspect this one's the fault of my crappy code somewhere, but not sure.

Gary (-;
Last edited by chunky on Mon Dec 17, 2007 7:31 pm, edited 3 times in total.
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: Experiments in framerate independence

Post by Erwin Coumans »

Hi,

The main issue is that an internal variable simulation timestep is not recommended and unsupported.

To avoid the issue of variable simulation timesteps due to variable graphics framerate, Bullet uses a fixed internal timestep. It interpolates the motion state, and subdivides the timestep provided by the user.

Setting 'maxNumSubSteps' disables this independence, and this can lead to variable internal simulation steps.

The effect of a very small internal substep is likely to internal damping. Can you try if commenting out EXPERIMENTAL_JITTER_REMOVAL and FORCE_VELOCITY_DAMPING around line 121 and 212 of Bullet/src/BulletDynamics/Dynamics/btRigidBody.cpp makes a difference?

Thanks,
Erwin
chunky
Posts: 145
Joined: Tue Oct 30, 2007 9:23 pm

Re: Experiments in framerate independence

Post by chunky »

The main issue is that an internal variable simulation timestep is not recommended and unsupported.
It's typical. I found out what maxNumSubSteps=0 actually means mere seconds after posting. I'm trying the tests again with EXPERIMENTAL_JITTER_REMOVAL and FORCE_VELOCITY_DAMPING commented out as I write this...

Thank-you very much
Gary (-;
chunky
Posts: 145
Joined: Tue Oct 30, 2007 9:23 pm

Re: Experiments in framerate independence

Post by chunky »

Oh, hey, look at that. Commenting out those two made the graphs look all tidy

Before looking at the pictures, be aware that gnuplot decided to resize the Y scale for the last two graphs.

Thank-you very much,
Gary (-;
chunky
Posts: 145
Joined: Tue Oct 30, 2007 9:23 pm

Re: Experiments in framerate independence

Post by chunky »

OK, so, 2.65 is out. Thought I'd run my graphs again to see, and ... wibble. I would guess that it's to do with the change that forces are only cleared at the end of each step. The graphs are here: http://chunkyks.com/bulletframerate/2.65/

What I *think* is happening [from reading the source quickly] is this: The force clearing is done at the end of each world->stepSimulation [rather than each individual step]. This means that gravity is added each step [btRigidBody.cpp, ~line 207 near the top of void btRigidBody::applyForces(btScalar step)], but then is added to each step. Basically if you need to step more than once per world->stepSimulation, gravity increases linearly each substep instead of staying constant.

Gary (-;
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: Experiments in framerate independence. 2.65 update, problems

Post by Erwin Coumans »

I would guess that it's to do with the change that forces are only cleared at the end of each step.
Indeed, it accidently slipped in the Bullet 2.65 release, it is fixed in Subversion and goes into Bullet 2.66 very soon.
At the same time, the jitter-damping experiments will be removed from the btRigidBody class, based on various feedback here and here.

Thanks a lot for pointing this out,
Erwin
chunky
Posts: 145
Joined: Tue Oct 30, 2007 9:23 pm

Re: Experiments in framerate independence. 2.65 update, problems

Post by chunky »

I'm just glad to be able to help in some way :-)

Gary (-;
chunky
Posts: 145
Joined: Tue Oct 30, 2007 9:23 pm

Re: Experiments in framerate independence

Post by chunky »

It's fixed again in 2.66, all's good!
http://chunkyks.com/bulletframerate/2.66/

Gary (-;
Post Reply