[ODE] Joint Groups

[Russ Smith]

hi adam,

> Is there any reason for explicit joint groups with a fixed size.

the fixed size provided to the joint group create function is
an upper limit. with the current implementation it is safe to
set this to, say, 100Mb - only the memory actually required for
the joints will be allocated. as discussed previously, the problem
here is that a system dependent mmap() call is used. i guess the
max_bytes parameter is another system dependent thing that
could be set internally.

joint groups prevent excessive allocation and deallocation time for
contact joints per time step. if you have a large articulated system
then this time is small by comparison and there seems to be little
point - but if your system is mostly single bodies flying around and
hitting each other (e.g. a particle system) then this time can be
substantial, and joint groups are helpful.

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

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

and few people set quaternions from known constants.

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

> The C++ wrapper for the C interface in odecpp.h is a joke

instead of complaining about it, you should fix it and send me a
patch. to quote from a previous mail:

    the external C++ interface is a very thin wrapper on top of the C
    API. it doesn't get you any additional functionality or ease
of           use, and i don't use it myself.

bare in mind that ODE is still in the alpha stage, and as such still
has a few warts.

russ.

--
Russell Smith
http://www.q12.org