[ODE] TriMesh comments

[John Miles]

I've been bringing the TriMesh functionality up to speed in my project, and
it seems to be working great.  It went in smoothly and seems to perform
reliably with minimal tweaking.  A couple of comments/suggestions:

---------------------
1) The dGeomTriMeshGetTriangle() function is documented as returning the
triangle vertices in "objectspace."  This is incorrect; it actually applies
the geom's position and rotation to the vertices before returning them in
world space.

I'd actually prefer it to behave the way the docs say it does, since some
users may actually want the object-space vertices, and if not, they can
always apply the geom pos/rotation operation themselves.  To bring the code
into compliance with the docs, the dGeomTriMeshGetTriangle() implementation
in collision_trimesh.cpp should be modified to call the overloaded version
of FetchTriangle() that doesn't take position and rotation parameters, and
the lines that set the Position and Rotation variables should be deleted.

Looks like the same is true of dGeomTriMeshGetPoint(), although I haven't
used this function myself.

---------------------
2) I added the following function to my copy of collision_trimesh.cpp:

int dGeomTriMeshGetTriangleCount(dGeomID g)
{
   dxTriMesh* Geom = (dxTriMesh*)g;

   return Geom->Data->Mesh.GetNbTriangles();
}

Without this, there's no way for the app to tell what range of Index
parameters can be passed to dGeomTriMeshGetTriangle() without violating
encapsulation or keeping redundant polygon-count variables around.

---------------------
3) I'd argue in favor of adding Vadim's patch for CCylinder/TriMesh
collisions to the main ODE distribution (i.e., not bothering with the
/contrib directory).  It appears to work great, but it's awkward to apply by
hand due to the number of source-file changes needed.

---------------------
4) It might be a good idea to add a comment to the documentation for
dGeomTriMeshSetData() that emphasizes the fact that ODE doesn't make a copy
of the data.  This may be a little confusing to some users.

Many thanks to Pierre, Vadim, and Erwin for this cool stuff!  It adds a heck
of a lot of value to the library.

-- jm