[ODE] Vector types (was: Joint Groups)

[Jani Kajala]

> > struct AdamsVector {
> >   dVector3 data;
> > };
> struct MyVector
> {
>   int x,y,z;
>   operator [] ...
> };

It doesn't matter what kind of type the 3-vector is (for example sound library,
graphics library, collision library, rigid body library, etc. might all be
independent packages with own vector types). Pretty much standard solution is to
make utility class / set of functions for converting between different types.


Regards,
Jani Kajala

----- Original Message -----
From: "Ruud van Gaal" <ruud at marketgraph.nl>
To: <ode at q12.org>
Sent: Tuesday, November 20, 2001 1:20 AM
Subject: [ODE] RE: Joint Groups


> > > I would use classes (read structs for C interface) for Matrix, Vector,
> > > and Quat.  They don't need operators, I just want to subclass them so
> > > they transparently cast to my own math classes.
> >
> > why not:
> > struct AdamsVector {
> >   dVector3 data;
> > };
>
> I'd rather define such a vector using:
> struct MyVector
> {
>   int x,y,z;
>   operator [] ...
> };
> This avoids having to 'dive' into the struct with mystruct.data.<x> and you
can
> cast return values to the MyVector types (perhaps as long as you don't use any
> virtual functions, since this makes the struct bigger than just xyz, by
> including a vtable). The [] operator then allows you to use myvector.x as well
> as myvector[0] (for loops).
>
> > > Why do the vector set methods take 3 scalars, while setQuaternion takes
> > > your quat typedef?
> >
> > the rule is: pass up to 3 array values explicitly, pass any more as
> > an array pointer. this is for convenience, e.g.
> >
> >    dBodySetPosition (b, 0.1,0.2,0.3);
> >
> > is easier to type than
> >
> >    dVector pos;
> >    pos[0] = 0.1;
> >    pos[1] = 0.2;
> >    pos[2] = 0.3;
> >    dBodySetPosition (b,pos);
>
> I'd say an overloaded function would be helpful. I know, C has no function
> overloading, so either use that from C++ (preferred) or you could use an
> OpenGL-type of thing with dBodySetPosition3fv() and dBodySetPosition3f().
> Note that because your engine will be mixed with other code, programmers often
> have to integrate your library in existing code. In that code, other Vector et
> al classes are used, which are often float v[3] arrays for example. So the
> latter array call would then be easier (I know it is in mine; I'm converting
my
> race sim to be able to use ODE). And the latter function would have been
> useful.
> Also, it seems like dBodySetRotation() passes the entire matrix on the stack?
> Ofcourse this function shouldn't be used much, so it's not much of an issue.
> But having an entire set of Set() functions which takes pointers and direct
> arguments is more predictable in the end.
>
> > > The second imbalance is that you let the dBodyGet*() functions return
> > > an ugly pointer to a scalar
> >
> > refer to the manual, "13.2.2. Returned vectors". dReal* is returned
> > in some cases for speed reasons (for commonly called functions).
> > using a dReal* as the return value instead of, say, a dVector* is a bit
> > syntactically simpler for the user. and type safety-wise, there is no
> > difference (both can be indexed out of bounds).
>
> Well, I'd say returning a dVector* would give less confusion though as to how
> many elements are returned, as you'll likely access those elements using the
> vector class members, not []-ing the structure as if it were an array. And I
> think it's easy to mistake the rotation matrix for a 4x4 or 3x3 one instead of
> 4x3. Ofcourse, these are all small enhancements, so focus on your main goals
> and perhaps add things like this when your head is less anxious to do hard
> work. :)
>
> > > The C++ wrapper for the C interface in odecpp.h is a joke
>
> A C++ wrapper for a C interface that is in itself a wrapper for a C++
interface
> is a strange thing. ;-)
> I'd then use the original C++ classes.
>
> > bare in mind that ODE is still in the alpha stage, and as such still
> > has a few warts.
>
> I'd say the 0.025 number give too few credits to what your library already
> does, Russell. More like 0.6. Functionality counts, and when most things are
> *possible*, you can name it 1.0. Adding extra joints is just for versions
>1.0.
> But this ofcourse is all up to you. It's just some people might not want to
> consider  a library that is numbered 0.025 just because the number is so low
it
> would look unusable.
>
> Cheers,
> Ruud
>
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>