Recommended Posts

Hello folks,
I'm implementing and comparing different kind of constraints, and I'm a bit confused about the so-called verlet constraint, which is described in wikipedia (http://en.wikipedia.org/wiki/Verlet_integration). It says:

Quote:

The most notable thing that is now easier due to using Verlet integration rather than Eulerian is that constraints between particles are very easy to do.

What I fail to understand is why this (rather crude) constraint is supposed to work better with velocity-less verlet integration? Why shouldn't this work exactly as good (or bad) with any other integration scheme?
Cheers,
Mike

0

Share this post

Link to post

Share on other sites

I think the idea is that when you project the configuration out of a collision, this gives you a "rebound velocity" of (projected_out_position - colliding_position)/dt automatically without the need to explicitly compute it, since Verlet works entirely with positions and not velocities.

I think this process should tend to dissipate energy, but so long as you're symmetric in each interacting pair with your corrections my guess is that it should conserve momentum. So it seems you get some sort of plastic collisions this way, but that you don't really know what's going to happen with any more specificity than this.

0

Share this post

Link to post

Share on other sites

It works "better" in that it's easy to program and use if you don't understand the underlying math or physics. <sarcasm>You just change positions for particles to not be in bad positions and your simulation magically gives proper behavior</sarcasm>. It's a tinker's approach to physics, without an understanding of the underlying laws the simulation should be trying to mimic.

If you understand enough math to know what Gauss-Seidel relaxation is, and what an integration scheme is and what the different ones are, you've already exceeded the boundaries of the Jacobsen paper. It was really aimed at people who don't know what they're doing :)

But because the Jacobsen paper is so famous, it's hard to escape its shadow when talking about verlet. That section in the wiki article came from the Jacobsen paper (I've tried correcting wiki a bit on this point. The mention later in that paragraph about not giving proper behavior necessarily is mine).

0

Share this post

Link to post

Share on other sites

You're right that that general approach is applicable to other integration schemes, however you'll then have to solve a position-level *and* a velocity-level constraint. The way that Jakobsen uses Verlet integration, position and velocity are coupled so that you only have to solve a single constraint.

Also I'm not sure, but I don't think it's correct to call that solution "relaxation"; solving multiple interacting constraints in that way would be relaxation, but each individual constraint is (approximately) solved by descending the gradient.. I have no idea what the correct term for this sort of equation-solving/error-minimization is though.

0

Share this post

Link to post

Share on other sites

Original post by NumsgilIf you understand enough math to know what Gauss-Seidel relaxation is, and what an integration scheme is and what the different ones are, you've already exceeded the boundaries of the Jacobsen paper. It was really aimed at people who don't know what they're doing :)

Thank for pointing this out Numsgil. I had a suspicion about this but got confused because I trusted the Wikipedia & Jacobsen article more than I should've. Lesson learned :-)

Cheers,Mike

0

Share this post

Link to post

Share on other sites

Original post by NumsgilIf you understand enough math to know what Gauss-Seidel relaxation is, and what an integration scheme is and what the different ones are, you've already exceeded the boundaries of the Jacobsen paper. It was really aimed at people who don't know what they're doing :)

I think you're not giving Jakobsen enough credit; not only did he apply the RATTLE step-and-project solver to a completely different context (realtime simulation instead of molecular dynamics), he also demonstrated an alternate approach to rigid-body simulation, picking up the Overveld/Barenbrug torch.

That presentation/method also established the groundwork for the Position Based Dynamics stuff; AFAIK many if not most of the cloth/softbody systems used in games owe a debt to Jakobsen.

And he also showed that it's possible to introduce physics simulation in a way that's approachable to people who don't have a math background, and maybe inspire some of them to learn more and go further :)

0

Share this post

Link to post

Share on other sites

Jakobsen is important in the sense that he introduced a huge number of game programmers to a technique that (a) requires no background in physics to understand and (b) with little work results in a stable and usable "physics simulation" that may not be realistic but looks good enough in a game. There's a large number of indie games that would not exist without the popularization of Verlet integration. Gish, World of Goo, and my own Soup du Jour all build on Jakobsen. After reading his article I had my first soft body physics system running in a couple of hours. It felt downright liberating to see an object stably resting on another one without me telling it to stop.

0

Share this post

Link to post

Share on other sites

Do not get me wrong: there is something to be said for the tinker's approach. The damage comes from not understanding it for what it is. And it becomes especially confusing when proponents use the term "constraint", which conflicts with the more proper constraint Jacobian from eg: Erin Catto's GDC presentations. You have to unlearn most of that paper in order to figure out the real math/physics. It's sort of like BASIC vs. a real programming language.

And yes, that's how most cloth systems work. So it has a place, just (please!) not in a physics engine. You'll end up thinking everything magically works right until it doesn't. Which will be two days before you need to ship.