Ahh... I finally got it quite right. Few days back I was trying to tackle frame rate independent physics. Sad to say, bullet physics as nice as it was, was horrible at interpolation. This is due to it doing extrapolation instead of interpolation which didn't work very well with force intensive physics (Having multiple forces applied to an object at each simulation step).

The reason for interpolation/extrapolation of physics is so that physics can be simulated at a fixed time step to maintain stability and determinism. This means that given an exact state of an initial physics world, the simulation will always end the same way with the given fixed input in any number of tries. However, as frame rate is not in fixed time step and can fluctuate depending on cpu/gpu performance, interpolation/extrapolation was introduced to provide "smooth" graphical display.

The sad part about bullet though was that it's doing extrapolation. In layman term, this means predicting into the future. In some sense it's correct if you think about each simulation is a few millisecond behind the current rendering frame. But it causes horrible jerks due to the prediction.

Hence I went and dig through bullet's source and modified it to do backward interpolation or I should say "true" interpolation as described here: http://gafferongames.com/game-physics/fix-your-timestep

After this, I managed to get good frame rate independent simulation which helped a lot on my machine where fps fluctuated around 30 to 60. All was nice and dandy until we tried it on the faster 8800GTS and 9800GT cards. It was giving horrible jerky motion due to fluctuating fps of 58 to 60. Thanks to Ogre for providing the frame smoothing feature. After turning it on and tweaking to a good enough value (0.05 - meaning average 3 frames at most), we got pretty darn smooth simulation. :)

But there were still some vital pops and jerks once in a while due to paging geometry. In the end, I had to crack my head and totally put all processing of paging geometry stuffs into the background thread. That solved almost all jerks and pops. :)

I think I'm happy with what I've achieved thus far. Now I can focus on network and scripts. FINALLY!

P.S. I'll be posting up a patch to bullet for that interpolation feature once I get enough time. I didn't remove the extrapolation technique. Just #defined them so users can switch between them when compiling. I think they should really embrace this method as the default though. It works a lot better for visual side of things even though it means visual is slower by 1 frame.
Posted by Lf3T-Hn4D


Prometheus said...

Great job man ! *3 thumbs up!*

March 30, 2009 at 5:46 AM  
Alex Delderfield (AD-Edge) said...

Very interesting stuff to read about. Its awesome that youve recoded some of bullet to interpolate like that now, very impressive.

Im sure the developers will be interested in seeing the new feature! Good to hear youll be posting a patch.

March 31, 2009 at 6:34 AM  
Anonymous said...

nice work! interpolation FTW :)

March 31, 2009 at 12:43 PM  
Lf3T-Hn4D said...

Hey, Thanks Glenn! Your articles were a huge help to me. :) It's going to be even more help once I start getting networking in. :D

March 31, 2009 at 7:52 PM  
Erwin Coumans said...
This comment has been removed by the author.
August 12, 2009 at 1:07 AM  
Erwin Coumans said...

Bullet is supposed to interpolate between two known frames A and A+1. Would you mind posting your patch on the Bullet forums or the Bullet issue tracker, so we can have a look?

Thanks a lot,

August 12, 2009 at 1:09 AM  

Post a Comment

Liquid Rock Games and Project Aftershock. All Rights Reserved.