Being the cheap bastard that I have to be, I'm looking for a free physics engine. It must satisfy the following requirements:

- Cross platform (win, lin & mac)
- Does not have to do 3D, 2D is enough.
- Support basic primitives of rectangle, circle, and point.
- Support non-complex polygon objects
- Provide some kind of unsigned long "userdata" variable
- Provide callbacks when a collision occurs
- Provide a method for determining if two objects can intersect *at all* (early test culling)
- Allow me to disable the linear or rotational components of individual objects, as well as disable them completely within the physics simulation

...I think that's everything. I've looked at a few different engines I could google, but didn't find any that really fit the bill. I won't name them here so as to keep your suggestions unbiased.

If you know of an item that fits the bill, please please let me know. I've been trying to write my own the last two days and either the equations are too hard or my methodology is all wrong. Please help me!

Thank you in advance :)

I'm not familiar enough with either one to know if it's everything you're looking for, and I'd be surprised if at least one of them didn't turn up in your searching, but here are two popular, free ones I know about:

http://www.tokamakphysics.com/
http://ode.org/

I don't know of any free ones, but when it comes to writing your own, there's a good article on writing a verlet-based physics engine in the book Game Programming Gems 4. It's really straightforward, and comes with source.

Yeah, ODE is pretty nice.

- Roulette

Never used it, just came across it the other day: DynaMo, a free (LGPL) library.
http://home.iae.nl/users/starcat/dynamo/

If you know your vector math (ie, using cross and dot products) then you should be able to come up with a fairly decent 2D verlet based physics engine on your own. The basic tenets of them are very simple and there's an excellent article on GamaSutra:

http://www.gamasutra.com/resource_guide/20030121/jacobson_01.shtml

Which I based my own stuff on, however it needs a HUGE overhaul before it's really useful for the sort of game I want to make now.

For vector math it's worth taking a gander at:

http://www.gamedev.net/reference/programming/features/vecmatprimer/

And reading up a little on what information you can get out of cross and dot products (which you'll need to determine if a point is inside a polygon). Plus you'll need algorithms for calculating intersecting lines and also nearest point on a line (if you're having particles with a radius) but I can mail you those.

The Gamasutra article looks intersting, they're certainly taking a different approach. I was trying to resolve the first moment of collision, deal with it, and then step the rest of the way through the timestep (or until another collision occured). This method was terribly accurate but also a major headache. I think I like this one more.

The only thing I don't understand in the Gamasutra article is in figure 4b of page http://www.gamasutra.com/resource_guide/20030121/jacobson_03.shtml. I don't know how point q was determined.

GrahamG, I believe that I have the equations you mentioned, I think the big challenge will be resolving the constraints.

Originally posted by Aggrav8d
The Gamasutra article looks intersting, they're certainly taking a different approach. I was trying to resolve the first moment of collision, deal with it, and then step the rest of the way through the timestep (or until another collision occured). This method was terribly accurate but also a major headache. I think I like this one more.

The only thing I don't understand in the Gamasutra article is in figure 4b of page http://www.gamasutra.com/resource_guide/20030121/jacobson_03.shtml. I don't know how point q was determined.

GrahamG, I believe that I have the equations you mentioned, I think the big challenge will be resolving the constraints.

Yeah, it's a nice simple way to do it as it's never 100% right, but it always *looks* right as long as you don't let it get too far out of whack.

I think point q is just the vertice common to both transgressed lines in that diagram. That's going to be the only type of collision if everything is a polygon of at least 3 points.

Resolving the collisions will be the trickiest bit, though, yeah. But even then it's not too hard. What I like about their approach is that it's just lots of really simple checks and routines instead of one big scary one. :)

That's going to be the only type of collision if everything is a polygon of at least 3 points.

Um, shouldn't that be "at MOST"? Imagine a very large triangle with one side bisecting a box. the box has 4 points, and I can't see any obvious way for determining q. (tho by looking at it the answer is, i think, guessable)

I'm making a prototype with ODE and it's quite good, although it's also quite complicated, low level, and assumes you know physics to do anything except the most simple stuff. It may be overkill for what you are trying to do, though.

Originally posted by Aggrav8d
Um, shouldn't that be "at MOST"? Imagine a very large triangle with one side bisecting a box. the box has 4 points, and I can't see any obvious way for determining q. (tho by looking at it the answer is, i think, guessable)

q would be whichever point on the cube was inside the triangle. Don't think of the landscape as something else - just think of it as an immovable physics object.

Oh, and I meant at least as in there are no objects which are single vertices or sticks formed from two vertices.

I meant the cube is static (world mesh) and the triangle is moving. Aslo, there would be more than one point from the cube inside the triangle.

The physics engine used in the last indie game jam was nice. I'm not sure how free or available it is though, especially for commercial use.

Originally posted by Aggrav8d
I meant the cube is static (world mesh) and the triangle is moving. Aslo, there would be more than one point from the cube inside the triangle.

There might be more than one point, but you only do things one point at a time. :)

Just choose one (whichever is sequentially first in your world mesh - doesn't matter) and call it "q" then find the nearest point on the line which intersects with one of the lines from it and carry out the operation as normal. Then do the same for the other corner of the square. Same if you have three points of the square inside the triangle, however if all four are then obviously there'll be no intersecting line occurring and so you must have *really* let things get out of whack! :)