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

[gl]

BTW, just to make the point that box stacking performance is actually quite
desirable for me (someone said previously that it wasn't to them).  I'm keen
to experiment with simple buildings that can be destroyed, so the more
things I can stack stably at reasonable speed, the better (of course I would
disable bodies once they're close to rest, but when they're interfered with,
speed is key).
--
gl

----- Original Message -----
From: <david@csworkbench.com>
To: <ode@q12.org>
Sent: Monday, March 24, 2003 8:57 PM
Subject: RE: [ODE] Particle/cloth/skeleton (was: Re: Choleski factorization)


> I am proposing reordering the contact joint's Info2 structure (in the
> GetInfo2 function), so that when a 3 DOF contact joint is created, it's
> penetration dimension, now stored in the first row of J, c, lo, hi, etc.
> is stored in the third row.  This makes simple, non-sliding collisions
> (which I presume happens more often than sliding ones) faster in my
> implementation by removing the refactorization step for them, and
> shouldn't affect the LCP system, unless you assumed that the penetration
> dimension would come before the friction dimensions at some point in the
> LCP code.  While I'm in there, I think I might have a solution to the
> powering into/away from joint limits problem that I'd like to try.
> There's no way to isolate the ordering change, though, short of reordering
> them in the function... wasting the cycles I was trying to save.  It
> probably won't make that big of a difference except in the most
> pathological cases (block walls), but it might help a bit.  So I can
> understand if you're protective of your code and would rather it stay like
> it is.  Or is there some restriction on the order of the rows of the
> Jacobian?
>
> The separate files argument does make sense.  I'll take the variables I
> added back out of the body class and implement them as an extra array.
>
> I'll need upload access to CVS at some point.
>
> Ah, yes, documentation.  I almost forgot.  I knew those 5 years of Honors
> English would come in handy at some point...  They probably also explain
> the length of most of my emails :)
>
> David
>
> >
> >> Well, the iterated solver is basically finished, but I was hoping to
> >> get an answer from Russ about changing the order of contact
> >> constraints and whether that will mess anything up in the old solver
> >> first....
> >
> > change the order how? are you proposing a change in the ODE core? or can
> > this change be isolated to the new code?
> >
> > as to contributing your code ... if would be best if your new code is
> > structured as separate source file(s) that can be put in the main src
> > and include directories. that way we can keep separate CVS changelogs,
> > you can edit your stuff in CVS without worrying about affecting anything
> > else, etc.
> >
> > also ... don't forget to document your new functions! :)
> >
> > russ.
> >
> > --
> > Russ Smith
> > http://www.q12.org/
> >
> > _______________________________________________
> > ODE mailing list
> > ODE@q12.org
> > http://q12.org/mailman/listinfo/ode
>
>
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
>