[ODE] Particle/cloth/skeleton (was: Re: Choleski factorization)

Sun Mar 23 15:17:02 2003

>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