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

[gl]

I take your point, and it would be real nice to have those opts.

I'm not keen on compile time processor dependency though.  I'm also against
using DLLs - a) I don't like them (won't go into reasons), and b) the XBox
doesn't support them, and you never know.  Never looked into this before -
is there a clean solution?

Also, is there an issue with getting the exact same floating point output
across the different code paths?  Again something I'm not familiar with, but
as I'm writing a client/server based game, something to worry about.
--
gl

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


> The problem is, the worst parts of the current implementation is the
> multiplication of an arbitrarily large matrix.  In the iterated solution,
> it's multiplication of up to a 6x6 matrix with padding to 6x8.  And you
> may need to add or subtract the results from a vector instead of replacing
> them in some cases.... Yes, there are a few cases where generic D3D
> functions might work, but for the worst internal stuff, you'll need more
> robust functions.  So what I'm thinking is a couple of nasm-based files,
> one implementation for each of 3dnow, sse (I can do these 2), sse2 (No can
> do until Hammer arrives/is affordable), and a fourth in c for none of the
> above, and either statically link them into the program at compile time or
> get really fancy and dynamically link them at runtime.... but then we
> start running into OS issues.  Either way, NASM is cross-platform and open
> source, so the only issue there is that it adds a dependency other than
> just a c++ compiler.  But it sure beats writing a different inline version
> for gcc, vc++ (are even 6 and .NET the same?), borland, mingw....  4
> compilers and 3 processor technologies and your already up to 12 different
> implementations.
>
> Just my 2 cents (and the way I'll probably implement it unless someone has
> a better cross-platform open source idea),
> David
>
> > gl wrote:
> >
> >> > Be nice for all us win guys, that's for sure : ).  There is some
> >> processor specific optimisation going on in D3DX (the DX utility
> >> library that
> >> provides
> >> > quat, matrix and various vector classes/functions, amongst others),
> >> and
> >> yes,
> >> > you do get it transparently and its updated over time.  Using that
> >> library doesn't tie you to any other parts of DX in any way (eg.
> >> there are no rendering dependencies).
> >> >
> >> > It's not clear though exactly what they've optimised - their vec3
> >> equivialent doesn't use padding, so they probably only accelerate a
> >> few complex operations.
> >
> > There's a 4-D vector in D3D as well though.
> >
> >> >  Matrices should be (you can use an aligned version),
> >> > not sure about quats.  They do intend to keep adding optimisations
> >> in key areas though.
> >
> >> I should also mention that you would also automatically get support
> >> for AMD's 3DNow.
> >
> > And at *runtime*, not compile time.  This idea sounds better all the
> > time ;-).
> >
> > --
> > Gary R. Van Sickle
> > Brewer.  Patriot.
> >
> >
> > _______________________________________________
> > ODE mailing list
> > ODE@q12.org
> > http://q12.org/mailman/listinfo/ode
>
>
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
>