[ODE] RE: Joint Groups

[Ruud van Gaal]

> > 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