Check out http://www.gamasutra.com/resource_guide/...n_01.shtml. This physics approach is really great, it only took me this afternoon to implement . And it is faster than Baraff's engine (which I did a few weeks back), way faster, and the code is also a lot simpler, plus, the verlet integrator scheme is really very stable. :grin:

I suggest anybody doing physics coding to check it out.

- D.G

My character physics in black shades were loosely based on that

I am still running tests with this, but it seems to be the best thing since sliced bread. Until now, I was looking for an analytical approach to physics simulation, but the combination of the integration technique with iterative constraints seems to be real smooth and fast. Also, this technique doesn't show the creep of my matrix constraint system, which had its problems with quickly rotating systems. I put together a car body with 18 particles and 49 constraints, and it bounces quite realistically. Now I have to add wheels and a steering wheel, and off I go!

- D.G

ooh, I like that. I'll be playing with that over the next few weeks, I think...

Astounding. I didn't read it very carefully, but I got the general idea and it seems logical. (Why didn't I think of that?)

...hold on.

How does bouncing work? If the only information the physics system remembers (per particle) is two positions (and so one implicit velocity), then surely it can't access enough information, unless the collision is dealt with by the AccumulateForces step as well as the SatisfyConstraints step, which seems contrary to the spirit of the thing, and potentially confusing.

Assuming the only times the collision subsystem is called are inside SatisfyConstraints(), how can bouncing work? I'll believe that it does, and maybe I'll work it out for myself when I start doing this, but if anyone can clarify how one could make the system handle collisions with arbitrary coefficients of restitution, I'd be interested.

Quote:Originally posted by w_reade
...hold on.

How does bouncing work? If the only information the physics system remembers (per particle) is two positions (and so one implicit velocity), then surely it can't access enough information, unless the collision is dealt with by the AccumulateForces step as well as the SatisfyConstraints step, which seems contrary to the spirit of the thing, and potentially confusing.

Assuming the only times the collision subsystem is called are inside SatisfyConstraints(), how can bouncing work? I'll believe that it does, and maybe I'll work it out for myself when I start doing this, but if anyone can clarify how one could make the system handle collisions with arbitrary coefficients of restitution, I'd be interested.

Basically, before actually applying the constraint, you have to detect a collision, record its parameters, and make a response. If you want to have impulse based elastic collisions, you could apply a force equal to the impulse/timestep and then solve the constraints. Note that it is difficult to handle friction in this case.

The way I want to do it is to basically apply a force proportional to the amount of penetration. This way, slight interpenetration might occur, but the system is stable enough to allow for some pretty stiff spring constants.

- D.G

hmm. To make that look right, surely you'd have to go around messing with the old positions? ...although that might work reasonably nicely in practice; a SetVelocity() that leaves the current position unchanged but modifies the old position. A bit of a hack perhaps, but as far as I can see it's the cleanest solution... comments?

Quote:Originally posted by w_reade
hmm. To make that look right, surely you'd have to go around messing with the old positions? ...although that might work reasonably nicely in practice; a SetVelocity() that leaves the current position unchanged but modifies the old position. A bit of a hack perhaps, but as far as I can see it's the cleanest solution... comments?

You can just apply the right force. P = F*t (read: impulse equals force times timestep duration) and delta V = P/m (change in velocity equals impulse divided by mass), therefore dV = (F*t)/m. So you can simply get the force F = P/t, in case you calculate with impulse and you can add the force to the accumulator.

I am not sure (now I get it!) how the constraints will affect the velocity, though. You may want to try to exchange the integrating and constraint solving steps, then you have no problems for sure, but constriants are not strictly enforced (read: slight interpenetration of objects might occur).

I think the setvelocity hack defies the purpose of verlet integration, you might as well do it the classical way of keeping a seperate velocity vector all the way.

-D.G

Apply the right force... when do you calculate this? At the start/end of a frame, objects will (generally) not be interpenetrating, so you'll need to calculate the forces due to collisions sometime after they've moved a step but before you apply the constraints. But to move them, you've already added up the forces on them and accelerated them by those forces. You could calculate the force and move them again, but this means that they won't bounce right unless the (new) newPos - oldPos vector points in the right direction (ie the expected bounce direction) away from the surface that's been hit, which it won't necessarily. I think this problem also applies to your swap-the-order suggestion.

Modifying one of the verlet/constraint-computed positions seems to be the only way to second-guess this, and it seems less hacky to me to modify the old position than the new one. I don't think it necessarily defies the purpose of Verlet integration - it simply extends it.

I may have simply misunderstood something - if my objections are foolish or wrong please correct me.

I am not quite sure how deal with this collision thing, I will think about it some more when I get there. Maybe modifying the old pos is not such a bad idea, though I think there must be some other way. Wait... just got an idea. The collision is detected only after the verlet integration places the particle inside whatever it is colliding with. Then, the constraint puts it to the surface of the object, and the collision response is evaluated the next step only. This means, the particle moves out of the object, and hence the surface constraint doesn't do anything, and the collision response should look quite alright.

- D.G

Fair enough... although I think our suggestions are as hacky as each other, they're just different methods for getting round what seems to be a problem with Verlet integration.

Please do post if you work something out, though...

Cheers
william