You can check out my cloth demo in the idevgames source code archive. It uses the technique from the gamasutra article along with my own implementation of friction. It wouldn't be difficult to extend it to do ragdoll or soft body physics since it's just how you attach the constraints together that matters.

Tod.

Quote:Originally posted by AJ Infinity
OSC: I use Havok. But my version cames with Director MX.

Can you use that version of Havoc outside Director? In other words could I use it in my CodeWarrior game project using C++?
If not, it's not much of an option. Looking at the Havok site, there's no standalone Mac version of it.

KenD

I suggest you start away with an object oriented language, as anything more complicated than 2 points cries for it.

That gamasutra really helps, but also look for Chris Hecker and Paul Bourke, they have fairly in-depth papers about constrained physics and rigid body geometry, but it requires a good math background.

The problem with the verlet relaxation and points concept in the aforementioned gamasutra article is that it is not really useful except for simple and sparse systems.

There is no really good way to speed up collision detection as you can with rigid bodies, so it gets slow for complicated things. I tried putting togetehr a car model with independnt suspension, but my system was crawling, even with a single ground plane to do collision detection with. Secondly, it is hard to do body to body collision detection that way, since you only have connected particles, but no surface mesh or even volume, though you can work around that by making the particles spheres, and testing collision between particles.

Quote:Originally posted by DoooG

There is no really good way to speed up collision detection as you can with rigid bodies, so it gets slow for complicated things. I tried putting togetehr a car model with independnt suspension, but my system was crawling, even with a single ground plane to do collision detection with. Secondly, it is hard to do body to body collision detection that way, since you only have connected particles, but no surface mesh or even volume, though you can work around that by making the particles spheres, and testing collision between particles.

I thought the article recommended that you write your own collision detection routines and use them in combination with the topics covered in the article. With a decent 3rd party or custom collision detection library behind it I don't see why the ideas presented couldn't be fast, unless I'm missing something... In the article they mentioned that verlet relaxation was used in a commercial game, however I forget the name of it now.
-- Ian

Hitman (2?).

It does indeed have nice ragdolls.

Quote:Originally posted by Ian Kerr
I thought the article recommended that you write your own collision detection routines and use them in combination with the topics covered in the article. With a decent 3rd party or custom collision detection library behind it I don't see why the ideas presented couldn't be fast, unless I'm missing something... In the article they mentioned that verlet relaxation was used in a commercial game, however I forget the name of it now.
-- Ian

As long as you only have to do collision detection of the particles against static objects (which can be easily put into spatial groups like octrees), things work just fine, which is what was done in "hitman", iirc. But when you are trying to collide a group of particles with another, you run into the problem that is not possible to do collision detection between point-like particles, since they have no surface, and just slide past each other.

You need to extend the particles to spheres, or dynamically build a surface mesh over your particle soup (not fast, not neat). The spheres approach is easy to program, but hard to use, as you can no longer build a simple mesh, but have to manually define its volume. gack, that's where I gave up last time trying to extend my particle system with decent collision detection. you might want to look at sourceforge.net/projects/ssframework/ which contains most of what I have done with a classical constraint solver and a vertex solver for particles.

To use the verlet scheme for rigid bodies, you have to (as the article said) use a tetrahedron of particles use the positions of those particles to determine the orientation of the rigid body, and do collision detection against the actual shape of the body rather than against the particles.

This means that for rigid body dynamics, the complexity of collision-detection is the same whether you use this scheme or another...

Quote:Originally posted by OneSadCookie
To use the verlet scheme for rigid bodies, you have to (as the article said) use a tetrahedron of particles use the positions of those particles to determine the orientation of the rigid body, and do collision detection against the actual shape of the body rather than against the particles.

This means that for rigid body dynamics, the complexity of collision-detection is the same whether you use this scheme or another...

Not quite. There is extra work involved in creating a physical model which has close to nothing to do with the triangle mesh of your actual object. This is largely manual work. And it is close to impossible to morph objects at runtime, which would require re-positioning the verlet particles, possible adding or removing some, too, depending on the body change.

Unfortunately, rigid body dynamics, especially with constraints, is not a trivial task to implement by itself already, not even considering collisions.

Maybe its just me, but when discover the limits of something, and I have to add some hack to the original system to make things work, I get aggrevated.

So i'm not the only one then....

I try to be more pragmatic about it... It's very, very hard to design software with 100% accuracy, especially when tackling a particular problem for the first time. I tend more to find joy in getting my code to do something new that I never expected it to do than focus on how it was done (aside from being efficient and bug-free, of course).

Quote:Originally posted by Mark Levin
I try to be more pragmatic about it... It's very, very hard to design software with 100% accuracy, especially when tackling a particular problem for the first time. I tend more to find joy in getting my code to do something new that I never expected it to do than focus on how it was done (aside from being efficient and bug-free, of course).

My exact point. I do something for a purpose, but then I want it to do more sooner or later. When it does not work for a certain purpose because of some petty technical glitch or limitation, I get angry.

Has anyone managed to use ODE on Mac? I tried building it for a few days, but gave up...

Quote:Originally posted by Fenris
Has anyone managed to use ODE on Mac? I tried building it for a few days, but gave up...

Yep. Works like a charm. I can't remember if I built a framework for it or just a static lib.

If you have a look here...

http://homepages.paradise.net.nz/~henryj...x.html#ODE

...there is a bunch of stuff. When I get home tonight I'll see if I can find any more of my ODE stuff if you're interested.

I just found the source distribs, but that's probably good enough for me, by the time I get enough time to try it out. I bookmarked you, so I'll get back to you. Thanks!