• Advertisement
Sign in to follow this  

2D Physics Engine

This topic is 3901 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I'm looking for a free (preferably open-source) C/C++ library for simulation of rigid body physics in 2D. I've done a lot of google-ing, and it seems that there aren't any mature, reliable, maintained C/C++ 2d physics libraries (though I'd love to be proven wrong). I came across this thread, but a lot of the recommendations in it are now non-existent or don't meet all of my needs. The two choices that stand out are ODE, with object positions constrained to a single plane, or the Chipmunk Game Dynamics library. My main concern regarding ODE is, naturally, the fact that it was designed for 3D physics simulation. My game is going to have lots of physically enabled objects, and I'm concerned that the extra, useless dimension is going to result in lots of overhead, in both memory and computation. Another concern I have for ODE is 2D polygons - how should I represent them, if at all? Constructing 3D polygonal volumes for this purpose seems like it would very wasteful, not to mention overly difficult. Chipmunk seems to be a pretty nice library, but I have some concerns:
  • It's not quite finished, and I don't know if it's still maintained
  • The documentation available is not nearly as complete or as easy to follow as it is in other libraries (notably ODE).
  • I'm not sure if it will assist me in managing objects that shouldn't always act like rigid bodies (such as the player), for which I should just need basic intersection prevention. ODE seems to be well equipped for this (with its separation of collision detection and collision response), but it's not clear to me from Chipmunk's documentation whether or not this is well handled. Right now I'm leaning toward ODE. Do any of you know of any good 2d physics libraries? Do you have any recommendations given the choices available? I really want to avoid rolling my own physics/collision detection library, so any advice would be greatly appreciated.

    Share this post


    Link to post
    Share on other sites
    Advertisement
    Chipmunk is nice from what i've seen, but as you pointed out, it's not quite finished. But, it is however still under active development I believe. I think its main limitation is that it doesn't support user controlled "kinematic" objects, though static objects can be acheived by setting mass to be infinite.

    Other than that, i'm not sure, thought I can say that Chipmunk will be at least twice as fast as ODE because its collision detection is much simpler and tailored for 2D objects.

    If you want the missing features, i'm sure you could implement them without much effort. All it takes is adding a couple of functions to the cpBody source file to set the position, as well as a flag denoting a body as kinematic, and then modifying collision detection slightly to filter out pairs of kinematically controlled objects (your player for instance). Basically if two objects are both controlled kinematically, no collision detection should be performed. Otherwise, if one object is dynamically controlled and the other kinematically, then during restitution only the dynamic object will be altered. One can do this by setting the mass of all kinematic objects to be infinite, or setting their inverse masses to be zero.

    hope this helps.

    Share this post


    Link to post
    Share on other sites
    Good idea. One thing I forgot to mention, however, is that Chipmunk's source code has very few comments in it, so it may be difficult for me to find out where to put my alterations. I'm also not very knowledgeable in the areas of mathematics and physics. Nevertheless, that's probably my best option so far.

    On another note, I realized earlier today that I'll probably need support for line segments as collision barriers to simulate terrain-like surfaces, which makes using ODE less desirable (and Chipmunk more desirable).

    Share this post


    Link to post
    Share on other sites
    There are several 2D-physics projects based on Erin Catto's Box2D simulator: http://gphysics.com/

    The Box2D source is so clean and simple that you might want to just roll your own engine from that -- all you need is broadphase collision and support for arbitrary polygons.

    There are several ports of Box2D to other languages, that should be a good place to start -- this one has a lot of extra functionality, you could simply port the stuff that was added back to c++: http://www.cokeandcode.com/phys2d/

    raigan

    Share this post


    Link to post
    Share on other sites
    I took a look at the box2D stuff earlier, but it just isn't feature complete enough for me. It would consume too much of my time to try and add the features I need. It is a great resource though. Thanks for the suggestion.

    Share this post


    Link to post
    Share on other sites
    Wow, I'm surprised you guys have heard of Chipmunk. Has anyone actually used/dabbled with it? I've been somewhat cautious about getting too well known yet. (largely because of the poor documentation at the source level) I actually registered for an account a couple of months ago to evangelize, but then never did.

    To answer some of your questions:
    1) Yes it's maintained. Development has slowed now (too much competition for my free time at the moment), but I'll be happy to fix bugs. I should start scheduling time for all my personal projects. ;)
    2) I know the documentation is somewhat lacking (again, particularly at the source level). Considering that you're the second person that's emailed me this week about Chipmunk, I should probably make the docs a priority. If you do end up using Chipmunk, and would like to help... it would be... helpful...

    You're last question is a bit more complicated. It depends on what you want to do, but you can probably have both good rigid body behavior and a large degree of control.
    1) Do surface velocities help? They were added with sidescrollers in mind.
    2) Setting the positions explicitly will work, but will result in rather poor looking physics. A better solution would be to modify the velocity of the object to slew it to the desired position in the next timestep.
    3) For things like moving platforms or elevators, give them an infinite mass and slew them into position using their velocity. (Just make sure they don't trigger collisions with other infinite mass objects!)
    4) If you still really don't want the objects to act like rigid bodies, it wouldn't be hard to query for collisions using a cpShape and cpBody that aren't added to the cpSpace. You would have to do all the collision response on your own, which wouldn't be easy without the impulse solver to help you.

    There was mention of Erin Catto's Box2D. Chipmunk is actually using his impulse solving technique. On top of that I've implemented several collision primitives for the narrow phase, and a spatial hash for the broad phase. I'm actually listed on his page.

    Oh, and one last thing. Someone did manage to get it to build under MSVC. I could probably get a binary of the library if anyone wants. It sounds like a cleaner solution would be to use MinGW, as that has better support for C99. Help on this front would be appreciated as I have no Windows machines.

    Share this post


    Link to post
    Share on other sites
    Quote:
    Original post by Aressera
    Other than that, i'm not sure, thought I can say that Chipmunk will be at least twice as fast as ODE because its collision detection is much simpler and tailored for 2D objects.


    Don't quote me on it, but I would guess that Chipmunk's impulse solver (the most expensive part of the simulation) is faster that ODE's by a large amount, thanks largely to Erin Catto's contact persistence idea. I don't have sleeping for inactive bodies implemented however. I have no hard performance facts, so this is all purely speculation.

    The real benefit (and the reason I wrote Chipmunk) is that using ODE or Newton for 2D physics is obnoxious. I started down that road and thought there had to be a better way. When I saw that there really wasn't, I started Chipmunk's (terribly crappy) predecessor.

    [Edited by - skorche on June 22, 2007 1:34:15 AM]

    Share this post


    Link to post
    Share on other sites
    Awesome, thanks for the reply. It looks like your library may be the best solution for me. Since you've done a proof-of-concept platformer successfully, I imagine using your library for the same purpose can't be too hard [smile].

    I'll be using Visual Studio for development of the game, so if I can get it compiling, I'll send you the info and or project files.

    I may be able to help a little with documentation (no guarantee); I'll be gathering information as I attempt to integrate the library with the rest of my code base, and I can use that information for writing up some documentation.

    Thanks for taking the time to reply here. I appreciate your help.

    Share this post


    Link to post
    Share on other sites
    Hello, I posted this a few weeks ago on the bullet forums on the thread about Chipmunk's release:

    I have a 2D collision detection engine that performs fully swept collisions, modelling the swept movements as 4th order polynomials to find the root of. However, it absolutely cannot handle interpenetration. Does your physical solver resolve collisions in such a way that interpenetration is guaranteed not to ever occur?

    [edit]
    The collision detection makes the assumption that objects move from non-penetrating positions to new non-penetrating positions. If I were to adapt your physical solver code to my collision engine, does it already or could it easily be instrumented to not stop converging until the relative velocities of any contact point is zero or positive and not negative.

    [Edited by - pTymN on June 22, 2007 3:20:42 PM]

    Share this post


    Link to post
    Share on other sites
    Oh, I haven't looked on that forum for quite a while now. Sorry about that.

    To answer your question, interpenetration is fixed iteratively after the collision occurs. However, given that you can do swept collisions, you could just look a frame ahead right? Catch the collision on the frame before instead of after. This won't necessarily guarantee non-interpenetration though unless you use a *lot* of solver iterations.

    What kind of primitives do you support? Is your code open-sourced? Supporting swept collisions would be awfully nice.

    Share this post


    Link to post
    Share on other sites
    Sign in to follow this  

    • Advertisement