[ODE] Particle/cloth/skeleton

[david@csworkbench.com]

Right, I was more making a point that it could be done than anything.  The
point is not to have the verlet integrator replace the rigid body
integrator, but to prove that it is flexible enough for the rare case
where you need the fancy constraints for particles.  I really don't expect
anything that would use the verlet integrator to be more complex than a
piece of rope, cloth, or water surface.  All inanimate (unpowered)
objects, which are there just to provide a higher sense of realism in your
world.  What are some other good applications of them, that aren't better
done with the rigid body side?

Has anyone ever seen the "cloth" between some areas in Everquest for
example (hidden caverns behind Shadow Haven)?  (Yes, I wasted 6 months of
my life in that game).  You basically walk through a board... no
interaction whatsoever.  A game with a "general" physics back-end
shouldn't have to resort to such tactics when there are good fast ways to
integrate soft bodies into the system.  Of course, if no one is going to
use it, there's not much point in me writing it.  But if people are
already writing specialized implementations of them for their
applications, a more general version that's built into the physics engine
would allow for a lot more 2-way interaction.

David

>
>>Verlet:
>>http://www.gamasutra.com/resource_guide/20030121/jacobson_01.shtml.
>> (Pretty much a reprint of the Hitman paper).
>>You really could constrain more degrees of freedom with just the
>> distance and angle constraints if you wanted to. For example, to make a
>> hinge, you simply attach a given structure at 2 particles (see link
>> page 4 for graphics -- if they had used a 2 particle wide leg, the
>> orientation calculation becomes a cross product).  A slider could be
>> implemented with two particles, and a third with a 0 degree angle
>> constraint.  I don't see why all the joints in ODE couldn't be
>> implemented as particles with distance and angle constraints.
> modeling rigid bodies as particles is rather unconvenient as they
> generate really many constraints which in turn means that really many
> iterations are needed
> in order to achieve an acceptable error(objects changing volume with
> highspeed impacts, etc..)
>
> Not to mention problems in the collision response. Talking about rigid
> bodies i would steer
> well away from that method.
>
>
>
>
>
>
>
>
> <david@csworkbench.com>@q12.org on 23/03/2003 20:11:56
>
> Sent by:    ode-admin@q12.org
>
>
> To:    <ode@q12.org>
> cc:
> Subject:    Re: [ODE] Particle/cloth/skeleton (was: Re: Choleski
>        factorization)
>
>
> Verlet:
> http://www.gamasutra.com/resource_guide/20030121/jacobson_01.shtml.
> (Pretty much a reprint of the Hitman paper).
> You really could constrain more degrees of freedom with just the
> distance and angle constraints if you wanted to. For example, to make a
> hinge, you simply attach a given structure at 2 particles (see link page
> 4 for graphics -- if they had used a 2 particle wide leg, the
> orientation calculation becomes a cross product).  A slider could be
> implemented with two particles, and a third with a 0 degree angle
> constraint.  I don't see why all the joints in ODE couldn't be
> implemented as particles with distance and angle constraints.  Of
> course, I may have all this
> oversimplified, since I haven't really delved into it yet, and you may
> not be able to afford all those particles, so that may just not work.
> But that's not really the point.  If you want to make a person, you
> implement them as a normal rigid body setup.  If that person, however,
> happens to be Batman, you attach a particle-based cloak to strategic
> points on his rigid body torso, and it would flap around when he ran.
> Or you could have a flag attached to a rigid body pole, add a little
> random "wind" force to each particle, and watch it flap in the wind.  Or
> you could allow your characters to climb ropes, that actually swing like
> a rope should, without all the added computations that small bodies with
> ball joints between them causes.  The particle system wouldn't replace
> the rigid body system, but augment and provide functionality it just
> can't do.  The more I think about it, the more I realize I could just
> use the tri-collider or some other particle, stick, and triangle
> collision functions with the normal collider, and integrate the verlet
> integrator into every iteration of the algorithm I'm working on, and
> have great interaction between rigid and soft bodies, both ways.
>
> David
>
>> david@csworkbench.com wrote:
>>> Then I could do a verlet integrator.... anybody interested in cloth
>>> and other particle effects (seen some cool water demos)?  There's
>>> only two constraints: distance (also known as stick constraints) and
>>> the angle between 2 sticks.  It shouldn't be too difficult to
>>> implement them as inequality constraints.  The integrator and the
>>> collision detection are really integrated, so a simloop would call
>>> normal collision and step routines, then the particle engine, and the
>>> particles would "flow" around the rest of the bodies.  There's a
>>> paper on the Hitman game and an article on Gammasutra that explain
>>> the concept better, I'll find the links if you're interested.  The
>>> basic concept is that you just make a particle at each of the
>>> vertices of a mesh, and then the mesh would act like cloth and drape
>>> over anything it came in contact with, or you could make it
>>> weightless and move one particle up and down to make a rippling water
>>> effect.
>>
>> A Verlet integrator paired with a simple constraint system is
>> quite fun, but IMHO might not ideally fit within ODE unless
>> it's going to be quite comprehensive.
>>
>> Two reasons:
>> * It's pretty easy to write a cloth or particle simulator with this
>> technique as something fairly independant of ODE.
>> * As soon as you want particles (and/or their connecting 'bones') to
>> have constrained orientations, which is essential for hanging skin
>> meshes off of them, the simple simulation described in the Hitman
>> paper needs to be rather expanded (the author just hints that
>> they derive/correct the bone orientations for their game after the
>> solving is complete, which sounds like something that'll work as a
>> hack only for well-known systems [e.g. a particular human skeleton
>> where they correct the knee orientation]).  The way in which
>> these orientations are derived, stored and constrained is somewhat
>> dictated by what the user wants to do with the resulting data
>> and one size might not fit all.
>>
>> That said, although the particle simulation can be done quite
>> independantly of ODE's simulation it's useful for such systems
>> to do collision-detection (particle-environment collision, skeleton
>> self-intersection and cloth self-intersection in particular, the
>> latter of which I'd like to know an excellent solution to) for
>> which ODE's pretty good collision-detection can be used.  There
>> *might* be advantages to a close tie between ODE and the particle
>> simulator for this reason.
>>
>> I haven't seen the gamasutra article.  I do find soft-body
>> simulation exciting and I'd like to see it in ODE, but IMHO
>> only if it's comprehensive enough to both be generally useful
>> and to benefit from tight integration with ODE itself.
>>
>> However, I'm not sure I vote for SIMD-like optimizations at this point
>> either.  :)  :)  :)  You've proven that there are interesting and
>> fairly radical *cross-platform* optimization opportunities within ODE,
>> and I find that whenever code gets an assembly implementation it tends
>> to 'crystalize' as people become fearful of spoiling the
>> sync between the C and assembly versions, and version 0.035 of
>> ODE seems terribly early to start crystalizing code.
>>
>> Right now I'm quite excited about seeing your iterative solution in
>> action.  That could change a lot of peoples' minds about where the new
>> performance hotspots are (the collision system might be
>> a really severe villain again, for example) and could influence
>> the answer to the question you posed in your email.
>>
>> Thanks for your work!
>>
>> --Adam
>> --
>> Adam D. Moss   . ,,^^   adam@gimp.org   http://www.foxbox.org/   co:3
>> ... but his bosses didn't like him so they shot him into space.
>>
>> _______________________________________________
>> ODE mailing list
>> ODE@q12.org
>> http://q12.org/mailman/listinfo/ode
>
>
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
>
>
>
>
>
>
>
>
>
>
> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they are
> addressed. If you have received this email in error please notify
> postmaster@scee.net
>
> This footnote also confirms that this email message has been checked for
> all known viruses.
>
> **********************************************************************
>  SCEE 2002
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode