Sign in to follow this  
Funkymunky

chipmunk or box2d?

Recommended Posts

I'm thinking of using an open-source 2d physics library with a project I'm working on. I've looked around and it seems that my 2 best bets are box2d and chipmunk. I'm leaning toward chipmunk because it's newer (and inspired by box2d), but I don't have any real working knowledge of either library. Anyone have any experience they'd like to share?

Share this post


Link to post
Share on other sites
CHIPMUNK!!!
I absolutely adore chipmunk! It is much better than box2d!
The creator is very active on the forum, and will answer your questions very quickly, plus he is constantly updating the SVN.
I haven't had any bad experiences with it.

Share this post


Link to post
Share on other sites
One thing i've noticed with chipmunk is that you have to have a really low timestep for it to be solid, i think i ran it 200 times a second in my litte app. But it doesnt require that much cpu anyways so it's pnot really a problem. Better yet is to split every timestep in three or more as the author does in his demos.

[Edited by - lexs on January 1, 2008 1:46:10 PM]

Share this post


Link to post
Share on other sites
Google has turned up this reference from Gamedev itself. To quote (the first post on that page):

Quote:
Original post by pTymN
Chipmunk basically a glorified and optimized version of Box2D.


Does that statement hold water, or is it biased? I'm still a bit hung up on the thought of chipmunk being designed with partial inspiration from Box2D; it seems like that would imply improvement.

Share this post


Link to post
Share on other sites
Quote:
Original post by Funkymunky
Google has turned up this reference from Gamedev itself. To quote (the first post on that page):

Quote:
Original post by pTymN
Chipmunk basically a glorified and optimized version of Box2D.


Does that statement hold water, or is it biased? I'm still a bit hung up on the thought of chipmunk being designed with partial inspiration from Box2D; it seems like that would imply improvement.



It was written before Box2D was released...before it was more like a sample code for Erin Catto's presentation. There were some big changes after the release.

Share this post


Link to post
Share on other sites
Quote:
Original post by Funkymunky
Google has turned up this reference from Gamedev itself. To quote (the first post on that page):

Quote:
Original post by pTymN
Chipmunk basically a glorified and optimized version of Box2D.


Does that statement hold water, or is it biased? I'm still a bit hung up on the thought of chipmunk being designed with partial inspiration from Box2D; it seems like that would imply improvement.

I believe Chipmunk is a glorified and optimized version of Box2D Lite, not the new Box2D.

Share this post


Link to post
Share on other sites
Well i've played with them both now, and I'd say they are equally easy to integrate / utilize. I'm leaning more toward Box2D now after the replies I've gotten in this thread.

Now I have a question which is actually relevant to both libraries, so I'll post just go ahead and post it here: What is the deal with these timesteps? I mean, I understand the concept of feeding the physics engine a timestep so as to advance the simulation by some tiny increment. However, both libraries seem to say that you shouldn't tie this timestep to the framerate. My question is, why not? It seems like, for a game, this is exactly what I want to do. I want the physics to perform relative to the rate at which my display is being rendered. Otherwise, gravity will be slower/faster on weaker/stronger machines, as well as pretty much every other physical interaction. Why not use the framerate as a basis for the timestep; because it can cause inaccuracies in the physics simulation? What is the best way to handle this, because I want the physics in the game to perform the same regardless of framerate.

Share this post


Link to post
Share on other sites
Using a fixed timestep for physics means you always run the same number of physics frames per second, thus it'll act the same on all systems. This is better in many ways than changing the timestep based on your (display) frame rate. Variable timesteps don't work with some integration methods (Verlet) and can cause inaccurate/unpredictable results with others if the frame rate drops too low.

The easiest way to implement fixed physics timesteps with variable frame rate is to simply run N timesteps each frame, where N varies depending on how much time has elapsed since the last frame. I tend to use a timer that increments a counter e.g. 100 times a second, so each frame I just check how much the timer has changed and do that many physics updates. I usually limit it to maximum of ten updates per frame to prevent runaway slowdown (too many updates slows down the frame rate, causing even more updates next frame etc).

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this