More Chipmunk Physics goodness.

[Skorche]

Domino Pyramid (http://cda.morris.umn.edu/~lemb0029/pyramid.mov)

This is an animation that I made for my senior seminar presentation using my physics library. It didn't actually run in real time, but a stack with half as many dominoes (250 or so) runs quite well on my 1.8GHz G5.

Domino pyramid + meteor. (http://cda.morris.umn.edu/~lemb0029/meteor.mov)

I recently got around to adding contact persistence, which makes resting contacts rock solid using only a few iterations of the constraint solver for each frame. I'm hoping to work on cleaning up the API a bit over Christmas break and releasing it publicly.

[maximile]

That looks so impressive. I'm looking forward to the release.

[unknown]

That looks absolutley amazing!

[Nick]

Very cool. Can't wait for a public API.

[akb825]

Very nice. Is this only 2D, or is there 3D physics, too?

[Skorche]

Very nice. Is this only 2D, or is there 3D physics, too?

It's 2D only. I was frustrated by the lack of a good library to use for 2D Physics. I tried using ODE and wasn't particularly impressed. Newton was better, but I eventually came to the conclusion that using it for physics in 2D games was awkward. That, and at the time, I didn't know there was a Linux version.

Besides, there are plenty of good 3D physics libraries out there already.

I actually used to make towers like that out of dominoes. I was even nerdy enough to record one once so I could see how it unravels, and I can verify that the wave of dominoes that sweeps out the bottom of the left side actually happens for large enough towers.

[imikedaman]

Wow, very nice! I have to do something very similar for my senior project too - the tentative title is "Real-time nonconvex rigid body dynamics", and I'm doing 2D for now. Hopefully I can pull off what you did there...

[imikedaman]

Oh I should ask, is this Verlet or rigid body dynamics?

[Skorche]

It's rigid body dynamics. I gave up on vertlet physics for anything more than strings and particles a couple years ago.

[DoG]

Using Verlet integration for rotation in rigid body physics might be worthwile, but I haven't seen a way of doing that, yet :)

[Skorche]

If you really wanted to do vertlet integration with rigid bodies, you could use first order impulses to resolve the interpenetration. (I already do something similar to this for resolving interpenetration) The problem is it makes friction and restitution really difficult because you aren't really dealing with the velocity of the objects directly.

[DoG]

Umm, the problem is rather that there isn't any convenient way to store velocity implicitly. Calculating velocity from pos/prev pos of a particle is simple, but I haven't seen a viable way for rotation, yet. I don't care as much about the constraints as the relatively high stability of verlet integration of stiff systems.

[Skorche]

Getting the rotation isn't hard, you just store the current and past rotations for every body instead of making them out of particles and distance constraints. That pretty much makes it into a rigid body.

Edit: You're right, getting the velocity isn't the problem, but that in order to model friction and restitution properly you'd have to modify the velocity which gets messy because you can't do it directly. Also, you end up needing to calculate the normal impulse anyway if you want to get a decent friction response. By the time you do all this, you've lost any benefits of using vertlet integration and you've made your life much more difficult by not having the extra state information on the bodies.

And I'd debate the stability of stick constraints when used to make rigid bodies out of particles. It takes too many iterations of the distance constraints to even keep the shape of a body. And because the shape changes every time, collision detection becomes much more difficult. Ultimately, using Jakobsen physics this way is really inefficient.

[Nick]

I can't wait to see this in action. I had a question though. What license are you planning on using for the library? I recently began working with C# and XNA over on the Windows side (I know, I'm evil or whatever), but I was wondering if it would be allowed for me to take your code and port it to C# so I can use it with my work there as well. Just curious.

[unknown]

You cant write bindings for C#?

[Nick]

You cant write bindings for C#?

I'm not sure. I haven't done much with C# to know what I can fully do. I don't know too much about the language just yet.

[Skorche]

It'll be some BSDish license.

It probably won't port well to C# though. You might be better off starting over from the original Box2D code (http://www.gphysics.com/downloads/) where I got most of the ideas. It would be much easier to port his C++ code than my C code. I've made a few modifications to the general algorithms, added a spatial hash to speed up collisions, and added a better set of collision prmitives, but nothing really groundbreaking.

I'd be a bit weary of the performance that you would get from C# for this kind of thing. I saw that there was a Java implementation of Box2D, and while it wasn't poorly written, (recycled it's objects, used spatial hashing, etc) it was way slower than my C implementation.

[DoG]

Getting the rotation isn't hard, you just store the current and past rotations for every body instead of making them out of particles and distance constraints. That pretty much makes it into a rigid body.

Edit: You're right, getting the velocity isn't the problem, but that in order to model friction and restitution properly you'd have to modify the velocity which gets messy because you can't do it directly. Also, you end up needing to calculate the normal impulse anyway if you want to get a decent friction response. By the time you do all this, you've lost any benefits of using vertlet integration and you've made your life much more difficult by not having the extra state information on the bodies.

And I'd debate the stability of stick constraints when used to make rigid bodies out of particles. It takes too many iterations of the distance constraints to even keep the shape of a body. And because the shape changes every time, collision detection becomes much more difficult. Ultimately, using Jakobsen physics this way is really inefficient.

I dont think we are talking about quite the same thing, though we seem to be getting closer :)

When I say Verlet integration, I mean just that, namely storing velocity/rotational velociy implicitly, none of the Jakobsen type incremental constraint resolution.

The real problem I see is with rotation is that it is hardly possibly to store it implicitly, at least not without significant computiational overhead. You can't just apply the usual Verlet formula when integrating, rotational velocity needs to be somehow calculated (this is the first problem) and then applied. Hardly pretty, methinks. However, if there was a viable way, I'd love to see it.

[Skorche]

I'm still not entirely sure if I understand what you mean then. It's easy enough to store the current and past position, and the current and past rotation. Integrating the rotation is then done exactly like the position.

An even better movie: meteor.mov (http://cda.morris.umn.edu/~lemb0029/meteor.mov). :)
http://cda.morris.umn.edu/~lemb0029/meteor.png

[DoG]

I'm still not entirely sure if I understand what you mean then. It's easy enough to store the current and past position, and the current and past rotation. Integrating the rotation is then done exactly like the position.

I tried that, didnt work, though I might have done something stupid, as I do quite often recently. If you know how it would work, please share.

[Fenris]

That's so awesome it hurts. I'll definitely put it to good use on my next project.

[Skorche]

I tried that, didnt work, though I might have done something stupid, as I do quite often recently. If you know how it would work, please share.

It goes something like this right?
v_new = 2*v_curr - v_past

You could just do the same with the rotation.
r_new = 2*r_curr - r_past

Applying collisions or constraints to the objects becomes much more difficult (and computationally expensive) though. You need something like an impulse that you can apply to the position, and such a thing doesn't really exist. However, if you treat the separation as the relative velocity and solve for the impulse to satisfy that. Then multiply the "impulse" by some small factor like 0.1 and apply it to the position/rotation. Iterating this process will give you a pretty good approximation of resolving the collision or constraint.

Once again though, I think Jakobsen style physics works terribly if you need friction or restitution. You can make it work, but the solution ends up being really convoluted. I just wouldn't use it for rigid body physics anymore.

[DoG]

You could just do the same with the rotation.
r_new = 2*r_curr - r_past

You're right, that works, and now I think I figured out where our theories don't match: That only works in 2D, unfortunately, but breaks down once you have to deal with 3D rotations, in either vector, quaternion or matrix form.

Either way, right now even though my physics loop uses verlet for position and implicit euler for rotation, I assume I am not gaining much right now, with a simple collision response, i might as well use implicit euler in both cases.