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

[Adam D. Moss]

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.