Verlet with Rigid Body

From my minimal experience I notice:

Pros

• Quick to process


• Practically any geometry can be simulated


• Soft Bodies


• Integration with other areas of physics such as pool balls and rope/cloth

Cons

• Has been described as "bouncy" with few iterations


• Inaccuracies develop from relaxation


• Collision detection and response is tricky

That is what I've gathered so far. I am very satisfied with the results although I will admit it was more difficult than I first thought. Collision detection is tricky to get working (aka believable). And it's not a perfect solution. Please visit my physics engine webpage and look at some of the sources provided. They should help.

[Edited by - y0y on January 25, 2005 7:44:55 PM]

no, Jakobsen is NOT the perfect system for rigid bodies
the advantage of Jakobsen is the ability to do non-rigid, and articulated bodies

the overhead of calculating springs and stuff for Jakobsen, when your object is rigid anyway and doesnt really need them, is why most physics engines dont use his system

if you want purely rigid bodies then just use rigid body math - classical mechanics and linear algebra

Quote:

Original post by q2guy If its so good, why the most used physic engines aren't using verlet for rigid bodies ?

Because whilst it's easy to get results really quickly using this method, as soon as you start doing slightly more complicated things like adding friction, non-inelastic collisions, angular constraints etc your code becomes full of hacks, more complicated than an impulse-based solution, behaviour becomes unrealistic and less robust etc etc. Well, that's my experience anyway.

Having said that, don't get confused between Verlet integration, and representation of objects by points-and-springs. For example - the Jakobsen paper does _not_ describe using Verlet integration for _rigid_ bodies.

I know of two descriptions of using Verlet integration for true rigid body simulation:
http://www.gdconf.com/archives/2004/baltman_rick.pdf
and one of the chapters in Game Programming Gems 4.

I've yet to see a 3D Verlet/particle demo (including mine!!) that comes anywhere near matching the behaviour and speed of impulse-based engines (including mine again!). So my advice is steer clear of it...

Some time ago when rag dolls were the height of fashion I added the features to my engine. This was all done with classic RB physics, but I was also doing work on the games dust/particle effects. For this I used particle physics with constraints (something I remembered from my college days). I used constraints to keep cloud sprites together but allow them to be blown in wind. I extended this to have a particle rag-doll, in much the same way as described in Jacobsens paper. I thought it was the future of physics systems, really fast physics with very little code (the whole particle physics system was maybe 1000 lines of code including the doll construction and collisions). Like a farmer discovering petrol driven tractors for the first time I spent all my time writting a particle based RB physics engine, convincing my boss it was the best thing to do (as I had pretty much finished the classic system for the game we were doing).

All went well, I could import models from Maya, construct the particle model/constraints and release it into a world. The first impression was good, the reactions seemed perfect, boxes would bounce, and come to rest with no additional code to make it do that (a classic RB implementation would have seen it bounce forever before you introduce fome friction/energy losses). However when we tried to make a game demo with it things went pear shaped. The energy losses became a burden as it was hard to get different levels of bounce, values in the coll responce code were way off what you would expect, and it came down to doing every object by eye, often adding some extra object specific code to achieve a nice look.

Another problem was with object stacking. The constraints will never be perfectly satisfied so if you have, say 3 objects stacked, the bottom one would be deformed, eventually popping out like a wet bar of soap in your hands as you give it a squeeze. This was a difficult problem, I only had satisfactory results when I used a set of object space points repositioned with a ori/trans matrix I calculated from the particle object. This brought some other problems that I was not willing to try to solve. By this point the code was messy, and looked hacky not because of bad implementation but because of the object specific code and hacks to get it to look correct.

At that level of almost being able to do what a simple classic RB system could do it was neither faster or cleaner.

That said for simple stuff it is useful, for explosion debris and other non-important effects its perfect, for that it is faster and the code you need is very small.

You can get upward of 1000 rag dolls (2ghz p4) on screen all being calculated, which i doubt you could get with classic RB, although the dolls are simple, at distances they look really nice, even up close they are good, but you pay for double hinged limbs like a leg with a knee etc.

The thing is processors are fast enough to cope with lots of classic RB objects, so the nasty hacks and potential bugs/unpredictable results from particle based physics pbjects outweigh any speed advantage it may give.

Hello,

I've been trying to implement Advanced Character Physics. Its going very well so far except for a bug I haven't been able to solve yet due to the nature of how I handle collision. Collision response was a huge pain although after implementing irregular objects - it unified a lot.

Classic RB Physics? I'd definitly like to improve my system I do notice its not providing a lot of flexibility. Any information would help. I.e. are there any physics that are as powerful and easy as verlet ingration & Constraints but more precise

Demo: http://cogsprocket.com/~qhacks/jason/Gordon_exe.zip
Minimum Requirements:
Resolution: 1024x768
.NET Framework 1.1 Runtime

