A pure-Python physics library?

Martin on 2010/07/23 18:57

So I was noodling round today while waiting for some real work to finish running, and I started reading about rigid body dynamics. To cut a long story short, I seem to have found myself writing the skeleton of a pure-Python 2d physics library.

Now, this isn't going to be a replacement for Chipmunk or Box2D or any of the other "real" physics libraries. It's likely to be quite slow, and not very feature-complete, and probably a bit unstable. On the other hand, there won't be any dependency issues, the interface should be relatively pleasant and Pythonic, and in theory it should be debuggable by anyone who knows Python. I've seen a lot of people struggle during Pyweek with physics libraries, and they're definitely one of the larger causes of people being unable/unwilling to deal with dependencies during voting. Hopefully this would alleviate these problems somewhat, and provide enough functionality for the fairly minimal needs of a lot of Pyweek entries.

So what I'm asking here is, would anyone be interested in this, if I continued development? It's obviously not going to be ready for this coming Pyweek, but I imagine even with my busy schedule, I could have something fairly complete for next time round. I'm likely to keep writing it at least for a bit as an intellectual exercise, but I'd have more motivation if I knew there were folks out there who wanted to use it. Any thoughts?

(log in to comment)

Comments

saluk on 2010/07/23 20:17:

The irritations of getting the physics libraries you mentioned running on this or that version of python would make your library look pretty good for pyweek. If it can do mostly what people need it will be cool. I probably wouldn't use it for a fuller game. It would be cool if you could somehow use the power of box2d or chipmunk if they were available, while still using the same interface, but that would take a lot more work!

richard on 2010/07/23 21:33:

I'd be interested because it might even be more readable than pure-C libraries :-)

Also, there's cython :-)  [look in my last pyweek entry for some cython goodness]

richard on 2010/07/23 21:35:

Oh, and I hassled the PyPy core devs about the MacOS standard library module while we were hanging around EuroPython, so there's a good chance we'll be able to use PyPy to run pyglet games under OS X soon! The JIT kicks serious performance butt (the time to run the curve generation benchmark in my last game was cut from 27ms per run down to 6ms per run -- cython only squeezed it slightly lower to 2.2ms per run.)

Martin on 2010/07/24 22:48:

richard: I'm not sure how much help cython would be - a lot of the slowness in a physics library involves some relatively complex algorithmic stuff, rather than simply bashing out numbers. I'll certainly look into it, but speed is not really a goal right now.

saluk: I think that using the "power" (by which I mean speed) of Box2D and Chipmunk probably wouldn't be that much work, but it would mean that one would be limited to the common subset of functionality between all three libraries, and that your code would likely run differently depending on which libraries were installed, depending on the choice of integrator and so on.

Anyway, you've both convinced me that it's a worthwhile project (like I needed another one). Watch this space for an early demo soon.

viblo on 2010/07/26 15:12:

I think it would be very cool if you managed to get something working. Before I started the pymunk project (built on top of the c library chipmunk) writing a pure python lib (possibly with help from numpy) was one of the options I considered, but with my math skills, time constraints and the speed disadvantage I took the wrap-a-C-library path instead :)

As for reusing the same interface as either pybox2d or pymunk, I think that it would have been great to have a fallback if the real lib is not available. But at the same time I see the point about other problems from this approach. I certainly don't want my pyweek game to be unbeatable just because the physics lib missed a fast moving box which it handled perfectly with another set of libs.

About the speed, most games (both in python and in other languages) that Ive been involved in usually have some kind of performance problem.. :) We usually do code first, profile/optimize later, and for some reason most of the fun parts are also heavy. I would certainly think some before choosing a slower lib if the difference is big, but it depends on the game, if its about balancing a box on top of a circle the limit will probably be somewhere else.

richard on 2010/08/06 08:31:

I've just come into the Morgan Kaufmann Real Time Collision Detection book by Christer Ericson.

It's gonna make for some interesting reading :-)

tartley on 2010/08/09 12:26:

That book's been bubbling around on my stack for ages, but I've never got around to it. I'd be interested to hear what you think of it (as no doubt would we all)