New physics article on gamasutra

DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #1
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 Cool Ninja . 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
Quote this message in a reply
Member
Posts: 164
Joined: 2002.04
Post: #2
My character physics in black shades were loosely based on that Cool
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #3
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
Quote this message in a reply
w_reade
Unregistered
 
Post: #4
ooh, I like that. I'll be playing with that over the next few weeks, I think...
Quote this message in a reply
Member
Posts: 201
Joined: 2002.06
Post: #5
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?)
Quote this message in a reply
w_reade
Unregistered
 
Post: #6
...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 this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #7
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
Quote this message in a reply
w_reade
Unregistered
 
Post: #8
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 this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #9
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
Quote this message in a reply
w_reade
Unregistered
 
Post: #10
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.
Quote this message in a reply
DoG
Moderator
Posts: 869
Joined: 2003.01
Post: #11
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
Quote this message in a reply
w_reade
Unregistered
 
Post: #12
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
Quote this message in a reply
Post Reply 

Possibly Related Threads...
Thread: Author Replies: Views: Last Post
  For Beginners - article on game development Byron Clarke 0 2,556 Jan 19, 2006 03:23 PM
Last Post: Byron Clarke
  One-button game article Fenris 3 3,885 Jun 10, 2005 09:15 AM
Last Post: funkboy