Quote:

Original post by HexSkillz Demo: http://cogsprocket.com/~qhacks/jason/Gordon_exe.zip

I wanted to try this but get an error: "System.IO.FileNotFoundException"

:(

HexSkillz, I had quite hard time shutting your app down :P

Something that has been bothering me: how are the physics implemented in havok, tokamak, novodex and so on? Impulse-based? What does it mean?
The verlet method is really quite easy, because I had my own simulation running from scratch in couple of hours...

Thanks for replies, I will go for a impulse based engine, but I'll give a little try to verlet&constraint method that seems easy.

When we tell impulse based engines (like havok, novodex, tokamak, ...) it means that you apply only impulse to objects (applying every frame to get a especific velocity/accel), or you can apply aceleration&initial velocity too ?

Quote:

Original post by q2guy When we tell impulse based engines (like havok, novodex, tokamak, ...) it means that you apply only impulse to objects (applying every frame to get a especific velocity/accel), or you can apply aceleration&initial velocity too ?

No, "impulse based" engines will let you apply forces or impulses to objects. The point is that they handle collisions between objects by applying impulses, the magnitude of which is just right to make the objects bounce apart (by affecting their velocities), rather than pass through each other, when they collide.

The particle-based Verlet method handles collisions by modifying object (in fact particle) positions, not velocities. The velocities do get affected, but thats a consequence of the objects being moved (to resolve interpenetration) by the engine.

Quote:

Original post by y0y Has been described as "bouncy" with few iterations Inaccuracies develop from relaxation Collision detection and response is tricky

Can explain further about the last 2 points of your cons? In accuracy, do you mean that relaxation can give only an estimate of the true configuration? Does have more iterations help? Also what do you mean by "tricky"? Thank you.

Quote:

Original post by Mystery Quote: Original post by y0y Has been described as "bouncy" with few iterations Inaccuracies develop from relaxation Collision detection and response is tricky Can explain further about the last 2 points of your cons? In accuracy, do you mean that relaxation can give only an estimate of the true configuration? Does have more iterations help? Also what do you mean by "tricky"? Thank you.

I'm glad you asked. By inaccuracies I mean the result of forcing particles into place even if they violate other constraints or intersect with other bodies. Relaxation is designed to dynamically correct this so it should never be a serious problem. But it is a problem. Collision response occasionally doesn't come out how you would expect because of the constraints displacing the particles. In my attempt to fix this, I developed this physics loop:

1. Sum forces for each particle
2. Integrate to each particle's new position
3. Update the bounding regions of each rigid/soft body
4. For each colliding body...
---A. Swept particle/particle collision detection+response
---B. Swept particle/(static) constraint collision detection+response
5. For each iteration
---A. Satisfy the constraints
---B. Separate the bodies

The initial coldet+response is just used to determine accurate collisions whereas the iteration loop is used to keep the system's shape.

Collision detection and response can be implemented in many ways. That's why I said it is tricky. First, there's the method Jakobsen presented in his paper. Then there's Bouncer's particle-with-radii method. Finally, there's kyc's dynamic constraint method. I've went with Bouncer's method so if you want an example, here you go.

Quote:

Original post by y0y I'm glad you asked. By inaccuracies I mean the result of forcing particles into place even if they violate other constraints or intersect with other bodies. Relaxation is designed to dynamically correct this so it should never be a serious problem. But it is a problem. Collision response occasionally doesn't come out how you would expect because of the constraints displacing the particles. In my attempt to fix this, I developed this physics loop: 1. Sum forces for each particle 2. Integrate to each particle's new position 3. Update the bounding regions of each rigid/soft body 4. For each colliding body... ---A. Swept particle/particle collision detection+response ---B. Swept particle/(static) constraint collision detection+response 5. For each iteration ---A. Satisfy the constraints ---B. Separate the bodies The initial coldet+response is just used to determine accurate collisions whereas the iteration loop is used to keep the system's shape. Collision detection and response can be implemented in many ways. That's why I said it is tricky. First, there's the method Jakobsen presented in his paper. Then there's Bouncer's particle-with-radii method. Finally, there's kyc's dynamic constraint method. I've went with Bouncer's method so if you want an example, here you go.

Thanks for the detailed explanation. I will take a look at the links you provided above. Btw, I am using Jackobsen system for my system. However, I have currently a little problem with my simulation.

THe objective of my simulation is to flatten a 3D structure which for example could be book. However, i have problem flattening it totally.

Here is an illustration:

Before


After


I am using a very simple collision response scheme. Anything that goes below the plane is simply projected up to the plane. I am not whether this is the main cause of my problem. The only external force I have is a downward force modelled by gravity.

I have posted a thread on this sometime back. You may want to take a look at it -> http://www.gamedev.net/community/forums/topic.asp?topic_id=291135


Maybe you can give me an advice or two. Thanks in advance.